Direct MQTT subscriptions update Rapid SCADA channels 600 and 601, but a JSON message received on /mesparam11 does not update channel 600. The JavaScript path recognizes the payload and publishes its value on /mesparam10; however, that publication is not evidence that the driver wrote a new value to channel 600.
Separate the Confirmed MQTT Paths
| Input path | Observed result | Engineering conclusion |
|---|---|---|
/mesparam1 bound to channel 600 |
Webstation value changes | The direct subscription path works. |
/mesparam2 bound to channel 601 |
Webstation value changes | The second direct subscription path works. |
/mesparam11 configured under <MqttSubJSs>
|
The script publishes the received value to /mesparam10, but channel 600 remains unchanged |
JSON reception and script execution work, but an internal channel update is not confirmed. |
Later publication on /mesparam10
|
The old value reappears | Channel 600 retained its previous value. |
Do Not Treat MQTT Republishing as a Channel Write
The tested JSON payload is:
{"Num":600,"Val":200.3,"Stat":0}The response on /mesparam10 proves that the JavaScript handler parsed or otherwise recognized the message. It does not prove that the resulting value entered the device-tag path used by the Server app and Webstation. Republishing to /mesparam1 may appear equivalent to the successful direct test, but the available evidence does not establish that changing the script destination is the intended driver architecture.
Test Device-Tag Registration Independently
A proposed diagnostic is to register /mesparam11 in MqttSubTopics and bind it to channel 602. This test checks whether the topic must appear in the driver's device-tag list before its data can reach the Server app and Webstation. Treat this as a diagnostic configuration, not a confirmed final mapping.
- Add
/mesparam11toMqttSubTopicsand bind it to channel 602. - Publish the JSON message to
/mesparam11. - Verify whether channel 602 appears and refreshes in Webstation while monitoring channels 600 and 601 for unintended changes.
- If channel 602 updates but channel 600 does not, inspect the JavaScript-processing source path to determine whether it updates a device tag, publishes MQTT only, or attempts a channel write.
Avoid Writing Back to a Device-Derived Channel
Channel 600 is already populated from a device tag through /mesparam1. A suggested configuration correction is to avoid using that device-derived channel as the JSON write target. Create a separate input channel with an empty signal field, then test whether the JSON-processing path can write to it without the device-tag refresh restoring the old value. The evidence does not confirm whether this is mandatory, so validate the result in Webstation and confirm that later MQTT cycles do not overwrite it.
FAQ
Why does Rapid SCADA parse JSON on /mesparam11 but not update channel 600?
The script recognizes the payload and publishes its value on /mesparam10, but channel 600 remains on its device-tag value. JSON parsing, MQTT publication, and an internal channel update are separate operations.
Should /mesparam11 be added to MqttSubTopics?
Add /mesparam11 to MqttSubTopics and bind it to channel 602 as a diagnostic test. If channel 602 then refreshes, the missing device-tag registration is part of the data-path problem.
Should the JSON script publish to /mesparam1 instead of /mesparam10?
The successful /mesparam1-to-channel-600 mapping makes that hypothesis plausible, but the evidence does not confirm it as the intended fix. First determine whether the script is designed to update a device tag, write a separate input channel, or only republish MQTT data.