Changes to device states not reflected in Home Assistant

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.

Same here - is there something I can do to help to identify the issue? Thanks!

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. 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. WebHooks 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.

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!

@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.

Actions initiated through Home Assistant may take up to 60 seconds to complete. This includes commands for your alarm, locks, garage doors, etc.
Changes to Door/Window/Motion sensors and actions taken outside of Home Assistant may take up to 3 minutes to register via push notification and may not register at all. If you have a low poll time, you should expect to see the same refresh times that you saw in the v2.x version of this integration.

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.
However, when I upgrade to the latest, there is a significant delay in arm/disarm (15-30 seconds at least). Not good!
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:
023-06-09 07:18:51.315 DEBUG (MainThread) [pyalarmdotcomajax.websockets.client]
====================[ WEBSOCKET MESSAGE: BEGIN ]====================
{
    "EventDateUtc": "2023-06-09T05:18:51.068Z",
    "UnitId": 100787381,
    "DeviceId": 127,
    "EventType": 10,
    "EventValue": 0.0,
    "CorrelatedId": null,
    "QstringForExtraData": "ew=&ew_contact_user_type=-1",
    "DeviceType": -1
}
2023-06-09 07:18:51.315 DEBUG (MainThread) [pyalarmdotcomajax.websockets.messages] WebSocket Message Type: Event
2023-06-09 07:18:51.315 INFO (MainThread) [pyalarmdotcomajax.devices] pyalarmdotcomajax.devices Got async update for partition1 (REDACTED) from WebSocket message with new {'state': 3, 'desiredState': 3}.
2023-06-09 07:18:51.316 DEBUG (MainThread) [pyalarmdotcomajax.devices] Desired: [3] | Current: [3]
2023-06-09 07:18:51.316 DEBUG (MainThread) [pyalarmdotcomajax.websockets.client]
====================[ WEBSOCKET MESSAGE: END ]====================

Although I'm not really sure what the state numbers mean, I'm pretty sure that partition1 is their name for my house. So me arming away appears to have caused this event to show up in the integration - but for some reason it still didn't show up as the new state until 10 minutes later when "getting all devices" occurred. (There were several Sending keep alive signal. entried in that time.)
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.

The debug logs are verbose. It's a pain to look through. Sorry about that!
State 3 is arm away.
You are missing one key message between WEBSOCKET MESSAGE: BEGIN and WEBSOCKET MESSAGE: END. Below is what you should expect to see in the logs when arming/disarming:

Arm away flow initiated:
2023-06-09 20:55:52.128 DEBUG (MainThread) [pyalarmdotcomajax.devices.partition] Calling arm away.

Integration changes partition status in pyalarmdotcomajax's device registry to "armed away":
2023-06-09 20:55:52.128 INFO (MainThread) [pyalarmdotcomajax.devices] pyalarmdotcomajax.devices Got async update for Alarm (999999999-127) from WebSocket message with new {'desiredState': 3}.

Integration receives state change update from pyalarmdotcomajax and changes state in HA to "arming". (Updates to a device trigger updates for all sub-entities.)
2023-06-09 20:55:52.131 INFO (MainThread) [custom_components.alarmdotcom.base_device] Updated Alarm Control Panel Alarm (999999999-127): arming
2023-06-09 20:55:52.131 INFO (MainThread) [custom_components.alarmdotcom.base_device] Updated Device Alarm Malfunction (999999999-127): off
2023-06-09 20:55:52.131 INFO (MainThread) [custom_components.alarmdotcom.base_device] Updated Device Alarm Battery (999999999-127): off
2023-06-09 20:55:52.132 INFO (MainThread) [custom_components.alarmdotcom.base_device] Updated Device Alarm Debug (999999999-127): None

Pyalarmdotcomajax sends arm away command to Alarm.com and waits for a synchronous response from the server:
2023-06-09 20:55:52.132 INFO (MainThread) [pyalarmdotcomajax] Sending Command.ARM_AWAY to Alarm.com.
2023-06-09 20:55:52.133 DEBUG (MainThread) [pyalarmdotcomajax] Url https://www.alarm.com/web/api/devices/partitions/999999999-127/armAway

While waiting for a synchronous response, pyalarmdotcomajax gets an asynchronous WebSocket message indicating that the alarm has been armed. (EventType 10 = armed away):
2023-06-09 20:55:53.211 DEBUG (MainThread) [pyalarmdotcomajax.websockets.client]
====================[ WEBSOCKET MESSAGE: BEGIN ]====================
{
    "EventDateUtc": "2023-06-09T20:55:52.989Z",
    "UnitId": 999999999,
    "DeviceId": 127,
    "EventType": 10,
    "EventValue": -234234234.0,
    "CorrelatedId": null,
    "QstringForExtraData": "lid=77777777&ew=&ew_contact_user_type=0",
    "DeviceType": -1
}
2023-06-09 20:55:53.212 DEBUG (MainThread) [pyalarmdotcomajax.websockets.messages] WebSocket Message Type: Event

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.
2023-06-09 20:55:53.212 INFO (MainThread) [pyalarmdotcomajax.devices] pyalarmdotcomajax.devices Got async update for Alarm (999999999-127) from WebSocket message with new {'state': 3, 'desiredState': 3}.
2023-06-09 20:55:53.215 INFO (MainThread) [custom_components.alarmdotcom.base_device] Updated Alarm Control Panel Alarm (999999999-127): armed_away
2023-06-09 20:55:53.216 INFO (MainThread) [custom_components.alarmdotcom.base_device] Updated Device Alarm Malfunction (999999999-127): off
2023-06-09 20:55:53.216 INFO (MainThread) [custom_components.alarmdotcom.base_device] Updated Device Alarm Battery (999999999-127): off
2023-06-09 20:55:53.217 INFO (MainThread) [custom_components.alarmdotcom.base_device] Updated Device Alarm Debug (999999999-127): None
2023-06-09 20:55:53.217 DEBUG (MainThread) [pyalarmdotcomajax.websockets.client]
====================[ WEBSOCKET MESSAGE: END ]====================

