Rules engine fails to map incoming device data from custom hardware-event triggers not firing as expected

IoT IBM Watson IoT
, , , , , , , ,
1

We’re experiencing issues with our custom temperature sensor hardware sending data to Watson IoT Platform. The device data is being ingested successfully (we can see it in the raw MQTT logs), but our rules engine fails to map the attributes correctly.

The problem manifests when trying to apply transformation rules - the incoming JSON payload doesn’t align with our device type schema expectations. Here’s what we’re receiving:

{
  "d": {
    "temp_celsius": 72.5,
    "unit_id": "SENSOR_A1"
  }
}

Our rules should map temp_celsius to the temperature attribute in our device schema, but it’s failing silently. The MQTT topic structure is iot-2/type/TempSensor/id/SENSOR_A1/evt/status/fmt/json which should be correct. We’ve verified the device type exists and the schema includes the temperature attribute. Has anyone dealt with attribute mapping failures in the rules engine when custom hardware doesn’t match Watson IoT’s expected format?

2

Lisa that’s a good catch on the casing. I verified and our device type registration matches the topic exactly. James, I think you’ve identified the core issue - we’re missing the explicit mapping configuration. Where exactly in Watson IoT do I define these physical-to-logical attribute mappings? Is this in the device type settings or somewhere in the rules configuration?

3

I’ve seen similar issues with custom hardware integration. First thing to check - is your device type schema actually defining the incoming attribute name or the transformed one? Watson IoT can be particular about this. Also verify your MQTT topic includes the correct event type. The rules engine won’t apply mappings if the event type in your topic doesn’t match what’s configured in your device interface.

4

Let me walk through the complete solution since this is a common integration challenge with custom hardware. The issue stems from Watson IoT’s separation of physical and logical interfaces, which requires explicit mapping configuration.

Device Type Schema Alignment: First, ensure your device type has both interfaces defined. In Watson IoT Platform dashboard, navigate to Devices > Device Types > [Your Type] > Interfaces. You need:

  1. Physical Interface - defines what the device actually sends (temp_celsius)
  2. Logical Interface - defines what your applications consume (temperature)

Attribute Mapping in Rules Engine: The mapping happens through schema composition. Create a mapping file that explicitly connects physical to logical:

{
  "temperature": "$event.d.temp_celsius",
  "deviceId": "$event.d.unit_id"
}

Apply this mapping in Device Types > Mappings section. The $event notation references the incoming MQTT payload structure.

MQTT Topic Verification: Your topic structure iot-2/type/TempSensor/id/SENSOR_A1/evt/status/fmt/json is correct. Key points:

  • Device type must match exactly (case-sensitive)
  • Event type (status) must be associated with your physical interface
  • Format must be json for schema validation to work

Validation Steps:

  1. Test the mapping with Watson IoT’s built-in simulator first
  2. Check Recent Events in the device dashboard to see if transformed data appears
  3. Enable debug logging for the rules engine to see transformation failures
  4. Verify your application interface is activated (inactive interfaces won’t process mappings)

Common gotcha: After creating mappings, you must deactivate and reactivate the application interface for changes to take effect. Also ensure your device’s firmware is publishing to the exact topic format Watson IoT expects - even minor variations will cause silent mapping failures.

Once properly configured, your rules engine will automatically transform temp_celsius to temperature for all downstream applications and analytics rules.

5

You’re on the right track. The issue is that you need to configure BOTH the physical interface and logical interface properly, then create explicit mappings between them. The schema alone doesn’t handle attribute name transformations. Check your device type configuration in the Watson IoT dashboard - you should have a mapping rule that explicitly states temp_celsius (physical) maps to temperature (logical). Without this mapping definition, the rules engine doesn’t know how to transform the incoming data structure.

6

I ran into this exact problem last quarter with our vibration sensors. The MQTT topic verification is critical too. Make sure your topic format exactly matches Watson IoT’s expectations including the device type name casing. We had issues where our device type was defined as “TempSensor” but the hardware was publishing to “tempsensor” (lowercase). Watson IoT is case-sensitive on device types in MQTT topics. Also double-check that your device is actually registered with the correct type - sometimes devices get registered with default types during initial setup and the topic structure becomes misaligned with your schema expectations.

7

Thanks Sara. I checked and our device type schema defines temperature as the target attribute. The event type in our topic is status which matches our application interface configuration. I’m wondering if there’s a mismatch between the physical interface (what the device sends) and the logical interface (what our applications expect). We might need to explicitly define the mapping between temp_celsius and temperature somewhere beyond just the schema definition.