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.

[elahd]

@catellie Good to hear!

@mikesalz Fixed that error. Try installing from master again.

[catellie]

@elahd still going strong here, but I noticed a different problem, that probably is more generic to the app: I'm afraid the locale is Swedish, but you should still be able to tell that log entries are duplicated. This seems to happen if I leave with this screen open and the come back a while later. I would suspect the content is refreshed, but without clearing the previous data. Do you know where to report this (I expect you would need to clarify this isn't an integration issue too...)

Just to be clear: if I use the top left "x" to close the view and the reopen it, all is good again.

Side note: you can here easily also see the mentioned minor issue with open/close time stamps being identical.

[elahd]

Thanks, @catellie. Both behaviors are weird, but I understand what's causing them:

1. Doors opening/closing at the same time: This is a weird behavior with Alarm.com's API. Doors have 3 states: opened, closed, and opened/closed. At times, the alarm control panel won't report a door open event. Instead, it'll wait for the door to close and will report a single open/closed event. When the integration receives an open/closed event, it reports separate opened and closed states so that the appropriate automations can be triggered. I can change this behavior as it's not ideal, but I'm not sure of what a better approach would be.
2. Duplicate state reports: Some states are reported twice through the WebSocket API, once as a state change and once as an event. I process both just in case one fails to come in. This is a guess, but Home Assistant may consolidate duplicate events on a delay, which is why you're not seeing dupes when you reopen the window. I can try to address this via the integration, but it'll be lower priority.

[catellie]

