Logging improvements: Sensor changes about homebridge-node-alarm-dot-com HOT 9 OPEN

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.

from homebridge-node-alarm-dot-com.

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!

from homebridge-node-alarm-dot-com.

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!

from homebridge-node-alarm-dot-com.

Looks good here, kinda.

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

from homebridge-node-alarm-dot-com.

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.

from homebridge-node-alarm-dot-com.

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.

from homebridge-node-alarm-dot-com.

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.

from homebridge-node-alarm-dot-com.

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)

from homebridge-node-alarm-dot-com.

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 node-alarm-dot-com/node-alarm-dot-com#27

from homebridge-node-alarm-dot-com.