Thanks for looking at this.
Yes we are adding a timestamp which is from the payload timestamp which is the time of data collection. Not the time sent.
Essentially we have a python process with an async loop collecting data via Modbus from the pumps.
This is not always reliable for various reasons. (For instance the controllers can’t support more than one Modbus connection at time, and so we close/open connections a lot.)
That set of data is timestamped and logged locally.
It is async pushed via pubnub to another more mobile friendly dashboard.
This same process writes it to REDIS. (The pubnub bit will move out of the core process an into a separate process listening to REDIS in future).
A separate process is subscribed to REDIS and grabs the payload as it is received (a queue) and then send it via MQTT to Losant. The timestamp of when the data was collected is taken from the payload and added as a Losant timestamp. (This is an early version of the software) we are now using mosquitto broker locally to queue. The idea is the timestamp is local to engine and not when data is received at Losant.
If there is interference on the network then the Modbus sampling can take time and be delayed, so it is quite possible that we might see some data come in with a shorter gap. As a MODBUS query could be delayed.
I figured it might be hard for you to replicate as seemed to be very dependent on active data coming and quite possibly due to the refresh.
It was however always showing in the same time period but different anomalous values when it was incorrect.
Hope this helps