@elahd Thanks for the explanation! On subject 1 I totally agree - if they are are reported as a single open+close even it make perfect sense to split them with with identical time stamps (sure, IF we knew the time limit for being reported as a single event, we could make an educated guess and subtract half of that to guesstimate it, but that's still just a guess). On subject 2 I should probably offer some further translation: "För X timmar sedan" is "X hours ago" - so pushing the boundaries I might accept the top 4 being mishandled as duplicate events, but the next batch being 15 hours old and still not properly processed, I sort of doubt that (and I'm pretty sure it was more like <2 hours since I looked the previous time). I can't say I'm 100% sure about this, but I think I've only seen this in the app, never on the web, so I'm tempted chalk that up as an app bug (lifecycle handling can be a pain - the app, at least on Android, has obvious issues when closing "dialogs" - causing the list that reappears to scroll up, often to the top compared to where it was when it opened - and it isn't even consistent). Perhaps I should look deeper into the app code? I get the feeling it is a "hybrid" app: some of the UI is native while a fair amount is a webview - as an Android dev myself my fingers are somewhat "allergic" to the webview feelings that almost behave correctly (since it is Material Design after all), but not quite... One obvious example is that the side menu USED to open when you slide your finger from the left edge, but recent releases now require you to click the hamburger icon :angry:

[catellie]

@elahd Well, it worked for a long time, but in the end it ran into this:

2023-06-19 05:54:24.920 DEBUG (MainThread) [pyalarmdotcomajax.websockets.client] Websocket WebSocketState.DISCONNECTED
2023-06-19 05:54:27.204 DEBUG (MainThread) [pyalarmdotcomajax] Sending keep alive signal. Time until session context refresh: \
imminent
2023-06-19 05:54:27.649 DEBUG (MainThread) [pyalarmdotcomajax] Reloading session context.

I could see no events after that so I've now installed the latest master...

[lbreggi]

Hi @elahd - I can confirm that this works on the background (like when I press the disarm or unlock for the door) but the dashboard continue to do not get updated until it reaches the pre configured refresh time. The behavior on 2.x version was actually real time (at least for me). Is there a way I can help to improve the new build to get similar behavior to 2.x version? Many thanks for your hard work! Really appreciated!

[catellie]

@elahd Looks like this is the error of the day:

2023-06-19 19:21:56.347 ERROR (MainThread) [pyalarmdotcomajax] Server returned wrong content type. Response: <ClientResponse(https://www.alarm.com/web/api/troubleConditions/troubleConditions?forceRefresh=false) [503 Service Unavailable]>
<CIMultiDictProxy('Content-Type': 'text/html', 'Server': 'Microsoft-IIS/10.0', 'P3P': 'policyref="/w3c/p3p.xml",CP="OUR SAMa ADM UNI BUS ALL CUR DSP TAI COR IND STA"', 'Access-Control-Allow-Origin': '*', 'X-Content-Type-Options': 'nosniff', 'Strict-Transport-Security': 'max-age=31536000; includeSubDomai\
ns', 'X-UA-Compatible': 'IE=edge', 'Date': 'Mon, 19 Jun 2023 17:21:55 GMT', 'Content-Length': '27')>

Response Text:

<coroutine object ClientResponse.text at 0xa7b7cdc0>

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/pyalarmdotcomajax/__init__.py", line 1138, in _async_get_trouble_conditions
    json_rsp = await resp.json()
               ^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/aiohttp_client.py", line 73, in json
    return await super().json(*args, loads=loads, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/aiohttp/client_reqrep.py", line 1104, in json
    raise ContentTypeError(
aiohttp.client_exceptions.ContentTypeError: 0, message='Attempt to decode JSON with unexpected mimetype: text/html', url=URL('https://www.alarm.com/web/api/troubleConditions/troubleConditions?forceRefresh=false')
2023-06-19 19:21:56.370 WARNING (MainThread) [py.warnings] /usr/local/lib/python3.11/site-packages/pyalarmdotcomajax/__init__.py:1162: RuntimeWarning: coroutine 'ClientResponse.text' was never awaited
  log.exception(

2023-06-19 19:21:56.399 ERROR (MainThread) [custom_components.alarmdotcom.controller] Failed to refresh data due to unexpected error.
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/pyalarmdotcomajax/__init__.py", line 1138, in _async_get_trouble_conditions
    json_rsp = await resp.json()
               ^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/aiohttp_client.py", line 73, in json
    return await super().json(*args, loads=loads, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/aiohttp/client_reqrep.py", line 1104, in json
    raise ContentTypeError(
aiohttp.client_exceptions.ContentTypeError: 0, message='Attempt to decode JSON with unexpected mimetype: text/html', url=URL('https://www.alarm.com/web/api/troubleConditions/troubleConditions?forceRefresh=false')

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/config/custom_components/alarmdotcom/controller.py", line 171, in async_update
    await self.api.async_update()
  File "/usr/local/lib/python3.11/site-packages/pyalarmdotcomajax/__init__.py", line 243, in async_update
    await self._async_get_trouble_conditions()
  File "/usr/local/lib/python3.11/site-packages/pyalarmdotcomajax/__init__.py", line 1167, in _async_get_trouble_conditions
    raise UnexpectedResponse from err
pyalarmdotcomajax.exceptions.UnexpectedResponse

I'm a bit sad to see the coroutine but since I generally think they are a great concept, but clearly that can fail too... :-( [At a glance: I think their server failed utterly and we need to figure out a way to gracefully handle that... :shrug: ]

[catellie]

@elahd presumably you are already aware that there is an argument count mismatch at the moment, effectively making the integration unable to listen to anything? Since the official app was recently upgraded I expect they tweaked their API again...

[elahd]

Yep I'm aware. The larger issue with the codebase right now is that there are multiple independent functions that make calls to the Alarm.com API. This was fine on older versions of the integration—when it had fewer features—but in its current state, it's not conducive to consistently handling failures with user sessions or connectivity. I'm working on a refactor that directs all API requests through a single API handler that is also responsible for recovering from connection issues.

[ifuchs]

I am looking at switching to Alarm.com from HAI. Is this integration intended to provide HA with the status of all devices that Alarm.com knows about (e.g., all doors, windows, and other sensors)? Given the closed nature of Alarm.com, is this even possible by web scraping their site?

[catellie]

@ifuchs I guess the answer is "mostly". On a good day I get status on all my devices pretty much instantly, but since it is more or less clever "scraping" it will often fall over after a day or so. Typically some stuff then keep working, only slower since the quicker "listeners" no longer work and instead the polling does some of the job. A minor thing is also that on each restart you will get a warning mail from your local reseller that a new "device" was added. There has been pretty good progress lately so I would expect better stability after the current refactor.

[ifuchs]

@catellie If only Alarm.com would offer some sort of API...if only :-)

[catellie]

@ifuchs Well, they sort of have an integration, but it is not particularly useful: You can hook it into Google Home and ask whether it is armed or not - so technically it exists (this is what I specifically asked for when I got mine), but nothing particularly useful has happened. [Disclaimer: I tried it long ago, but have not verified lately.]

Edit: apparently it just died: https://answers.alarm.com/Customer/Website_and_App/Home_Automation/Google_Home

[pdobrien3]

not to stack on @elahd , but a heads up, this is coming down the pipes:

Entity None (<class 'custom_components.alarmdotcom.alarm_control_panel.AlarmControlPanel'>) is implicitly using device name by not setting its name. Instead, the name should be set to None, please report it to the custom integration author.

just came up on todays beta.

[Raul-7-7]

I am going to setup a test instance of HA and do some testing, my issue is, I rely heavily on this integration and since Version 2.2.0 is running flawlessly for months, I can not upgrade on my main machine.

I got to say, @elahd you made 2.2.0 so perfect that it is hard to upgrade! Thank you! Cheers,

[bringel]

Following along because I don't see any websocket messages when I enable the debug logs and I'm not sure what I need to do to make them show. I am on 3.0.4

[catellie]

@bringel last I checked that was only on master which I believe is currently still in a state of refactoring. Stay tuned for a message from @elahd when it is in shape for testing again... (Unless you feel like hacking some python!)

[pdobrien3]

Anyone else willing to update to the latest beta and check their devices? I feel like 2023.8 is going to pretty much break everyone's alarm.com instance. Also a little concerned with no comments from @elahd (maybe i am missing comments elsewhere though)

[elahd]

Hey sorry -- had to step away for a bit. I'll take a look now about releasing quick updates to the 2.x and 3.x releases to fix compatibility with 2023.8, then I'll get back to refactoring.

[pdobrien3]

Thank you very much.

[lbreggi]

I’m in! I can try on my side!

Sent from my iPhone

On Jul 27, 2023, at 06:18, pdobrien3 @.***> wrote:



Anyone else willing to update to the latest beta and check their devices? I feel like 2023.8 is going to pretty much break everyone's alarm.com instance. Also a little concerned with no comments from @elahdhttps://github.com/elahd (maybe i am missing comments elsewhere though)

— Reply to this email directly, view it on GitHubhttps://github.com/pyalarmdotcom/alarmdotcom/issues/288#issuecomment-1653414540, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGEJQ7WFOH6GPU6HVQZXKATXSJFBTANCNFSM6AAAAAAYVUWEVY. You are receiving this because you commented.Message ID: @.***>

[pdobrien3]

@lbreggi , you can either update to V2.2.3 or V3.0.5, both seem stable and neither version exhibits the traits i was originally asking about above. They were fixed by elahd. V3.0.5 may cause you to lose some devices, specifically smoke detectors i believe. There is also some other errors that will pop up in V3.0.5 but they dont affect the operation.

anyone know why in V2.2.5 my smoke detectors entity_id changed from binary_sensor.smoke_detector to binary_sensor.smoke_detector_smoke_detector. Also, some friendly names show as front door front door instead of just front door.

[lbreggi]

Thanks for the heads up! I know that some chats were running about the changes on the 3.x version. Here is a summary of the tests I’ve made:

• upgraded to 3.0.5 - everything works same as before - it works with delays to get states reflected in dashboard (15 to 20 secs). Very stable
• moved from 3.0.5 to 2.2.3 - have some stability issues (had to restart the integration a couple of times because it stopped to respond) - but changes were real time into the dashboard.

I ended moving back to 3.0.5 because it is way more stable, but would love to get the real time updates again in the dashboard.

Let me know if there is something I can share to help!

Thanks!

Leo

Sent from my iPad

On Jul 29, 2023, at 08:25, pdobrien3 @.***> wrote:



@lbreggihttps://github.com/lbreggi , you can either update to V2.2.3 or V3.0.5, both seem stable and neither version exhibits the traits i was originally asking about above. They were fixed by elahd. V3.0.5 may cause you to lose some devices, specifically smoke detectors i believe. There is also some other errors that will pop up in V3.0.5 but they dont affect the operation.

anyone know why in V2.2.5 my smoke detectors entity_id changed from binary_sensor.smoke_detector to binary_sensor.smoke_detector_smoke_detector

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

[Raul-7-7]

Hi, I been using 3.0.5 for the past month, as suggested by @lbreggi it is super stable but takes a while to update, what I notice the update seems to be much slower on CLOSE as oppose to open, for example, when I open the window, the status is updated in about 5 seconds, however, when I close the same windows, takes up to 3 min (sometimes 5 min) for it to reflect the change. @elahd thanks again and let me know if I can help with testing. Cheers,

[sspaul1976]

This is interesting. My experience is the opposite of this. Up to 30 seconds to recognize Open, but Close is usually around 5. The arm/disarm though is within 2-3 seconds, so that's fairly responsive.

On Thu, Aug 31, 2023, 18:45 Raul-7-7 @.***> wrote:

Hi, I been using 3.0.5 for the past month, as suggested by @lbreggi https://github.com/lbreggi it is super stable but takes a while to update, what I notice the update seems to be much slower on CLOSE as oppose to open, for example, when I open the window, the status is updated in about 5 seconds, however, when I close the same windows, takes up to 3 min (sometimes 5 min) for it to reflect the change. @elahd https://github.com/elahd thanks again and let me know if I can help with testing. Cheers,

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

[pdobrien3]

has anyone else started to notice the alarm.com integration doing things on it own? i just disarmed my alarm and it disarmed, then alarmed home, and then disarmed again on the home assistant side.

[catellie]

I'm on 3.0.5 and use it actively daily (the actual alarm typically twice a day, the sensors for turning off lights in unused rooms continuously) and I've never noticed anything like that. Although I wish the instant listener would work properly, I can't say I'd have much real use for it and I respect that @elahd most likely have more pressing things to work on at the moment. Overall I think it works well enough for my purposes.

[pdobrien3]

it isn't very frequently. prob once a week. sometimes it will cycle between alarmed home and disarmed multiple times.

[elahd]

Hey all. Sorry for dropping -- summer got busy. I released some updates in v3.0.8 that may help here. This release fixes a bug introduced in June that blocked some WebSocket updates from sticking.

@lbreggi / @Raul-7-7 / @sspaul1976: The slow updates are either the rate limiting described in the release notes for v3.0.3 or the bug fixed in v3.0.8. If v3.0.8 doesn't speed things up, I'm going to write this off as a limitation with the ADC API. Their rate limiting really kills the experience. You may have to go back to setting a low refresh rate for polling.

@pdobrien3: I think you're seeing a UI issue where the integration misinterprets states while the system arms/disarms. I hope that v3.0.8 will fix this, as well. Either way, the alarm state isn't actually changing.

[catellie]

@elahd I installed 3.0.8 within minutes of your email and as far as I can tell it works fine. However, I still don't see the quick door opening events etc that for some time earlier were registered through the socket listener (as opposed to the slower polling). IIRC you wanted to do some refactoring around that which I assume is still on the TODO list?

[elahd]

Thanks, @catellie. There's one more thing you can do to help here, which is comparing WebSocket messages you see on the Alarm.com website vs Home Assistant. These instructions are for Chrome:

1. Go to Alarm.com. Don't log in yet.
2. Open the Chrome developer console via either Menu > More Tools > Developer Tools or by hitting Ctrl + Shift + I. Keep the console visible.
3. Log in to Alarm.com.
4. Go to the Network tab (1) in the developer console.
5. Click on the WS button (2) to show only WebSocket connections.
6. You should see a request in the request list that starts with "?auth=" (3). Click on that.
7. In the pane that appears on the right, click on the Messages tab (4).

This will show you the same live stream of updates that the integration gets. If you open and close the door, you should see that event reflected as a new message. I'm interested in:

1. Whether the messages you see here line up with state changes in Home Assistant, specifically whether you're missing the same events through this interface.
2. Whether messages for door open/close events have the fields "EventType", "NewState", or "PropertyValue".

Thanks!

[pdobrien3]

3.0.10 brought back some old errors. It is late and I was also dealing with zwave beta issues. I just rolled back to 9. If someone else doesn't report it, I will update and get the info.

Also, I was still seeing the arming/disarming UI issues in .8, I didnt actually restart Hass, just reloaded the integration. I am on .9 with a HAss restart. will advise.

[pdobrien3]

updating to 3.0.10 gives me these:

Logger: homeassistant
Source: custom_components/alarmdotcom/base_device.py:198
Integration: Alarm.com ([documentation](https://github.com/pyalarmdotcom/alarmdotcom), [issues](https://github.com/pyalarmdotcom/alarmdotcom/issues))
First occurred: 8:28:01 AM (5 occurrences)
Last logged: 8:29:01 AM

Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/pyalarmdotcomajax/devices/registry.py", line 299, in get
    return self._devices[device_id]
           ~~~~~~~~~~~~~^^^^^^^^^^^
KeyError: 563023

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 233, in _handle_refresh_interval
    await self._async_refresh(log_failures=True, scheduled=True)
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 389, in _async_refresh
    self.async_update_listeners()
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 172, in async_update_listeners
    update_callback()
  File "/config/custom_components/alarmdotcom/base_device.py", line 91, in _handle_coordinator_update
    super()._handle_coordinator_update()
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 469, in _handle_coordinator_update
    self.async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 743, in async_write_ha_state
    self._async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 843, in _async_write_ha_state
    state, attr = self._async_generate_attributes()
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 787, in _async_generate_attributes
    attr.update(self.extra_state_attributes or {})
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/alarmdotcom/base_device.py", line 198, in extra_state_attributes
    raw = self._controller.api.devices.get(self._adc_id).raw_attributes
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/pyalarmdotcomajax/devices/registry.py", line 301, in get
    raise UnkonwnDevice(device_id) from err
pyalarmdotcomajax.exceptions.UnkonwnDevice: Unknown device ID '563023'.

"unique_id: 563023 is related to enitity scene.home_2 in HAss. I also have a scene.home generated by HAss scenes so I am not sure this is the reason. I do in fact have a home scene in alarm.com. I also have a wake_up scene in both alarm.com and HAss so .10 also generated a scene.wake_up_2 for the alarm.com scene but it doesnt seem to be generating an error.

[catellie]

Hi @elahd,

I believe I've followed you instructions (note that I'm bounced to their Swedish site for a bit, but it appears not to be particularly harmful) and here is what I see in various logs when I quickly opened my front door at 13:37 (!) UTC (2 hours off from Sweden)

The Chrome Data message says:

1. CorrelatedId: null
2. DeviceId: 3
3. DeviceType: 1
4. EventDateUtc: "2023-10-28T13:37:04.446Z"
5. EventType: 100
6. EventValue: 0
7. QstringForExtraData: null
8. UnitId: 100787381

This corresponds very nicely with what I see in their app, which translated from Swedish says: "15:37 Front door opens/closes"

However, the HA web interface Log book shows nothing.

As I dig into the low level home-assistant.log file (still with a lot of logs from earlier experiments) I find this websocket block:

2023-10-28 15:37:05.280 DEBUG (MainThread) [pyalarmdotcomajax.websockets.client] ====================[ WEBSOCKET MESSAGE: BEGIN ]==================== { "EventDateUtc": "2023-10-28T13:37:04.446Z", "UnitId": 100787381, "DeviceId": 3, "EventType": 100, "EventValue": 0.0, "CorrelatedId": null, "QstringForExtraData": null, "DeviceType": 1 } 2023-10-28 15:37:05.280 DEBUG (MainThread) [pyalarmdotcomajax.websockets.messages] WebSocket Message Type: Event 2023-10-28 15:37:05.281 INFO (MainThread) [pyalarmdotcomajax.devices] pyalarmdotcomajax.devices Got update for Entredörr (100787381-3) from WebSocket message with new {'state': 2, 'desiredState': 2}. 2023-10-28 15:37:05.281 INFO (MainThread) [pyalarmdotcomajax.devices] pyalarmdotcomajax.devices Got update for Entredörr (100787381-3) from WebSocket message with new {'state': 1, 'desiredState': 1}. 2023-10-28 15:37:05.281 DEBUG (MainThread) [pyalarmdotcomajax.websockets.client] ====================[ WEBSOCKET MESSAGE: END ]====================

As you can guess "Entredörr" is Swedish for "Front door" so that makes fair sense. The only strange thing here (IMHO) is that the "EventValue" appears to have gone from an integer ("0") to a float ("0.0") - this MIGHT affect a switch/when type mapping table.

If I instead look in the HA Overview (web or app) for this device things get a bit confusing. The door shows up as "binary_sensor.entredorr" having NO events, but still claims to have been closed for almost exactly 24 hours (it will slowly shift the start-end times as I keep re-opening the little hover popup.

So, as far as I can see, socket events are picked up as expected, but somehow are not converted into HA events and hence they can not be used for automation. Seems like some minor tweak that needs polishing since it worked in the past. The only problem at the time, in my experience, was that soon or later some glitch would cause the socket listener to die after a while (typically a few days, occasionally just a couple of hours).

True, a single event representing open+close is not ideal, but since that's the way it is reported in their API we just have to live with it. (I actually opened the door for about 10 seconds.)

Hope this helps! / Jonas

PS. Let me know if I should retry with a later version, I'm still on 3.0.8

• the fixes/enhancements listed for 3.0.10 seemed very unrelated.

On Fri, Oct 27, 2023 at 5:06 PM Elahd Bar-Shai @.***> wrote:

Thanks, @catellie https://github.com/catellie. There's one more thing you can do to help here, which is comparing WebSocket messages you see on the Alarm.com website vs Home Assistant. These instructions are for Chrome:

[image: image] https://user-images.githubusercontent.com/466460/278681183-be885854-c286-4046-9b3f-c9742b57faff.png

1. Go to Alarm.com. Don't log in yet.
2. Open the Chrome developer console via either Menu > More Tools > Developer Tools or by hitting Ctrl + Shift + I. Keep the console visible.
3. Log in to Alarm.com.
4. Go to the Network tab (1) in the developer console.
5. Click on the WS button (2) to show only WebSocket connections.
6. You should see a request in the request list that starts with "?auth=" (3). Click on that.
7. In the pane that appears on the right, click on the Messages tab (4).

This will show you the same live stream of updates that the integration gets. If you open and close the door, you should see that event reflected as a new message. I'm interested in:

1. Whether the messages you see here line up with state changes in Home Assistant, specifically whether you're missing the same events through this interface.
2. Whether messages for door open/close events have the fields "EventType", "NewState", or "PropertyValue".

Thanks!

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

[pdobrien3]

@pdobrien3: I think you're seeing a UI issue where the integration misinterprets states while the system arms/disarms. I hope that v3.0.8 will fix this, as well. Either way, the alarm state isn't actually changing.

This is till happening on V3.10. You are correct, the actual alarm.com state does not change but automations that trigger off alarm state are being run.

[davidfromtandym]

@pdobrien3 Where can I find the mapping between device ID and alarmdotcom component? I'm getting a similar error as you, but I'm not finding where to identify which device in the integration is the culprit. This seems to be a different device ID than what HA uses, as those device IDs are much longer.

[pdobrien3]

I am not 100% sure which error you are talking about but this is a good start and probably what I did:

https://github.com/pyalarmdotcom/alarmdotcom/wiki/How-to-Test-&-Debug#install-the-adc-command-line-tool

[dstanchfield]

I believe I found the bug that may have been causing this issue for some people.

First, I verified what @catellie was seeing, Websocket was seeing device events just fine. They just were not making their way into HA.

So I dug a little deeper and noticed that Websocket events start making their way to HA great at system restart, but after the first poll for a hard update of all devices, those Websocket events stop making their way into HA.

The problem ends up being that pyalarmdotcomajax reinitializes each device in async_update (called for polling by HA), so all the initial callbacks back to HA for Websocket events are lost (https://github.com/pyalarmdotcom/pyalarmdotcomajax/blob/58a4b0aabac9c3760d23941fc00393731deedc52/pyalarmdotcomajax/__init__.py#L222)

Here is a quick and dirty hack I made that fixes it for me. It just makes sure the callback list is empty so we do not end up with duplicate callbacks, and then re-registers the callback for updates:

*** Removed, provided proper fix below

[dstanchfield]

My hack is work in progress, I just noticed a mistake..

[dstanchfield]

Because of the async nature of the updates, I had to move my hack up to pyalarmdotcomajax. This just checks to see if there were existing devices about to be replaced and copies their callbacks:

https://github.com/dstanchfield/pyalarmdotcomajax/commit/dcfee989220533ae2cb3bdeb736e02da1c865c88

[catellie]

Hi again,

I've been using the recent release for a few days and as far as I can tell it is not harmful, nor does it solve the base problem for my case:

Looking at the "WEBSOCKET MESSAGE: BEGIN" chunks in the log and comparing it with the events shown in Home Assistant's UI, it seems that my motion detectors (I have two) are correctly reported in the websockets log as well as in the UI logs - hence I can trigger turning off lights when the have been idle for a while. (This is also fine for a light I've connected in a Z-wave power socket I got in the Alarm.com package, I see no reason to automate that further.) However, although my front door open/close events show up in the websockets log (along with state/desiredState 2 and 1 entries - which I assume indicate one "open" followed by one "close") these never show up in the UI and hence can not be used for any automation.

I've not run it long enough (yet) to know whether the socket connection is now more stable than before (it seemed to often run for a week and then possibly die) - this may well be what your fix was primarily about, if so all is perhaps good.

Still, I THINK I've seen door events in UI in the past, but not since last summer or so. 🤷‍♂️

Anyway, this is hardly critical, I just wanted you to know what I see. Keep it up!

/ Jonas

PS. I can't say I have a solid use case for what I'd automate with the front door events, but it is annoying that they no longer show up.

[dstanchfield]

You're correct, my pull request did not address this issue. I'll submit my hack as a pull request to pyalarmdotcomajax for reference on how to solve this.

That said, what I am seeing after a couple of weeks with my hack is that websockets are extremely reliable and near realtime now in the UI. I haven't had any issues, and have normal polling set at the default of 15 minutes.

[TheWebMachine]

Hi again,

I've been using the recent release for a few days and as far as I can tell it is not harmful, nor does it solve the base problem for my case:

Looking at the "WEBSOCKET MESSAGE: BEGIN" chunks in the log and comparing it with the events shown in Home Assistant's UI, it seems that my motion detectors (I have two) are correctly reported in the websockets log as well as in the UI logs - hence I can trigger turning off lights when the have been idle for a while. (This is also fine for a light I've connected in a Z-wave power socket I got in the Alarm.com package, I see no reason to automate that further.) However, although my front door open/close events show up in the websockets log (along with state/desiredState 2 and 1 entries - which I assume indicate one "open" followed by one "close") these never show up in the UI and hence can not be used for any automation.

I've not run it long enough (yet) to know whether the socket connection is now more stable than before (it seemed to often run for a week and then possibly die) - this may well be what your fix was primarily about, if so all is perhaps good.

Still, I THINK I've seen door events in UI in the past, but not since last summer or so. 🤷‍♂️

Anyway, this is hardly critical, I just wanted you to know what I see. Keep it up!

/ Jonas

PS. I can't say I have a solid use case for what I'd automate with the front door events, but it is annoying that they no longer show up.

I am not having this issue. While there is a delay of up to 15 seconds (as is the case with all of my alarmdotcom sensors), I am seeing door open/close events in HA just fine. I have automation setup for window open/close to control my HVAC - don't need the AC on if someone opens a window - and that works fine, too.

That said, all of my door and window sensors are the same wireless Resideo units:

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

[dstanchfield]

@TheWebMachine out of curiosity, what is the time you have set for polling of alarmdotcom?

[TheWebMachine]

@TheWebMachine out of curiosity, what is the time you have set for polling of alarmdotcom?

Update 10s Websocket Timeout 300s

I found setting higher than 10s resulted in a uselessly long delay (it takes 5-10s sometimes just in delay from sensor -> panel -> alarmdotcom's cloud as it is). Setting lower would piss off their servers and get me temp banned.

[dstanchfield]

@TheWebMachine I suspect that it's actually the polling that is updating your sensors and not the websockets. In my experience websockets are nearly close to realtime.

If your willing, I have a way to test this theory as well as determine if your seeing the same bug @catellie and I are. Set the polling to 900 seconds and restart HA. For the first 15 minutes sensors should be updated near realtime. Then after 15 minutes sensors will not be updated at all unless they changed states since the previous poll.

[ghds514]

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?

[TheWebMachine]

Sure, I'll give it a try.

[TheWebMachine]

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.

[TheWebMachine]

It's bunching open/close events together and they are delayed by several minutes, even in the adc app. It does not like this websocket.