Just had my first real-world test of having a LastTime timestamp added to the log (#176 in this thread). My hub burped, probably due to my internet going down. I didn’t otherwise see any status broadcast SMSs from SmartThings HQ so I assume ST servers themselves were okay and it was only my local internet connection, correct me if wrong.
For the record, my reporting (queue) interval is 10 minutes.
At 00:47 EST this a.m., I got a ST phone notification saying my hub was down, then at 00:52, another saying it was back up. (It takes 10 minutes or more to time out and give the “down” message, but the “up” message is usually pretty real-time.)
On the Google Logging side, the Time field showed a gap of 35:37 mm:ss (00:16:49 to 00:52:26). I will call the script’s Time field “FirstTime” here (the time the first data was collected for a row) to keep things separate from my LastTime field (the last time data was collected, on a row).
With the LastTime field I made in #176, I could see that the difference between the last LastTime (at 00:24:16) and first FirstTime (at 00:52:26) across the gap was 28:10 mm:ss of no data.
Due to having LastTime, I can now tell that it wasn’t a 35 minute gap that might or might not have been filled with data (it could have simply been an abnormally wide logging period). Now I know with certainty that there was a 28-minute gap in data reporting, in that 35 minute span.
I can tell from all the rest of my usual LastTime to FirstTime gaps that there are usually only a few seconds to a couple of minutes at most for one of many sensors to report something,as you might expect. This means my 28:10 gap was probably more like a 27 minute data lost gap.
I have also found that the script’s Time field sometimes gets changed based on events in the script. So while 999 times out of 1000 the Time field is FirstTime for data, like you expect, on the rare occasions when it is not the expected interval, it may in fact be due to the script having changed Time to something else. I don’t know exactly what causes this in the script, but clearly it is sometimes not the first data time - and it’s also likely to to happen right when the inter-row interval looks real screwy. So, as currently implemented, it’s not a good measurement of when data is being received… it specifically is not often right when there’s a problem (and you want it to be what it’s supposed to be).
Don’t get me wrong, I am not dissing anybody or the script. I think the script and folks here are magically wonderful! I’m just saying that the script could supply more info to troubleshoot problematic data.
My LastTime field helps with problem intervals. But what I really wish the script had was a timestamp for when a given row’s time period started and ended, period (regardless of data timing). And also the FirstTime and LastTime for data. Then it should be 100% clear what is happening relative to data reporting when weird things happen.
I tried putting this in the script, but could not get it to work. If anyone can find a way, that would be great. Like I said, I’d love 4 timestamps (Begin and End row and First and Last data). Then there will be a lot of ways to figure what happened in hindsight, if things look screwy but you only notice it well after the fact.
John, if you’re still around, I don’t care about that format issue as much as this timestamp one. Format is a cosmetic thing. But if your data is screwy and you can’t tell what happened, it’s more than a cosmetic thing.
Thanks again for this fantastic script!
P.S. In my example, you can also see how the additonal time fields can help clarify what happened, for how long, as a proxy log of your internet and power being down, too. With only the Time field, you can’t say for sure it means the time of the first (only?) data, or the time the time-out period started (or ended?). But LastTime (and the other time fields) make all this very clear.