Changes to device states not reflected in Home Assistant

[patrickabernathy]

I've been testing version 3.0.1 and the new version 3.0.2 but both versions seem to do an initial poll but after a few minutes just stops. In the debug logs I see the initial poll request then nothing else. I've been arming and disarming my system in an attempt to get it to trigger but no response from my integrations. I've switched back to v2.2.2 and everything seems to work normally with the 30 second poll timer.

[TheWebMachine]

I just reverted my setting to 10s and noticed that the integration reload also took a fraction of the time, maybe a full second. When I set it to 900s, it took almost 30 seconds to init the integration.

[dstanchfield]

Set the polling to 900 seconds and restart HA.

So, I did this and was fairly surprised to see the door status update in ~real time as promised. I did not previously think these updated at all because of the long polling time (I have left this at 900 seconds). Is polling happening very frequently during this first 15 minute period?

So for that first 15 minute period, websocket events properly propagate their way into HA. That first polling at 15 minutes breaks the event propagation, and from there on updates in HA to device states rely solely on the polling. With websockets correctly passing events, that poll interval could really be in the hours, and events would still arrive in realtime.

I just submitted a pull request to show where is bug is.

[ghds514]

Got it, thanks.

[dstanchfield]

Yeah, no, my system did NOT like that at all. I got only about 2 real-time updates, then nothing at all in either HA OR the Android app. I stood here until my toes froze with the door open and no update at all. I'll keep testing, but I'm not getting consistency so far at all, even in the first 15 min after making the change.

Oh man, you were risking life and literally limb to test that for me, hahaha. Sorry! Really strange what you are seeing though. Websockets are definitely broken for you, and your relying purely on that 10s poll.

[TheWebMachine]

On the plus side, it woke me up! haha

I'll point out one thing that shouldn't make any difference, but I'm the A-hole if I'm wrong and don't mention it. My system was installed and is monitored by ADT. Of course, it's all just rebranded Alarmdotcom equipment using adc's cloud all the same. I have to make some system changes via alarmdotcom that are simply not exposed on ADT's site, but it all phones home the same, as best I can tell comparing my own logs to first-party customers.

[catellie]

What door sensors do you have? Perhaps they are being reported differently within alarmdotcom than mine/others that are working.

My sensor certainly look different, but I could not figure out the model/brand myself, so I've asked my installer guy now - will hopefully come back soon. For now here is a picture:

(No banana for scale, but the larger part is about 6.5cm wide while the smaller one is about 4cm) Still, I would assume we can compare the websocket data to see what is different. Here is mine:

{
    "EventDateUtc": "2024-01-24T16:14:52.896Z",
    "UnitId": 100787381,
    "DeviceId": 3,
    "EventType": 100,
    "EventValue": 0.0,
    "CorrelatedId": null,
    "QstringForExtraData": null,
    "DeviceType": 1
}

