Download code should be fine, as mentioned has been working under Vera for some time and it has managed to go into Standard Plus a couple of times and Powerlink mode once using this component.
Last night I stopped HA and fired up the test.py program with similar results as before i.e. the panel seems to ignore the download command completely but is otherwise fine working in Standard mode.
I then reverted to the openLuup (Vera) and Visonic plugin to see if there was any difference, but the same thing occurs there now, so my suspicion at the moment is that perhaps the panel is in an odd state?
As it was late, I restarted HA and went to bed, I’ve noticed this morning some slightly different behaviour in the log at startup as this time there’s a “Download Timer has Expired” message and no further attempts.
Next I will stop HA and leave it off for a few hours, then try the test.py again to see if the panel recovers by itself.
Is there anything else you’d like me to try?
My memory is a bit fuzzy on how the Powermax+ works as it was many years ago that I played around with it under the Vera plugin to initially get it working, but with your component startup flow I see it trying to “enroll as a powerlink device” … why does it do that every time? Isn’t the panel already in powerlink mode (because on the Powermax+ you manually set that in the menu). Apologies if that’s a dumb question, as I said I’m a bit vague on the protocol now!
Hi Dave,
Thanks for the good work. I’m using the Visonic Powermax + in combination with raspberry pi 2b for 6 months now and it works good, but I have the following question, the time in the display of the Powermax + is not synchronising with my Raspberry pi time, other question, sometimes de the HA remains in standard mode instead of powerlink mode, so a button to restart the connection is preferable I think I agree with the posts above. Last question I have, does the release 0.3.4 of your components, provide a solution for the HA 103.2 update?
Hi and thanks.
With a Powermax+ the time sync doesn’t work, it only works for Powermax Pro I think. I don’t think it works for PowerMaster panels either, I’m not 100% sure.
The Standard/Powerlink thing I believe to be related to timing issues between HA and the panel, so it depends on what you run HA on and what other Components you have running. The faster the CPU and the more memory the better I would expect. Having said that, I’ll think about how to do a “reconnect to panel” feature.
Release 0.3.4 needs HA version 103.0 as a minimum as it includes the new
Add supported_features to Alarm Control Panel to limit device_actions (@SukramJ - #29065)
By comparing how the openLuup / Vera plugin works with how your component seems to work, I think it’s because on the Powermax+ (certainly the version that I have) you have to do the Powerlink enrollment from the panel itself.
So here’s how this seems to work consistently under openLuup / Vera:
Start the openLuup / Vera plugin
It connects to the panel and operates in a Standard mode
It periodically tries to Download and gets denied
Carries on like that … until …
I go into the installer menu on the panel and Define Powerlink
Panel sends an 0D AB 0A 00 01 00 00 00 00 00 00 00 43 06 0A
Plugin replies with an 0D AB 0A 00 00 56 50 00 00 00 00 00 43 60 0A
Panel gives the triple-beep confirmation and Powerlink is enrolled
I exit installer menu and the panel immediately shows “Downloading”
Plugin is off and running, got the EEPROM and is now in Powerlink mode
If I now stop the openLuup / Vera plugin and start the test.py straight away it will operate in Standard mode but never get a reply to the Download command (until it times out).
If I now restart the openLuup / Vera plugin it goes straight back in with a Download and is up and running again.
If I clear the Powerlink enrollment on the panel and then start test.py it seems to alternate between sometimes trying to download (and timing out) and sometimes trying to download and then trying to enroll. I can’t quite see what determines whether it operates with the former or latter behaviour.
When it tries to enroll itself I think this is where it’s not quite right because the panel never seems to reply to the enroll request. I think it’s here that the panel is expecting to initiate the Powerlink enrollment and then expecting to receive a reply, whereas your component is itself initiating the Powerlink enrollment and expecting to receive a reply.
Sometimes I can go into the panel and Define Powerlink and depending on the timing of where the component is in the enrollment process, it will sometimes work, but most of the time the panel will give a single loooooong beep that indicates a failure to enroll.
I did capture some extensive logs of all of this today from the openLuup / Vera Plugin and from the test.py output, happy to upload those - but equally so I understand that this is an old panel and probably a corner case so no problem if you’d rather not dig any deeper!
OK thank’s for the detailed information, I don’t need your detailed logs yet but the description helped me a lot.
I’ve just uploaded version 0.3.4.1 to Github, can you give it a try.
A few things I’ve been up to:
I’ve added a service to close and reconnect the connection to the panel, it is called visonic.alarm_panel_reconnect. If you go to developer tools and then services, you should be able to select it from the drop down list. Just click “call service” as there are no parameters.
I’ve looked a bit further through your previous log files, and using your 1 to 10 above. In your item 3, when you say “gets denied” how do you know. Can you see an “08” access denied message anywhere?
I’ve made quite a few changes to try and accommodate your Powermax+ and I react to the enroll request (item 6 in your list) now.
If it doesn’t succeed on its own then try to do item 5 on your list within 3 minutes of starting HA (or following a reset of you use the new service)
Hopefully the changes I’ve made won’t break it for everyone else but this release is specifically for you
EDIT: Since you can run test.py on a Windows PC, would you be able to run bridge.py and install the Visonic Software “Remote Programmer” and connect to your panel. It uses a COM port on a windows PC. Look here and here
I’ll try the new code a bit later on, it’s a little complicated here as I’m running a Docker with an older version of HA so will need to update that first.
Although presume I can test outside of HA with test.py instead as a first step?
Yes, so the openLuup / Vera plugin periodically sends the download command and handles the 08 reply:
POWERMAX: PDU sent to panel: 0D 24 00 00 56 50 00 00 00 00 00 00 35 0A
POWERMAX: PDU received 0D 08 F7 0A
POWERMAX: PDU sent to panel: 0D 02 FD 0A
POWERMAX: Handling DENIED message (24)
POWERMAX: Vera Powerlink not enrolled.
I’m actually on Linux for the most part here but can dig out a Windows PC and give this a go too.
Why is it that I can send exactly the same PDU to the panel “0D 24 00 etc” and I don’t get back an “08” message? I don’t understand this, do you have any ideas? It’s line 33 in the log file you uploaded. Perhaps it’s because of the messages I send before that, perhaps I shouldn’t send Exit, Stop or Init? Something to think about.
EDIT: Perhaps you could upload the vera log file, that might help me
OK, fair enough. If you can’t do it easily then don’t spend too much time doing this, it would just show the interaction to upload the EPROM from the panel with a manually enrolled panel, if you see what I mean.
I went to the panel at around line 130 or so and went into the Define Powerlink option a few times, but got the loooong beep on each time.
When I got back to the PC it didn’t seem to have registered any of that at all? And then the timer expires and a short time later it stopped completely.
I restarted test.py and oddly at that point it seems to “see” those enroll requests? It’s almost like something caused all of that to get stuck in the panel outbound buffer perhaps?
They’re quite verbose (and have some other non-Visonic stuff going on in there too). You should be able to see the initial startup in the first log file and then the second log file at around line 1530 is after carrying out the Define Powerlink process on the panel.
It seemed to be the INIT that stopped the panel replying with an access denied to the download command. After commenting out that INIT, I was getting the access denied … but then it was trying to auto-enroll Powerlink and getting stuck there (even if I went into the Define Powerlink menu on the panel at that point).
After commenting out that ENROLL command, the sequence seemed to be:
Try to download
Get access denied
Don’t auto-enroll
Download timeout
So, if I then restarted and went into the panel and Define Powerlink between step 3 and step 4, I get the triple beep to indicate success, the download seemed to complete and we’re off and running.
Unfortunately my screen buffer didn’t keep all the logs for the above
I’ve run out of time today, but tomorrow I will delete the Powerlink from the panel and start the whole process again, making sure I get a log of it.
In the meantime, I’ve not looked too deeply at the ramifications of my changes above, but I think that all that’s needed are a couple of settings to not send that initial INIT and to not try to automatically ENROLL?
That’s really good, commenting out the INIT would have been my next move, then the EXIT and STOP.
I’ve uploaded version 0.3.4.2 to Github, can you give it a try.
Commenting out INIT is a good move I think. Looking at the Vera Lua code, there are only 2 conditions where this command is sent to the panel:
when there is a new plugin version
there’s a communication error and an exception has been caused
These seem weird to me but I’m sure it makes sense to someone. Anyway, I no longer send INIT at all.
I’ve incorporated these changes (in a slightly different way) but the main thing for all users is the commenting out of the INIT.
I’ve also undone some of the changes from 0.3.4.1 that didn’t make a difference, and some debug code changed.
I’ve also made my auto enroll code section depend on the panel type, so for you it should not try to auto enroll, it has to wait for the panel or if the panel sends a powerlink keep-alive (then it already thinks we’re in powerlink state).
Let me know how you get on with this release please, you shouldn’t need to edit any code
You can create a button in HA to call the service “visonic.alarm_panel_reconnect”. Give it a try and let me know how you get on I’m not admitting too widely about it and haven’t yet included it under the “services” list on Github as it needs some testing with more than just my panel.
This time it completes the download and gets to Standard Plus mode but doesn’t seem to get to Powerlink mode, it’s possible the panel timed out the Powerlink keep-alives from earlier on so perhaps I need to restart it, which I’ll do tomorrow.
test.py did crash eventually, does it look like the panel terminated the connection?
What you are seeing looks correct.
With a Powermax+ and version 0.3.4.2 I no longer attempt to connect in Powerlink unless the panel sends me powerlink “Keep-Alive” which yours has stopped doing by the looks of your log file. So it will stay in “Standard Plus” mode. You would need to establish powerlink from your panel again manually, hopefully that should prompt my component to establish powerlink.
I don’t think the panel terminated the connection, I think it’s my fault, I’ve squashed another bug in the code. Lines 1607 to 1610 look like this now if you want to do a temporary fix but hopefully you wouldn’t see this normally, it’s just a move of a line of code upwards i.e. cut and paste.
Will check this tomorrow, from memory it’s still got Powerlink defined when this happens, but it’s stopped sending the keep-alives - I think that a restart of the panel sorts it when this has happened with the openLuup / Vera plugin before (if it doesn’t manage to self-recover). I don’t remember having to delete and then Define the Powerlink again … but I may be wrong.
Ah so it’s possible that it might have eventually got to Powerlink mode IF it had continued running (and received a keep-alive?
I’ll add that fix tomorrow and retry.
No problem at all, although I’m sure I’m getting more out of it than you are!
I had had high wifi congestions/interferences headaches recently with my now abandoned ESP32 wifi integration so network failure experiences was something I first think to challenge onto this new reconnect service.
Nothing serious/urgent as it’s a (great) nice to have new feature but i think i found an issue, maybe just caused by the way i (stress)tested it, involving changing IP adress on USR-TCP232-T2 module to simulate an network connection loss and restart the USR and reset it back(so also serial line break)
Then when calling to visonic.alarm_panel_reconnect service, it nicely restores sensors that had been frozen by previous loss of comms but the alarm_control_panel stay in a failed state as it is not able anymore to arm the panel.
Restarting HA restores a good panel behavior.
Here are detailled logs where you’ll see stacktraces and the alarm_control_panel.visonic_alarm’s “Entity id already exists” error : https://pastebin.com/raw/4s1RKU9T
You are very much in demand at the moment, the compatibility of a powermax+ model is far more important for this integration so there is no hurry for it, it was mainly to inform you of this (particular?)case.
Before I called it a night last night I restarted the HA Docker instance (which is running an older version of HA and the component) and interestingly it went straight into Powerlink mode and continues to be OK this morning. So I think the panel itself was OK and the unintended test.py crash was a red herring.
I’ve stopped HA again now, added the temporary fix and will leave test.py running today (it got Powerlink mode after just 11 seconds).
If all looks good I’ll need to update my HA Docker instance to the latest HA version, then the latest component and see how it goes!
I’ll give this a go too, perhaps a future revision could be a separate stop / start button and a setting to disable (or perhaps delay) auto-start ? I figure that by not automatically starting with HA then you give HA a chance to settle and shed that initial load burden. Then the component can start after a configurable delay to suit each persons install. Or manually start it with a start button.
I’ve just uploaded release 0.3.4.3 that fixes the issue with my panel, can you give it a try. I used to remove the alarm panel config entity and now I keep it.
I’ve tried doing this and it won’t work. I can stop the Component but then I can’t get it to start again yet the same functions are used to do a reconnect (stop then start in sequence) and that works. I don’t understand but I’ll give it some more thought.
This may be confusing for people and is not what HA seem to want developers to do. I’ve tried to make the Component so that it doesn’t rely on timing, I think that’s a better way to go.
This sounds promising, keep me updated as to how you get on. I’ve included the fix in release 0.3.4.3 that I’ve just uploaded to Github. Assuming it works would you also write a few sentences describing how you set up your Powermax+ and how to get it working, it would be useful for me to include in the readme/wiki if that would be OK
It looks odd to me because the first packets received seem to be Powerlink keep-alives? Then the download completed and we got to Standard Plus mode, but there’s no further Powerlink keep-alives so we didn’t get to Powerlink mode.
Is it possible that those first packets were stuck in a buffer somewhere and are old?
I’ve left test.py running again, will restart the panel next and see if it recovers.
Of course no problem, once I get to the point of updating HA and the component there, I’ll start the whole process from scratch and document it.
EDIT: I restarted the panel and that’s started the Powerlink keep-alives again and test.py has recovered to Powerlink mode. I uploaded a log showing that to Dropbox - File Deleted - Simplify your life
For both log files that are “stopped”, the end of the file is like this. This specific extract is from the end of the original but they are both very similar.
0:12:15.952379 < 2630> DEBUG [handle_msgtypeA5] Parsing A5 packet 09 09 00 00 00 00 00 00 00 00 43
0:12:16.061673 < 1558> DEBUG [pmSendPdu] Sending Command (Ack Long) raw data 0d 02 43 ba 0a waiting for message response []
0:13:30.894315 < 1621> DEBUG [pmSendPdu] Resetting expected response counter, it got to 75 Response list before 0 after 2
0:13:30.896927 < 1558> DEBUG [pmSendPdu] Sending Command (Restore PowerMax/Master Connection) raw data 0d ab 06 00 00 00 00 00 00 00 00 00 43 0b 0a waiting for message response ['0XA5', '0X2']
0:13:30.902052 < 1066> ERROR ERROR Connection Lost : disconnected due to exception [Errno 104] Connection reset by peer
0:13:35.908561 < 1075> ERROR No Exception handler to call, terminating Component......
So:
The panel sends an A5 message that is decoded.
75 seconds later (approx) my Component asks the panel for an update using the “MSG_RESTORE” request.
The same request is done all the time and has happened 5 times previously in the same log file with the correct response from the panel.
Those previous 5 times didn’t leave it as long as 75 seconds, the timing depends what is happening with the panel
That last request causes an exception and stops test.py.
So, could there be a timeout on the comms between your PC and the gadget you have in your panel, perhaps if there’s no bytes sent after XX seconds ( < 75 ) it shuts the connection down?
EDIT: It could be the panel itself that decides to shut the connection down after too many seconds
Looking at the 2 “restarted” files:
In the original, it doesn’t achieve powerlink and I haven’t gone through in fine detail but there isn’t a time gap big enough for this to happen
Similarly for the second file, there isn’t a time gap bit enough for this to happen
In the code I have this
status_counter = status_counter + 1
if status_counter >= 3: # every twice around the loop i.e every KEEP_ALIVE_PERIOD * 3 seconds
status_counter = 0
if self.pmPowerlinkMode:
self.SendCommand("MSG_RESTORE") #
else:
self.SendCommand("MSG_STATUS") # Asks the panel to send us the A5 message set
The constant KEEP_ALIVE_PERIOD is set to 25 seconds at the top of the pyvisonic.py file.
I suggest that you change
if status_counter >= 3:
to
if status_counter >= 2:
and give it a try. This would leave a maximum of 50 seconds between comms.
I used to have it set to 2 (as in the comment “every twice around…” but for some reason changed it to 3). I assume that you’re confident enough to make this change or I wouldn’t ask, it just saves me uploading another release to Github when we’re just testing something. But if you’re not then I can do a Github update
but the description helped me a lot.
I’m not admitting too widely about it and haven’t yet included it under the “services” list on Github as it needs some testing with more than just my panel.