A few days ago, I updated to 0.6.9.0 and things seemed to be working well until this morning. When checking the panel to see what was going on, it flagged a communication error. A Supervisor Restart resulted in the same problem after a few minutes, so I reset the panel. It’s working again in Standard Mode, but not without errors.
This release contains 2 bug fixes
First of all it fixes a bug in the case where data is received from the panel and then stops for a long period of time (I have set this to 10 minutes)
Secondly, it recognises what I suspect is a bug in the PowerMaster firmware so it doesn’t send EPROM data PDUs correctly every time, sometimes they are less than the correct number of bytes. I initially thought this was only PowerMaster 33 panels but I’ve seen it in PowerMaster 10 panels also
I think you have a problem with your set up. The integration achieves PowerLink Mode but at 17:02:59 the integration stops receiving any data from your panel. The integration keeps trying to receive for several hours after that. As you are using USB I suggest that you check to see if the software driver is going to sleep. I have updated my code as it wasn’t detecting this condition correctly, if it hasn’t received any data within a 10 minute period then it restarts the integration and attempt to reconnect (although this may not be successful).
Are you sure that you have the configuration settings ticked to allow remote arm and disarm. This could also be due to a disconnect as per the above problem. I’d need a log file to check further. as I said in the first post, when reporting a problem then please upload a log file to illustrate that problem.
The integration initially connected to the panel and achieved PowerLink Mode. It then receives the same packet for 40 consecutive messages in a row and I assume this to be the panel in error so I restart the integration. After this restart the downloading of the EPROM fails and so it only goes to Standard Mode. This is a known problem for PowerMaster 33 panels but I’ve never seen it before with PowerMaster 10 panels. I’ve added you panel and model to the list in the code so it bypasses failed EPROM data (in a limited way).
But that doesn’t resolve the same packet in a row for 40 times. If it happens again then please edit pyvisonic.py and change the SAME_PACKET_ERROR value on line 72, try making it a very large number such as 10000 and lets see what happens.
As an aside, you need to untick auto sync time in the config as PowerMaster panels cannot do this. The time on your panel also needs setting manually.
The panel does not tell the integration when it is sounding the siren so you need to set this configuration to be the same as the settings on your panel when it triggers the siren.
The Home Assistant Entity alarm_control_panel.visonic_alarm has an attribure called Panel Siren Active that is either True or False. You could create an Entity from this Attribute.
The Panel Siren Active Attribute is set to True based on the configuration setting
In my case I wanted more detailed information about the situation so I created a Home Assistant event as described here on the wiki. I include lots of event data that I can use in the Automation Action.
This is my automation that creates a persistent notification on Home Assistant and “pings” my mobile phone with an alert. I have to upload it as 2 screengrabs.
I installed 0.6.9.1 and set the clock and date while in Installer Mode. It appeared to reset when I exited. I have yet to change the value on line 72 of pyvisonic.py, but performed a Server Restart to see if the new protocol helps. It seems to alternate between Standard and Download mode.
I’ve rolled back to 0.6.8.2 and it’s doing the same thing. It’s as if the panel is in some new state. I let it run for a while and see if it changes to a stable mode. If you think I should do anything different, let me know.
In the meantime, here’s the log after the update to 0.6.9.1:
It’s trying to download EPROM data but getting an access denied, this is usually when it stops recognising the download code. It’s currently using the default 5650, please try overriding the download code to AAAA. You’ll need to delete the integration and add it (do not delete the files, just delete it from the integrations page) so that you can set the download code.
Although, it’s interesting that the panel is asking to auto enroll, perhaps I should check this in the code i.e. if download fails due to an access denied AND the panel asks to auto enroll then I should perhaps continue with the auto enroll instead of waiting for the download to progress, I’ll think about it.
EDIT: I’ve just looked closer and you’ve turned off “Auto Enroll Supported” in the settings, please tick this. Your panel is asking to auto enroll and you’ve disabled it. Try this first
Ugh. Yes, it’s working now. I did see the enrollment issue in the log, but I didn’t delete/reintegrate when I updated to 0.6.9.1. I just copied the 14 files, figuring the configuration wasn’t changed. Is this the wrong thing to do? That said, I did reintegrate when I rolled back to 0.6.8.2, and now when I restored 0.6.9.1.
Once again, I feel embarrassed.
Thanks for spending time to look at the log and the reply.
That’s OK, your first log file showed up a few problems so please keep an eye on it over the next few days. The config settings functionality hasn’t changed in a while so it should reuse previous settings, although I’m not 100% sure on this as it depends on the internal workings of HA.
I’m concerned about 2 things at the moment and I don’t think they are related to each other.
First of all, the downloading of the EPROM. I initially thought that this is only a problem with PowerMaster 33 Model 71 panels so I did a quick workaround for only that panel, but now that your panel has also shown up the same issue then it’s something to look out for. I added your panel to workaround. The workaround doesn’t fix it, it tolerates it and ignores the problem.
With your panel, in your first log file I saw the integration perform a normal start and then a restart that was provoked from receiving the same data 40 times in a sequence. The first start was OK, the EPROM downloaded OK, the second time it started showing problems part way through the download. I download the EPROM 128 bytes at a time and there are several of these to download. I might consider performing retries if I get a failure.
The second issue I’m looking at is receiving the same PDU data many times in a row and I recently changed my restart check from 20 to 40 before I restart the integration. I have had this in the past with my panel but it’s very difficult to provoke it to do it. When it has happened to me in the past I’ve tried everything to stop it and the only solution I found was to re-trigger an EPROM download so I decided to trigger a restart of the whole integration. If this is happening to users more regularly then perhaps I need to look at it again and take some action other than an integration restart.
Thanks for the comprehensive reply. The PowerMaster 33, 20, and 10 are all from a common product line, so I’m not surprised they have the same quirks.
Currently, I’m not using the alarm much as I’ve been staying close to home due to the pandemic. So there’s not much to keep an eye on other than to observe its behavior when I occasionally use it or upgrade the integration. I could configure the debug logs, but they can get very big unless I restart the supervisor every once in a while (which might be more useful to determine if communication is reliably established).
There might be another option. If there are specific filter attributes for which I can make template variables (e.g. timeouts, et. al.), I could record these values and log them. Those data would then be persistent in the HA recorder database. Is that something worth doing? If the idea has merit, just let me know what to record.
Moreover, if you have a state variable that’s used in establishing communication, it too could be recorded if you made it a filter attribute. I believe there’s a way to asynchronously record value change vs. continuous sampling; it would minimize the data volume. Maybe you’re doing this already.
If recovery is automated, the events would remain silent unless logging is enabled. If logged, it takes proactive action to sort through it. As suggested, if you can detect the events and create a metadata attribute, it can be recorded in HA and/or generate a notification.
As an aside, you might give some thought to a status panel that can display communication activity and error events. Here’s something from my software-defined router:
Perhaps there’s a Lovelace card that can handle the task.
It is a Home Assistant Event called visonic_alarm_panel_state_update. If you look closely at the automation in my post above I set the trigger type to Event and use an attribute of the event called condition being set to 3. Think of the condition as an attribute of the event, I create many more of these as part of the Event including the sensor that triggered the event. Here on the wiki is a description of them all.
You can see the event working if you go to “Developer Tools” > Events.
Type visonic_alarm_panel_state_update in the “Event to subscribe to” and click “Start Listening”. It looks like nothing is happening but now do things with the alarm, trigger sensors etc and you’ll see the event that is present on the Home Assistant Event Bus.
It shows condition set to 1, this means a sensor has been triggered and it tells you which sensor (Zone) and that it was violated (motion).
Click stop listening when you’re done
Don’t be put off by this and I understand it is complicated and difficult to understand and I don’t understand it all yet. Just copy the settings in my previous post exactly and try it.
To save you typing here is the yaml action
service_template: persistent_notification.create
data_template:
title: Alarm Siren
message: >-
{% set ety = trigger.event.data['Entity']|string %} {% if ety == 'None' %}
Alarm siren from unknown sensor {% else %} The Sensor that triggered the
Siren is the {{ state_attr(ety, 'friendly_name') }} {% endif %}
It’s a good idea and it’s something I do with my system although I mainly rely on the HA log files. I restart my Home Assistant at most every 10 days or so anyway, the log file does get quite large but it’s not too bad. There are 4 attributes of the alarm panel entity that I monitor:
Exception Count tells me if the integration has restarted the comms with the panel so if it’s more than 0 then I know to look at the log file. The 3 timeouts are also important and I do check out the log file as well. I create HA Entities from the 4 attributes so I can easily log and manipulate them. All except the “Watchdog Timeout (Past 24 Hours)” are cumulative and so I can check them easily and I don’t really need the history, I use them as indicators to look at the log file.
To be honest the main issue I have is the number of different panel types that I try to support and their variability. Each panel has its own timings, firmware nuances etc etc (software bugs don’t exist, what we have is special functionality ). I’m 100% rock solid with my own panel (a PowerMax Pro Plus i.e. panel type 4 model 71) but I recognise that is not the case with the other 7 or so panel types. If I did an integration for most other devices then there is either only 1 type or it has a manufacturer defined API that we could use. I picked an integration with no manufacturer API, no manufacturer defined protocol and several different panel types across a span of 2 decades. Do you see what I mean.
Overall I have no real idea of how many people are using this integration and what the spread of panel types is across those users. From the posts in the forum I estimate maybe a 100 users but it’s difficult to tell as some people could use it and never create a post. When people report genuine problems then I try to fix them in a generic way so it applies to all panel types. The PowerMaster panel introduced a few new status messages from the panel and as I don’t have this panel type it’s very difficult to investigate. I have tried in the past with different users but it’s difficult without me seeing a direct cause and effect i.e. I do something to the panel or trigger a sensor and then I see the status message come from the panel.
Anyway, enough of my ramblings.
I should probably add some of this discussion to the wiki
Thanks for the information. I’ll spend some time setting it up and looking for a card to to present the current values. In addition, I’ll try to add Panel Mode to the group. If I get it working, I’ll post it here. I’ll also set up the logs and accumulate some data. The communication has been stable the last couple of days, so I don’t expect to see much, if anything. Still, it’s not clear what happened when I upgraded to 0.9.9.1. HA behavior changes over time and there have been recent updates.
Yes, this has been a persistent issue. Perhaps I’ll keep an eye out for a used panel on eBay. It’s times like this that make me think I should’ve done that a couple of years ago.
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”
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.
