Can you set your logger as per my wiki page and upload a log file please, I may then be able to spot what is going on to be able to help you. I need the start of the log file to see your settings and EEPROM download to get to a normal powerlink connected state and then the point in the log file where the connection is broken. That’s likely to be about the first 1500 lines and then probably search for “PyVisonic has caused an exception” in the log file and then a few hundred lines either side of this.
thank you for your help
I cannot activate the log file
When i add the integration, I must tick the box "Force auto enroll for the powermax+ panel ?
it seems contrary to the wiki (This will work but needs to be Manually Enrolled (please set force_autoenroll to ‘no’). (i have a visonic powermax+)
In the general log, i can see when i lost the connection :
Logger: pyvisonic
Source: /usr/local/lib/python3.8/site-packages/pyvisonic/__init__.py:1362
First occurred: 13:28:50 (1 occurrences)
Last logged: 13:28:50
ERROR Connection Lost : disconnected due to exception [Errno 104] Connection reset by peer
Logger: pyvisonic
Source: /usr/local/lib/python3.8/site-packages/pyvisonic/__init__.py:1386
First occurred: 13:28:55 (1 occurrences)
Last logged: 13:28:55
Calling Exception handler.
Logger: custom_components.visonic.client
Source: custom_components/visonic/client.py:116
Integration: Visonic Intruder Alarm ([documentation](https://github.com/davesmeghead/visonic/wiki))
First occurred: 13:29:02 (1 occurrences)
Last logged: 13:29:02
Failed to connect into Visonic Alarm. Check Settings.
when I add the integration I have this :
Logger: pyvisonic
Source: /usr/local/lib/python3.8/site-packages/pyvisonic/__init__.py:1725
First occurred: 13:18:50 (3 occurrences)
Last logged: 13:24:23
* [data receiver] Warning : Construction of incoming packet validation failed - Message = 0d f1 07 43 00 00 8b 56 0a 0d 02 43 ba 0a checksum calcs 0X85
* [data receiver] Warning : Construction of incoming packet validation failed - Message = 0d f1 07 43 00 00 8b 56 0a 0d ab 03 00 1e checksum calcs 0X1C
* [data receiver] Warning : Construction of incoming packet validation failed - Message = 0d f1 07 43 00 00 8b 56 0a 0d a5 00 02 00 checksum calcs 0X25
and after manually connecting powerlink from the alarm :
Logger: pyvisonic
Source: /usr/local/lib/python3.8/site-packages/pyvisonic/__init__.py:3444
First occurred: 13:24:28 (1 occurrences)
Last logged: 13:24:28
[handle_msgtypeA7] Panel has been reset. Don't do anything and the comms might reconnect and magically continue
Is there anywhere I can download updated firmware for my PowerMax ? I bought it in 2007, so I assume there are updates.
I am using esp-link, and it seems it loses connection once in a while despite having a -43 to -51 dBm signal
I would be happy as well if the code was updated, such that if it detect connection failures, it will wait 30 secs and retry so I get rid of the “Failed to connect into Visonic Alarm. Check Settings. status”
After reboot of HomeAssistant, I always gets a working connection.
Update: Found the call I can always do if it is down: visonic.alarm_panel_reconnect - Did not work. But I will try and get some logic running to try it automatically
New update.
Did a wireshark test. Panel working. Then reconnect.
FIN/ACK and new connection with SYN, SYN/ACK.
Never seems to come up again on the HA side, yet they are talk back and forth the 30 seconds I wait before doing a restart. HA sends 415 bytes and receives 2845.
Doing the restart shuts down the connection nicely. Then 37 seconds passes, and communications happens again. This time with success…
After about 30 seconds, we are close to the same number of bytes exchanged.
To me the flow on the failed reconnect, and the successfull connect looks more or less the same, yet the code says that the connection failed. But behind the scenes it looks like the same amount of data keeps flowing. So communications runs as usual. So maybe it is just front-end failing ?
Guess I have to look at bit more at the code, possible insert some debug stuff, and then create issues on github
Assuming you’re not using HA-OS, I have a few random thoughts…
Check and see if the ModemManager process is running. If so, disable and stop it using the systemctl command. Also double check the UART settings on the esp-link configuration.
Lastly – and this is just good practice – ensure the logic levels of the signals are compatible. If the panel is 5 volts and the esp-link is using 3.3 volt logic, you might have reduced or negative logic levels margins in one direction, and the potential for an over-driven input in the other.
My ESP-Link is running on an ESP-12 board. It is 3.3V, but I/O is 5V tolerant. Not sure with the powerMax. But things runs mostly stable, once in a while I get a disconnect that never recovers.
The reconnect command does that, and the debug log shows everything is perfect, but the GUI shows the error and does not update anything. But the Aync handlers behind the scene still works, and the debug log looks perfect after the reconnect.
But I get the error in the log, and I can not see a status, but debug log shows everything running as normal.
So something is wrong with the code. Either this or the pyvisonic.py library
OK. Understand. I’m primarily a hardware guy, so I was concerned about logic levels and other related things I’ve seen before. You’re already in the right forum for the integration. Dave will likely comment soon, but configure the logging for debug in the meantime.
Seems to be in pyvisonic things are bad.
2020-12-17 21:22:28 DEBUG (MainThread) [pyvisonic] Setting TCP socket Options
2020-12-17 21:22:29 DEBUG (MainThread) [pyvisonic] Waiting for Protocol Handler to Start
2020-12-17 21:22:30 DEBUG (MainThread) [pyvisonic] Waiting for Protocol Handler to Start
2020-12-17 21:22:30 DEBUG (MainThread) [pyvisonic] Waiting for Protocol Handler to Start
2020-12-17 21:22:31 DEBUG (MainThread) [pyvisonic] Waiting for Protocol Handler to Start
2020-12-17 21:22:31 WARNING (MainThread) [custom_components.visonic.client] Failed to connect into Visonic Alarm. Check Settings.
But then I do not understand why things keeps comming in the debug log like everything works. Will create a github issue
You’ve got it wrong and it’s my fault, I wasn’t clear enough.
The log setting that you have used is to get the event log from the alarm panel.
That is not what I need to see.
Please set the logger settings as per this in your configuration.yaml file and restart Home Assistant.
Make sure there are pyvisonic.py entries in the home-assistant.log log file.
If you have a powermax+ then set this to False (unticked). With a powermax+ previous users experience the panel does not like the autoenroll command at all and it causes problems.
The wording in the setup could be taken 2 different ways so I will change that to make it better.
I assume that you mean the home-assistant.log file. If you set the logger file settings above then I will get the information I need to help. You will see a lot more detail in the log file
No. Visonic do not provide firmware updates to anyone but their closest installers.
I would expect that this works. Please set you logger settings as per the description on the wiki here. Try to call the service from the developer tools and upload to pastebin/dropbox please.
Please upload a log file so I can work through it.
Feel free to create issues on github, that’s what it is there for. However, without any evidence from a log file there isn’t going to be much I can do.
I like to see the first 1500 lines of the log file to see how the integration started up.
Then give me approx 200 lines each side of a crash report in the log file when it restarts
I keep looking at code, found out the github version is not the pip installed version. Not sure where that is maintained.
The problem is in the pyvisonic library. Tried to set the wait_for_connection count to 50 with no luck. My guess is that it is a timeout issue.
No matter how high I put count = 4 in the wait code, I get a timeout. The EventHandler is always called much later, after [pyvisonic] [Settings] B0 Max Wait Time set to 5 which is part of the ProtocolBase of the connection, so it makes sense.
There is no crash report. Only as below, then everything seems to work in the log.
But the failure (WARNING) basically marks the integration as being down, despite everything running normally after.
As I can see, it is the EventHandling constructor that is setting the value that dc.getPyVisonic() tries to wait for. But no matter how high I make count in wait_for_connection, the EventHandling Constructor is never called before after the timeout. Since it is called at that time, all the async stuff keeps talking to the alarm without HA knowing about it.
BTW: I am using the containerized installation on an ARM64 based TVbox.
2020-12-17 23:59:42 DEBUG (MainThread) [pyvisonic] Setting TCP socket Options
2020-12-17 23:59:43 DEBUG (MainThread) [pyvisonic] Waiting for Protocol Handler to Start
2020-12-17 23:59:43 DEBUG (MainThread) [pyvisonic] Waiting for Protocol Handler to Start
2020-12-17 23:59:44 DEBUG (MainThread) [pyvisonic] Waiting for Protocol Handler to Start
2020-12-17 23:59:44 DEBUG (MainThread) [pyvisonic] Waiting for Protocol Handler to Start
2020-12-17 23:59:48 WARNING (MainThread) [custom_components.visonic.client] Failed to connect into Visonic Alarm. Check Settings.
2020-12-17 23:59:48 DEBUG (MainThread) [pyvisonic] [Settings] Force Standard set to False
2020-12-17 23:59:48 DEBUG (MainThread) [pyvisonic] [Settings] Force Auto Enroll set to False
2020-12-17 23:59:48 DEBUG (MainThread) [pyvisonic] [Settings] Force Auto Sync Time set to True
2020-12-17 23:59:48 DEBUG (MainThread) [pyvisonic] [Settings] Download Code set to 15 09
2020-12-17 23:59:48 DEBUG (MainThread) [pyvisonic] [Settings] Language set to EN
2020-12-17 23:59:48 DEBUG (MainThread) [pyvisonic] [Settings] Remote Arm set to True
2020-12-17 23:59:48 DEBUG (MainThread) [pyvisonic] [Settings] Remote DisArm set to True
2020-12-17 23:59:48 DEBUG (MainThread) [pyvisonic] [Settings] Enable Sensor Bypass set to False
2020-12-17 23:59:48 DEBUG (MainThread) [pyvisonic] [Settings] Motion Off Delay set to 120
2020-12-17 23:59:48 DEBUG (MainThread) [pyvisonic] [Settings] Override Code in new settings, the length is 4 isdigit = True
2020-12-17 23:59:48 DEBUG (MainThread) [pyvisonic] [Settings] Override Code set <omitted for security>
2020-12-17 23:59:48 DEBUG (MainThread) [pyvisonic] [Settings] Force Numeric Keypad set to False
2020-12-17 23:59:48 DEBUG (MainThread) [pyvisonic] [Settings] Arm Without Code set to True
2020-12-17 23:59:48 DEBUG (MainThread) [pyvisonic] [Settings] Siren Trigger List set to ['intruder']
2020-12-17 23:59:48 DEBUG (MainThread) [pyvisonic] [Settings] B0 Enable set to False
2020-12-17 23:59:48 DEBUG (MainThread) [pyvisonic] [Settings] B0 Min Interval set to 30
2020-12-17 23:59:48 DEBUG (MainThread) [pyvisonic] [Settings] B0 Max Wait Time set to 5
2020-12-17 23:59:48 DEBUG (MainThread) [pyvisonic] [EventHandling] client is not None, calling setPyVisonic <class 'pyvisonic.dummyclient'>
2020-12-17 23:59:48 DEBUG (MainThread) [pyvisonic] [Connection] Connected to local Protocol handler and Transport Layer
2020-12-17 23:59:48 DEBUG (MainThread) [pyvisonic] [ClearList] Setting queue empty
On the code page on github here it says that release 0.6.0.0 was split in order for me to start integrating it with Home Assistant core. HA insist that direct interface code to devices are in a pypi library. It says in the description that it is a pypi library called pyvisonic. It’s here.
What version of python do you have installed? It should be 3.8 or higher, can you please check. It looks like the python asyncio library is not working properly.
EDIT: Could you also try to install and run Home Assistant on another device please, a Windows PC would be best. Just use the default config and just add this integration to see if it works.
I am on Python 3.8.6
Using latest home assistant.
As said, everything works on first connect. Reconnect always fails. Think this has been the case for months - as it never recovered from lost connection.
I am not a python guy, just picked up a little along the way. So don’t know inner workings of async, threads, constructors etc.
Looking at Asyncio I see:
Coroutines and Tasks — Python 3.9.1 documentation
Event loops use cooperative scheduling: an event loop runs one Task at a time. While a Task awaits for the completion of a Future, the event loop runs other Tasks, callbacks, or performs IO operations.
So maybe on reconnect the create_task(conn) is created, but is queued until return.
I’ve been updating the code base quite a bit over the last 6 weeks but most of it is from using the auto code formatter black that I need to apply before submitting it for inclusion in to the HA Core as a new integration. However, I’ve come to realise lately that submitting this as a new integration is going to take many many months and so I’ve reverted back to not using a pypi library for the next few months or so to give me flexibility to make code changes.
I created a pull request against Home Assistant core to propose some minor changes and it’s going nowhere. I am actually proposing 2 things:
- Include ability to display a keypad or not, depending on the logged in user, see here. The pull request is here
- The code parameter to arm and disarm should differentiate whether a keypad is shown or not, see here
If I can’t get a couple of minor changes in HA, what chance do i have of getting 1000s of new lines of code accepted for a new integration 
.
Anyway, I have a full development environment set up for the HA backend and frontend so I can easily see and debug what’s happening now, at least within my own setup.
One of the aspects that I’ve been working on is to make the config, start and restart of the integration more reliable. So I’ve created a new release 0.6.1.0 so please give it a go.
As an aside: I toyed with the idea of doing minimal change to 0.6.0.0 to push out the update (without all the auto code changes) but then I thought “just go for it” as it would involve lots more effort. With that in mind this release has lots of changes, mostly automated but some that I’ve done, I also toyed with the idea of making it 0.7.0.0 as it is quite a change, but didn’t.
I’ve had this 0.6.1.0 release running in my own production environment for a couple of weeks now so … it should be OK.
Give it a try and let me know 
Hi @pocket
The module I bought and installed in my Visonic panel was a “WiFi to Serial” board. I assume this is recognised by the HA Visonic component as being Ethernet (as that is what i selected when configuring it).
You may be correct that removing brltty has nothing to do with the issues, but I removed it anyway. But still to this day I still have to rely on luck of the draw as to whether or not the Visonic component starts up correctly after a reboot.
I fear rebooting, because when I do, I break Visonic, and have to reboot about 10 times and try all sorts of different things (like uninstalling, reinstalling etc).
New Find: I did notice that if I actually reboot my actual server itself, and in turn this will restart HA, and the components all as freshly loaded, I tend to get a successful load.
Thanks for still looking into this. I can see you’re busy, because I have just noticed you posted:
One of the aspects that I’ve been working on is to make the config, start and restart of the integration more reliable. So I’ve created a new release 0.6.1.0 so please give it a go.
This sounds promising, so I’m going to install it now.
UPDATE: I just installed 0.6.1.0 and also upgraded to Supervisor 2020.12.1 and done a HA restart. And the Visonic component has loaded perfectly first time 
Thanks for the feedback, I’ll take it as a good sign but I’ll wait for others to try it as well before I celebrate 
Do you know how to call a service using developer tools? Can you try calling visonic.alarm_panel_reconnect and see if it disconnects and then reconnects please, there is no service data for it so it’s fairly easy to do. If it doesn’t work you know what to do by now, upload a log file 
1 Like
I see you have things running now, thanks to Dave.
1 Like
I updated my configuration.yaml again to enable the necessary logging and restarted HA and it came back up at 16:33 - the Visonic component loaded fully shortly after with no issues. This is fantastic!
Then at 16:45 I executed a call service on: visonic.alarm_panel_reconnect - the Visonic component didn’t break, and the Lovelace dashboard is showing my alarm panel cards and entities without error. I can see in the logs that the component did indeed disconnect and reconnect. So, the fact that the component is running again without errors is double fantastic!
I then left the system to settle, and for the logs to gather for another 5 minutes.
I have uploaded the logs here: https://cl1p.net/ha_log_visonic_181220