Hi,
Just wanting to know if there is a way to access the timestamp from the last received data point of any kind within the GPS block. I want to be able to present this in the Popup window as an alternative to the {{time}} variable which is the time of the last reported location. I know I can access attributes themselves by means of {{data.}}, but there doesn’t seem to be a way to access the timestamps associated with any variables other than location.
This would be a preference for the current use of our maps to provide insight into fleet performance - as not all the devices have GPS reporting (hence the location timestamp is not indicative of whether or not a device is performing correctly). For the use case, we would simply require the timestamp to update when any data update is provided from the device, so the block is used simply to indicate the install position and last reported time.
Thank you in advanced for any help with this matter.
Kind regards,
Ben
PiP IoT
Hi @Ben_Sinclair,
The current architecture of Losant dashboards will require the value you intend to display to be available as device state.
The GPS History block can currently only access the associated timestamps for the selected GPS attribute. The {{data}} object that is accessible within the block exclusively contains the data points for any non-GPS attribute you’ve selected and, unfortunately, does not include the timestamp.
There are a couple of solution options to this would be to make this timestamp accessible. Regardless of how you implement for your use case, this timestamp will need to be reported at the same time (and within the same device) as the GPS value. This gives you three options: storing the last state timestamp as a new attribute on your current device; creating a system device; or creating a new standalone “metadata” device that stores both values. This choice will depend on your use case, but the GPS attribute value would need to be reported within the same state and device as the timestamp attribute value.
Please let me know if these implementations would suffice, or if you have any further questions!
Thanks,
Julia
Hi Julia,
Thanks for the prompt response.
I thought this may be the case, I’ll have to make a considered approach as we have devices which both do and don’t have GPS reporting built-in - so I’ll need to make a solution which subsequently allows me to see GPS update timestamp and last received timeframe.
Out of interest has there been any backlogged update for allowing individual attribute timestamps accessible through the handlebars? This would be an improvement for cases like this where not all data types are updated at the same rate. We have devices that can send up to 5 different data types, so being able to display timestamps associated with low-frequency data such as battery voltage would be an advantage (but I am digressing).
Thank you for your insight - I’ll know where to start now (please close my ticket).
Kind regards,
Ben
PiP IoT
1 Like
Hi @Ben_Sinclair,
There has not been an update to this Feature Request. However, a metadata device would continue to be my recommendation. I did neglect to mention, you also have the option of accomplishing your task using the Custom HTML Block and System devices together.
You are looking to store 4 values: a GPS point and it’s associated timestamp as well as a value of some kind and it’s associated timestamp.
The System device will allow you to store three of these values, keeping only one of the timestamps depending on if you choose to update this device only when new data is reported or on an interval. On the interval, your timestamp will be the time that state was reported to the system device, which will overwrite the GPS value timestamp.
However, if you choose to create a System Device for all of your variables besides the GPS values, you could use the Custom HTML Block with two queries. One to the system device and one to get the GPS value. You could then use Javascript and HTML and the Google Maps API to achieve this functionality.
Unfortunately, this might be equal effort in comparison to creating a metadata device that stores all of these values together (and includes a workflow for the logic of “most recent” state).
I will close this ticket, but these were just a couple of implementation paths I considered.
I will keep you updated on the status of this feature request.
Thanks!
Julia