I’m still having events logged as of 10 minutes ago.
It seems to have stopped for me too (uk)
Is there an alternative event logger?
I think it might have something top do with the event history. I noticed I am not seeing up to date events in device history. It is not consistent across devices and this seems to coincide with the logging issues. One of my loggers stopped on the 4th about 06:00 UK time. The other stopped on December 26th
Mine stopped working as of Jan 4th too (UK )
Looks like we’re back in action. I noticed the device history is now up to date and a quick look at one of my spreadsheets show data is being logged again.
Great ! I am seeing the same as of yesterday afternoon and still going. - One of life’s great mysteries !
My Simple Event Logger stopped working yesterday evening. I get a debug log event that it’s running but can’t find any events. I’ve deleted it and reloaded it. It will find events for 15 mins or so and then can’t find them again. Anyone else seeing this behavior?
Same here - it looks like it stopped working reliably yesterday at 17:18PM EST. Right after that I got some events logged from a few hours earlier. Since then I’ve gotten very few events logged.
I think this is due to a cloud outage on the ST aide. There have been some cloud platform issues recently causing slow responses and delayed events. I checked one of mine this morning an it’s still logging away.
The instance I have logging temperatures started to work normally again at 4:02AM EST today.
OTOH, I just noticed that the instance I have logging battery stopped as of Oct 27, 11:25AM. It did seem like SmartThings changed the way they report battery events, so that looks like it no longer works.
Of course, I have similar instances running on Hubitat for my devices there, and they never have a problem.
I haven’t seen a BATTERY status report in SEL since 23 Oct.
I just noticed the same thing, nothing logged since 10/27/2020. I don’t think I am seeing a fix for this at the current time unless I am missing something.
Hi Kevin, @krlaframboise,
I already know that this smartapp will stop working when groovy disappears and that battery events are no longer captured because they are not in the event history. The rest still works fine.
There are many of us who still use app so as not to lose the graphics that we already have made for a long time…
To avoid the loss of device event capture due to frequent delays or stops in the smatthings event history server during the month of July and possible future failures, I have modified the Simple Event Logger app to version 1.6, to set the start time of the next event capture period (startDate variable) at the time of the last event captured + 1 sec.
In this way, if the event history is stopped or delayed, the time of the last event captured will be kept as the startDate value and no events will be lost when the history is restored.
The end time of the capture period (endDate variable) remains to the current time + the time selected as the events capture frequency.
I’ve tested it and it works fine, no live logging errors and no duplicate or missing events on google sheet appears.
If you want to review and publish the modification I will send you the link or if you want I will publish it here.
Thanks for your app
Hi @Mariano_Colmenarejo , thanks a lot for this improvement!
@krlaframboise, I am are aware you have discontinued the support for the tool, but I can’t stress enough how useful this still is today. So, I guess we will keep on using until it breaks!
I got very interested in Mariano’s modification above, so I wonder if that is ok for you that I run some tests with his version? Thank you!
I’m not sure why any changes were necessary because the application already has a catch-up feature built-in which prevents it from missing events when there’s an issue preventing it from logging events.
How long it goes back is controlled by the setting “Maximum Catch-Up Interval” which is located in “Other Options”.
The maximum is currently 6 hours because if you’re logging a lot of devices it will normally time out and never catch up with values higher than that, but if you want a higher number then you could easily add additional intervals on line 298 and around line 590.
It does not recover delayed events, since there are problems of delays in the processing of events, not events missing and therefore the app reports 0 events captured in that period and correct final status, therefore it goes to the next period time and simply considers that there have been no events in that period.
With the modification, what it does now is assign the time of the last event captured as the start time of the new capture period. In this way, even if there are delays in the history, those events are not lost. They Will be captured when they appear in the history.
Here are some snapshots of what happened in July in Europe. App with “Maximum Catch-Up Interval” = 6 hours
That’s a relatively new issue so you’re right about my handler not have a built-in feature to handle that problem.
The change you made could potentially cause problems for a couple of rare scenarios and I don’t have time to review and test your version so I won’t be adding it to the SmartApp.
I’m sure there are others that are interested in the changes you made, but I’d rather not have 2 instances of the SmartApp linked to on this topic so I’d appreciate it if you could PM the code/link to any users that request it.
thank you for your code: It’s simple but very powerful. I’ve acquired a Sonoff TH16 and now I can register external temp of my home.
I write here because I have some trouble with registered data. Today is 30 december 2021: at 16:37 I read 1640878657000 in Google Sheet. I can’t understand to convert this number (I haven’t discovery any information about this format). In addition: If I connect my Google Sheet with Google Data Studio for the same number I read 30 december 2021 15:37 (there is a difference of 1 hour). Can you help me? .
Sorry and Happy New Year,
This is a typical Java time value: (Unix epoch time) * 1000 + milliseconds.
1640878657 is the epoch time (Thursday, December 30, 2021 3:37:37 PM UT) and 000 milliseconds. Things typically display it in your local timezone, taking into account if DST is active.
Did @jlv’s reply provide you enough information to solve your problem?