Alarm.com Device Refresh Broken about alarmdotcom

[elahd]

I'm working on a release that greatly simplifies the underlying code and incorporates instant updates for device events. It's a big lift on top of work and family life, but I'll be able to release soon. Sorry for the trouble here -- I know how annoying it is to have something like this break. FWIW, rolling back the changes in 2.2.2 will just resurface other bugs. That's why I'm leaving it as-is.

…

On Tue, Mar 28, 2023 at 2:17 PM _Mike ***@***.***> wrote: Same issue for me. Following… — Reply to this email directly, view it on GitHub <#234 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADR4HECOMNCMCOZ2UVZBLDW6MTMFANCNFSM6AAAAAAVZXJNPE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[elahd]

@Anrolosia Thanks. I heard you guys like refactoring, so the next release is going to be a more structural refactor instead of a fix for this specific bug 😬.

Currently, the integration makes one API call for every device type (contact sensor, thermostat, partition, etc.). This means that every minute or so (depending on your settings), the integration makes like 15 calls to Alarm.com. Refreshing is a heavy operation.

I recently found an endpoint on ADC's API that returns data for just about all device types in a single call. I'm going to use that single endpoint instead. This will significantly reduce complexity and the number of calls made on each refresh. I'm hoping that this will smooth out a lot of these harder to track down issues.

[pdobrien3]

@mikesalz Just bump back and be patient.

[elahd]

It's a big lift on top of work and family life, but I'll be able to release soon. Sorry for the trouble here -- I know how annoying it is to have something like this break.

Hi @elahd - First, I think I speak for everyone when I say that I am very grateful for all of the hard work you've put into this integration. I totally understand that "real life" is much more important than updating an HA integration, but just wondering if you have any kind of general ETA as far as when it might be fixed? Thanks!!

@mikesalz: Realistically, 2 weeks.

I've reworked the polling part of the library to use the single endpoint I mentioned in #234 (comment). This cuts the number of requests needed to poll by ~75%. This should speed things up a bit, and I'm hoping that this eliminates some of the errors that have caused update failures in the past. This, unfortunately, required lots of downstream changes, but it's done now.

I'm also able to connect to ADC's WebSocket API and can receive messages, but processing those messages is a pain in the ass. The identifiers used to represent device states in the WS API are different than use those used everywhere else on their platform, so I need to build an dedicated WebSocket translator for each device type. I'm going to try my luck outsourcing this work to Copilot or ChatGPT this week.

Once that's done, I'll release an update for pyalarmdotcomajax with WebSocket support for people here to test (via the pyalarmdotcomajax CLI) while I work on updating the actual Home Assistant integration.

[Anrolosia]

Hey @elahd , I also have this issue, and so HomeAssistant is not able to set the alarm anymore. If it can help you, I rolled back to version 2.2.1, and it worked again, so something included in 2.2.2 refactoring must be the culprit ^^
Thanks and good luck fixing this issue!

[Raul-7-7]

@mikesalz if you want, you can remove the Repo from HACS then it will stop reminding you and then add it back when fix is in.

[elahd]

Test out v3.0.4-beta.1.

[pdobrien3]

so yea, at 5 seconds its very responsive considering it is cloud based. arm/disarming as well as state changes were fairly immediate. going back to 15 seconds for now. also lost my smoke sensor entities which you seem to be aware of

fire_alert smoke_detected and high_heat_alarm the freeze alarm has never worked but it did not disappear

[TheWebMachine]

installed 3.0.4-beta2 and it seems positive still early with polling @ 15 seconds it was fairly responsive but inconsistent. its odd because using hass to arm/disarm was immediate at my panel but it took the actual state in hass time to update. out of 6 total arm/disarms it seemed to range anywhere from immediate once to 5-20 seconds. i bumped polling down to 5 seconds and will see how it reacts. Seems good enough for now to leave it installed though

I am reasonably sure this inconsistent delay in status change is on ADC side. I can watch their direct cloud panel and see delays of 5-25 seconds before it shows the panel state change I make locally. This also coincides perfectly with my SMS notifications from ADC. I think they just experience delays in polling on their end at random for whatever reason. As soon as ADC sees state change, HA is seeing it, if refresh interval is low enough in the integration.

After a few more hours of my house sitting completely idle while I was gone, I came back to find the integration is continuing to poll perfectly fine without glitching out. Unless I see something new in the next day or so, I'd considering the polling issue finally resolved.

Thank you to everyone for all of your work! As someone who has to deal with the willy nilly shifts of closed-source APIs all the time myself, I totally feel your pain on this one! 🤗

[Raul-7-7]

I believe this is related to the same issue here: #229

[pdobrien3]

Yea. I need to filter through 187 better. I think my error was mentioned in one post but most of that thread seemed different. Reloading the integration does seem to fix things though.