Presumably the event type 100 is the important part? A few lines down from that it appears that this is converted to two events (one for open and one for close): [I've trimmed time stamps and prefixes for readability]

WebSocket Message Type: Event
Got update for Entredörr (100787381-3) from WebSocket message with new {'state': 2, 'desiredState': 2}.
Got update for Entredörr (100787381-3) from WebSocket message with new {'state': 1, 'desiredState': 1}.

So, "Entredörr" is Swedish for "Front door", does your door also produce a double event of 2 and 1 from a 100 event type - IIRC 100 is the event for "OpenAndClose". (Looking around the trace file this sensor comes with 3 more attributes: "Malfunction", "Battery" and "Debug" - if that helps at all?)

Best / Jonas

[catellie]

@TheWebMachine apparently my sensor is a somewhat older version of this "Tyco Visonic": https://www.visonic.com/Products/Zigbee-based-detectors/zigbee-intrusion-detector/magnetic-door-window-sensor-mct-350

[elahd]

v3.0.13 contains @dstanchfield's fix. Thanks for doing the heavy lifting on this one.

I'm almost done with a complete rebuild of pyalarmdotcomajax. The new code is cleaner and addresses the structural issues that made the current version unwieldy. Current progress is in the refactor-2024 branch. Pull/push updates are working, as are commands for the device categories that I can access.

I'll put together a CLI and will post back here when it's ready for testing.

[catellie]

v3.0.13 contains @dstanchfield's fix. [...] Pull/push updates are working, as are commands for the device categories that I can access.

I installed it earlier today, and lo&behold: my door events registered correctly when I came home! (A double open+close the same second) Time will tell whether this is stable (it has worked on and off in the past), but this is really promising...

Great work guys / Jonas

[ghds514]

The whole thing is working very impressively for me since installing this latest update. Very appreciative of the work of those who have made this happen.

[Raul-7-7]

@ghds514 @catellie Hey guys, do you mind sharing your setting? What is your pull frequency? I am on the latest and it delayed by about 10 min. Cheers

[ghds514]

My polling remains at 900 seconds (Update Interval) and Websocket Reconnect Timeout is 300 seconds. The fix referred to above in 3.0.13 apparently addresses an issue with websockets and it is this that is allowing for instantaneous updates.

There is some chance that the provider you are with has a bearing on this. I was previously with ADT (which later became Telus in Canada) and this system was never so efficient, and degraded to barely-reliable and then disabled over time. Since switching to a "vanilla" alarm.com provider, it is working fantastically. It is therefore possible (or to some extent, certain in Telus' case at least) that some providers are applying layers that limit functionality of the alarm.com service.

[Raul-7-7]

Thanks @ghds514 Must be that then, I am with Telus actually! if I set it to 900, it updates every 15 min ! I changed it to 15 seconds and this is good enough for me, but not live :(
I had it on 15 before this update and so far Telus has not complained!

[ghds514]

I moved from Telus because they are forcing migration to a proprietary login:

https://github.com/pyalarmdotcom/alarmdotcom/issues/357

[pdobrien3]

door open events seem to take a while to update for me. Close events are almost instantaneous. Seems weird one is quick while the other isn't.

[Raul-7-7]

@pdobrien3 who is your provider? if you login to Alarm.com and open a window, does it update there instantly?

[sspaul1976]

This is the same for me. I have frontpoint. Alarm. Com is instant.

On Sat, Feb 10, 2024, 19:34 Raul-7-7 @.***> wrote:

@pdobrien3 https://github.com/pdobrien3 who is your provider? if you login to Alarm.com and open a window, does it update there instantly?

— Reply to this email directly, view it on GitHub https://github.com/pyalarmdotcom/alarmdotcom/issues/288#issuecomment-1937371232, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPFFBTQYI5OR5UDTXG6J4TYTAGZJAVCNFSM6AAAAAAYVUWEV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZXGM3TCMRTGI . You are receiving this because you were mentioned.Message ID: @.***>

[pdobrien3]

@pdobrien3 who is your provider? if you login to Alarm.com and open a window, does it update there instantly?

The state changes in Home Assistant seem to be consistent with changes in the alarm.com app. Maybe it is time for a service provider change.

[catellie]

FYI: My context is still looking stable (3+ days into the current release). I'd say this is now in the state I had expected Alarm.com to provide me with - assuming their local sales guy had known what he was talking about... So thumbs up for this! In reality, I can't say I really needed the door states to work for any of my automations, the movement sensor have been good enough for me, it was just annoying that it appeared to work for 24 hours and then stopped in the past.

[pdobrien3]

anyone else noticing two new states between armed_home/armed_away and disarmed? I mow seem to have arming and disarming. Through me for a loop for a hot minute as I have to: and from: defined. Wondering if this is a software or alarm.com thing

[TheWebMachine]

'Arming' and 'Disarming' are intermediate states presented by the integration when you send an arm or disarm command from the integration to ADC, as a confirmation that the command was sent and is pending. Then, once ADC processes the command, the actual state changes to Armed [Home|Away] or Disarmed, and that is picked up by the integration and shown as such.

You won't see 'Arming' or 'Disarming' statuses from the Integration if you do arm/disarm from ADC or the alarm panel directly.

[TheWebMachine]

Through me for a loop for a hot minute as I have to: and from: defined.

How long are you in 'Arming' or 'Disarming' state before you get 'undefined?' Can you show your history for the panel in HA like this (note that 'Arming' and 'Disarming' states don't show in History at all):

As you can see, I am getting 'unavailable' state every hour or so, which may also be what you are seeing. I suspect there is something timing out. I have Update Interval set to 10s and Websocket Reconnect Timeout set to 300s.

[pdobrien3]

I am seeing arming/disarming state changes in the text part of history, not the bar graph part, but they are so quick they might be there and hard to see. My arming/disarming states seem to last between 1 and 3 seconds

[ElJefeClicko]

I changed it to 15 seconds and this is good enough for me, but not live :( I had it on 15 before this update and so far Telus has not complained!

Good to know 15 seconds is working without trouble. 5 definitely got Alarm.com's attention, and I received a warning email.

[Raul-7-7]

@ElJefeClicko I am with Telus as well, I am on 900. Have you tried this:

• Have your SmartSecurity app open
• Open a Door or Window
• Does the status update in app? (try refreshing the app by pulling down the screen) see how long it takes for the app to show the door/window you opened is actually open.

[ElJefeClicko]

Unfortunately, status updates are delayed in parallel between Hass and the Alarm.com app for me. That's extra frustrating given that I overhauled my security system to this service specifically for automation, most of which is time-critical.

--- original message --- On February 14, 2024 at 12:52 PM CST @.*** wrote:

@ElJefeClicko I am with Telus as well, I am on 900. Have you tried this:

Have your SmartSecurity app open

Open a Door or Window

Does the status update in app? (try refreshing the app by pulling down the screen)

see how long it takes for the app to show the door/window you opened is actually open.

—

Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you were mentioned.Message ID: @.***> --- end of original message ---

[TheWebMachine]

I changed it to 15 seconds and this is good enough for me, but not live :( I had it on 15 before this update and so far Telus has not complained!

Good to know 15 seconds is working without trouble. 5 definitely got Alarm.com's attention, and I received a warning email.

5s also got me a warning email, but 10s has been working for me without issue or warning. 10s seems reasonable enough given it often takes up to 10s for ADC to get its act together when something changes at the panel, especially if it has been a while since something has changed (as if the websocket between panel and ADC went stale)...I've watched ADC's cloud take 8-12s to show change when a door or window is open. Arm/disarm from ADC to panel often takes north of 5s, too. Very rarely do I find the integration lagging behind ADC in these latest versions; it's usually ADC lagging behind reality.

[TheWebMachine]

Unfortunately, status updates are delayed in parallel between Hass and the Alarm.com app for me. That's extra frustrating given that I overhauled my security system to this service specifically for automation, most of which is time-critical.

I have taken to employing the following in my automations to account for this unknown delay while also allowing for a timeout. It has allowed for better flow when the panel is involved.

repeat:
  sequence:
    - delay:
        hours: 0
        minutes: 0
        seconds: 1
        milliseconds: 0
  while:
    - condition: template
      value_template: "{{ repeat.index <= 15 }}"
    - condition: state
      entity_id: alarm_control_panel.panel
      state: armed_home

Then I put a final If-then to confirm and act accordingly. The Repeat allows the script to proceed as soon as possible while still waiting and timing out if it doesn't happen in time. (repeat.index is the # of times the loop has run) Then I can send out a notification or TTS to alert of the failure.

[Raul-7-7]

@ElJefeClicko @TheWebMachine I had the same issue (app not updating) then I did a trick and it seems to be working Go to alarm.com --> Notification --> Setup a new notification rule that sends PUSH notification to your mobile device if any sensor you care about is opened.

Now when I open the window (my update is 900 seconds) it is updated in HA in about 5-10 seconds. and Close is instant. The only downside, you get extra notification! Cheers,

[catellie]

For the record: As far as I can tell, my setup still runs smoothly on v3.0.13, so from my perspective, the only remaining (and minor) issue is that I get a complaint mail from my retailer on each restart with "Alert for Sign in from New Device". I would suspect this is because it is expected that the "web browser" the Home Assistant plugin pretends to be doesn't retain the cookie between calls, and hence it regarded as a new login each time? I guess a simple mail filter would handle that, but I prefer not to do that since it might hide an actual bad player... Anyway: great work everyone!

[elahd]

A new pyalarmdotcomajax version is ready for testing. See #391 if you're able to help. Thanks!