Hi every body.
I'm using an EDGE Panel to send TAGs values to a Central Ignition Gateway via MQTT.
And I have noticed a strange behavior where value changes are lost during a loss of MQTT communication.
The EDGE Panel is reading data via Modbus at 1min scan rate, when the MQTT communication between the EDGE and the broker (in the central Ignition) is lost, if there is any change in the value of a TAG during the communication outage, this It is not updated in the Ignition Central when the communication is reestablished but the history is reestablished correctly, leaving the current value with the value not updated but the historical chart correctly.
Check your timeout settings on MQTT. The shorter these timeouts are, the less dataloss you'll have, but at the risk of timing out more often than what you want. Are you using a primary host ID on both Transmitter and Engine to properly detect all comm losses?
Hi Michael, thanks for the answer.
I'm usin 5s Keep Alive and 1s reconnect dalay in my TO settings, Am I missing something else?
Yes, I'm using a primary host ID in both modules, and is detecting de comm loss. In fact, when the comm is up again the historical data is forwarded correctly.
Only the TAG value change that occurs in the EDGE while the communication is down is lost.
This is very worrying, since if, for example, a setpoint change occurs in the PLC during the MQTT communication drop, that value is never updated in the Ignition Central until that setpoint is changed again (perhaps in days).
What version of the transmitter are you using. It looks like in the release notes there's been some fixes in v4.0.19 and some in a later version also that could cause this issue depending on configuration.
Fixed cache update code that could result in BIRTH messages not publishing the most recent/valid value
@Matrix_Engineering I don't think their store/forward would work at all if that wasn't selected. I think their main issue is that the live value isn't coming in once comms are re-established.
Your tag pacing is set to 60000 also? I think your next step would be to reach out to CirrusLink support and see what they can do to help figure this out...or if you've discovered a bug.
Yeah, reach out to CirrusLink then. So you're only polling Modbus at 60sec but the pacing period means it should push that value change no longer than 1 second after it changes.