[elahd]

Well, I'm at least getting the same error on my end this time so I'll have an easier time investigating.

[Raul-7-7]

thanks @elahd
I just want to say this has NOT happened to me in the past 6 days now! if it helps :)

[Raul-7-7]

LOL this is hilarious! of course I post that and few hours later, it happened! :)

[TheWebMachine]

I also had to roll back to v2.2.1 because I started losing control of my panel via HA. It would eventually clog up the works every 6-8hrs until I reloaded the integration to get it connected again.

[Valdorama]

Just want to add another data point and note that I'm also seeing this behaviour.

[Raul-7-7]

For what is worth, the issue seem to have escalated, it is now happening to me as well every 6-8 hours. Going to roll back later as well.

[RB14060]

Also had this issue on 2.2.2 and it would lose alarm status after 4-8 hours. Rolled back to 2.2.1 with no issues.

[Raul-7-7]

Same here, rolled back to 2.2.1 and has been rock solid.

[mikesalz]

Same issue for me. Following…

[Raul-7-7]

really appreciate your work @elahd . Thank you.
I am curious what bug does 2.2.1 has? the issue for me at least, 2.2.2 makes the product not usable as every 8 hours you should restart HA. so far 2.2.1 has been working great, but perhaps other things are happening that I am not aware!

[TheWebMachine]

really appreciate your work @elahd . Thank you. I am curious what bug does 2.2.1 has? the issue for me at least, 2.2.2 makes the product not usable as every 8 hours you should restart HA. so far 2.2.1 has been working great, but perhaps other things are happening that I am not aware!

The only thing I've noticed in 2.2.1 is that sometimes it takes a bit (a minute or two) for HA to poll a change on the system. For example, my routine to turn off HVAC when a window is open (not the community blueprint; my own automation) will sometimes fire within the 30 second polling rate but other times will take 2 minutes to see the change and run the automation. I think that is what is meant by the major changes coming in the next version (polling all devices in one giant request vs individual and custom polling in the newly found API calls).

[pdobrien3]

I was still seeing errors in 2.2.1. I rolled back to 2.2.0 and both issues and errors seem to be better. I also really appreciate your work @elahd and look forward to the new version whenever it is ready.

[Raul-7-7]

Just a quick update, similar to @pdobrien3 , 2.2.1 started showing errors as well for me, rolled back further to 2.2.0 and the past 3 days have been perfect.

[mikesalz]

It's a big lift on top of work and family life, but I'll be able to release soon. Sorry for the trouble here -- I know how annoying it is to have something like this break.

Hi @elahd - First, I think I speak for everyone when I say that I am very grateful for all of the hard work you've put into this integration. I totally understand that "real life" is much more important than updating an HA integration, but just wondering if you have any kind of general ETA as far as when it might be fixed? Thanks!!

[TheWebMachine]

Just a quick update, similar to @pdobrien3 , 2.2.1 started showing errors as well for me, rolled back further to 2.2.0 and the past 3 days have been perfect.

Are you through ADT as the reporting carrier or another? Just curious if there are differences between carriers even though they are all using Alarm.com's equipment and backend. I've noticed that firmware version numbers on panels vary a little between carriers, but that might just have to do with the whitelabeling. With ADT, 2.2.1 works fine for me, spare a sometimes lengthy delay in state change reporting in HA (known issue mentioned above).

[Raul-7-7]

@mikesalz I rolled back to 2.2.0 and about a week now, zero issues.
@TheWebMachine I have ADT Canada.

[mikesalz]

I rolled back to 2.2.0 and about a week now, zero issues.

@Raul-7-7 2.2.2 never worked for me, so I rolled back to 2.2.1. It has been pretty stable. But seeing the HACS update notification is bothering the OCD in me. I'm just going to have to learn to deal with it! :)

@TheWebMachine I am also using ADT.

[RB14060]

@TheWebMachine I am NOT using ADT. Panel is an IQ Panel 2 running firmware 2.6.0.

[mikesalz]

I appreciate the suggestion @Raul-7-7. But it's not that big of a deal. I can leave it as is.

[TheWebMachine]

@mikesalz I rolled back to 2.2.0 and about a week now, zero issues. @TheWebMachine I have ADT Canada.

Interestingly enough, I just had to roll back to 2.2.0 because 2.2.1 stopped polling all together for about a day, even after fully rebooting my HA VM. I did set the poll rate to 60s to be sure I don't overload the API.

[elahd]

I've released an update to the underlying pyalarmdotcomajax library that powers this HA integration. This release fixes issues with 2FA, introduces a new method for refreshing device data, and supports real time notifications. My ability to test is limited -- it would be great if anyone here could help run some basic tests. See #265 for testing details. Thanks!

[elahd]

