I’m struggling with custom rules in the rules-engine module that aren’t triggering alerts despite threshold breaches. We’re monitoring temperature sensors on industrial equipment, and I’ve created custom rules using the Rules Editor with expressions like sensor.temperature > 85 AND sensor.duration > 300. The rule evaluation logs show the conditions are being evaluated, but no alerts are generated when both conditions are true.
Here’s my rule definition:
IF (temperature > 85 AND duration_seconds > 300)
THEN CREATE_ALERT(severity: 'CRITICAL')
The rule is assigned to the correct thing type (IndustrialPump), and I can see evaluation entries in the logs showing TRUE results. What am I missing with the custom rule syntax or rule assignment?
Check your alert action configuration. The CREATE_ALERT function needs to reference an actual alert definition ID, not just specify severity inline. Your rule syntax evaluates correctly, but the action might not be properly linked to an alert template.
This sounds like an alert action binding issue. In the Rules Editor, after defining your rule logic, you need to explicitly configure the alert action in a separate step. The CREATE_ALERT in your rule syntax is pseudocode - the actual alert generation is configured through the action binding interface. Go to your rule definition and look for the ‘Actions’ tab. You should configure an ‘Alert Action’ there with the alert template ID and severity mapping.
Let me walk through the complete solution addressing your custom rule syntax, rule assignment, and evaluation logs issue.
Custom Rule Syntax: Your rule logic is correct, but the action definition needs proper configuration. The inline CREATE_ALERT syntax isn’t valid in SAP IoT 2.4. Instead, your rule should look like:
IF (temperature > 85 AND duration_seconds > 300)
THEN TRIGGER_ACTION('alert_high_temp')
Rule Assignment to Thing Type: The rule being assigned to IndustrialPump is correct, but you need to verify the action binding. In Rules Editor:
- Navigate to your rule definition
- Go to the ‘Actions’ tab
- Create a new Alert Action with ID ‘alert_high_temp’
- Link it to an alert template (create one if needed)
- Set the severity mapping: CRITICAL
Rule Evaluation Logs: The TRUE evaluation results confirm your condition logic works. The issue is that evaluation logs and action execution logs are separate streams. Check action logs:
Logs > Alerting > Action Execution
Filter: ruleId='your_rule_id'
You’ll likely see errors about missing alert action definitions or invalid template references. Create the alert template first in the Alert Configuration section, then bind it properly in the rule action configuration. Make sure the alert template has notification channels configured (email, dashboard, etc.). After fixing the action binding, the alerts should fire within the next evaluation cycle (typically 30-60 seconds for real-time rules).
I’ve dealt with this exact scenario. The problem is usually in how the rule is bound to the thing type. When you assign a rule to a thing type in SAP IoT 2.4, you need to ensure the property names in your rule expression exactly match the property names defined in the thing type model. If your thing type has ‘temperatureValue’ but your rule uses ‘temperature’, it won’t work even though evaluation logs might show activity. Also check if the rule state is set to ACTIVE - rules can be assigned but not activated.
Good point about property names. I verified and they match exactly. The rule state shows ACTIVE in the Rules Editor. The evaluation logs specifically show ‘Rule evaluated: TRUE’ with timestamps matching when the threshold was breached. It’s like the evaluation is working but the alert generation step is failing silently.
Also verify your alert template exists and is active. I’ve seen cases where the alert action is configured but references a deleted or inactive alert template, causing silent failures. The rule evaluation logs won’t show this because they only track the condition evaluation, not the action execution. Check the action execution logs separately - they’re in a different log stream under the alerting subsystem.