Firmware update event does not trigger OTA job execution in dashboard

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

We’re running Watson IoT Platform wiot-ea and have configured OTA firmware updates for our device fleet. The devices successfully send firmware update events when they detect new firmware availability, but these events are not triggering OTA job execution in the dashboard.

Here’s the event our devices are sending:

{"event": "firmware_available", "version": "2.4.1", "deviceId": "DEV-5001"}

The events appear in the device event log, but no OTA job is created or executed. I’ve verified the OTA job mapping configuration in the dashboard, and the event filter seems to be set correctly to match firmware_available events. Device permissions show that OTA operations are enabled for this device type. What could be preventing the automatic job execution? Is there a manual trigger we’re missing?

2

The OTA dashboard in wiot-ea doesn’t automatically create jobs from device events - it requires an explicit job definition first. You need to create an OTA job template in the dashboard with your firmware version 2.4.1, then the events will trigger execution of that pre-defined job. Check if you have a job template configured for version 2.4.1.

3

Check your event filter configuration syntax carefully. In wiot-ea, the OTA job mapping requires exact JSON path matching. Your filter should specify event == "firmware_available" not just match on the event name. Also verify that the device type is included in the job template’s target devices. Sometimes the job is ready but not targeted to the right device types, so events from those devices won’t trigger execution.

4

I checked the event filter and it’s set to match event == "firmware_available" exactly. The device type DEV-SENSOR is included in the job template targets. But I noticed something in the device permissions - there’s an “OTA Execution” permission that’s separate from “OTA Operations”. Could that be the missing piece? The documentation isn’t clear about the difference between these two permission types.

5

Let me clarify the complete OTA job triggering mechanism in wiot-ea, as there are three components that must align correctly.

OTA Job Mapping Configuration: Your event filter needs to match not just the event name but also include the version field mapping. Update your job mapping configuration:

{
  "eventFilter": "event == 'firmware_available'",
  "versionMapping": "version",
  "deviceIdMapping": "deviceId"
}

The versionMapping tells the OTA system which field in your event contains the firmware version to execute. Without this, the system can’t match the event to the correct job template.

Event Filter Configuration: In wiot-ea, event filters support advanced matching. Your current filter might be too simple. Use this enhanced filter:


event == "firmware_available" AND version EXISTS AND deviceId EXISTS

This ensures all required fields are present before attempting job execution.

Device Permissions: You need both permissions enabled at the device type level:

  • OTA Operations: Allows devices to receive firmware update commands
  • OTA Execution: Allows device events to trigger automatic job execution

The key distinction: OTA Operations is for passive updates (platform-initiated), while OTA Execution is for active updates (device-initiated). Enable both in Device Type Settings → Permissions → Firmware Management.

Additionally, there’s a manual refresh workaround if you need immediate execution: After the device event arrives, go to the OTA dashboard, select your job template, and click “Refresh Targets”. This forces the system to re-evaluate which devices should receive the update based on recent events. This is useful for debugging but shouldn’t be necessary once the automatic triggering is configured correctly.

After enabling OTA Execution permission and updating your event filter with version mapping, restart the OTA service (Dashboard → Services → OTA Manager → Restart). Then send a new firmware_available event from your device and monitor the job execution logs for successful triggering.