Pyalarmdotcomajax gets a (synchronous) response from the arm away request.

Integration updates HA entity states:
2023-06-09 20:55:54.185 INFO (MainThread) [custom_components.alarmdotcom.base_device] Updated Alarm Control Panel Alarm (999999999-127): armed_away
2023-06-09 20:55:54.186 INFO (MainThread) [custom_components.alarmdotcom.base_device] Updated Device Alarm Malfunction (999999999-127): off
2023-06-09 20:55:54.186 INFO (MainThread) [custom_components.alarmdotcom.base_device] Updated Device Alarm Battery (999999999-127): off
2023-06-09 20:55:54.186 INFO (MainThread) [custom_components.alarmdotcom.base_device] Updated Device Alarm Debug (999999999-127): None

The relevant parts of the code that handle this process are (in order):

Partition WebSocket message handler, here, which calls...
async_handle_external_dual_state_change() for the device's representation in pyalarmdotcomajax. This calls async_handle_external_attribute_change() a few lines below, which, here, calls...
All external update callback functions registered with the device. Each entity in Home Assistant registers a callback function with pyalarmdotcomajax to be run when the library receives a state update. That function is _update_device_data(). This is the function that appears to have been skipped in your case.

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.

@catellie
I added trace logging to the master branch. If you install master via HACS, you'll see additional logs. Included are:

Logs when the integration registers an update listener with pyalarmdotcomajax:

2023-06-10 01:13:32.288 DEBUG (MainThread) [pyalarmdotcomajax.devices] Registering external update callback for Front Porch (103238342-1200) with Front Porch Light (103238342-1200)

Logs when the integration is notified of a state change:

2023-06-10 01:13:38.901 DEBUG (MainThread) [pyalarmdotcomajax.devices] pyalarmdotcomajax.devices Calling external update callback for listener Front Porch Malfunction (103238342-1200) by Front Porch Light (103238342-1200)

A count of how many external update callbacks are registered with every device in pyalarmdotcomajax. This is shown when pyalarmdotcomajax gets an update:

2023-06-10 01:13:38.907 DEBUG (MainThread) [pyalarmdotcomajax.devices] pyalarmdotcomajax.devices Front Porch Light (103238342-1200) has 4 external update callbacks.)

I also added version numbers for the integration and library to the message that you see when Home Assistant starts:
===================================================================
ALARMDOTCOM v3.0.5-alpha.1

This is a custom component
If you have any issues with this you need to open an issue here:
https://github.com/pyalarmdotcom/alarmdotcom/issues

pyalarmdotcomajax v0.5.4-alpha.1
===================================================================

@elahd strange: the newest I can see to download, even with beta turned on its 3.0.4, so now I'm on master  🤞

@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.

One basic thing: It appears that may door sensor information do not show up in the UI Logbook while the motion sensors (and partions) do. Both kinds show up on the websockets logfile trace so presumably this is intentional?
Also, I've not quite figured out the timestamps in the trace file compared to the UI Logbook - typically what I see in the  UI is some 10-20 seconds later than the traces - this makes comparison a bit harder, but typically no big deal.
With the above in mind, the stuff I've compared have mostly made fair sense so far, with one excaption:

====================[ WEBSOCKET MESSAGE: BEGIN ]====================
{
    "EventDateUtc": "2023-06-10T09:14:30.889Z",
    "UnitId": REDACTED,
    "DeviceId": 127,
    "EventType": 8,
    "EventValue": 1.0,
    "CorrelatedId": 0,
    "QstringForExtraData": "ew=REDACTED&ew_contact_user_type=0&ew_group_id=0&ew_contact_id=REDACTED",
    "DeviceType": -1
}
2023-06-10 11:14:31.098 DEBUG (MainThread) [pyalarmdotcomajax.websockets.messages] WebSocket Message Type: Event
2023-06-10 11:14:31.098 INFO (MainThread) [pyalarmdotcomajax.devices] pyalarmdotcomajax.devices Got update for partition1 (100787381-127) from WebSocket message with new {'state': 1, 'desiredState': 1}.
2023-06-10 11:14:31.098 DEBUG (MainThread) [pyalarmdotcomajax.devices] pyalarmdotcomajax.devices partition1 (REDACTED) has 0 external update callbacks.)
2023-06-10 11:14:31.099 DEBUG (MainThread) [pyalarmdotcomajax.websockets.client]
====================[ WEBSOCKET MESSAGE: END ]====================

(and a very similar one with state 2 just before) I think this one is from when I did a short "ARM HOME" / "DISARM" on my entrance panel, but it never showed up in the HA UI.
Related to your extra logs points above:

I see these base ones in my list, but there are also many variants that are labeled with Malfunction/Battery/Debug. Intentional or not?

2023-06-10 07:58:56.471 Hemlarm Garda REDACTED with partition1 REDACTED
2023-06-10 07:58:56.478 Altandörr REDACTED with Altandörr REDACTED
2023-06-10 07:58:56.480 Entredörr REDACTED with Entredörr REDACTED
2023-06-10 07:58:56.481 Källardörr REDACTED with Källardörr REDACTED
2023-06-10 07:58:56.482 Övervåning REDACTED with Övervåning REDACTED
2023-06-10 07:58:56.483 Panel Glass Break REDACTED with Panel Glass Break REDACTED
2023-06-10 07:58:56.483 Vardagsrum REDACTED with Vardagsrum REDACTED
2023-06-10 07:58:56.491 Switch REDACTED with Switch REDACTED
2023-06-10 07:58:56.491 Köksfönster REDACTED with Köksfönster REDACTED
2023-06-10 07:58:56.492 Dimmer-relay REDACTED with Dimmer-relay REDACTED

I see no logs with Calling external update callback  from pyalarmdotcomajax.devices - only registering and initializing

Here are the external backs extracter from my logs (trimmed down for readability):

2023-06-10 09:30:58.376 pyalarmdotcomajax.devices Övervåning REDACTED has 0 external update callbacks.)
2023-06-10 10:10:50.954 pyalarmdotcomajax.devices Övervåning REDACTED has 0 external update callbacks.)
2023-06-10 10:26:49.655 pyalarmdotcomajax.devices Vardagsrum REDACTED has 0 external update callbacks.)
2023-06-10 10:56:51.058 pyalarmdotcomajax.devices Vardagsrum REDACTED has 0 external update callbacks.)
2023-06-10 11:08:49.068 pyalarmdotcomajax.devices Vardagsrum REDACTED has 0 external update callbacks.)
2023-06-10 11:09:12.354 pyalarmdotcomajax.devices Övervåning REDACTED has 0 external update callbacks.)
2023-06-10 11:14:24.405 pyalarmdotcomajax.devices partition1 REDACTED has 0 external update callbacks.)
2023-06-10 11:14:31.098 pyalarmdotcomajax.devices partition1 REDACTED has 0 external update callbacks.)
2023-06-10 11:44:02.754 pyalarmdotcomajax.devices Övervåning REDACTED has 0 external update callbacks.)
2023-06-10 12:20:18.950 pyalarmdotcomajax.devices Vardagsrum REDACTED has 0 external update callbacks.)
2023-06-10 12:28:55.509 pyalarmdotcomajax.devices Vardagsrum REDACTED has 0 external update callbacks.)
2023-06-10 12:58:59.349 pyalarmdotcomajax.devices Vardagsrum REDACTED has 0 external update callbacks.)
2023-06-10 13:26:45.028 pyalarmdotcomajax.devices Vardagsrum REDACTED has 0 external update callbacks.)
2023-06-10 13:27:54.291 pyalarmdotcomajax.devices partition1 REDACTED has 0 external update callbacks.)
2023-06-10 13:28:00.985 pyalarmdotcomajax.devices Entredörr REDACTED has 0 external update callbacks.)
2023-06-10 13:28:00.985 pyalarmdotcomajax.devices Entredörr REDACTED has 0 external update callbacks.)
2023-06-10 13:47:46.853 pyalarmdotcomajax.devices partition1 REDACTED has 0 external update callbacks.)
2023-06-10 13:56:50.954 pyalarmdotcomajax.devices Vardagsrum REDACTED has 0 external update callbacks.)
2023-06-10 13:58:56.784 pyalarmdotcomajax.devices Entredörr REDACTED has 0 external update callbacks.)
2023-06-10 13:58:56.784 pyalarmdotcomajax.devices Entredörr REDACTED has 0 external update callbacks.)
2023-06-10 13:58:57.758 pyalarmdotcomajax.devices Vardagsrum REDACTED has 0 external update callbacks.)
2023-06-10 15:02:03.004 pyalarmdotcomajax.devices Vardagsrum REDACTED has 0 external update callbacks.)

The timings here make fair sense to when things HAVE happened: For example the partition1 arm home/disarm at 11:14 and later 13:27 just before Entredörr (Front door) opens/closes (but leave no trace in the Logbook) and then disarm again at 13:47 (this one was automatic, so it makes snse that the door was opened later at 13:58).
Also, here is the blurb:
ALARMDOTCOM v3.0.5-alpha.1

This is a custom component
If you have any issues with this you need to open an issue here:
https://github.com/pyalarmdotcom/alarmdotcom/issues

pyalarmdotcomajax v0.5.4-alpha.1

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 python --version (if that doesn't work, python3 --version).

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
https://github.com/pyalarmdotcom/alarmdotcom/issues/288#issuecomment-1585710238,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADZ47LYQIOAENF6WUT56EDXKSIUFANCNFSM6AAAAAAYVUWEVY
.
You are receiving this because you were mentioned.Message ID:
@.***>

Side note: I've noticed some HA devices now have "Attributes" showing at the bottom of the info dialog. It would be pretty neat if you were able to expose the battery level that way - currently my front door just shows "DisplayStateText Closed". Also, somewhat strangely, it currently has two Logbook entry that say "Turned off" and "Became unavailable" about an hour after I came home last night - this seems to be the same for all (or at least most) of my alarm.com sensors so I suspect those entries should be ignored.

Further digging: On the positive side, the presence sensors (Vardagsrum and Övervåning in my list above) seem to report "Turned on/off" perfectly still while neither the of the doors (Entredörr and Altandörr) make any sense. Obviously they are different kind of sensors (the doors have what I believe are magnets) so that might affect the details in how they are reported? For kicks, I opened and close the back door and saw this in the logs:
====================[ WEBSOCKET MESSAGE: BEGIN ]====================
{
    "EventDateUtc": "2023-06-11T11:03:39.963Z",
    "UnitId": REDACTED,
    "DeviceId": 4,
    "EventType": 100,
    "EventValue": 0.0,
    "CorrelatedId": null,
    "QstringForExtraData": null,
    "DeviceType": 1
}
2023-06-11 13:03:40.142 DEBUG (MainThread) [pyalarmdotcomajax.websockets.messages] WebSocket Message Type: Event
2023-06-11 13:03:40.143 INFO (MainThread) [pyalarmdotcomajax.devices] pyalarmdotcomajax.devices Got update for Altandörr (REDACTED) from WebSocket message with new {'state': 2, 'desiredState': 2}.
2023-06-11 13:03:40.143 DEBUG (MainThread) [pyalarmdotcomajax.devices] pyalarmdotcomajax.devices Altandörr (REDACTED) has 0 external update callbacks.)
2023-06-11 13:03:40.143 INFO (MainThread) [pyalarmdotcomajax.devices] pyalarmdotcomajax.devices Got update for Altandörr (REDACTED) from WebSocket message with new {'state': 1, 'desiredState': 1}.
2023-06-11 13:03:40.143 DEBUG (MainThread) [pyalarmdotcomajax.devices] pyalarmdotcomajax.devices Altandörr (REDACTED) has 0 external update callbacks.)
2023-06-11 13:03:40.143 DEBUG (MainThread) [pyalarmdotcomajax.websockets.client]
====================[ WEBSOCKET MESSAGE: END ]====================

