Why my Device is not Compatible in FTT Project or FDD Configs

Why my Device is not Compatible in FTT Project or FDD Configs

Device compatibility in FTT Projects or FDD Configurations depends on whether the device contains the required data points and matches the logic defined in your Routine or Workflow. Below are the key reasons a device may appear as “No compatible devices found” and how to verify compatibility.

Why a Device is Not Compatible

Device compatibility is determined by ensuring that the device's actual data structure exactly matches the data structure required by the routine or workflow logic. If a required element is missing from the device's configuration, it will be incompatible.

Missing Required Data Points

The most common cause of incompatibility is that the device is missing one or more required data points (or "entities") needed for the routine or workflow logic to execute.

Cause - No Compatible Devices Found:

  • Problem - Your devices lack the required data points (Entities/Ontology) specified in the routine/workflow.

  • Solution - Verify that point templating is complete for the devices and that they contain all necessary points.

Failure to Meet Device Reference Requirements

When a routine or workflow logic requires one device to be referenced to another (a parent-child relationship), both the
reference itself and the required data points on both devices must be present.

  • Example: A workflow is designed to manage a VAV unit but needs to reference its associated AHU (VAV-AHU child-parent relationship).

Requirement

Description

Incompatibility

Required Relationship

The logic demands that the child device (VAV) must be referenced with its parent device (AHU).

If the VAV device is not correctly referenced to an AHU device, the VAV will be incompatible.

Required Data Points

Both the parent (AHU) and the child (VAV) must contain all the Canonical Types, Entities, and Ontology Point Fields included in the logic.

If the AHU is missing a required point, or if the VAV is missing a required point, the VAV device will be incompatible.

Mismatch in Data Point Configuration

Missing Ontology Entities

The routine/workflow defines devices by their Canonical Type and requires specific Entities (data points) to be present on the device.

  • Incompatibility: If a device is missing just one of the required Ontology Entities (e.g., if the logic requires BYPASSVALVEPRC, PLELTS, and PLETS, but the device only has the first two), the device will be deemed incompatible with the created logic.

Missing Point Fields

When you select a device type and its entities, the system views all associated point fields.

  • Incompatibility: The device must have its points fully templated to contain all these associated fields. If the device is missing the point fields associated with the chosen categories, it will be incompatible.

How to Verify Device Configuration

Before creating the routine or workflow, or to troubleshoot an incompatibility issue, you can inspect
the device's data structure:

  1. Go to the device that is missing from the FTT Project or FDD Config.

  2. Navigate to the right-side bar.

  3. Select the Report module.

  4. Click on Ontology.

  5. Check for the list of its Ontology Entities.


If the device is missing an entity that is a requirement of the routine/workflow, you must update the device's point templating to include that entity.

How to Verify Routine / Workflow Logic

When creating the logic within the Workflow Details, Logic, or Debugger sections, ensure the requirements you define are correctly matched to the capabilities of the target devices.

Check Logic Block and Point Kind Match

Every data point has a Kind (data type) such as String, Boolean, or Enum. The logic block you use must match the point's kind.

​

Point Kind (Data Type)

Required Logic Block

Incompatibility

String

String block

Using a Boolean block with a String-kind point.

Boolean

Boolean block

Using a String block with a Boolean-kind point.

  • Recommendation: If you have different devices that have the same points (e.g., a "Status" point), but some are of String kind and others are of Boolean kind, use the Enum block. The Enum block can accommodate both kinds,allowing a broader range of devices to be compatible.

Writable Block Match (For Workflows)

Workflows often contain writable blocks designed to issue commands (e.g., turning a system on/off, setting a value).

  • Requirement: For every writable block used and associated with a point, the device's corresponding point must be writable (i.e., its properties allow it to accept a command).

  • Incompatibility: If a logic block tries to write to a point that is read-only, the device will be incompatible with the logic.

Use Case: Missing Occupancy Data for FCU

scenario

You created an FDD routine called "Temperature Greater Than Set Point While Occupied". However, when you check the FDD Configs for this routine, the device FCU_208 is missing from the list of compatible devices.

Troubleshooting and Fix

Step 1: Check Required Entities in the Routine

  1. Go to FDD.

  2. Select Routines from the left navigation bar.

  3. Locate the "Temperature Greater Than Set Point While Occupied" routine.

  4. Click the 3 dots button on the right and select Edit Routine.

  5. Review the required Entities and Point Fields to see what the logic needs. (In this use case, the logic requires the Occupancy Mode data point along other points)

Step 2: Check Device Details and Ontology

  1. Go to the Devices module.

  2. Search for and select FCU_208.

  3. Click on the Reports module from the right sidebar.

  4. Select Ontology from the popup window.

  5. Check for missing Entities.


Finding: The OM entity (which corresponds to the occupancy_mode point field) is missing on FCU_208. The device knows its temperature, but it cannot tell the routine if it is currently "Occupied" or not, making it incompatible with the routine logic.

​

Step 3: Fix the Missing Point Templating

  1. On the FCU_208 device page, click the Model Device button.

  2. Search for the occupancy mode point.

  3. Add the occupancy_mode field to the point and ensure it is properly templated.



Result: The device now has the occupied_mode point field and the corresponding OM entity has been added to the device's Ontology. The FCU_208 device will now correctly appear on the FDD Config page for the "Temperature Greater Than Set Point While Occupied" routine.

    • Related Articles

    • Setting Up FDD Notifications for High and Low Room Temperature Alerts via Email and SMS

      Overview Notifications for alerts are set up through the FDD module in KODE OS. To use this module, you first need the appropriate read and write access, which can be enabled through roles. If you don’t have access, contact KODE ...

    • How to Schedule and Notify Your Team for Seasonal Device Testing?

      Overview This guide is created to show you how to perform seasonal cooling tests for a building, testing devices floor by floor while ensuring your Engineering team receives timely notifications. It will walk you through the process of setting up and ...

    • Use Cases by Role (Tenant)

      Overview Tenants want spaces that feel great, work reliably, and make costs and sustainability visible without a maze of requests and emails. Office managers and workplace teams juggle comfort concerns, after-hours events, indoor air quality ...

    • Use Cases by Industry (Healthcare)

      Overview In healthcare, every detail matters. Comfort, reliability, and compliance are not just expectations, they are requirements that directly impact patient safety and trust. Hospitals, clinics, and care facilities must maintain precise ...

    • Use Cases by Industry (Education)

      Overview Educational institutions, from K-12 schools to sprawling university campuses, face the challenge of delivering safe, comfortable, and sustainable environments for learning while managing limited budgets and staff. Campuses often include ...