Hi Rob
I made several tests but always unsuccessful,
Something very strange also happen, when I woke up today and also yesterday, my HassIO was frozen, this was the first time this happened, When I disconnected the USB cable to restart it, I noticed that my USB CC2531 (Zigbee Hub) had the Red light still on, I had to disconnect the FTDI cable to turn it off, apparently the FTDI cable is Powering the raspberry pi USB Stack, this happen twice, today and yesterday, is this normal?
Dave told me there is another way to test the connecting using a Windows PC With Phyton 3 and a test program called Test.py.
How can I do that? Plugging the FTDI directly to the PC USB port.?
Hi David.
I’m sorry to hear you haven’t been successful in getting things working. We haven’t exhausted all possibilities yet, but my optimism is fading.
Unfortunately, I have no experience with the Zibee Hub. I’ve looked around a little and it appears the hardware is dependent upon a firmware load. The firmware would define the functionality of the hardware, including the red LED. Do you have a link to any documentation?
I don’t understand what you mean by ‘powering the raspberry pi USB Stack.’ Isn’t the FTDI serial cable is connected to the alarm panel? Power for the cable comes from the USB port of the Rpi.
There are many things that could cause HA to lock up. Have you looked at your system log for clues? If there’s any suspicious entry, try to correlate the time stamp to whatever else is going on with the system. Did you have a power interruption either night? Your microwave oven might provide a clue.
One thing that could cause trouble is your power supply. It needs to have enough current sourcing capacity for the Rpi board and the USB devices. Depending upon the model you’re using, 2.5 A or 3 A is considered the minimum current capacity. That said, the FTDI cable would require only tens of milliamperes unless the Tx output was shorted to ground.
Another thing to consider is that the Zigbee devce might somehow be conflicting with the FTDI cable. For cases where the misbehavior is repeatable, you can isolate a cause by establishing the simplest configuration and incrementally adding more devices. It can take days, however, to establish the stability of a configuration unless you know exactly how to force misbehavior.
Perhaps consider continuing debugging the alarm panel without the Zigbee or any other peripheral devices installed. Before making any changes, I would take a snapshot of your current configuration and move it to your PC.
I think you’re correct. What I can’t do is explain how it works as I’ve never needed to use it. As far as I know, Windows has no native support for Python. I believe the first thing you’d need to do is install the appropriate version of Python on your PC. Here’s a link that I just found:
https://www.python.org/downloads/windows/
Beyond that, look at Dave’s README.md file on the GitHub site:
https://github.com/davesmeghead/visonic#for-testing-without-ha
There are a few folks here who have used test.py to get the bits flowing. Dave might be an authoritative resource. 
Considering there’s a stability issue with your current HA configuration, it makes sense to decouple the alarm panel debugging from the Rpi. I’d move the FTDI cable to your PC and see what’s possible using the debug script.
To do this you would need to connect your PC to the alarm panel, presumably you would be able to plug the USB device in to your PC (with a USB extension if necessary).
See here for what to do.
Also, test.py is downloaded as part of the component but you can download it as a zip file from here
Edit: haha, I’m too late as usual 
Our posts passed each other in the darkness of the Interwebs.
After saying what I said in my previous post it occurred to me that you could download the Visonic Software “Remote Programmer” and connect to your panel. It uses a COM port on a windows PC.
Edit: I can’t find a download link but here’s the manual on the Visonic site
Edit2: Found the download link for the software on the visonic site here. The login username and password are in the pdf file in the previous edit.
I think I will stop trying to connect my HassIO to my panel for now, and instead try the PC - panel connection to see if it is possible to do it, but I’m losing hope this will ever work, I think my panel might be too old,
I think I will try the “Remote Programmer” first.
I don’t understand what you mean by ‘powering the raspberry pi USB Stack.’ Isn’t the FTDI serial cable is connected to the alarm panel? Power for the cable comes from the USB port of the Rpi.
What I meant was that, when I disconnected my Raspberry Pi from the power, everything connected to the Raspberry Pi should turn off, as there was no energy powering it, but what actually happened was that the FTDI cable connected to my panel was feeding energy back to my Raspberry Pi via the USB I only noticed it because I had a USB CC2531 dongle connected and the red led of the dongle was still turned on, and only turned off when I disconnected the FTDI Usb adapter from my Raspberry Pi.
I will try without the CC2531 dongle but I’m pretty sure that’s not the problem.
That’s possible, but I might call FTDI about that to see if there’s current limiting on the Rx path. I doubt we misidentified the 5 volt pin. It seems unlikely because there’s so much experience with the Powermax.
Edit: Make sure you don’t have both Tx lines connected together.
Try the PC with the panel. If it doesn’t work out, we might be able to identify what things to look for in a used panel.
Hello Dave,
I’m still working on getting my installation reliable and have another issue. I occasionally get disconnections from the panel but this time I cannot access the USR Wifi device with either ping or the web interface.
I have ordered a new one in case it’s a HW problem but, the more I think about it, I am not sure that is the issue. This is based upon that I have previously had the Wifi device’s web interface running for several months when I didn’t have HA running.
I looked through the logs and it does seem to be doing some strange things.
Anyway, if you get a chance…
https://pastebin.com/dbQLNwTu
Regards
Mark
Hi Rob and Dave.
I finally had some success connecting my PC to my panel with the Visonic PRP, I can connect with the panel and upload information from it and also make changes and download them to the panel, when my PC is connected to the panel the word “processando” (Portuguese for “processing”) is displayed on the screen.
I wasn’t able to connect with the panel using the script test.py, maybe I’m doing something wrong, this is what I get when I run the command:
python3 test.py -usb COM5
Traceback (most recent call last):
File "test.py", line 3, in <module>
import pyvisonic
File "C:\Users\david\OneDrive\Desktop\Hassio\Visonic\pyvisonic.py", line 39, in <module>
from dateutil.relativedelta import *
ModuleNotFoundError: No module named 'dateutil'
This is hopeful news. Let’s see what Dave recommends.
Ah yes, you’ve probably done a normal python3 install and so you’ll be some python libraries missing, do this and try again please
pip3 install pyserial
pip3 install python-datetime
pip3 install pyserial_asyncio
Hi Mark,
I’ve had a look through your log file extract and have a few observations but nothing really something that would fix your issues:
I noticed that HA and the panel loses communications and my Component tries to reconnect with the panel. The first time is at line 55.
I think that the problem is that your panel is “Armed Away” at the time, see line 97. So the download request fails. I’m not sure about this bit, but the download fails!
The EPROM download fails by line 103.
The panel requests that my Component re-enrolls on line 106.
I try to re-enroll on 119.
Enrolling appears to succeed (the panel sends powerlink keepalive messages, line 126) so I request an EPROM download again, see line 130.
The panel ignores this request until line 161 where my download timer expires and I try to force standard mode (when in powerlink we should be able to download the EPROM and the panel isn’t playing).
I call “Exit”, “Stop” and “Initialise” to bring the panel back in to a known state, line 170 to 186.
It looks like communication has been lost again as between lines 182 and 203 I try sending things but I’m not getting anything back from the panel.
Line 204 I seem to get garbage data from the panel until line 213 where I start to receive data from the panel again. Note that this garbage data might be from what remains in local buffers at the time.
This doesn’t last long and I stop receiving data from the panel again, lines 223 to 234 when the connection is lost.
Line 234 is when the communication has been terminated in the underlying system and I get the exception that tells me.
Line 238 I start trying again.
I can only conclude that the communication is not reliable enough between HA and the panel.
Hi Dave,
I cannot install
pip3 install python-datetime
I am getting this Error:
ERROR: Could not find a version that satisfies the requirement python-datetime (from versions: none)
ERROR: No matching distribution found for python-datetime
I searched the internet for a solution but was unsuccessful finding a working solution for this 
.
I’m no expert on this, but I wonder if “pip3 install datetime” will work.
FYI, the repositories for datetime are here:
https://github.com/python/cpython/blob/7e9bbbe51e74e5928e6a6c3e70434d824970ef58/Lib/datetime.py
The link will take you to version 3.7, but there’s a drop-down menu to select other Python versions. It needs to match the version of Python you installed on your PC.
I don’t consider myself an expert either but when I type “pip3 freeze” to get the packages and versions I get this
asyncio==3.4.3
asyncws==0.1
flux-led==0.22
pyserial==3.4
pyserial-asyncio==0.4
python-dateutil==2.8.0
six==1.12.0
websocket-client==0.56.0
websockets==8.0.2
Hi Rob and Dave,
In the meanwhile I think I got the command (python3 test.py -usb COM5) to work when I installed this:
pip install python-datetime-tz
With the command “pip3 freeze” I get this;
DateTime==4.3
pyserial==3.4
pyserial-asyncio==0.4
python-datetime-tz==0.5.4
python-dateutil==2.8.1
pytz==2019.3
six==1.13.
zope.interface==4.7.1
I think it’s not connecting to my panel, I have entered and exited the installer mode to reset the panel, but that didn’t help either, this is the output:
type or paste code here0:00:00.000998 < 3389> INFO Setting key OverrideCode to value -1
0:00:00.001735 < 3389> INFO Setting key ForceStandard to value False
DEBUG:asyncio:Using proactor: IocpProactor
0:00:00.032910 < 1034> INFO [Connection] Connected to local Protocol handler and Transport Layer
0:00:00.033908 < 1604> DEBUG [ClearList] Setting queue empty
C:\Users\david\OneDrive\Desktop\Hassio\Visonic\pyvisonic.py:1538: RuntimeWarning: coroutine 'wait_for' was never awaited
asyncio.wait_for(t, None)
RuntimeWarning: Enable tracemalloc to get the object allocation traceback
0:00:00.047620 < 1618> INFO [Start_Download] Starting download mode
C:\Users\david\OneDrive\Desktop\Hassio\Visonic\pyvisonic.py:1598: RuntimeWarning: coroutine 'wait_for' was never awaited
asyncio.wait_for(t, None)
RuntimeWarning: Enable tracemalloc to get the object allocation traceback
0:00:00.059059 < 1592> DEBUG [pmSendPdu] Resetting expected response counter, it got to 0 Response list before 0 after 1
0:00:00.067919 < 1529> DEBUG [pmSendPdu] Sending Command (Exit) raw data 0d 0f f0 0a waiting for message response ['0X2']
0:00:00.070911 < 1531> DEBUG [pmSendPdu] Command has a wait time after transmission 1.5
0:00:01.549455 < 1529> DEBUG [pmSendPdu] Sending Command (Stop) raw data 0d 0b f4 0a waiting for message response ['0X2']
0:00:01.550558 < 1531> DEBUG [pmSendPdu] Command has a wait time after transmission 1.5
0:00:03.048555 < 1529> DEBUG [pmSendPdu] Sending Command (Initializing PowerMax/Master PowerLink Connection) raw data 0d ab 0a 00 01 00 00 00 00 00 00 00 43 06 0a waiting for message response ['0X2']
0:00:03.049498 < 1531> DEBUG [pmSendPdu] Command has a wait time after transmission 8.0
0:03:00.047677 < 1142> WARNING [Controller] ********************** Download Timer has Expired, Download has taken too long *********************
0:03:00.047677 < 1143> WARNING [Controller] ************************************* Going to standard mode ***************************************
0:03:00.057357 < 1265> INFO [Standard Mode] Entering Standard Mode
0:03:00.060161 < 1604> DEBUG [ClearList] Setting queue empty
WARNING:__main__:Visonic attempt to add device with type <class 'int'> device is 7
0:03:00.061158 < 1592> DEBUG [pmSendPdu] Resetting expected response counter, it got to 181 Response list before 0 after 1
0:03:00.062157 < 1529> DEBUG [pmSendPdu] Sending Command (Exit) raw data 0d 0f f0 0a waiting for message response ['0X2']
0:03:00.062157 < 1531> DEBUG [pmSendPdu] Command has a wait time after transmission 1.5
0:03:01.548653 < 1529> DEBUG [pmSendPdu] Sending Command (Stop) raw data 0d 0b f4 0a waiting for message response ['0X2']
0:03:01.548884 < 1531> DEBUG [pmSendPdu] Command has a wait time after transmission 1.5
0:03:03.050001 < 1529> DEBUG [pmSendPdu] Sending Command (Initializing PowerMax/Master PowerLink Connection) raw data 0d ab 0a 00 01 00 00 00 00 00 00 00 43 06 0a waiting for message response ['0X2']
0:03:03.050997 < 1531> DEBUG [pmSendPdu] Command has a wait time after transmission 8.0
0:03:10.048200 < 1208> DEBUG [Controller] ****************************** Response Timer Expired ********************************
0:03:10.048974 < 1604> DEBUG [ClearList] Setting queue empty
0:03:10.060667 < 1592> DEBUG [pmSendPdu] Resetting expected response counter, it got to 0 Response list before 0 after 2
0:03:11.048930 < 1529> DEBUG [pmSendPdu] Sending Command (Getting Status) raw data 0d a2 00 00 00 00 00 00 00 00 00 00 43 1a 0a waiting for message response ['0XA5', '0X2']
0:03:20.048493 < 1208> DEBUG [Controller] ****************************** Response Timer Expired ********************************
0:03:20.049298 < 1604> DEBUG [ClearList] Setting queue empty
0:03:20.054968 < 1592> DEBUG [pmSendPdu] Resetting expected response counter, it got to 0 Response list before 0 after 2
0:03:20.056973 < 1529> DEBUG [pmSendPdu] Sending Command (Getting Status) raw data 0d a2 00 00 00 00 00 00 00 00 00 00 43 1a 0a waiting for message response ['0XA5', '0X2']
0:03:30.048986 < 1208> DEBUG [Controller] ****************************** Response Timer Expired ********************************
0:03:30.049774 < 1604> DEBUG [ClearList] Setting queue empty
0:03:30.055764 < 1592> DEBUG [pmSendPdu] Resetting expected response counter, it got to 0 Response list before 0 after 2
0:03:30.058422 < 1529> DEBUG [pmSendPdu] Sending Command (Getting Status) raw data 0d a2 00 00 00 00 00 00 00 00 00 00 43 1a 0a waiting for message response ['0XA5', '0X2']
0:03:40.047791 < 1208> DEBUG [Controller] ****************************** Response Timer Expired ********************************
0:03:40.048705 < 1604> DEBUG [ClearList] Setting queue empty
0:03:40.055740 < 1592> DEBUG [pmSendPdu] Resetting expected response counter, it got to 0 Response list before 0 after 2
0:03:40.057687 < 1529> DEBUG [pmSendPdu] Sending Command (Getting Status) raw data 0d a2 00 00 00 00 00 00 00 00 00 00 43 1a 0a waiting for message response ['0XA5', '0X2']```Yes, you’re correct. There is no data received at all.
So, is this the end of the line for me with this panel? Is there anything left I can try?
I can easily connect with the panel using the Visonic PRP application,
Well, that shows you how much I know!
I’m perplexed. How can the panel communicate with Visonic PRP and not with the test script? Do you think the USB-to-serial adapter might need a Windows driver for Python?
https://www.ftdichip.com/FTDrivers.htm
There are two ways to interfacing with the adapter. One method emulates a COM port and the other is direct communication with the hardware. How does the test scrip set the UART parameters? Is there any confirmation when it’s configured? Is there a way to check operation using loop-back (i.e. connecting the adapter’s Tx and Rx together)? More to the point, if you can’t verify loopback with Python, the problem is not in the panel. Correct?
There’s also an application note on the FTDI’s driver page. Maybe it has some useful nugget of information in the document.
https://www.ftdichip.com/Support/Documents/AppNotes/AN_107_AdvancedDriverOptions_AN_000073.pdf
I share your perplexity, and just to be clear, I’m doing all this in the same computer, when I connect to the panel, with the Visonic PRP I’m able to connect, disconnect and reconnect the number of times I want but with the script, nothing happens.
I wonder if the Visonic PRP during the connection stage with the panel sends any hidden command to put the panel in some special connection mode or something like that?