... but still nothing in the Logbook. Just to be on the safe side: I assume you don't care too much about the name? In the json dump the ö character in the name shows up as Altand\u00f6rr which seems to be the correct unicode representation, but there is clearly potential for a mismatch depending on the parser...
Best / Jonas

@catellie Thanks, this is fantastic detail. I'm pretty sure that we're running into a race condition in which the integration attempts to register update listeners with the pyalarmdotcomajax devices before the devices are fully initialized. I made a few changes to how events are reported from the library to the integration. Instead of pyalarmdotcomajax devices reporting directly to their Home Assistant counterparts, a controller in pyalarmdotcomajax now reports directly to a controller in the integration. The controllers are initialized before any devices and are more reliably present. Can you install the latest master branch and see if you have better results?

@elahd Installed. Have plans for the evening, but will try to check the logs...

@elahd Well, I can already say one thing is better: my front door was correctly registered as opening and closing when I left today!

I upgraded to 3.0.4 from 3.0.3 Beta.  I noticed when we left the house today, my routine didn't arm my Alarm.  I went back into the system and had to configure the entity state in the scene back to Away.

Thanks @catellie. Let me know whether this is looking stable.
@mbhforum: I'm hoping that the fix for @catellie's will work for you as well. You can test it out now by installing the master branch through HACS, or hold off for v3.0.5.

@elahd it is still looking pretty good. The only issue I've seen is that all alarmdotcom devices suddenly became unavailable at 9:14 and then repeated the previous state about a minute later. Some kind of reset perhaps? I'll take a look when I'm back home (say in 6+ hours).

@catellie Devices now only show up as unavailable if the periodic pull refresh fails. The pull script refreshes all devices at once, so they'll all get marked as unavailable if a single poll fails.
Polling retries automatically, but that's a built-in Home Assistant process so I can't tell you much else about it.
Do you see anything about the failure in the logs? This would show up even with debug logging turned off.
With that said, I wouldn't consider this a serious issue as-is since it was able to recover quickly.

Hi @elahd - Sorry, I accidentally posted this in the Closed issue.  So reposting here.  I installed 3.0.4 yesterday and it did work at first.  But today I am getting this:

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}]}

@elahd I believe I've now found the error. All is fine at 2023-06-12 09:12:29 (assuming [pyalarmdotcomajax.devices] Initialized .... all devices pretty often is considered "normal"). Then:
2023-06-12 09:13:59.221 DEBUG (MainThread) [custom_components.alarmdotcom.controller] custom_components.alarmdotcom.controller: Requesting update from Alarm.com.
2023-06-12 09:13:59.221 DEBUG (MainThread) [pyalarmdotcomajax] Calling update on Alarm.com
2023-06-12 09:13:59.661 DEBUG (MainThread) [pyalarmdotcomajax] Trouble condition response:
{'errors': [{'status': '403', 'detail': 'NotAllowed', 'code': 403}]}
2023-06-12 09:13:59.661 DEBUG (MainThread) [pyalarmdotcomajax]
==============================
Server Response:
{"errors": [{"status": "403", "detail": "NotAllowed", "code": 403}]}
==============================
2023-06-12 09:13:59.661 DEBUG (MainThread) [pyalarmdotcomajax] pyalarmdotcomajax: Request error. Status: 403. Response: {'errors': [{'status': '403', 'detail': 'NotAllowed', 'code': 403}]}
2023-06-12 09:13:59.663 WARNING (MainThread) [py.warnings] /usr/local/lib/python3.11/site-packages/pyalarmdotcomajax/__init__.py:1219: RuntimeWarning: coroutine 'AlarmController.is_logged_in' was never awaited
  if not self.is_logged_in():

2023-06-12 09:13:59.696 INFO (MainThread) [pyalarmdotcomajax] Getting system data for REDACTED.
2023-06-12 09:14:00.160 DEBUG (MainThread) [pyalarmdotcomajax]
==============================
Server Response:
{"errors": [{"status": "403", "detail": "NotAllowed", "code": 403}]}
==============================
2023-06-12 09:14:00.160 DEBUG (MainThread) [pyalarmdotcomajax] pyalarmdotcomajax: Request error. Status: 403. Response: {'errors': [{'status': '403', 'detail': 'NotAllowed', 'code': 403}]}
2023-06-12 09:14:00.160 ERROR (MainThread) [pyalarmdotcomajax] Failed to get system metadata.
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/pyalarmdotcomajax/__init__.py", line 1061, in _async_get_system
    return [json_rsp["data"]]
            ~~~~~~~~^^^^^^^^
KeyError: 'data'
2023-06-12 09:14:00.162 ERROR (MainThread) [custom_components.alarmdotcom.controller] Error fetching REDACTED data:
2023-06-12 09:14:00.163 DEBUG (MainThread) [custom_components.alarmdotcom.controller] Finished fetching REDACTED data in 0.943 seconds (success: False)

