this is very odd and I noticed just recently while debugging.
One device gets a correct disconnection message:
But then it never gets updated as disconnected in the device UI:
I refreshed the page a thousand times but it still shows connected.
and even more oddly I get all the notifications and alerts
Take a look at the timestamps in your application log message. Your “Connected Since” time is actually later than your “Disconnected At” time, and we are using the most recent value we have (including up to 24 hours in the future) for a set-via-REST connection status on the device object.
Now, any connection or disconnection requests that pass our validation should still appear in your live log and device connection log, and they would still trigger your workflows, but we use the value with the most recent timestamp as the source of truth when it comes to the device itself.
Interesting that is still odd, since I am setting the status via API as you mentioned how the Connected Since is calculated? Should that attribute not be automatically set to just before the Disconnected timestamp?
Sorry, but I’m not following what you’re saying here. Can you try and rephrase and/or attach the workflow that is setting the connection status?
Yes my suggestion would be what about in the UI showing a status “Disconnected since” (when a disconnect event is pushed) otherwise it’s almost impossible to know the current status.
So are you suggesting that, instead of us using the the connection status with the most recent timestamp to determine a device’s connection status, we instead use the most recently received connection event, even if it was in the past?
I peeked in your account trying to figure out what is going on here and I see that you are setting the connection status based on a call out to a third-party API. Not knowing what’s happening in that other service, all I can say is that it is possible that that could be the cause of the confusion, if they previously provided a connection timestamp and then provided a disconnection timestamp that predated the last connection. On the Losant side, we chose to go with the most recent timestamp (not the most recently received event) as what we would use to determine a device’s connection status.
yes sounds like I have a very specific use case.
The way I poll the device status via API from TTN is a poll mode, so I schedule a workflow to run every 10 minutes.
I iterate all through the devices and then check which ones are connected or disconnected.
The API call is quite simple:
So to your point to make an example sequence:
- I poll the devices status via API to TTN at 10:15 am (every 15 minutes for example)
- One device will be disconnected at 10:05 am
- This means that the disconnection happened in the past 10 minutes
- I poll then again at 10:30 am
- The same device show to be disconnected at 10:05 am
- This means that the disconnection happened in the past 25 minutes
Note that there is no specific API call from their service or my code to set the connection status.
Potentially this can go for days or weeks until somebody reconnect the device.