I’m wondering if there’s a way to get a gateway timestamp in the MQTT data from the MQTT gateway. It seems like if the connection gets week, there’s a potential that a number of messages could back up and fire all at once. This means that some of the messages could potentially be stale data, and I’d like to know how to check for this.
Hi,
Most generally this will not happen. We are sending very very small amounts of data. As long as there is at least some internet connection the messages will go through. However if connection is completely lost then the sensor telemetry will be lost as there is no local logging on the gateway.
One way to combat loss of data in the case of an internet outage would be to run a local MQTT Broker host on the network which the gateway would connect to. That MQTT Broker server can then upload the data if connection is available, if internet connectivity to the remote cloud is not available it can log the information locally and then upload once internet connectivity is restored.
I have actually written a couple of articles about setting up an MQTT Broker locally and logging data to a MySQL database which you can check out here:
Hi Travis, so I’m kind of having the opposite problem. In order to test sensor range today I walked a couple of blocks away from home with a sensor and monitored the mqtt messages remotely on my phone.
Updates were about once every couple of seconds when close. Once I got far enough away, it didn’t update for 20 or 30 seconds. Then a bunch of messages came through rapidly.
So I’m not sure if this was the sensor or the QoS of the mqtt client. But either way it would be nice to have a device time stamp in the mqtt message to know if the data is stale or not. I’m ok with throwing some messages out, I just need to know that they’re recent and if I put my own time stamp on the message it’s accurate.
Hi,
That sounds like a range issue on the wireless connection between the sensor and the gateway. Unfortunately there is no real time clock on the sensor itself which would be required to overcome this sort of issue. I will however note this for future development.
Thanks. I’m ok with the range. I just want to make sure I don’t get data and have it actually be 20 or 30 seconds old. A timestamp would be great, but alternatively if there’s some way I could set this up to make sure older data gets thrown out, that would be helpful as well.
Wireless connections such as those used between the sensor and the gateway can have the tendency to buffer transmissions if the connection is weak. This means it can take several seconds for a transmission to make it’s way from the sensor to the Gateway. Currently the Gateway has no way of knowing how old a transmission is once it is received. The only way to remedy that would be to time stamp the data on the sensor itself which would require a real time clock on the sensor which we do not currently offer.
I understand the desire for this capability but currently it is not possible with our products.