Hacs shows disconnected after (up to) 3 hours, have to constantly "reconfigure" #187
Comments
MithUK1
changed the title
|
Can you enable debug logging for the integration and post what shows up in Home Assistant's logs? Add the following to logger:
default: warn
logs:
custom_components.alarmdotcom: debug
pyalarmdotcomajax: debug |
|
I just installed this today and experience the same problem. After turning on the above, restarting and then re-authenticting I just see this in my log file: Home Assistant appears to be happy at this stage though. 🤷 In case it matters, I'm located in Sweden and got this though the Garda reseller - which shows up as expected in the UI. The imported list of devices seems fairly reasonable, except for one device that the was just "unknown". |
|
As I dig around more I also found this in the log: and later: |
|
Just to add to this, I see the following in debug logs: There's no changes to the credentials to cause this. I tried reducing the sync frequency to see if it was a weak attempt at rate limiting, but that made no difference. Somewhat related, because the underlying library makes opportunistic attempts to re-establish login when unsupported device types are found, this doubles the number of calls to the login endpoint. |
|
Tagging @roooodcastro and @dkedinger from #207. Can anyone running into this problem help inspect web browser cookies when logged into Alarm.com? To do this in Chrome:
@cmbuckley The add-in attempts to log in so frequently because, in some instances, Alarm.com returns the same response for expired credentials and lack of permissions. There's definitely a more intelligent way to go about this, just haven't gotten around to implementing it. |
|
Here's mine:
I appreciate why there's the repeated log-in, but as you say it'd be nice to have a better way to deal with this, such as being able to restrict the device types that are checked. |
|
Mine are similar:
However, I must add that this is not just an annoyance. The integration functionality is affected too. I can arm/disarm the alarm just fine, sometimes it takes a couple of minutes, however all sensors, including the arm/disarm state sensor, have stale or simply wrong readings, due to them only updating sporadically.
Do you know what a solution for this looks like, or have you not looked into this at all yet? I could have a go at implementing it if you have a plan. |
|
Thanks. The "afg" cookie is the AJAX cookie that the integration is complaining about missing. I thought that some providers may just not use that cookie, but looks like thats not the case since you all have it. I need to do a deeper dive and, also, release code that provides more detailed errors when the cookie goes missing. It's possible that the missing cookie is just a side effect of an upstream error. @catellie The "7 is not a valid AlarmControlPanelEntityFeature" error should be fixed in the latest release. @roooodcastro My plan was to have the integration look at the response object from either the system or partition endpoints. These objects contain a list of IDs for all sensors/devices in the system. If any device category has no devices listed, the library would skip over the endpoints for those devices on every subsequent refresh. This check would be done, say, once every 5-10 minutes so that the library could pick up new devices as they're added. This would need to be implemented in pyalarmdotcomajax, not in this Home Assistant integration. |
|
@elahd just to be clear here - the integration configures and works absolutely fine for a few hours, or a couple of days even, and then sporadically gets a bad response from the login endpoint, which causes the reconfigure notification. As @roooodcastro mentioned, once that happens the sensors no longer perform their regular sync, even though the integration itself continues to work from the perspective of being able to set/unset the alarm. Your suggestion of remembering empty device responses and skipping them from subsequent requests in the underlying library sounds spot on - but it feels like there's a separate need for an improved retry mechanism around that failed log-in, which is unfortunately coupled to the device detection because of the 403 responses when there's none of that device type. |
|
@elahd : I updated earlier today, and as I got the red warning again now (hours later, but not when I upgraded) I re-authenticated and it appears to not make much of a difference: I also got some Let me know if there is more info I can provide. |
|
Thanks, @catellie. I'll release something later tonight in line with the last part of this comment to help with the multiple login attempts. |
|
@elahd Either you were super fast or my previous update didn't fully "bite", as I found another which gives a different error: I hope that's more helpful? Using |
|
@catellie Which version of Home Assistant are you using? Also, autocomplete use is in line with Home Assistant standards: https://developers.home-assistant.io/docs/data_entry_flow_index#enabling-browser-autofill. These autocomplete hints help password managers locate username, password, and OTP fields. |
|
Also, I had a fix for the "reconfigure" issue ready to go but accidentally purged the Codespace before pushing the code 🤦🏻♂️. Currently waiting on a GitHub support ticket to recover the data. |
|
@elahd I run |
|
For the record: I had reason to restart my HA and noticed that I no longer get the complaining message and even though I have not re-authenticated since the above message (5 days ago), I could still toggle a light switch that came with my alarm. So I guess something has mended? How/why is unclear, but thanks anyway! |
|
@catellie Thanks for the update. I think that some of the "extra" errors you were getting were related to your version of Home Assistant, although I'm not able to replicate them on my end in 2022.12.0. @cmbuckley I implemented a smarter device update scheme that only hits endpoints for device types that are present in a user's account. The integration is also smarter about attempting to log back in -- it'll only log back in after verifying that it has been logged out. Can you re-install from the master branch to verify that everything works? @roooodcastro? Thanks! |
|
Has anyone been able to test? |
|
Hi @elahd, sorry for the delay, I was away from home for a few days. I've re-downloaded it now from master a couple hours ago, and so far it's not prompting me to re-configure the integration anymore. I do see however some errors that I don't remember seeing before (or I might just not have noticed either): I get these for a few device types, both from devices types I don't have, and these two The sensors also don't seem to be updating, I've triggered a motion sensor, some window/door sensors, and armed/disarmed the alarm, and the integration doesn't seem to pick up any of the events. I'll update tomorrow how's it looking. Using the latest HA 2023.2.5 now too. |
|
I've updated today, but since the errors were sporadic I will give it a couple of days before reporting back with any logs. |
|
Thanks, guys. @roooodcastro Can you enable debugging for the integration (instructions)? I'd like to see the actual server response for that system data fetch error. Also, which provider are you using? |
|
Further to my previous feedback: it would appear that although I no longer
see any errors, the integration is only half working.
Even though all devices seem to be registered as such and I'm able to
toggle the power sockets from the app, very few sensor changes seem to be
reported, for example: my kitchen lights automatically turn on at sun down
and then off before bed time (this works perfectly fine as such since long
before I installed HA), but the HA logs currently claim nothing has
happened for 3+ days. Similarly, when I manually turn the alarm on it still
shows as disarmed in HA (but it's correct in the Alarm.com app).
Hence, I'm not able to automate stuff when I leave the house. :-(
Best / Jonas
Den ons 22 feb. 2023 02:38Elahd Bar-Shai ***@***.***> skrev:
… @catellie <https://github.com/catellie> Thanks for the update. I think
that some of the "extra" errors you were getting were related to your
version of Home Assistant, although I'm not able to replicate them on my
end in 2022.12.0.
@cmbuckley <https://github.com/cmbuckley> I implemented a smarter device
update scheme that only hits endpoints for device types that are present in
a user's account. The integration is also smarter about attempting to log
back in -- it'll only log back in after verifying that it has been logged
out. Can you re-install from the master branch to verify that everything
works? @roooodcastro <https://github.com/roooodcastro>? Thanks!
—
Reply to this email directly, view it on GitHub
<#187 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADZ47KKC7CHVADD3A5GGJTWYVUZNANCNFSM6AAAAAAS2GTXNE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Thanks, @catellie. With the issues you had before the update, were the sensors updating as you expected them to? Also, can you enable debug mode and share the errors? It seems like this issue is caused by some sort of intermittent connection issue or provider-specific rate limit. The debug logs should show the details. |
|
Hi again @elahd , I'm not 100% sure about the sensors stability before since it wasn't really fully working. I believe I've seen my camera sensors occasionally report motion and the mentioned kitchen lights have at least HAPPENED to show the right state. Still, I've had the debug mode on since day one (due to this issue) and scanning them I can see a couple of things (some of the them somewhat odd:
And then nothing more in the logs at all related to alarmdotcom (a fair amount about a broken ledstrip I'm aware of, though so logging certainly works in general). Does this help? The garage door issue can presumably be removed although it appears harmless, but perhaps the autocomplete exception is what causes the updates to fail? I can see the "garage_door" being imported in cover.py, but I've not decoded exactly where it fails to realize that it shouldn't bother with them... As a side: the installer of my system named devices/sensors in my local language, which includes some non-ASCII characters, but at a glance that appears to correctly handled. Best / Jonas |
Hi, I'm using Smartzone, which is an Irish provider for Alarm.com. Since my last reply, nothing has really changed in the system. I'm not getting re-prompted over and over for login anymore, but sensors are not being updated at all. Here's the full debug log of a single "update cycle": While all doors and windows are indeed closed, I know for a fact that at least one of those motion sensors are not detecting any motion, and that my alarm is armed, not disarmed, so I know that this data is not correct. Thanks |
|
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! |
|
I just released v3.0.0-beta of the integration with support for real time "push" updates and a fix for 2FA. If you don't see this version, go to HACS, click on integrations, click on Alarm.com, click on the 3 dot menu at the top right of the screen, click on redownload, and turn "show beta versions". v3 will appear shortly after turning this setting on. |
|
Hi,
Sorry, I've been a bit offline lately so didn't have an opportunity to try
this out earlier. However, I've had a quick spin now and it looks good.
Certainly no worse than before, but it appeared to react quicker. Only one
iteration so far, but I'll keep an eye on it and see whether it is also
more long term stable than it used to be.
🤞 / Jonas
…On Sat, May 20, 2023 at 11:15 PM Elahd Bar-Shai ***@***.***> wrote:
I just released v3.0.0-beta of the integration with support for real time
"push" updates and a fix for 2FA.
If you don't see this version, go to HACS, click on integrations, click on
Alarm.com, click on the 3 dot menu at the top right of the screen, click on
redownload, and turn "show beta versions". v3 will appear shortly after
turning this setting on.
—
Reply to this email directly, view it on GitHub
<#187 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADZ47KMVWU4NWGOUHV7OKLXHEX6DANCNFSM6AAAAAAS2GTXNE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Hi again, I've had it running since I mentioned it above, and status reporting is indeed very fast for a fair amount of time. Best / Jonas |
|
Thanks for testing. Can you try again with v3.0.0-beta.2? |
|
Hi again,
I still have the debug flags set from earlier issues. A quick look makes
this stack trace spring out:
```2023-05-22 22:51:51.170 ERROR (MainThread)
[custom_components.alarmdotcom.controller] Unexpected error fetching Garda
Alarm:REDACTED data:
Traceback (most recent call last):
File
"/usr/local/lib/python3.10/site-packages/pyalarmdotcomajax/__init__.py",
line 784, in _async_get_system
async with self._websession.get(
File "/usr/local/lib/python3.10/site-packages/aiohttp/client.py", line
1141, in __aenter__
self._resp = await self._coro
File "/usr/local/lib/python3.10/site-packages/aiohttp/client.py", line
643, in _request
resp.raise_for_status()
File "/usr/local/lib/python3.10/site-packages/aiohttp/client_reqrep.py",
line 1005, in raise_for_status
raise
ClientResponseError(aiohttp.client_exceptions.ClientResponseError: 403,
message='Forbidden', url=URL('
https://www.alarm.com/web/api/systems/systems/10825643')
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File
"/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line
258, in _async_refresh
self.data = await self._async_update_data()
File
"/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line
217, in _async_update_data
return await self.update_method()
File "/config/custom_components/alarmdotcom/controller.py", line 106, in
async_update
await self.api.async_update()
File
"/usr/local/lib/python3.10/site-packages/pyalarmdotcomajax/__init__.py",
line 225, in async_update
raw_devices: list[dict] = await
self._async_get_system(self._active_system_id)
File
"/usr/local/lib/python3.10/site-packages/pyalarmdotcomajax/__init__.py",
line 800, in _async_get_system
raise DataFetchFailed from err
pyalarmdotcomajax.errors.DataFetchFailed
2023-05-22 22:51:51.172 DEBUG (MainThread)
[custom_components.alarmdotcom.controller] Finished fetching Garda
Alarm:REDACTED data in 0.952 seconds (success: False)```
The above shows up about every 5ish minutes or so in my logs. For the
record (but most likely not directly related), I have occasional tracebacks
from pure_energie (my electricity meter), but they appear to recover fine.
Similarly pychromecast.socket_client seems to fail to communication on some
socket on and off (no traceback), but that is also pretty "normal" I think.
Best / Jonas
…On Sat, Feb 25, 2023 at 7:55 PM Elahd Bar-Shai ***@***.***> wrote:
Thanks, @catellie <https://github.com/catellie>. With the issues you had
*before* the update, were the sensors updating as you expected them to?
Also, can you enable debug mode
<https://github.com/pyalarmdotcom/alarmdotcom/wiki/How-to-Test-&-Debug#enable-code-debugging>
and share the errors?
It seems like this issue is caused by some sort of intermittent connection
issue or provider-specific rate limit. The debug logs should show the
details.
—
Reply to this email directly, view it on GitHub
<#187 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADZ47KIZIQMAG5TBEHAOGTWZJITJANCNFSM6AAAAAAS2GTXNE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@catellie Is this with v3.0.0-beta or v3.0.0-beta.2? |
|
The above was with the first beta. I've just applied the beta.2. So far I can see a neat looking websocket message block and no tracebacks, but I see some errors like this one: As far as I can tell this version has no serious problems that turns into tracebacks. I'll let it run and see what happens... 🤞 / Jonas |
|
Have now studied a fair number of iterations and as far as I can tell there are just two messages that are on the odd side: I assume this indicates that I DON'T have 2FA? Presumably this is not harmful? Best / Jonas |
|
Ooops, there was just a problem: |
|
That happens when the connection times out during a pull update.
Does the integration continue to work after this? If it does, this may just
be a case of having to make the failure silent when the integration fails
to connect to ADC.
The current model is that the integration does a full pull from ADC on
load, listens for push updates, and does a pull refresh every 15 minutes.
…On Mon, May 22, 2023 at 5:41 PM Jonas Petersson ***@***.***> wrote:
Ooops, there was just a problem:
2023-05-22 23:35:15.056 ERROR (MainThread) [custom_components.alarmdotcom.controller] Unexpected error fetching Garda Alarm:REDACTED data:
Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/pyalarmdotcomajax/__init__.py", line 891, in _async_get_system
return [json_rsp["data"]]
KeyError: 'data'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 258, in _async_refresh
self.data = await self._async_update_data()
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 217, in _async_update_data
return await self.update_method()
File "/config/custom_components/alarmdotcom/controller.py", line 142, in async_update
await self.api.async_update()
File "/usr/local/lib/python3.10/site-packages/pyalarmdotcomajax/__init__.py", line 243, in async_update
raw_devices: list[dict] = await self._async_get_system(self._active_system_id)
File "/usr/local/lib/python3.10/site-packages/pyalarmdotcomajax/__init__.py", line 895, in _async_get_system
raise DataFetchFailed from err
pyalarmdotcomajax.errors.DataFetchFailed
—
Reply to this email directly, view it on GitHub
<#187 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADR4HEB446TO6LZ32KSL3DXHPMPDANCNFSM6AAAAAAS2GTXNE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Yes, it still appears to work. I see one from detectors and I was also able
to arm/disarm after that happened.
/ Jonas
Den tis 23 maj 2023 00:01Elahd Bar-Shai ***@***.***> skrev:
… That happens when the connection times out during a pull update.
Does the integration continue to work after this? If it does, this may just
be a case of having to make the failure silent when the integration fails
to connect to ADC.
The current model is that the integration does a full pull from ADC on
load, listens for push updates, and does a pull refresh every 15 minutes.
On Mon, May 22, 2023 at 5:41 PM Jonas Petersson ***@***.***>
wrote:
> Ooops, there was just a problem:
>
> 2023-05-22 23:35:15.056 ERROR (MainThread)
[custom_components.alarmdotcom.controller] Unexpected error fetching Garda
Alarm:REDACTED data:
> Traceback (most recent call last):
> File
"/usr/local/lib/python3.10/site-packages/pyalarmdotcomajax/__init__.py",
line 891, in _async_get_system
> return [json_rsp["data"]]
> KeyError: 'data'
>
> The above exception was the direct cause of the following exception:
>
> Traceback (most recent call last):
> File
"/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line
258, in _async_refresh
> self.data = await self._async_update_data()
> File
"/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line
217, in _async_update_data
> return await self.update_method()
> File "/config/custom_components/alarmdotcom/controller.py", line 142, in
async_update
> await self.api.async_update()
> File
"/usr/local/lib/python3.10/site-packages/pyalarmdotcomajax/__init__.py",
line 243, in async_update
> raw_devices: list[dict] = await
self._async_get_system(self._active_system_id)
> File
"/usr/local/lib/python3.10/site-packages/pyalarmdotcomajax/__init__.py",
line 895, in _async_get_system
> raise DataFetchFailed from err
> pyalarmdotcomajax.errors.DataFetchFailed
>
> —
> Reply to this email directly, view it on GitHub
> <
#187 (comment)
>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AADR4HEB446TO6LZ32KSL3DXHPMPDANCNFSM6AAAAAAS2GTXNE
>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<#187 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADZ47LU7ZLZ6ZLREHHQFU3XHPO4BANCNFSM6AAAAAAS2GTXNE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Well, it appears to still break after some time. Here are some log snippets: and As far as I can tell, the websocket message blob looks fine (the device type is -1 though). And my energy meter still has occasional glitches. |
|
Can you try again with v3.0.1? |
|
I installed it some 30 mins ago, but it still has not succeeded to fetch anything. From the log: |
|
Hmm, downgrading appears not to help. Did you perhaps adjust something in the library, @elahd ? For the record, I'm now on: |
|
@catellie Alarm.com changed their API, so lower versions will still break for some accounts. Try downloading v3.0.2. That fixes the last error you posted, but I'm not sure of whether something new will pop up now that this is fixed. |
|
Yo, @elahd - I installed 3.0.2 late last night and it appears to work as before - for better and for worse: My log file keeps repeating blocks like this: Looking for a pattern, I see that after an initial OK handshake I started to get this about a minute after installation (on every call): Then about an hour after I left, it starts alternating between the two types of responses - not in any clear pattern, just a fair amount of one and then a fair amount of the other and so on. I can see ONE fairly clear pattern, though: Now and then there seems to be a Does this help you see the culprit? / Jonas |
|
In my mind: 403 should indicate that the request is reasonably authenticated (hence no 401) as such, BUT still tries to fetch info that is not allowed for some reason (as opposed to data that is missing -> 404). That is of course assuming the http codes are used according to my interpretation of the RFC... 🤷 |
|
Another thought about the numbers: is the |
|
So, I just left it running and 24 hours later, there has still not even been a TRY to do the I can't say I fully understand the protocol, but just looking at the results, I'd say there are two issues, that are possibly related:
Thoughts @elahd ? / Jonas |
|
My understanding of what an Alarm.com 403 response means comes from these 3 files: https://www.alarm.com/web/system/assets/addon-tree-output/@ember-data/adapter/error.js /**
A `ForbiddenError` equates to a HTTP `403 Forbidden` response status.
It is used by an adapter to signal that a request to the external API was
valid but the server is refusing to respond to it. If authorization was
provided and is valid, then the authenticated user does not have the
necessary permissions for the request.
@class ForbiddenError
@extends AdapterError
*/
var ForbiddenError = extend(AdapterError, 'The adapter operation is forbidden');
_exports.ForbiddenError = ForbiddenError;
ForbiddenError.prototype.code = 'ForbiddenError';https://www.alarm.com/web/system/assets/customer-site/services/user-activity.js // If its a 403, the server received our request but the session already timed out.
if (error.code === 403) {
return this.contextManager.handleSessionExpiration();
}https://www.alarm.com/web/system/assets/addon-tree-output/@adc/ajax/enums/AjaxResponseHttpCode.js const InvalidAntiForgeryToken = 403;
_exports.InvalidAntiForgeryToken = InvalidAntiForgeryToken;There is a retry mechanism—that's why you see two requests every 15 minutes and not one—but that doesn't seem to be working. Can you capture traffic via your browser's devtools while you log into Alarm.com? You should see a request to https://www.alarm.com/web/api/identities. Post the contents of the response, specifically {
"shouldTimeout": true,
"keepAliveUrl": "/web/KeepAlive.aspx",
"enableKeepAlive": true,
"logoutTimeoutMs": 900000,
"inactivityWarningTimeoutMs": 780000
}The integration uses the exact values pulled from this object to keep the session alive, so you probably have 780000, as well, if you're seeing the 13 minute keep alive interval. |
|
Hmm, the first one makes perfect sense and I guess the session expiration is fair - assuming this is indeed the correct time out, so it smells a lot like the AntiForgery is triggered (which I guess is what you have been saying really). I've just traced the session properties and they are indeed identical to what you listed above. |
|
@catellie Test out v3.0.4-beta.1. It uses a dedicated web session instead of sharing with other HA integrations. |
|
I installed it instantly and about 1.5 hours in it is looking 👍! |
|
@elahd it is still going strong, detecting my manual Disarm when I arrived back home today. I'd say this is already more stable than I've seen in recent months. |
|
For the record: I just upgraded to the -beta, and it did *not* register me
manually arming this morning.
Den tors 8 juni 2023 06:11Elahd Bar-Shai ***@***.***> skrev:
… @catellie <https://github.com/catellie> Test out v3.0.4-beta.1. It uses a
dedicated web session instead of sharing with other HA integrations.
—
Reply to this email directly, view it on GitHub
<#187 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADZ47LA6GTMEBWL6T3DHQLXKFGILANCNFSM6AAAAAAS2GTXNE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Which version were you running when you posted "it is still going strong" earlier? What do you see in the debug log after the system was armed? Also -- what is your polling interval set to? Did the manual arming register eventually? |
Hi, this has been an issue fo rme since i styarted using this integration quite some time ago.
I leave this hoping the next version will fix my issue but it never does.
Eseentially at some random time interval after configuring the integration it will stop communicating with alarm.com and will show as needing reconfiguration:
Until that point, my motion sensors and alarm system are seen and function correctly
For note, I can still log in to alarm.com with the same username and password (and authenticator code) as normal.
However in the activity log you can see it does a web login over and again (to scrape the sensor activity is my guess) then at 11:01 it simply stops and the integration displays as recongure.
I'm unsure of what log or where to get it to help troubleshoot this issue further, but if you let me know i'll help from my end however i can.
Thanks, M
The text was updated successfully, but these errors were encountered: