Alert status light widget not updating on threshold breach in monitoring mashup

IOT PTC ThingWorx
, , , , , , , ,
1

We have a monitoring mashup with status light widgets that should change color when equipment metrics breach thresholds. The widgets are stuck on their initial state and don’t update when alerts trigger.

Each equipment Thing has a status property (STRING type) that changes from ‘normal’ to ‘warning’ or ‘critical’ based on threshold checks. I can see these property values updating correctly in the Thing’s property view. The status light widgets are bound to these status properties.

I’ve configured the widget value mapping with state definitions for each status value (normal=green, warning=yellow, critical=red). The property type compatibility should be fine since status is a STRING and the widget expects text values. Service output validation shows the status property returns valid string values.

The widgets display the correct initial color when the mashup loads, but they never update after that even when the status property changes and alerts are triggered. What’s missing in the configuration for status light widgets to react to real-time property changes?

2

The root cause involves three interconnected issues: widget value mapping configuration, property type compatibility handling, and service output validation. Here’s the comprehensive solution.

Widget Value Mapping: Status light widgets use the StateFormatting property, but the binding mechanism is specific. The widget doesn’t just compare string values - it evaluates them against state definitions at render time.

First, ensure your state definitions are properly structured in the widget’s configuration panel:

  1. Select the status light widget
  2. In the StateFormatting property, use JSON format:
[
  {"value": "normal", "color": "#00FF00", "displayString": "Normal"},
  {"value": "warning", "color": "#FFFF00", "displayString": "Warning"},
  {"value": "critical", "color": "#FF0000", "displayString": "Critical"}
]

Property Type Compatibility: The status light widget’s Data property must receive a STRING value, but the binding needs proper type handling. Create a dedicated service for each equipment Thing:

// GetEquipmentStatus service
// Output: STRING
var currentStatus = me.status; // Direct property access
return currentStatus;

Don’t return the property object itself - return the actual string value. Property objects contain metadata that can interfere with widget value matching.

Service Output Validation: The critical missing piece is the binding chain with proper refresh triggers. Here’s the complete mashup configuration:

  1. Add a Subscription widget for the equipment Thing:

    • EntityName: Your equipment Thing
    • EventName: PropertyChange
    • PropertyName: status

  2. Add the GetEquipmentStatus service to your mashup

  3. Create the binding chain:

    • Subscription widget’s EventFired output → GetEquipmentStatus service’s Execute input
    • GetEquipmentStatus service’s result output → Status light widget’s Data property

  4. Add initialization binding:

    • Mashup’s Loaded event → GetEquipmentStatus service’s Execute input

This ensures the status light updates both on initial load and whenever the property changes.

For multiple equipment items, use a more efficient pattern:

Create a GetAllEquipmentStatuses service that returns an Infotable:

var result = Resources["InfoTableFunctions"].CreateInfoTableFromDataShape({
    dataShapeName: "EquipmentStatusShape"
});
var equipment = Things["EquipmentGroup"].GetImplementingThings();
for (var i = 0; i < equipment.rows.length; i++) {
    var thing = equipment.rows[i].name;
    result.AddRow({
        equipmentId: thing,
        status: Things[thing].status
    });
}
return result;

Bind different rows to different status lights using the Infotable Filter widget or by creating individual services that extract specific rows.

Common gotcha: If your status property is updated by a subscription (from edge devices), ensure the Thing’s property has DataChangeType set to VALUE or ALWAYS. If set to NEVER, property change events won’t fire even when the value changes.

After implementing this binding chain, the status light widgets will update immediately when threshold breaches occur and status properties change. The subscription-driven approach ensures real-time updates without polling overhead.

3

Status light widgets don’t auto-refresh by default. You need to set up event subscriptions or use a timer widget to poll the status property periodically. Direct property binding without refresh mechanism won’t trigger visual updates.

4

Alternatively, if you have many status lights, use a single timer widget set to refresh every 5-10 seconds. Bind the timer’s tick event to a service that retrieves all equipment statuses at once, then bind different rows of the result Infotable to different status light widgets. More efficient than individual subscriptions for large monitoring dashboards.