I'd appreciate it if anyone here could try again with v3.0.1. Any takers?

[pdobrien3]

I am installing it. What do you want me to test?

[pdobrien3]

ok, i installed 3.0.1 and after about an hour (i got busy) i tried to arm and it didnt work. it is actually arming as i can see it armed in the alarm.com app. it just isnt recognizing the state change in hass. i enabled debug mode and restarted hass. i was able to arm/disarm 2 different times. i will give it some time and try to grab the logs when it fails.

[pdobrien3]

So I just tested it. If you wait long enough Hass actually picks up the state, it just takes a while. I would say similar to the comments surrounding sensors when the initial beta of pyalarmdotcomajax was happening.

[Valdorama]

I installed 3.0.1 yesterday and so far have noticed sizeable delays in HA picking up state changes. As as example, I disarmed my alarm at 07:10. HA state history shows the state change occurring at 07:24.

[elahd]

Take a look at v3.0.3. Also, be sure to read the release notes. There was an issue with v3.0.2 and alarm panel statuses not updating, but there are also some limiting factors in the Alarm.com API that limit status updates.

[mikesalz]

Thanks for the update, @elahd! I will give 3.0.3 a try tonight. Question - I read that smoke and CO detectors will be removed because they do not work. Does this mean they never worked? Or due to new-ish changes in their API, they no longer work. Just curious. Thanks!

[mikesalz]

