twrecked / lovelace-hass-aarlo

Lovelace card for hass-aarlo integration.
75 stars 23 forks source link

Issues with modes being set #103

Closed lexiismadd closed 3 years ago

lexiismadd commented 3 years ago

Hello, I'm experiencing issues with Aarlo setting modes using the aarlo.alarm_set_mode service. The problem seems to be very intermittent, and when debugging is enabled, is less problematic. I find that often the service does not actual set the mode. The debug logs even show that its set to "armed" (or "disarmed" depending on what I am setting), but Arlo itself is not switching to that mode.

Here's an example from my hassio log when I tried to arm:

2021-06-23 12:58:45 DEBUG (ArloEventStream) [pyaarlo] sseclient-error=ChunkedEncodingError
2021-06-23 12:58:50 DEBUG (ArloEventStream) [pyaarlo] Fetching device list after ev-reconnect
2021-06-23 12:59:05 DEBUG (ArloBackgroundWorker) [pyaarlo] pinging Arlo Home
2021-06-23 12:59:07 DEBUG (ArloBackgroundWorker) [pyaarlo] set:ArloBase/4RE1737KA107B/connectionState=available
2021-06-23 12:59:07 DEBUG (ArloBackgroundWorker) [custom_components.aarlo.binary_sensor] callback:Connected Arlo Home:connectionState:available
2021-06-23 12:59:17 INFO (SyncWorker_2) [custom_components.aarlo.alarm_control_panel] alarm_set_mode service called
2021-06-23 12:59:17 DEBUG (SyncWorker_2) [custom_components.aarlo.alarm_control_panel] Arlo Home set mode to armed
2021-06-23 12:59:17 DEBUG (SyncWorker_2) [pyaarlo] no mode change needed
2021-06-23 12:59:17 INFO (SyncWorker_2) [custom_components.aarlo.alarm_control_panel] alarm_control_panel.aarlo_arlo_home setting mode to armed

However if I go to the Arlo app, its still showing as Disarmed. The same happens when I do the reverse (try to disarm when armed).

It seems to be very intermittent from what I can see too. After a reboot of HASSIO, it works the first 1-2 times ok, but then starts failing..

TheDK commented 3 years ago

Just wanted to say that I am seeing the same behaviour. The modes are being set mostly correctly bei aarlo, but not being reported back, leading to a different status in HA then in Arlo. That again leads to the next mode change not being carried out as [pyaarlo] no mode change needed .

Not quite sure why you closed this?

TheDK commented 3 years ago

@twrecked a couple of months back we discussed the possibility of regularly polling the mode state to pick-up changes that got lost? Maybe that could be a sort of fail-over mechanism for most critical stuff (current mode of a base, last recordings, etc.) - and if carried out maybe once every 10-15min shouldn't bring to much load?

lexiismadd commented 3 years ago

@twrecked a couple of months back we discussed the possibility of regularly polling the mode state to pick-up changes that got lost? Maybe that could be a sort of fail-over mechanism for most critical stuff (current mode of a base, last recordings, etc.) - and if carried out maybe once every 10-15min shouldn't bring to much load?

I've actually gone ahead and done that with a time pattern automation and adding "refresh_modes_every: 1" under aarlo in configuration.yaml. That addition to configuration.yaml causes my Arlo (in HA) to refresh its current mode every 1 minute. I then setup a sensor template for presence detection for both my partner and I. If we are both away, the sensor goes to false, but if either or both of us are home, it sets its state to true. I then set an automation to run every /1 minute to check for presence state and if its false, it sets the mode to armed. If its true, it sets to disarmed. For some reason this works. I can't say flawlessly yet because I only set it up today, but in tests it hasn't failed and has set the mode every time, depending on the presence state.

lexiismadd commented 3 years ago

In saying this, I closed this one because I posted it in the wrong github. Lol. The correct one is at https://github.com/twrecked/hass-aarlo/issues/461