node-alarm-dot-com / homebridge-node-alarm-dot-com

Alarm.com plugin for Homebridge using Node.js
MIT License
58 stars 23 forks source link

Logging improvements: Sensor changes #114

Open tbaur opened 1 year ago

tbaur commented 1 year ago

A specific log level that only logs changes to sensors (and not API login re log level 3).

Examples -- motion activated/deactivated, door opened/closed, window opened/closed etc. and so on.

While it's in the alarm.com app/web UI, this would be very helpful.

chase9 commented 1 year ago

I'm thinking it would be best to just move the login call to the debug level. Thinking about it, it seems like it's not useful to know unless you're debugging something.

tbaur commented 1 year ago

Ah, that could make sense. I also noticed that even when on log level 3, not all changes to sensor state seemed to log. I admittedly didn't do much testing because of all the API login messages ...saw one log msg for a change in sensor state, but then went to open/close a door, no log... but with all the API login messages, I just disabled it. I'm guessing now that I didn't wait long enough for the login poll, to see the change and write the log. IF all changes to sensor state do log at log level 3 and API login is moved to debug, then we're probably good!

chase9 commented 10 months ago

I just pushed a commit to the beta branch which moves some spammy calls to debug. Hope you can use log level 3 without being annoyed now!

tbaur commented 9 months ago

Looks good here, kinda.

Some sensor updates are being logged, but some are not. Haven't seen a pattern yet, will test some more.

tbaur commented 9 months ago

Can confirm, a few select sensors do log properly (a motion, patio door that has a contact sensor) and others do not log anything ...ex standard door and window sensors. Unclear why. They all report correctly in the alarm.com app event log.

tbaur commented 9 months ago

Bit more info. It seems that if a sensor goes state=1 and then state=0, ex a door opened and closed, it will not get logged.

If a sensor goes state=1 and stays that way for some period of time, it will eventually get logged. So, someone opening a door to walk through it and then the door closes, no logs. Open and close a window, no logs.

These state changes do show up properly in the alarm.com event log, per above. Unclear why we have no logs here.

chase9 commented 9 months ago

I'll check this out and see which sensors are missing logging in the code.

The issue of missed state changes has to do with limitations of this being a cloud polling plugin. If you both open and close a door within the time your plugin is not checking the cloud status, the plugin will just see that the door has kept the same state. The only way to fix this would be to lower the refresh rate super low (which I do not recommend!) or for us to implement web sockets.

tbaur commented 9 months ago

Gotcha. Is there a way to request state changes vs current state, when you poll, to get more info? They have the data as it shows up in the app event history. Maybe no way to get it via their API?

(...think the sensors are all logging, but the above issue means the events don't all show up, making it seem they aren't logging)

chase9 commented 8 months ago

So we are able to pull sensor history, but there is no way to inject history into Homekit. I think the way to acomplish what you're asking for would be to lower the polling time (something you can try yourself already) or implement websocket polling as mentioned in https://github.com/node-alarm-dot-com/node-alarm-dot-com/issues/27