I replicated your status card and added the four attributes to it. Everything works except the Siren status. Somehow, I need to change the boolean ‘false’ to ‘Off’ and ‘true’ to "On’. Not being fluent in Jinja, I haven’t yet found an equivalent example. Can you point me in the right direction?
I have just uploaded a new release to Github 0.6.10.0
This release contains a new feature that should be backwards compatible.
When downloading the EPROM data, the integration downloads 20 (PowerMax) or 30 (PowerMaster) data blocks, where each data block is 128 bytes. However, sometimes for PowerMaster panels only 125 to 127 bytes are downloaded for a data block yet the message from the panel claims that it is 128 bytes. So we do receive most of the data but not all and the integration uses specific parts of the EPROM data (in Standard Plus and Powerlink Modes). It’s just lucky whether the necessary data is retrieved in these rare cases.
I originally treat this as an error but then put in some special cases to allow it for specific PowerMaster panels and model types. I have removed this special case but have added retries, up to 30 retries in total and if that isn’t enough then it tries to use whatever data has been downloaded for the last retry.
Note that:
I have also made this a HACS release
There is an additinal attribute for this called “Download Retries”
1 Like
I’m not sure. Something is happening in your log file where data just stops coming form the panel and there’s no indication of a disconnection. It’s as if the Rx wire was disconnected from the panel as it just stops receiving data.
Version 0.6.10.0 just uploaded to Github and made a HACS release
You might want to add the new “Download Retries” attribute
A yeah, sorry but I’m the same really, I use google and piece together what I need from examples I find.
1 Like
Added.
I struggled a bit with it. Here’s the result for the Filter attribute sensors template:
- platform: template
sensors:
alarm_panel_status:
value_template: "{{ state_attr('alarm_control_panel.visonic_alarm', 'Panel Status') }}"
alarm_panel_mode:
value_template: "{{ state_attr('alarm_control_panel.visonic_alarm', 'Panel Mode') }}"
alarm_panel_ready:
value_template: "{{ state_attr('alarm_control_panel.visonic_alarm', 'Panel Ready') }}"
alarm_panel_siren_active:
value_template: >-
{% if is_state_attr('alarm_control_panel.visonic_alarm', 'Panel Siren Active', false) %} Off
{% elif is_state_attr('alarm_control_panel.visonic_alarm', 'Panel Siren Active', true) %} On
{% endif %}
alarm_panel_exception_count:
value_template: "{{ state_attr('alarm_control_panel.visonic_alarm', 'Exception Count') }}"
alarm_panel_watchdog_timeout:
value_template: "{{ state_attr('alarm_control_panel.visonic_alarm', 'Watchdog Timeout') | int }}"
alarm_panel_watchdog_timeout_24h:
value_template: "{{ state_attr('alarm_control_panel.visonic_alarm', 'Watchdog Timeout (Past 24 Hours)') }}"
alarm_panel_download_timeout:
value_template: "{{ state_attr('alarm_control_panel.visonic_alarm', 'Download Timeout') }}"
alarm_panel_download_retries:
value_template: "{{ state_attr('alarm_control_panel.visonic_alarm', 'Download Retries') }}"
I hope I picked the correct siren attribute. I’m wondering why your example presents the Panel Ready state as ‘Off’ while in Powerlink mode. Is this off nominal? I’m also wondering why the ‘Watchdog Timeout’ attribute needed an integer operation to make it visible. It might’ve been “None” which may indicate it wasn’t initialized.
I’m going to tweak the status card a bit to make it presentable. If there’s any interest, I can post the final configuration.
Just as I thought things were working well, this happened while testing the status card:
The status card was in a hung state since it never established communication. Eventually, the alarm panel declared a loss of communication.
A Supervisor restart did not correct the condition. I had to perform a panel reset and operation returned to normal.
Thanks for the log file, I’ve just spent a few hours looking through it and I’ve created a test build on Github (version 0.6.10.1), can you please give it a try.
I think that this log file has everything that could go wrong 
, it has
- Repeated message 40 times in sequence causing a reconnection (twice)
- Invalid length EPROM download blocks (causing retries)
- Invalid EPROM block leaving the integration in Standard Mode
- A new message type FD
- B0 messages from the panel being 1 byte shorter than the declared length (causing CRC errors that after 5 times in 10 minutes causes reconnection)
As a warning to other users it may break things as I’m experimenting a little here:
- B0 (PowerMaster only) message processing. This message comes from PowerMaster panels and I do have experimental code in there already that has not changed in this release. However, looking at the log file the B0 messages are not constructed correctly each time. Sometimes they are 1 byte short (but still have a valid CRC) so in this release I accept them as valid messages (i.e. they do not create CRC errors) but I do not process them.
- I ignore the FD message type as it is not constructed correctly and I have no idea what it’s for
- I only respond to AB messages from the panel with a powerlink acknowledge in this release. I suspect it may be the cause of the message bombardment (40 or more) that some panels see.
@pocket if you could give this a try please and thanks again for the comprehensive log file
Black clouds seem to follow me. 
Certainly. I’ll attempt to stress test the code with repeated server restarts. If I see any errors in the logs, I’ll post them.
Thanks.
I’ve performed about 20 server restarts and so far I’ve seen no problems. One observation is some variability in the time between Standard Plus and Powerlink modes. Once it gets past Downloading to Powerlink mode, the communication has been stable.
The addition of the status card has been helpful; however, I’ve yet to see any incrementing of the timeout or reset counters, even before the update.
It just occurred to me the FD message could be for the remote siren (SR-720B) I have on the system. It beeps during the Exit Delay, so there could be a detectable change of state. It’s battery powered, so there’s likely status for the state of charge. You might check for similarity to sensor messages.
Hi,
A new version has been uploaded to Github, version 0.6.10.2
I have introduced a loopback test that can be used for people struggling to get it working, see here on the wiki for more details.
There are no other changes although I should mention that it also includes the test changes from 0.6.10.1
Just wanted to let you know that I switched to an ethernet connection instead of the USB. Fingers crossed, but it seems to be working now!
New release on Github: 0.6.11.0
Last weekend I implemented the new Select Entity in Home Assistant so that you can Arm or Bypass individual sensors. This seems to be working well and I have tested it over this past week so I’ve just uploaded release 0.6.11.0 to Github. There are a couple of other minor changes in there as well.
There are 3 main changes in this release
- For every sensor there is also a new select Entity so you can arm or bypass the sensor from the frontend. Look for “select.visonic_z” in the entity list in developer tools. Click on the exclamation mark inside a circle and then in the selector. The drop down list should display Armed and Bypass. Simply add the Select Entities that you want to use to your frontend. If you don’t know what any of this means then no worries, just ignore the new entities.
- Increased same packet error from 40 to 10000 as some users were having problems
- With the new release of Home Assistant (2021.7.X) I started having problems arming and disarming. I’m not sure what changed as I’ve read the various release notes but it sometimes failed due to python updates in asyncio and complaining about calling certain function not from the main loop. This is now fixed.
I’ve tried out the Armed/Bypass selector. It initially shows Arm and Bypass. If I select Bypass, it displays Pending and there’s no obvious way to revert back to Arm. Is this expected behavior?
Hi Rob
It’s getting stuck somewhere.
There’s no timeout processing so I assume that either:
- my code is broken somewhere or
- your panel doesn’t accept bypass commands and my code is waiting for the panel to report that it has set the sensor to bypass.
The procedure should be:
- frontend shows Armed
- select Bypass
- state changes to Pending
- frontend show Pending
- send Bypass command to panel
- wait for panel to change sensor to Bypass
- state changes to Bypass
- frontend show Bypass
It looks like it’s getting stuck at “wait for panel to change sensor to Bypass”, perhaps I need to consider a timeout so if it doesn’t happen in say 2 seconds then report a failure and change State and frontend to represent what the panel is currently reporting.
Also, if you know how to call the service from developer tools to bypass the sensor that would be a good test as well. Something like this, with the code changed to be valid for your panel. You can use the “Fill Example Data” and it will insert an example for you to change.
Once again, can you upload a log file please
Hi Dave,
I verified ‘Allow each sensor to be bypassed’ was checked in the configuration and ran the test. This is what I saw in the log file when attempting to bypass z04. The sensor never changes to Bypass. Am I missing some setting in the alarm panel?
021-07-26 18:44:09 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [handle_msgtypeA5] Parsing A5 packet 10 0a 00 00 00 00 00 00 00 00 43
2021-07-26 18:44:09 DEBUG (SyncWorker_4) [custom_components.visonic.select] Sending Option Bypass to visonic_z04
2021-07-26 18:44:09 DEBUG (SyncWorker_4) [custom_components.visonic.client] Visonic update event 12 {'PanelReady': True, 'OpenZones': [], 'Bypass': [], 'Tamper': [], 'ZoneTamper': [], 'Command': 'Bypass', 'Reason': 6, 'Message': 'Sensor Arm State Disabled by panel settings', 'condition': 12}
2021-07-26 18:44:09 DEBUG (SyncWorker_4) [custom_components.visonic.client] [Sensor Arm State] Disabled by panel settings
2021-07-26 18:44:09 DEBUG (MainThread) [custom_components.visonic.pyvisonic] [sendPdu] Sending Command (Ack) raw data 0d 02 fd 0a waiting for message response []
Edit: I reran the test to capture all the events: https://pastebin.com/A0HKy6Yy
Here are the times:
21:45:00 – Initial conditions; frontend shows z04 Armed
21:46:02 – Bypass is selected
21:47:38 – Bypass service call attempted
Hi Rob,
The message in the log file " [Sensor Arm State] Disabled by panel settings means that you have it disabled in your integration settings. In Home Assistant on the Integrations panel, Configure the integration and look for this
The bottom setting needs to be ticked. If you change it then select submit and go through the other menus and finally click finish. Can you confirm this please.
If you definitelly have this ticked and you still get the same message in the log file, then I need a log file from starting the integration to make sure the settings are getting through please.
D
Yup, they’re ticked:
FYI: Here’s the service call configuration:
The log is huge. Here’s startup through Powerlink, but if you need more, I can run the same test and make it contiguous.
Thanks again.
Hi Rob,
I’ve looked at your log files and I think I’ve spotted the problem. In your panel settings (on the panel itself) there should be a menu option somewhere to enable sensor bypass (and not panel bypass).
I believe that your panel is currently set to “No Bypass”.
You should be able to check this in HA.
Developer Tools → States.
Look at the attributes of alarm_control_panel.visonic_alarm and find Bypass like this
Mine is set to Manual Bypass as you can see, I think yours is currently set to “No Bypass”. The panel is currently stopping sensors being bypassed.
Let me know if this is it or not please
Thanks
Yes, that’s it.
I’ll change the panel setting, check things out, and let you know if it’s working.
Once again, thanks.
Edit: Changed the panel setting and it’s working.
New release on Github: 0.6.11.1
A lot more frontend notifications for the Select Entity for when things don’t go as planned. I’ve probably gone a bit over the top so if you use the new Select Entity to arm/bypass your sensors then after a while I plan to cut down on the notifications when things settle down.
There’s also a 3 second timeout, if the panel hasn’t responded to the request within this time then the Select Entity goes back to representing the state of the sensors bypass value.
1 Like