Kural sorun giderme

Because rule chains manage complex data flows, you may occasionally encounter situations where rules don't behave as expected. This guide will help you diagnose and resolve the most common issues using a systematic approach.

Debugging Process

Follow these steps in order whenever you encounter an issue.

Trigger a Message

Run the rule chain in Debug mode and send test telemetry data.

Inspect Log Output

Check input/output data and error messages at each node.

Isolate the Node

Identify the problematic node, disconnect it, and test separately.

Fix & Validate

Apply the fix, re-test, and confirm the expected behavior.

Common Issues & Solutions

Review the most frequently encountered situations during rule chain development.

Message Not Entering Chain

The most common issue. Make sure the rule chain is assigned to the Device Profile. If multiple profiles exist, check each one. Also verify the Root Rule Chain is active.

Check Device Profile → Rule Chain field
Verify the rule chain is not disabled
Check for client_id conflicts on MQTT

Root Rule ChainDevice ProfileMQTT

Script Node Error

Syntax errors or undefined property access in Script nodes are the most common error source. Always connect the Failure output to a Log node.

Ensure you're accessing the correct field instead of msg.payload
Add null guards: if (msg && msg.data)
Use the script editor's test tool to isolate issues first

JavaScriptTransformationScript

Alarm Not Created

If the Create Alarm node runs but no alarm appears, the alarm severity and type may conflict with an existing open alarm on the device. The dedup mechanism prevents creating a new alarm of the same type.

Check existing open alarms in the Alarms panel
Verify your Clear Alarm node is connected correctly
Ensure Severity and Type values match

AlarmThresholdCondition

REST API Call Failing

If you're receiving 401 or 500 errors from the REST API Call node, check your authentication headers and target endpoint URL. The platform must have the necessary permissions to reach external networks.

Verify the Authorization header is in the correct format
Try increasing the timeout (default: 10 sec)
Check HTTPS certificate validation settings

REST APIWebhookHTTP

Using Debug Mode

The SolarTools rule chain editor has built-in debug tools.

Enable Debug Mode

Click the Debug toggle in the top-right corner of the rule chain editor. When active, a message counter appears on each node.

Send a Test Message

Use the "Send test message" button in the left panel to manually trigger a telemetry packet. You can simulate the flow without a real device.

Inspect Node Output

Click any node to view the full JSON content of incoming and outgoing messages. Nodes with errors are highlighted with a red border.

Always use Log nodes

Add Log nodes at critical points in your rule chain. These nodes don't add overhead in production and are the fastest way to trace message flow.

Never leave the Failure output empty

Always connect the Failure output of every Script, REST API Call, and Save Telemetry node to a Log or Create Alarm node. Otherwise, silent errors become very difficult to detect.

Performance Issues

If your rule chain runs with delays or messages are piling up, perform the following checks.

Script Optimization

Scripts with heavy loops or synchronous HTTP calls block the entire processing pool. Use async/await and move unnecessary computations outside the chain.

ScriptPerformance

Message Queue

For high-frequency telemetry, add a Throttle node. Devices sending many messages per second can fill the queue and affect other rule chains.

QueueThrottleRate Limit

Monitor Parallel Chains

If more than one active rule chain is bound to the same device, every message is processed in all chains. Disable any chains that are no longer needed.

ProfileParallelism

Troubleshooting Checklist

After resolving the issue, confirm these items before going to production.

Rule chain is assigned to the correct Device Profile
Root Rule Chain is enabled
All script nodes have been tested with no errors
Failure outputs are connected to log or alarm nodes
Alarm types and severity values are consistent
REST API credentials are current and valid
Validated in Debug mode with realistic test data
Throttle is configured for high-frequency devices

Still not resolved?

Please share the rule chain name, error message, and log output with our support team. Screenshots taken in Debug mode significantly speed up the resolution process.