I installed 3.0.3. It takes MANY minutes before it registers that the system is armed or disarmed. If it’s even working at all. :(

[elahd]

If you arm/disarm from Home Assistant, does it also take a few minutes for the change to show in the Alarm.com app?

[Nealtron]

I installed 3.0.3. It takes MANY minutes before it registers that the system is armed or disarmed. If it’s even working at all. :(

Same here, 10-15 minute lag between arm/disarm and Home Assistant updating.

[mikesalz]

If you arm/disarm from Home Assistant, does it also take a few minutes for the change to show in the Alarm.com app?

Sorry, not sure. I rolled back to 2.2.1 when 3.0.3 was not working. 2.2.1 is still the most reliable version.

[Sinandgrin]

If you arm/disarm from Home Assistant, does it also take a few minutes for the change to show in the Alarm.com app?

Sorry, not sure. I rolled back to 2.2.1 when 3.0.3 was not working. 2.2.1 is still the most reliable version.

I may need to do this as well. What is the best way to achieve this on a windows run Home Assistant host? I installed this via HACS. At the moment I am on V 2.2.2. If anyone knows the best way, that would be great if you could share. I am guessing this would involve manually installing the V2.2.1 version from this github repo, just not sure how easy that is to do and if it may make more of a mess for myself. At the moment I just need to periodically reload the integration to restore control to the Alarm.com system.

[Raul-7-7]

@Sinandgrin I am on 2.2.0 and find that the most reliable one, it has been weeks and no issues, there is a small delay in picking up status (seconds) but that is totally fine for my usecase.
This link shows you how to switch to another version in HACS https://hacs.xyz/docs/faq/select_version/

[mikesalz]

This link shows you how to switch to another version in HACS

I think the built-in redownload function only displays the last 5 releases/tags. I think @Sinandgrin may need to downgrade to a slightly lower version first, and then after restart it should have the option to go further back to 2.2.1/2.2.0.

[TheWebMachine]

This link shows you how to switch to another version in HACS

I think the built-in redownload function only displays the last 5 releases/tags. I think @Sinandgrin may need to downgrade to a slightly lower version first, and then after restart it should have the option to go further back to 2.2.1/2.2.0.

Yeah, that doesn't work. Even when on 2.2.2, HACS only shows 2.2.2 thru 3.0.3 and no earlier versions. I had to manually download 2.2.1 from git and unzip it over the existing version and restart HA. It borks the version info in HACS for the time being (still shows last HACS installed ver #), but it will get you back to the earlier version.

That said, since v3.x before 3.0.3 was woefully broken, can't the version tags in HACS for 3.0.2, 3.0.1, and 3.0.0 be hidden or flagged as betas so HACS will show more versions from v2.x?

[TheWebMachine]

If you arm/disarm from Home Assistant, does it also take a few minutes for the change to show in the Alarm.com app?

Sorry, not sure. I rolled back to 2.2.1 when 3.0.3 was not working. 2.2.1 is still the most reliable version.

I may need to do this as well. What is the best way to achieve this on a windows run Home Assistant host? I installed this via HACS. At the moment I am on V 2.2.2. If anyone knows the best way, that would be great if you could share. I am guessing this would involve manually installing the V2.2.1 version from this github repo, just not sure how easy that is to do and if it may make more of a mess for myself. At the moment I just need to periodically reload the integration to restore control to the Alarm.com system.

The only side effect I found of unzipping an old version from git over the HACS-installed ver is HACS still thinks the ver it installed is there, but that should be fine once the next v3.x comes out and it will still show there is an update to be installed. HACS installed integrations are stored in config/custom_components/ and you'll just overwrite the contents of the alarmdotcom dir with the contents from the version you downloaded from git releases. Then restart HA.

Like I said, HACS will not update ver number when you do this so you'll have no GUI indication that you were successful...but I confirmed that things were working as I expect them to on v2.2.1 when I installed it manually.

[Sinandgrin]

Thanks all. I can confirm that I am only able to access the 5 most recent builds via the Redownload feature, so sounds like I may need to give the manual method a go, unless @uvjustin wants to try and flag the 3.0.x releases as Beta and see if that then allows v2.2.1 to be selected from the Redownload window.

[TheWebMachine]

Giving it a try now and will report back soon.

[TheWebMachine]

Test out v3.0.4-beta.1.

{sigh} No dice. It polled arming status updates for about 60 minutes - my panel auto-armed on its own and HA noticed. Another hour later now - 2 hours after installing 3.0.4-beta, I disarmed via ADT/ADC android app and HA still shows Armed status several minutes later.

I forgot to reenable debug logging, so I've reenabled it and will reload the integration to try again.

Edit: the moment I reload the integration it polls status and updates entities.

[elahd]

What's your polling time set to?

[elahd]

The default poll time is 15 minutes. If you're not seeing instant refreshes when the alarm is armed, either Webhooks are breaking or you're using an arm state that I'm not aware of / can't access on my account. It would be great if you could post debug data showing the Webhook responses. Dropping your poll time to ~15 seconds may solve the problem on your end.

[pdobrien3]

Is there any concern of polling too frequently with the web hooks setup?

[elahd]

Nope -- should be fine.

To be more specific, there aren't any concerns that didn't exist with the pre-websockets version of this integration.

[elahd]

Use v3.0.4-beta.2. There's a bug in beta.1 that ignores user-entered polling intervals.

[pdobrien3]

Even down to something like every second?

[pdobrien3]

Logger: custom_components.alarmdotcom.binary_sensor
Source: custom_components/alarmdotcom/binary_sensor.py:205
Integration: Alarm.com (documentation, issues)
First occurred: 4:42:12 PM (3 occurrences)
Last logged: 4:42:12 PM

Cannot determine binary sensor state. Found raw state of DeviceState.UNKNOWN.

I think this is binary_sensor.system_battery

[elahd]

Even down to something like every second?

You may kill your HA performance or get locked out by Alarm.com. I don't know for sure, though.

Cannot determine binary sensor state. Found raw state of DeviceState.UNKNOWN.

I'll fix this in a future release. That shouldn't actually impact the integration, though. How is the rest of it working?

[pdobrien3]

installed 3.0.4-beta2 and it seems positive still early with polling @ 15 seconds it was fairly responsive but inconsistent. its odd because using hass to arm/disarm was immediate at my panel but it took the actual state in hass time to update. out of 6 total arm/disarms it seemed to range anywhere from immediate once to 5-20 seconds. i bumped polling down to 5 seconds and will see how it reacts. Seems good enough for now to leave it installed though

[elahd]

That actually makes sense. The arming call takes a loooooong time... up to 30 seconds. When you arm the alarm through Home Assistant, the integration immediately changes the alarm's state to "arming". This state remains until the integration gets a state confirmation from Alarm.com. The integration gets confirmations both as a response to the synchronous arming call and as an async WebSocket message.

I'm happy to hear that this is working, though. I won't be able to get the confirmation time down any lower. If this is the only delay that you've experienced, you may be better off raising your poll time to avoid trouble.

[elahd]

As someone who has to deal with the willy nilly shifts of closed-source APIs all the time myself, I totally feel your pain on this one!

THANK YOU lol. I should add: I live in a doorman apartment building in NYC. I'm writing this code without actually owning and Alarm.com system. I have access to one but am not regularly on prem.

I'm going to close this out. I'm keeping #288 open to work out the remaining device refresh issues. Post back there if the problems return.

[mikesalz]

Oh man, I thought this was fixed. But I got this today using 3.0.4. :(

Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/config/custom_components/alarmdotcom/controller.py", line 155, in _keep_alive
return await self.api.keep_alive() # type: ignore
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/pyalarmdotcomajax/init.py", line 745, in keep_alive
await self._reload_session_context()
File "/usr/local/lib/python3.11/site-packages/pyalarmdotcomajax/init.py", line 770, in _reload_session_context
raise UnexpectedResponse(f"Failed to reload session context. Response: {json_rsp}")
pyalarmdotcomajax.exceptions.UnexpectedResponse: Failed to reload session context. Response: {'errors': [{'status': '403', 'detail': 'NotAllowed', 'code': 403}]}