mag1024 / bosch-alarm-mode2 Goto Github PK

I learned the other day that while AMAX panels don't support Mode 2 subscriptions, they do support another protocol where they push updates, DC-09.

Do we think it would be worth implementing DC-09 support, or should we just leave AMAX with only polling?
I just don't know if its worth the development time or not, though there are existing DC-09 implementations out there iirc.

Hi There,

Trying to give this a crack - can't seem to connect to the unit.

You mention

To enable the "Mode 2" API in the panel, in the set the "Automation / Remote App" section of the panel settings, set the "Automation Device" to "Mode 2", and use the "Automation Passcode".

However this option doesn't seem to exist in the A-Link software. Any ideas on how to activate using A-Link?
Thanks!

Its probably worth submitting an icon to https://github.com/home-assistant/brands so that the integration has a proper icon

It seems to be slower (i.e. fewer events returned by response), and harder to understand (more terse, using abbreviations).
Example:

text:

[5005] 2023-06-16 20:48:00 | Network Cable Open On-board Ethernet
[5006] 2023-06-16 20:48:00 | Network Cable Good On-board Ethernet
[5007] 2023-06-17 20:25:00 | User Code Tamper Ar-1 P240,�Us-5002
[5008] 2023-06-18 02:02:00 | Sked Report Exec Sk-3
[5009] 2023-06-18 02:02:00 | Test Report

raw:

[5005] 2023-06-16 20:48:00 | Network Cable Disconnected, SDI 2 Device: 399
[5006] 2023-06-16 20:48:00 | Network Cable Connected, SDI 2 Device: 399
[5007] 2023-06-17 20:25:00 | User passcode tamper - too many attempts, Area: 0, User ID: 5002
[5008] 2023-06-18 02:02:00 | Test Report Sked has executed., Sked: 2
[5009] 2023-06-18 02:02:00 | Test Report - System off-normal, non-expanded status

Seems like it might be a negative value add.

Hi @mag1024,
I recently updated the bosch-alarm-homeassistant integration on my RPi 4 HA instance. Now I'm getting cyclic connection drops with my Solution 3000 panel. This is what's coming up in the debugging log:
`Logger: root
Source: /usr/local/lib/python3.11/site-packages/bosch_alarm_mode2/panel.py:255
First occurred: 4:35:41 AM (109 occurrences)
Last logged: 11:05:55 AM

Connection monitor exception
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/bosch_alarm_mode2/panel.py", line 251, in _monitor_connection
await self._monitor_connection_once()
File "/usr/local/lib/python3.11/site-packages/bosch_alarm_mode2/panel.py", line 281, in _monitor_connection_once
await self._connect(load_selector)
File "/usr/local/lib/python3.11/site-packages/bosch_alarm_mode2/panel.py", line 214, in _connect
await self.load(load_selector)
File "/usr/local/lib/python3.11/site-packages/bosch_alarm_mode2/panel.py", line 151, in load
await self._load_history()
File "/usr/local/lib/python3.11/site-packages/bosch_alarm_mode2/panel.py", line 231, in _load_history
if any(area.is_armed() for area in self.areas):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/bosch_alarm_mode2/panel.py", line 231, in
if any(area.is_armed() for area in self.areas):
^^^^^^^^^^^^^
AttributeError: 'int' object has no attribute 'is_armed'
`

Maybe instead of throwing generic exceptions when things fail, we construct some actual error codes when we throw exceptions? That way, home assistant can just make use of those directly instead of needing to construct its own, and we can even do more specific exceptions like potentially seperate exceptions for automation code failures vs user code vs installer code failures?