Then there seems to be a full update of all my devices and after that:
2023-06-12 09:14:06.259 DEBUG (MainThread) [pyalarmdotcomajax] Sending keep alive signal. Time until session context refresh: ~ 12 minutes.
2023-06-12 09:14:06.768 DEBUG (MainThread) [pyalarmdotcomajax] Session expired.
2023-06-12 09:14:06.768 INFO (MainThread) [pyalarmdotcomajax] User session expired. Logging back in.
2023-06-12 09:14:06.768 DEBUG (MainThread) [pyalarmdotcomajax] Attempting to log in to Alarm.com
2023-06-12 09:14:07.502 DEBUG (MainThread) [pyalarmdotcomajax] Response status from Alarm.com: 200
2023-06-12 09:14:08.917 DEBUG (MainThread) [pyalarmdotcomajax] Logged in to Alarm.com.
2023-06-12 09:14:09.686 DEBUG (MainThread) [pyalarmdotcomajax] *** START IDENTITY INFO ***
2023-06-12 09:14:09.686 DEBUG (MainThread) [pyalarmdotcomajax] Provider: REDACTED
2023-06-12 09:14:09.686 DEBUG (MainThread) [pyalarmdotcomajax] User: REDACTED
2023-06-12 09:14:09.686 DEBUG (MainThread) [pyalarmdotcomajax] Keep Alive Interval: 780000
2023-06-12 09:14:09.686 DEBUG (MainThread) [pyalarmdotcomajax] Keep Alive URL: /web/KeepAlive.aspx
2023-06-12 09:14:09.686 DEBUG (MainThread) [pyalarmdotcomajax] *** END IDENTITY INFO ***
2023-06-12 09:14:10.108 DEBUG (MainThread) [pyalarmdotcomajax]
==============================
Server Response:
{"data": {"id": REDACTED, "type": "twoFactorAuthentication/twoFactorAuthentication", "attributes": {"smsMobileNumber": {"country": "44"}, "email": "REDACTED", "currentDeviceName": "Other", "isCurrentDeviceTrusted": false, "selectedTypeOf2FA": 0, "enabledTwoFactorTypes": 0, "valid2FAPermissions\
": [1, 4], "canReset2FA": false, "showSuggestedSetup": false, "canSkipSuggestedSetup": false}}, "meta": {"transformer_version": "1.1"}}
==============================
2023-06-12 09:15:06.260 DEBUG (MainThread) [pyalarmdotcomajax] Sending keep alive signal. Time until session context refresh: ~ 12 minutes.
2023-06-12 09:15:30.220 DEBUG (MainThread) [custom_components.alarmdotcom.controller] custom_components.alarmdotcom.controller: Requesting update from Alarm.com.
2023-06-12 09:15:30.220 DEBUG (MainThread) [pyalarmdotcomajax] Calling update on Alarm.com
2023-06-12 09:15:30.653 DEBUG (MainThread) [pyalarmdotcomajax] Trouble condition response:
{'data': [], 'included': [], 'meta': {'transformer_version': '1.1'}}
2023-06-12 09:15:30.653 DEBUG (MainThread) [pyalarmdotcomajax]
==============================
Server Response:
{"data": [], "included": [], "meta": {"transformer_version": "1.1"}}
==============================
2023-06-12 09:15:30.653 INFO (MainThread) [pyalarmdotcomajax] Getting system data for REDACTED.
2023-06-12 09:15:31.183 DEBUG (MainThread) [pyalarmdotcomajax]
==============================

There is plenty of  Initialized ... after that but the only triggering external state update callback for line is from when I manually clicked on one of the lamps that are connected though the alarm (Köksfönster) listening no sensor updates at all.
I've not (YET!) gone into further details (I can if you think it helps!), but this APPEARS to strike now and then:
The logs were "stable" in the above state most of the day, but from around 17:18 (this is around the time I was picking up my gym bag) until 21:26 the Became unavailable triggered a handful or so times for no apparent reason.
If it matters I can leave it like this for a while, but I think it makes more sense to restart and see if I can find a more clear pattern.
Best / Jonas

@mikesalz @catellie
Looks like you're both running into issues with recovery code that tries to log the user back in when the session expires. I fixed and re-uploaded. If you install master again via HACS you'll have the update.

Thanks @elahd !  Dumb question, but do you literally mean install "master" or should we reinstall v3.0.4?

Literally install master. That'll give you v3.0.5-alpha.3.

@mbhforum for now I'd suggest you stick to getting the "listening" for stuff happening in alarmdotcom - until we get that part stable, I think it is pretty optimistic to hook in automations on top... YMMV.
@elahd I've found two significant suspects today. First this one some 15 minutes after I left and armed the house:
2023-06-13 07:36:37.113 ERROR (MainThread) [pyalarmdotcomajax.websockets.client] Unexpected WebSocket error
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/pyalarmdotcomajax/websockets/client.py", line 138, in _connect
    await self._async_handle_message(json.loads(msg.data))
  File "/usr/local/lib/python3.11/site-packages/pyalarmdotcomajax/websockets/client.py", line 176, in _async_handle_message
    message = process_raw_message(raw_message, self._device_registry)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/pyalarmdotcomajax/websockets/messages.py", line 44, in process_raw_message
    return EventMessage(message, device)
                                 ^^^^^^
UnboundLocalError: cannot access local variable 'device' where it is not associated with a value
2023-06-13 07:36:37.116 DEBUG (MainThread) [pyalarmdotcomajax.websockets.client] Websocket WebSocketState.DISCONNECTED

I suspect this effectively killed the listening? At least I see no event logs after I left (like for instance when I returned back and opened the door)
Later in the evening (this is ~5 minutes after I came back home after picking up a package) - I had still not had time to look at logs:
[successful fetch of SYSTEM data just milliseconds before]
2023-06-13 17:54:59.433 INFO (MainThread) [pyalarmdotcomajax] Getting all devices in REDACTED.
2023-06-13 17:55:30.827 ERROR (MainThread) [custom_components.alarmdotcom.controller] Error requesting REDACTED data: Cannot connect to host www.alarm.com:443 ssl:default [Connection reset by peer]
2023-06-13 17:55:30.828 DEBUG (MainThread) [custom_components.alarmdotcom.controller] Finished fetching REDACTED data in 32.398 seconds (success: False)
2023-06-13 17:55:30.828 INFO (MainThread) [custom_components.alarmdotcom.base_device] Updated Alarm Control Panel Hemlarm Garda (REDACTED): disarmed
[... all other devices...]

If I read this right it claims to have tried for 32+ seconds to get all devices, and calls it success: False but in the very same microsecond has state information about every single device. So either this unsuccessful call had a fair bit of data, or perhaps there was a race with parallel calls? Or are the time stamps not at all to be trusted?
As I mentioned, at this stage I see no logs at all from any listeners, just active polling.
For the record: I'll just restart this now, still on master.
Best / Jonas

The timestamps can be trusted.
That first issue is a bug that caused websocket monitoring to fail when a message came in for an unsupported device. That's now fixed in master.
The second error is just a connection error from Python's aiohttp library. Home Assistant couldn't connect to Alarm.com for some reason. I added more logging to master to give us more context. Also, it's possible that connection errors permanently knock websocket monitoring offline.
Please update when you have a chance.

@elahd good to hear. Installing now...

@elahd Well, this time around it only seems to have run for less than 20 mins before this happened:
2023-06-14 07:48:40.737 ERROR (MainThread) [pyalarmdotcomajax.websockets.client] Unexpected WebSocket error
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/pyalarmdotcomajax/websockets/client.py", line 138, in _connect
    await self._async_handle_message(json.loads(msg.data))
  File "/usr/local/lib/python3.11/site-packages/pyalarmdotcomajax/websockets/client.py", line 176, in _async_handle_message
    message = process_raw_message(raw_message, self._device_registry)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/pyalarmdotcomajax/websockets/messages.py", line 44, in process_raw_message
    return EventMessage(message, device)
                                 ^^^^^^
UnboundLocalError: cannot access local variable 'device' where it is not associated with a value
2023-06-14 07:48:40.740 DEBUG (MainThread) [pyalarmdotcomajax.websockets.client] Websocket WebSocketState.DISCONNECTED

However, I'm not entirely sure this is correct as I'm 99.999% sure I selected and restarted master, but now that I double checked your new header with more versioning is not in the logs and under HACS it is listed as v3.0.4. For good measure I installed it once again with identical results. Hence I suspect master somehow got rolled back?!? (Technically is makes sense since the error looks rather familiar.)
Or is my HA installation utterly confused? / Jonas :thinking:

It's not your HA instance. It's failing in a weird way. My last change was an attempt to prevent the UnboundLocalError from appearing. I just uploaded new code that catches UnboundLocalError and shows more detail around the message itself. That code is now in master.
Alternatively, are you able to scroll up in the logs and share the message that triggered this error? What kind of device is it for?

Now I'm on dd326b0 :tada:
I still had my editor around with that buffer. Scrolling past a for number of Energie errors hope this is the one that cause the problem above:
====================[ WEBSOCKET MESSAGE: BEGIN ]====================
{
    "EventDateUtc": "2023-06-14T05:48:10.003Z",
    "UnitId": REDAC,
    "DeviceId": TED,
    "EventType": 403,
    "EventValue": 2175683.0,
    "CorrelatedId": 0,
    "QstringForExtraData": "fence_id=2175683",
    "DeviceType": -1
}
2023-06-14 07:48:10.735 DEBUG (MainThread) [pyalarmdotcomajax.websockets.messages] Got a message for unknown device REDACTED:
{
    "EventDateUtc": "2023-06-14T05:48:10.003Z",
    "UnitId": REDAC,
    "DeviceId": TED,
    "EventType": 403,
    "EventValue": 2175683.0,
    "CorrelatedId": 0,
    "QstringForExtraData": "fence_id=2175683",
    "DeviceType": -1
}
2023-06-14 07:48:10.735 DEBUG (MainThread) [pyalarmdotcomajax.websockets.messages] WebSocket Message Type: Event

Presumably 403 still indicates FORBIDDEN? The id (that I have redacted) points to that it is a geolocation/geo-device (clearly under geoDevices) when it is picked up correctly in the  system data. The fence_id bit sort of indicates that it MIGHT relate the position of my phone vs home? IIRC, there is a flag to auto-disarm when you approach, right?
Perhaps the API can not provide locations for regulation reasons?

Ok, just made another fix. Try installing master once more.
403 isn't on the list of known event types, but I don't think that it means forbidden. I haven't seen that these error codes line up with HTTP status codes.
If we're still seeing failures after this attempt, I'll try building more robust testing around this feature to iron out the issues locally.

Cool, I'm now on 887365c

FYI I just tried the latest Master and received this error:

Error setting up entry ADT Security for alarmdotcom
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 387, in async_setup
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/alarmdotcom/init.py", line 155, in async_setup_entry
entity_registry.async_remove(entity_entry.id)
File "/usr/src/homeassistant/homeassistant/helpers/entity_registry.py", line 649, in async_remove
self.entities.pop(entity_id)
File "", line 912, in pop
File "/usr/local/lib/python3.11/collections/init.py", line 1124, in getitem
raise KeyError(key)
KeyError: 'cd94bdb1decc17ab81d843fe6cccc055'

@elahd For me, above mentioned master is still ticking along and both doors and motion detectors are reported seemingly close to perfect (the doors are still opened and closed at the same second, but I can live with that). Also arming/disarming appear to work/be detected correctly. If this holds true for a while longer I'll add some automation on top...

@catellie Good to hear!
@mikesalz Fixed that error. Try installing from master again.

@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 work 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.

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

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.
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.

@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 you finger form the left edge, but recent releases now require you to click the hamburger icon :angry:

@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...

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!

@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... :-(

@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...

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.

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?

@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.

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

@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.]

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.

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,

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

@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!)

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)

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.

Thank you very much.

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: @.***>

@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

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: @.***>

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,

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:
@.***>

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.

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.

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

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.

@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 socker 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?

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.

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'.

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:

CorrelatedId: null
DeviceId: 3
DeviceType: 1
EventDateUtc: "2023-10-28T13:37:04.446Z"
EventType: 100
EventValue: 0
QstringForExtraData: null
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

Go to Alarm.com. Don't log in yet.
Open the Chrome developer console via either Menu > More Tools >
Developer Tools or by hitting Ctrl + Shift + I. Keep the console visible.
Log in to Alarm.com.
Go to the Network tab (1) in the developer console.
Click on the WS button (2) to show only WebSocket connections.
You should see a request in the request list that starts with
"?auth=" (3). Click on that.
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:

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.
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 Thanks. Any idea what kind of device 563023 is? You can check using the adc command. adc -u "username" -p "password" get.

@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.

@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.

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:
https://github.com/pyalarmdotcom/alarmdotcom/commit/7ebcc745748ded3fa8a0a7454a11a670c375195a
This is not the proper fix, like I said a hack.  I do not know the code base well enough to do a decent pull request.

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

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

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.

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.

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.

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

@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).

@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.

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?

Sure, I'll give it a try.

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.

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.

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

Set the polling to 900 seconds and restart HA.

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

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

Got it, thanks.

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

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

On the plus side, it woke me up! haha
I'll point out one thing that shouldn't made 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.

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

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

Still, I would assume we can compare the websocket data to see what is different. Here is mine:
{
    "EventDateUtc": "2024-01-24T16:14:52.896Z",
    "UnitId": 100787381,
    "DeviceId": 3,
    "EventType": 100,
    "EventValue": 0.0,
    "CorrelatedId": null,
    "QstringForExtraData": null,
    "DeviceType": 1
}

Presumably the event type 100 is the important part? A few lines down from that it appears that this is converted to two events (one for open and one for close): [I've trimmed time stamps and prefixes for readability]
WebSocket Message Type: Event
Got update for Entredörr (100787381-3) from WebSocket message with new {'state': 2, 'desiredState': 2}.
Got update for Entredörr (100787381-3) from WebSocket message with new {'state': 1, 'desiredState': 1}.

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

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

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.

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

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

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.

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

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
Must be that then, I am with Telus actually! if I set it to 900, it updates every 15 min ! I changed it to 15 seconds and this is good enough for me, but not live :(
I had it on 15 before this update and so far Telus has not complained!

I moved from Telus because they are forcing migration to a proprietary login:
https://github.com/pyalarmdotcom/alarmdotcom/issues/357

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
https://github.com/pyalarmdotcom/alarmdotcom/issues/288#issuecomment-1937371232,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABPFFBTQYI5OR5UDTXG6J4TYTAGZJAVCNFSM6AAAAAAYVUWEV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZXGM3TCMRTGI
.
You are receiving this because you were mentioned.Message ID:
@.***>

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

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

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.

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

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

As you can see, I am getting 'unavailable' alongside my arm and disarm status changes, which may also be what you are seeing. I suspect there is something timing out during the state change, but I haven't dug into the logs yet.

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

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

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

@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.

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 ---

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

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

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

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

I have taken to employing the following in my automations to account for this unknown delay while also allowing for a timeout. It has allowed for better flow when the panel is involved.
repeat:
  sequence:
    - delay:
        hours: 0
        minutes: 0
        seconds: 1
        milliseconds: 0
  while:
    - condition: template
      value_template: "{{ repeat.index <= 15 }}"
    - condition: state
      entity_id: alarm_control_panel.panel
      state: armed_home

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

@ElJefeClicko @TheWebMachine
I had the same issue (app not updating) then I did a trick and it seems to be working
Go to alarm.com --> Notification --> Setup a new notification rule that sends PUSH notification to your mobile device if any sensor you care about is opened.
Now when I open the window (my update is 900 seconds) it is updated in HA in about 5-10 seconds. and Close is instant.
The only downside, you get extra notification!
Cheers,

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 Sing 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!


shelter cost ratios

Data file https://github.com/bcgov/housing-data-challenge-ruby/blob/master/census_data/NHS_99-014-X2011031_sheltercostratio.csv now added, with the 2011 National Household Survey (NHS) shelter cost ratio data for each Census Metropolitan Area (CMA) in Canada

This has been superseded by Census 2016 data.


Panic in Reaper on Linux when closing plugin window

Tested on two systems. I get this crash inside baseview when closing the plugin window of my plugin using Vizia:
17:39:21 [ERROR] thread 'unnamed' panicked at 'called `Result::unwrap()` on an `Err` value: XLibError { error_code: 9, error_message: "BadDrawable (invalid Pixmap or Window parameter)", minor_code: 3, request_code: 130, type: 0, resource_id: 8388612, serial: 2718 }': /home/jussi/.cargo/git/checkouts/baseview-9d6c750431f4479e/7001c25/src/gl/x11.rs:246
   0: nih_plug::wrapper::util::log_panics::{{closure}}::{{closure}}
             at /home/jussi/.cargo/git/checkouts/nih-plug-a2d2dc277b128e13/ce2eab8/src/wrapper/util.rs:128:29
      nih_plug::util::permit_alloc
             at /home/jussi/.cargo/git/checkouts/nih-plug-a2d2dc277b128e13/ce2eab8/src/util.rs:25:5
   1: <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/alloc/src/boxed.rs:2002:9
      std::panicking::rust_panic_with_hook
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/std/src/panicking.rs:692:13
   2: std::panicking::begin_panic_handler::{{closure}}
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/std/src/panicking.rs:579:13
   3: std::sys_common::backtrace::__rust_end_short_backtrace
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/std/src/sys_common/backtrace.rs:137:18
   4: rust_begin_unwind
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/std/src/panicking.rs:575:5
   5: core::panicking::panic_fmt
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/core/src/panicking.rs:64:14
   6: core::result::unwrap_failed
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/core/src/result.rs:1790:5
   7: baseview::gl::x11::GlContext::swap_buffers::{{closure}}
      baseview::gl::x11::errors::XErrorHandler::handle::{{closure}}::{{closure}}
             at /home/jussi/.cargo/git/checkouts/baseview-9d6c750431f4479e/7001c25/src/gl/x11/errors.rs:73:17
      <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/core/src/panic/unwind_safe.rs:271:9
      std::panicking::try::do_call
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/std/src/panicking.rs:483:40
      std::panicking::try
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/std/src/panicking.rs:447:19
      std::panic::catch_unwind
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/std/src/panic.rs:140:14
      baseview::gl::x11::errors::XErrorHandler::handle::{{closure}}
             at /home/jussi/.cargo/git/checkouts/baseview-9d6c750431f4479e/7001c25/src/gl/x11/errors.rs:71:32
      std::thread::local::LocalKey<T>::try_with
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/std/src/thread/local.rs:446:16
      std::thread::local::LocalKey<T>::with
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/std/src/thread/local.rs:422:9
   8: baseview::gl::x11::errors::XErrorHandler::handle
             at /home/jussi/.cargo/git/checkouts/baseview-9d6c750431f4479e/7001c25/src/gl/x11/errors.rs:66:9
      baseview::gl::x11::GlContext::swap_buffers
             at /home/jussi/.cargo/git/checkouts/baseview-9d6c750431f4479e/7001c25/src/gl/x11.rs:242:9
      baseview::gl::GlContext::swap_buffers
             at /home/jussi/.cargo/git/checkouts/baseview-9d6c750431f4479e/7001c25/src/gl/mod.rs:107:9
   9: <vizia_baseview::window::ViziaWindow as baseview::window::WindowHandler>::on_frame
             at /home/jussi/.cargo/git/checkouts/vizia-629668219022e428/39e295a/crates/vizia_baseview/src/window.rs:221:9
  10: baseview::x11::window::Window::run_event_loop
             at /home/jussi/.cargo/git/checkouts/baseview-9d6c750431f4479e/7001c25/src/x11/window.rs:478:17
  11: baseview::x11::window::Window::window_thread
             at /home/jussi/.cargo/git/checkouts/baseview-9d6c750431f4479e/7001c25/src/x11/window.rs:365:9
  12: baseview::x11::window::Window::open_parented::{{closure}}
             at /home/jussi/.cargo/git/checkouts/baseview-9d6c750431f4479e/7001c25/src/x11/window.rs:140:13
      std::sys_common::backtrace::__rust_begin_short_backtrace
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/std/src/sys_common/backtrace.rs:121:18
  13: std::thread::Builder::spawn_unchecked_::{{closure}}::{{closure}}
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/std/src/thread/mod.rs:558:17
      <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/core/src/panic/unwind_safe.rs:271:9
      std::panicking::try::do_call
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/std/src/panicking.rs:483:40
      std::panicking::try
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/std/src/panicking.rs:447:19
      std::panic::catch_unwind
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/std/src/panic.rs:140:14
      std::thread::Builder::spawn_unchecked_::{{closure}}
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/std/src/thread/mod.rs:557:30
      core::ops::function::FnOnce::call_once{{vtable.shim}}
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/core/src/ops/function.rs:250:5
  14: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/alloc/src/boxed.rs:1988:9
      <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/alloc/src/boxed.rs:1988:9
      std::sys::unix::thread::Thread::new::thread_start
             at /rustc/8460ca823e8367a30dda430efda790588b8c84d3/library/std/src/sys/unix/thread.rs:108:17
  15: start_thread
             at ./nptl/pthread_create.c:442:8
  16: clone3
             at ./misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

I'm getting reports of the same issue from users, and can confirm it happens when using Vizia, Iced, and Egui, so it's not tied to Vizia specifically.

I've finally managed to track down the issue, and have a quick fix! It's caused by a race condition that starts in baseview::x11::WindowHandle::close().
Explaination of the Bug:
WindowHandle::close() sets the close_requested atomic so that the event loop knows to finish up, but the function returns immediately allowing windows to close before baseview can complete rendering and process the close request.  To make matters worse, this frequently happens at the start of frame rendering because activating an OpenGL context will wait for things to catch up (like vsync).
Because it's a race condition that also depends on driver quirks, every system I've tested behaves differently. Usually crashes occur upon reopening the window. Some systems crash on the first reopening, some can survive 100, it's all over the place.
A proper fix would be to synchronize with the event loop thread, as the existing comment points out...  I wish I had spotted that before spending an embarrassing amount of time tracking this down. 🤦
A quick-and-dirty fix is to add a small delay when closing:
impl WindowHandle {
    pub fn close(&mut self) {
        if self.raw_window_handle.take().is_some() {
            // FIXME: This will need to be changed from just setting an atomic to somehow
            // synchronizing with the window being closed (using a synchronous channel, or
            // by joining on the event loop thread).

            self.close_requested.store(true, Ordering::Relaxed);

            // HACK: Allow the window time to close nicely to avoid OpenGL errors/crashing
            //       until proper synchronizing (mentioned above) can be implemented.
            thread::sleep(Duration::from_millis(200));
        }
    }

    ...

These issues are the same:
https://github.com/robbert-vdh/nih-plug/issues/98
https://github.com/ardura/Subhoofer/issues/9
Possibly the same:
https://github.com/robbert-vdh/nih-plug/issues/124

@PolyVector , did this quick fix get implemented? I would like to notify @ardura if it has... I'm waiting to use their plugins in Reaper.
-Thanks!

To my knowledge this bug hasn't been addressed yet in baseview unfortunately.