simont77 / fakegato-history

Module to emulate Elgato Eve history
MIT License
167 stars 15 forks source link

"addEntry" for past timestamps vs. internal "10 minute filler"-timer #56

Closed skrollme closed 5 years ago

skrollme commented 6 years ago

This should be more a discussion point than a real issue:

I modded a "if cellphone is pingable, person is at home"-homebridge plugin to act as a motion-sensor with EVE compatible history.

Because cellphones are not always connected to the wifi there is a 20minute period where the plugin tries to ping the phone. If it does not answer while these 20minutes, the state of the motion-sensor goes to false. At the same time a history entry is written with the timestamp of the last successful ping, which was 20min ago.

But it seems, that in the meantime fakegato's internal timer writes two filler entries with the - until now - correct values. But chronologically these two filler (with state=true) are after the manually set false-state. This results in a 20minutes long additional true-state after the cellphone last successful ping:

img_a398b5c590d3-1

Would it be best to disable the internal timer and let the plugin write it's own 10min-filler states (after a state change back till the pre-last state change) or is this something fakegato should/can handle?

simont77 commented 6 years ago

The timer is meant to simplify the addition of periodical entries, with a period less than 10 minutes, and to automatically fill exrra entries for motion and door. In your case, the best way to proceed is leaving the plugin to manage entirely the entries.

skrollme commented 6 years ago

OK, I will try to disable the internal timer and see how this works. For this kind of characteristics it does not make sense to have a (filler) value every 10minutes at all.

I will report if it works with a disabled timer.

skrollme commented 6 years ago

After a few days observation it looks like disabling the timer is the best solution in my case. The history records and displays the correct time even if it was in the past.

But I have still problems with the reliability of the history. The persistence-files for the history a correct (timestamps for statechanges) but some of these state change does not make it to the EVE.app.

The extra characteristic for "last movement detected" works as it should so the plugin's basic functionality seems to work. What would the best way to debug this? Switching to debug-logging and monitoring the log if the failure occurs?

simont77 commented 6 years ago

What is in the persisted file is exactly what is sent to Eve (the file is a direct copy of the entire history structure in memory). Maybe timestamps are out of order? I don’t know if this will cause Eve to ignore them.