Changes to device states not reflected in Home Assistant #288
Comments
|
Same here - is there something I can do to help to identify the issue? Thanks! |
|
Greatly appreciate everything being done for this plugin. Also experiencing this. When moving from 2.2.2 to 3.0.1, polling it seemed like everything was working correctly once I added 2FA authentication to my account. When I moved to 3.0.2, HA reported a need to reconfigure the plugin, although it appeared to continue to function correctly. Once I re-authenticated for 3.0.2, the Arming status stopped updating. Let me know if there is anything I can do to help. |
|
v3.0.3 fixes the alarm status issue. Can you try that? |
|
I believe the arm / disarm is now working again with the 3.0.3 but the feedback about locks still not working |
|
Arm/Disarm status still not updating properly for me in 3.0.3. If I manipulate from HA, it updates status. If it is armed/disarmed elsewhere, the status never updates and my automations in HA never run. Reverting back to 2.2.2 for now. |
|
I believe everything is working correctly for me in 3.0.3. It does seem that a change in arming status takes loner to be reflected in HA than before, but I do see that there is a setting in the configuration that may allow for modification of this. |
|
Ugh...forgot 2.2.2 was funky, too. I'm rolling back to 2.2.1 until v3.x is resolved. Between 3.0.3, 3.0.2, and 2.2.2, I've had 3 false alarms incidents on my system because of these status polling issues...I basically can't rely on HA at all for this at the moment or else I risk losing my alarm permit from all the false alarms. 🤦🏻♂️ 3.0.3 polls correctly for no more than 20 minutes after the integration is loaded/reloaded and if you manipulate via HA, polling works again for a while. The moment anything outside of HA happens to the system (scheduled arming, manual arming, etc), the polling completely stops until I perform an action against alarm.com via HA or reload the integration. 🤷🏻♂️ |
|
Test out v3.0.4-beta.1. WebSockets work more reliably now (on my account, at least). If you're still running into trouble, go into the integration's settings page and set a low poll time. |
|
Use v3.0.4-beta.2. There's a bug in beta.1 that ignores user-entered polling intervals. |
So far, so good. A little over an hour into updating. I have my polling set to 30 seconds (have since the option became available in v2.x) and when I externally manipulate the panel, it takes no more than 30 seconds to show up in HA, which is actually about as long as it takes ADC to send me the SMS alert, so that is what I expect. I'll keep testing throughout the day and with different intervals and report back. I'll be able to leave the house idle for a few hours while I go run some errands, which will give time for polling to start failing again if it's going to, as that's usually when I notice it stop working...and how I've accidentally set my system off a few times before forgetting we were pecking at a bug. hahaha |
|
I'm also trying the beta and so far seems to be working fine! I'm still with the feeling that the 2.x version was reflecting changes faster in the dashboard, but the way it is in the beta is totally fine. I will keep testing. Thanks! |
elahd
changed the title
|
@jprasm / @sspaul1976: Can you post details about the delays you posted about in #289? There are delays that are inherent to Alarm.com's infrastructure, so I want to confirm whether the delays that you're experiencing are expected or unexpected. Expected behavior is below. See the release notes for v3.0.3 for details regarding why this is the case.
Also, can you confirm the refresh interval that is set for the integration? |
|
Hi elahd, I only use this integration to arm and disarm my alarm system - I know that there is a delay with the various window and door sensors, and I know that's normal behaviour (the delay on door/window sensors is so long that I don't use them for any automations unfortunately). With 2.2.1 the arm/disarm of my system is nearly instantaneous! Love it. I have the update interval set at 15 seconds. |
|
Are you on the latest 3.0.4-beta2? Arm/Disarm from within HA is under 5s for me in the latest beta, regardless of polling interval. |
|
@elahd [continuing from other thead] I thought I was using the actual release (3.0.4), but as I checked my logs it looks like the restart somehow didn't work out so I expect it might be in a state of flux (downloaded, but not yet successfully restarted). A closer examination of the logs indicates that I may have jumped the gun a bit: It did indeed get into the correct state just minutes later - roughly 10 minutes after I armed away. I can see this event just before the door event: Although I'm not really sure what the state numbers mean, I'm pretty sure that So basically, it works in the end, but the websocket listener seems to have ignored the partition1 becoming armed message for some reason. BTW: I still have a fair amount of noise from the energy meter currently being blocked by my provider plus some Tapo device issue, so reading the logs is pretty messy for me. |
Arm away flow initiated: Integration changes partition status in pyalarmdotcomajax's device registry to "armed away": Integration receives state change update from pyalarmdotcomajax and changes state in HA to "arming". (Updates to a device trigger updates for all sub-entities.) Pyalarmdotcomajax sends arm away command to Alarm.com and waits for a synchronous response from the server: While waiting for a synchronous response, pyalarmdotcomajax gets an asynchronous WebSocket message indicating that the alarm has been armed. (EventType 10 = armed away): The below is the same pattern at the earlier arming change, except that we're changing the state to armed away. Your post is missing the "Updated Device..." logs, indicating that the integration never got a notice from the library. Pyalarmdotcomajax gets a (synchronous) response from the arm away request. Ignore the "async" in the "Got async update" message -- it's a synchronous update. Integration updates HA entity states: The relevant parts of the code that handle this process are (in order):
I'lll add extra tracing code to a dev release for you to test. That should highlight what the problem is. I'll follow up here when it's ready. |
|
I added trace logging to the master branch. If you install master via HACS, you'll see additional logs. Included are:
I also added version numbers for the integration and library to the message that you see when Home Assistant starts: |
* Addresses issues with state update propagation and diagnostic entity names. * Fixes for real-time notifications. * Fix bug with update interval. * bump version numbers * Fixes issue with devices reporting unavialable when integration loads. * Added tracing for #288
|
@elahd the newest I can see to download, even with beta turned on its 3.0.4, so now I'm on |
|
@elahd I've now let it run for a while and comparing logs with what I do and what I see in Home Assistant UI Logbook.
(and a very similar one with Related to your extra logs points above:
The timings here make fair sense to when things HAVE happened: For example the Also, here is the blurb: As always, let me know if you need more details / Jonas |
|
Thanks, that's really helpful. Now I need to figure out why external update callbacks wouldn't register. Registration happens when the device is added to hass, either after integration config or on boot. Can you tell me again which operating system, Python version, and Home Assistant version you have installed? You can check your Python version in the command line using |
|
I'm out and about for the evening, but basically I'm running the latest
(ish) 32bit (don't ask) docker image:
Home Assistant 2023.6.1
Frontend 20230608.0 - latest
I can give more details tomorrow.
Best / Jonas
Den lör 10 juni 2023 17:41Elahd Bar-Shai ***@***.***> skrev:
… Thanks, that's really helpful. Now I need to figure out why external
update callbacks wouldn't register. Registration happens when the device
is added to hass
<https://developers.home-assistant.io/docs/core/entity/#async_added_to_hass>,
either after integration config or on boot.
Can you tell me again which operating system, Python version, and Home
Assistant version you have installed? You can check your Python version in
the command line using python --version (if that doesn't work, python3
--version).
—
Reply to this email directly, view it on GitHub
<#288 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADZ47LYQIOAENF6WUT56EDXKSIUFANCNFSM6AAAAAAYVUWEVY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
BTW: If it wasn't obvious from my last message, I'm on It should hardly matter, but for the record the host is running 32 bit Ubuntu 18.04. |
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. |
|
Got it, thanks. |
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. |
|
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. |
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) 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] 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 |
|
@TheWebMachine apparently my sensor is a somewhat older version of this "Tyco Visonic": |
|
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. |
I installed it earlier today, and lo&behold: my door events registered correctly when I came home! (A double open+close the same second) Great work guys / Jonas |
|
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. |
|
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. |
|
Thanks @ghds514 |
|
I moved from Telus because they are forcing migration to a proprietary login: |
|
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. |
|
@pdobrien3 who is your provider? if you login to Alarm.com and open a window, does it update there instantly? |
|
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
<#288 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABPFFBTQYI5OR5UDTXG6J4TYTAGZJAVCNFSM6AAAAAAYVUWEV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZXGM3TCMRTGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
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. |
|
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! |
|
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 |
|
'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. |
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. |
|
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 |
Good to know 15 seconds is working without trouble. 5 definitely got Alarm.com's attention, and I received a warning email. |
|
@ElJefeClicko I am with Telus as well, I am on 900. Have you tried this:
|
|
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 ---
|
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. |
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.
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. |
|
@ElJefeClicko @TheWebMachine 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. |
|
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! |
|
A new pyalarmdotcomajax version is ready for testing. See #391 if you're able to help. Thanks! |
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.
The text was updated successfully, but these errors were encountered: