Visonic Powermax and Powermaster Component

[pocket (Rob)]

I just upgraded to the latest version of Home Assistant (0.92.1). Everything seems to work as before, and Configuration validation came up clean. The log is also clean. Nevertheless, I ran a check with the Check Home Assistant configuration add-on <https://www.home-assistant.io/addons/check_config/>, and it came up with the following:

[Info] Start install HomeAssistant latest
[Info] Installed homeassistant==0.92.1, check config now
[Error] Wrong config found!
Testing configuration at /tmp/config
Failed config
  General Errors: 
    - Integration not found: visonic

Has anyone else tried this?

[CorjanV]

I tried to install the Visonic component, but stuck on getting it work. The log says:
Thu May 02 2019 15:41:27 GMT+0200 (Midden-Europese zomertijd) Unable to find component visonic

The python files refer to custom_component.visonic but I can’t find a file that wears the name “visonic.py”. I guess I need this file, right? Has someone else troubles with this, or even more, has someone solved this?

Thanks!

[pocket (Rob)]

You should have six files from the GitHub distribution. The file “pyvisonic.py” is among them (no “visonic.py”). They should all be in a directory “/custom_components/visonic/”. Note the “s” in “components.” The full path may be different, depending upon your particular installation. You also need to appropriately modify the configuration.yaml file.

My experience is with Hass.io. It required a system reboot before the visonic integration worked.

[CorjanV]

Thanks! Component now recognized by HA. But still unable to connect in standard or powerlink mode. I ran test.py to see if that worked. Therefore I need to execute sudo pip3 install python-dateutil to let it work. Then I executed python3 test.py -address 192.168.135.162 -port 135 and it gave me the following log:

test_py.yaml (3.0 KB) (changed to .yaml to be able to upload)

So it looks like there is even no connection. But when I snuff with a telnet session via putty, it gives output:

I think it are the SendCommands from pyvisonic. But I can’t read it since it are strange characters. Baudrate in USR-TCP232-E2 is set to 9600 baud, 8 bit data size, 1 stop bit, no parity and no flow mode.

So where could the problem be? Are it the settings in the USR-TCP232-E2, or maybe a setting in the alarm panel? How did I get the panel in PowerLink mode? Is that just as simple as turn it in installation mode and then get out of there? Or am I missing something?

Thanks in advance!

[davesmeghead (Dave)]

@CorjanV

So where could the problem be?

@UffeNisse

Anyways, I have a Powermaster 10 v19.4 and with baud rate 9600 on my **USR-TCP232-E2 I had no success what so ever, absolutely nothinng happend after connect… But after readings some odd post at the openhab forum I changed the baud rate to 38400 and then it work a lot better.

A quote from an earlier post, perhaps you could try baud set to 38400 in your USR-TCP232-E2 instead of 9600

[pocket (Rob)]

Are the interface signals 3.3 volt logic level or RS-232 levels (+/- 12 volt)? They should be logic levels. If you’re confident they’re OK, check the connections and give it a go. FYI, I used a USB-to-logic-level serial cable from Adafruit.

[CorjanV]

OK, thanks for giving help. I’ve tried almost all standard baudrates, no luck yet. The signals are TTL so the pins are directly connected to the USR-TCP232-E2. I guess I’ve one of the first panels of the PowerMax line, so pinout is a little different. I used this picture to figure out what all the pins are:

I intepret this as [TX, VCC, RX, GND] so I connected TX to RX of the TCP-module and RX to TX and GND to GND and feed it with an external 5V power supply. With this configuration I get the strange characters, with TX and RX swapped, no output is available.

Here is a screenshot of my USR-TCP232-E2 module with baudrate set to 9600, since other baudrates give the same strange characters:

[pocket (Rob)]

@CorjanV

I intepret this as [TX, VCC, RX, GND] so I connected TX to RX of the TCP-module and RX to TX and GND to GND and feed it with an external 5V power supply. With this configuration I get the strange characters, with TX and RX swapped, no output is available.

I’ve seen the same strange characters when I was doing loop-back testing with puTTY. I could never figure it out, but I’m guessing it’s trying to establish a secure session. Try connection type Raw. I never got to try it, since I eventually connected the serial interface to the alarm panel and saw it was working.

Here is a screenshot of my USR-TCP232-E2 module with baudrate set to 9600, since other baudrates give the same strange characters:

Try deselecting Sync Baudrate. RF2217 might imply it’s selecting a Telnet server capability or a synchronous data stream. Either that, or you might be seeing the link attempting to negotiate baud rate.

Unfortunately, I can only guess since I have no experience with the module.

[CorjanV]

Did some testing, I connected a arduino directly to the USR-TCP232-E2 module with a serial read-and-print sketch on it. This setup gives me the following output:

Left the SSH session with the Pi running Home-Assistant, right the serial monitor connected to the arduino. That gives expected output. I only has to convert the incoming characters on the arduino to HEX and then the incomming characters correspond with the sended commands by the Pi. (I converted the pivisonic-commands to ASCII and that are human unreadable characters, which explains the strange characters appeared in putty sessions with the USR-module.) So I think the connection between the Pi and the USR-module is working correctly, since the strange characters are only the ASCII translations of the HEX characters. Now I wil check the serial connection with the PowerMax, but I will have a little thinking on how to do that. Could I just send for example the command 0d ab 0a 00 01 00 00 00 00 00 00 00 43 06 0a with an arduino and then wait for message response 0X2?

EDIT: found same issue in some previous posts:

@sosandstrom

I got response from Sector Alarm, Swedish reseller, and they confirmed their version of PowerMax firmware has the RS-232 pins disabled

But I won’t give up for now, maybe it is possible to upload new firmware. Did you either found a solution, @sosandstrom?

SECOND EDIT:
Now I have connected the PowerMax with an FTDI-USB adapter to my computer and downloaded the PowerMAX Remote Programmer, unzipped it with the password ‘PowerMaxPRO’ and installed it. With this software, I can connect to the PowerMax, so RS232 is enabled . Via this software I even can get it in download mode (the word ‘downloading’ appears on the LCD of the PowerMax). So I’m happy RS232 is still working.
But, when I tried to run test.py (so connected to PowerMax via USR-module) it goes not in download mode; after a while the script says: download timer expired.

I will try to connect the PowerMax via FTDI to my Raspberry Pi and then run test.py again. We’ll see if it works.

THIRD EDIT:
OK, tried running test.py with PowerMax connect via USB, still same output. Unable to become in download mode. I see the RX led on the FTDI blinking when starting the test.py script, but no answer from PowerMax. TX led blinks only when I access installation mode so both RX and TX channels are working properly. I’m a bit out of ideas now…

[pocket (Rob)]

Are you using a serial USB adapter with 3.3v logic I/O? Have you tried the interface with an operational configuration (i.e. not using test.pi)?

I’m curious about the remote programmer software. Did you get it running on a Windows 10 computer?

[davesmeghead (Dave)]

@CorjanV

Could I just send for example the command 0d ab 0a 00 01 00 00 00 00 00 00 00 43 06 0a with an arduino and then wait for message response 0X2 ?

Yes, this is the “panel initialise comms” command to the panel.

@CorjanV

Via this software I even can get it in download mode (the word ‘downloading’ appears on the LCD of the PowerMax)

The PC Remote Programmer software will try to get it in to powermax mode and therefore be able to donwload the EPROM data i.e. Downloading

Since you are running it from a PC now, can you install Python3 on your PC and try the test.py script again but from the PC as you know that the hardware works. Use the USB interface on test.py instead of the IP address and port.

@CorjanV

OK, tried running test.py with PowerMax connect via USB, still same output. Unable to become in download mode. I see the RX led on the FTDI blinking when starting the test.py script, but no answer from PowerMax. TX led blinks only when I access installation mode so both RX and TX channels are working properly. I’m a bit out of ideas now…

Does it receive any data?

[CorjanV]

@pocket

Are you using a serial USB adapter with 3.3v logic I/O? Have you tried the interface with an operational configuration (i.e. not using test.pi)?

Yes, I am. However, I can switch VCC between 3.3v and 5V. But I’m not using VCC, only GND, TX and RX since the PowerMax has its own powersupply.

I’m curious about the remote programmer software. Did you get it running on a Windows 10 computer?

Yes, it is still working, although it crashes sometimes. But I can download stuff from the PowerMax.

[CorjanV]

@davesmeghead

Does it receive any data?

Yes, when I go in the installermode I receive character ‘C’, when I go out the installer mode I receive the characters ‘BXX’.

EDIT:
When I send 0d ab 0a 00 01 00 00 00 00 00 00 00 43 06 0a via serial connection, nothing happends.

[pocket (Rob)]

@CorjanV

Yes, I am. However, I can switch VCC between 3.3v and 5V. But I’m not using VCC, only GND, TX and RX since the PowerMax has its own powersupply.

I think you’re really close to having it work, but there are some things that should be confirmed.

If the FTDI adapter is strictly logic level, which it should be, you should be able to disconnect the Tx line and measure an idle state voltage (i.e. assumes no communication) that is approximately between 3.0 and 3.6 volts relative to ground. You should also measure the idle state of the Tx signal on the alarm panel. If either Tx line is much higher than that, or a few tenths of a volt negative, we’ll need more information. If all is at the appropriate level, and you’re able to get into the download state, that’s enough to know you have a working panel interface. If the interface voltages are higher or the least bit negative, we’ll need to determine if the adapters are appropriate for your panel. If either interface is outside of logic levels, it may inform us of an inverted logic level and of an additional risk of overstressing something.

Assuming all is OK with levels and polarity, you could try to use the FTDI adapter on your Pi. If you can get that working, the USR module should be able to work assuming it hasn’t been damaged. You’ll still need to go through the configuration to ensure it’s not misconfigured.

Here’s a good reference:

https://www.sparkfun.com/tutorials/215

Yes, it is still working, although it crashes sometimes. But I can download stuff from the PowerMax.

The question is regarding the operating system of your computer. Can you confirm you’re using Windows 10? If so, did you have any issues installing the remote programmer software?

Thanks.

[CorjanV]

Voltages looks OK. They are between 0 and 5 Volts, both at FDTI and panel side. So I thinks that is good.

@pocket

The question is regarding the operating system of your computer. Can you confirm you’re using Windows 10? If so, did you have any issues installing the remote programmer software?

The Windows version is 10, with a 64-bit processor. The remote programmer software goes in ‘not responding’ when I tried to save a file or cancel the download. But when I start the download and let is fulfill it, it successfully succeed. So I was wondering why that seems to go correct, in addition to the execution of the test.py script. Therefore, I installed a serial connection sniffer and watched data traffic between PC and panel while remote program software was doing a download. This is the first part of the output:

00000008	2019-05-04 15:44:13,2145321	+19,1573770	IRP_MJ_CREATE - process 50636 (PMax2010.exe)	DOWN	0x00000000		
00000009	2019-05-04 15:44:13,2216857	+0,0071536	IRP_MJ_CREATE	UP	0x00000000		
00000010	2019-05-04 15:44:13,2217114	+0,0000257	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000011	2019-05-04 15:44:13,2218114	+0,0001000	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000012	2019-05-04 15:44:13,2218209	+0,0000095	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_QUEUE_SIZE	DOWN	0x00000000	00 04 00 00 00 04 00 00 	........
00000013	2019-05-04 15:44:13,2218220	+0,0000011	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_QUEUE_SIZE	UP	0x00000000		
00000014	2019-05-04 15:44:13,2218269	+0,0000049	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE	DOWN	0x00000000	0f 00 00 00 	....
00000015	2019-05-04 15:44:13,2218284	+0,0000015	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE	UP	0x00000000		
00000016	2019-05-04 15:44:13,2218330	+0,0000046	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_TIMEOUTS	DOWN	0x00000000	ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 88 13 00 00 	....................
00000017	2019-05-04 15:44:13,2218333	+0,0000003	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_TIMEOUTS	UP	0x00000000		
00000034	2019-05-04 15:44:13,2219334	+0,0000053	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE	DOWN	0x00000000	80 25 00 00 	.%..
00000035	2019-05-04 15:44:13,2220048	+0,0000714	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE	UP	0x00000000		
00000036	2019-05-04 15:44:13,2220172	+0,0000124	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_RTS	DOWN	0x00000000		
00000037	2019-05-04 15:44:13,2220508	+0,0000336	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000038	2019-05-04 15:44:13,2221271	+0,0000763	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_RTS	UP	0x00000000		
00000039	2019-05-04 15:44:13,2221388	+0,0000117	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_CLR_DTR	DOWN	0x00000000		
00000040	2019-05-04 15:44:13,2222305	+0,0000917	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000041	2019-05-04 15:44:13,2222400	+0,0000095	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000042	2019-05-04 15:44:13,2223332	+0,0000932	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_CLR_DTR	UP	0x00000000		
00000043	2019-05-04 15:44:13,2223408	+0,0000076	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL	DOWN	0x00000000	00 00 08 	...
00000044	2019-05-04 15:44:13,2224386	+0,0000978	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000046	2019-05-04 15:44:13,2225368	+0,0000914	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL	UP	0x00000000		
00000047	2019-05-04 15:44:13,2225417	+0,0000049	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS	DOWN	0x00000000	1a 00 00 00 11 13 	......
00000048	2019-05-04 15:44:13,2225428	+0,0000011	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS	UP	0x00000000		
00000049	2019-05-04 15:44:13,2225447	+0,0000019	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW	DOWN	0x00000000	00 00 00 00 40 00 00 00 00 01 00 00 00 01 00 00 	....@...........
00000050	2019-05-04 15:44:13,2227323	+0,0001876	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW	UP	0x00000000		
00000053	2019-05-04 15:44:13,2292535	+0,0000053	IRP_MJ_WRITE	DOWN	0x00000000	0d 24 00 00 48 93 00 00 00 00 00 00 00 0a 	.$..H.........
00000058	2019-05-04 15:44:13,2294468	+0,0000566	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000059	2019-05-04 15:44:13,2295491	+0,0001023	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000062	2019-05-04 15:44:13,2530921	+0,0000317	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000063	2019-05-04 15:44:13,2532095	+0,0001174	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000066	2019-05-04 15:44:13,2690834	+0,0000268	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000067	2019-05-04 15:44:13,2691952	+0,0001118	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000076	2019-05-04 15:44:13,3465332	+0,0000026	IRP_MJ_READ	UP	0x00000000	0d 02 fd 0a 0d 22 fd 0a 01 16 15 00 0d 00 00 00 9c 0a 	....."............
00000083	2019-05-04 15:44:13,3492847	+0,0000042	IRP_MJ_WRITE	DOWN	0x00000000	0d 02 fd 0a 	....
00000088	2019-05-04 15:44:13,3493987	+0,0000068	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000089	2019-05-04 15:44:13,3495029	+0,0001042	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000103	2019-05-04 15:44:14,3662742	+0,0000086	IRP_MJ_WRITE	DOWN	0x00000000	0d 5a ba 09 04 00 00 00 00 00 00 00 dd 0a 	.Z............
00000108	2019-05-04 15:44:14,3664914	+0,0000095	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000109	2019-05-04 15:44:14,3666198	+0,0001284	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000112	2019-05-04 15:44:14,3887918	+0,0000571	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000113	2019-05-04 15:44:14,3889205	+0,0001287	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000116	2019-05-04 15:44:14,4046614	+0,0000593	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000117	2019-05-04 15:44:14,4047864	+0,0001250	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000126	2019-05-04 15:44:14,4857858	+0,0000056	IRP_MJ_READ	UP	0x00000000	0d 33 fd 0a 13 18 63 00 00 00 00 00 36 0a 	.3....c.....6.
00000133	2019-05-04 15:44:14,4924121	+0,0000110	IRP_MJ_WRITE	DOWN	0x00000000	0d 02 fd 0a 	....
00000138	2019-05-04 15:44:14,4926522	+0,0000144	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000139	2019-05-04 15:44:14,4927957	+0,0001435	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000142	2019-05-04 15:44:14,5169593	+0,0001000	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000143	2019-05-04 15:44:14,5170847	+0,0001254	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000154	2019-05-04 15:44:14,6189485	+0,0000053	IRP_MJ_READ	UP	0x00000000	0d 33 05 0b 00 00 00 00 00 00 00 00 bc 0a 	.3............
00000161	2019-05-04 15:44:14,6295219	+0,0000181	IRP_MJ_WRITE	DOWN	0x00000000	0d 02 fd 0a 	....
00000166	2019-05-04 15:44:14,6297171	+0,0000442	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000167	2019-05-04 15:44:14,6298183	+0,0001012	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000170	2019-05-04 15:44:14,6445583	+0,0001132	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000171	2019-05-04 15:44:14,6446758	+0,0001175	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000174	2019-05-04 15:44:14,6606127	+0,0001348	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000175	2019-05-04 15:44:14,6607370	+0,0001243	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000186	2019-05-04 15:44:14,7520919	+0,0000045	IRP_MJ_READ	UP	0x00000000	0d 33 0d 0b 00 00 00 00 00 00 00 00 b4 0a 	.3............
00000193	2019-05-04 15:44:14,7619728	+0,0000139	IRP_MJ_WRITE	DOWN	0x00000000	0d 02 fd 0a 	....
00000198	2019-05-04 15:44:14,7623512	+0,0001839	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000199	2019-05-04 15:44:14,7624595	+0,0001083	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000202	2019-05-04 15:44:14,7724620	+0,0000634	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000203	2019-05-04 15:44:14,7725632	+0,0001012	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000206	2019-05-04 15:44:14,7885281	+0,0000922	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000207	2019-05-04 15:44:14,7886821	+0,0001540	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000220	2019-05-04 15:44:14,8785271	+0,0000071	IRP_MJ_READ	UP	0x00000000	0d 33 15 0b 00 00 00 00 00 00 00 00 ac 0a 	.3............
00000227	2019-05-04 15:44:14,8876930	+0,0000159	IRP_MJ_WRITE	DOWN	0x00000000	0d 02 fd 0a 	....
00000232	2019-05-04 15:44:14,8880049	+0,0000876	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000233	2019-05-04 15:44:14,8881355	+0,0001306	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000236	2019-05-04 15:44:14,9003914	+0,0000623	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000237	2019-05-04 15:44:14,9005141	+0,0001227	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000240	2019-05-04 15:44:14,9163767	+0,0000619	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000241	2019-05-04 15:44:14,9165039	+0,0001272	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000254	2019-05-04 15:44:15,0093107	+0,0000057	IRP_MJ_READ	UP	0x00000000	0d 33 1d 0b 00 00 00 00 00 00 00 00 a4 0a 	.3............
00000261	2019-05-04 15:44:15,0165531	+0,0000110	IRP_MJ_WRITE	DOWN	0x00000000	0d 02 fd 0a 	....
00000266	2019-05-04 15:44:15,0167653	+0,0000106	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000267	2019-05-04 15:44:15,0169122	+0,0001469	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000270	2019-05-04 15:44:15,0286806	+0,0001058	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000271	2019-05-04 15:44:15,0288346	+0,0001540	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000274	2019-05-04 15:44:15,0444193	+0,0001107	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000275	2019-05-04 15:44:15,0445858	+0,0001665	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000286	2019-05-04 15:44:15,1388297	+0,0000057	IRP_MJ_READ	UP	0x00000000	0d 33 25 0b 00 00 00 00 00 00 00 00 9c 0a 	.3%...........
00000293	2019-05-04 15:44:15,1515829	+0,0000140	IRP_MJ_WRITE	DOWN	0x00000000	0d 02 fd 0a 	....
00000298	2019-05-04 15:44:15,1518547	+0,0000071	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000299	2019-05-04 15:44:15,1520669	+0,0002122	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000302	2019-05-04 15:44:15,1726979	+0,0001442	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000303	2019-05-04 15:44:15,1728576	+0,0001597	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000306	2019-05-04 15:44:15,1886644	+0,0001273	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000307	2019-05-04 15:44:15,1888651	+0,0002007	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000320	2019-05-04 15:44:15,2699050	+0,0000083	IRP_MJ_READ	UP	0x00000000	0d 33 2d 0b 00 00 00 00 00 00 00 00 94 0a 	.3-...........
00000327	2019-05-04 15:44:15,2791573	+0,0000136	IRP_MJ_WRITE	DOWN	0x00000000	0d 02 fd 0a 	....
00000332	2019-05-04 15:44:15,2794227	+0,0000072	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000333	2019-05-04 15:44:15,2796039	+0,0001812	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000336	2019-05-04 15:44:15,3005948	+0,0001182	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000337	2019-05-04 15:44:15,3007870	+0,0001922	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000340	2019-05-04 15:44:15,3165846	+0,0001340	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000341	2019-05-04 15:44:15,3167783	+0,0001937	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000352	2019-05-04 15:44:15,3967538	+0,0000076	IRP_MJ_READ	UP	0x00000000	0d 33 35 0b 00 00 00 00 00 00 00 00 8c 0a 	.35...........
00000359	2019-05-04 15:44:15,4074861	+0,0000223	IRP_MJ_WRITE	DOWN	0x00000000	0d 02 fd 0a 	....
00000364	2019-05-04 15:44:15,4078229	+0,0000581	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000365	2019-05-04 15:44:15,4080159	+0,0001930	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000368	2019-05-04 15:44:15,4282009	+0,0000664	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000369	2019-05-04 15:44:15,4283660	+0,0001651	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000372	2019-05-04 15:44:15,4444068	+0,0001201	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000373	2019-05-04 15:44:15,4445759	+0,0001691	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000386	2019-05-04 15:44:15,5310457	+0,0000075	IRP_MJ_READ	UP	0x00000000	0d 33 3d 0b 00 00 00 13 11 17 01 0c 3c 0a 	.3=.........<.
00000393	2019-05-04 15:44:15,5409112	+0,0000140	IRP_MJ_WRITE	DOWN	0x00000000	0d 02 fd 0a 	....
00000396	2019-05-04 15:44:15,5411566	+0,0000547	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000399	2019-05-04 15:44:15,5413182	+0,0001246	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000402	2019-05-04 15:44:15,5561874	+0,0000974	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000403	2019-05-04 15:44:15,5563581	+0,0001707	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000406	2019-05-04 15:44:15,5721941	+0,0001344	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000407	2019-05-04 15:44:15,5724184	+0,0002243	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000418	2019-05-04 15:44:15,6595215	+0,0000064	IRP_MJ_READ	UP	0x00000000	0d 33 45 0b 14 08 07 17 09 15 04 05 1b 0a 	.3E...........
00000425	2019-05-04 15:44:15,6686299	+0,0000125	IRP_MJ_WRITE	DOWN	0x00000000	0d 02 fd 0a 	....
00000428	2019-05-04 15:44:15,6688459	+0,0000465	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000431	2019-05-04 15:44:15,6689965	+0,0001197	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000434	2019-05-04 15:44:15,6842368	+0,0001193	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000435	2019-05-04 15:44:15,6844052	+0,0001684	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000438	2019-05-04 15:44:15,7001058	+0,0000634	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000439	2019-05-04 15:44:15,7002633	+0,0001575	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000452	2019-05-04 15:44:15,7910666	+0,0000060	IRP_MJ_READ	UP	0x00000000	0d 33 4d 0b 0f 16 00 03 06 0d 0e 18 13 0a 	.3M...........
00000459	2019-05-04 15:44:15,7971169	+0,0000106	IRP_MJ_WRITE	DOWN	0x00000000	0d 02 fd 0a 	....
00000464	2019-05-04 15:44:15,7973076	+0,0000189	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000465	2019-05-04 15:44:15,7973948	+0,0000872	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000468	2019-05-04 15:44:15,8121050	+0,0000895	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000469	2019-05-04 15:44:15,8122579	+0,0001529	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000472	2019-05-04 15:44:15,8280895	+0,0001816	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000473	2019-05-04 15:44:15,8282556	+0,0001661	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000484	2019-05-04 15:44:15,9142841	+0,0000075	IRP_MJ_READ	UP	0x00000000	0d 33 55 0b 19 02 0b 0b 0b 1a 1b 1c de 0a 	.3U...........
00000491	2019-05-04 15:44:15,9226608	+0,0000140	IRP_MJ_WRITE	DOWN	0x00000000	0d 02 fd 0a 	....
00000494	2019-05-04 15:44:15,9229319	+0,0000533	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000497	2019-05-04 15:44:15,9230840	+0,0001314	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000500	2019-05-04 15:44:15,9399041	+0,0000811	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000501	2019-05-04 15:44:15,9400382	+0,0001341	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000504	2019-05-04 15:44:15,9560959	+0,0000895	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000505	2019-05-04 15:44:15,9562658	+0,0001699	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000518	2019-05-04 15:44:16,0420039	+0,0000061	IRP_MJ_READ	UP	0x00000000	0d 33 5d 0b 15 00 00 5a 6f 6c 64 65 4f 0a 	.3]....ZoldeO.
00000525	2019-05-04 15:44:16,0495955	+0,0000125	IRP_MJ_WRITE	DOWN	0x00000000	0d 02 fd 0a 	....
00000530	2019-05-04 15:44:16,0498368	+0,0000053	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000531	2019-05-04 15:44:16,0500037	+0,0001669	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000534	2019-05-04 15:44:16,0682261	+0,0001132	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000535	2019-05-04 15:44:16,0683632	+0,0001371	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000538	2019-05-04 15:44:16,0842099	+0,0001125	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	DOWN	0x00000000	fd 01 00 00 	....
00000539	2019-05-04 15:44:16,0843908	+0,0001809	IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK	UP	0x00000000		
00000550	2019-05-04 15:44:16,1723381	+0,0000072	IRP_MJ_READ	UP	0x00000000	0d 33 65 0b 72 20 20 20 20 20 20 20 09 0a 	.3e.r       ..
00000557	2019-05-04 15:44:16,1815805	+0,0000136	IRP_MJ_WRITE	DOWN	0x00000000	0d 02 fd 0a 	....

After this it is sending all off its sensors, connected devices and settings.

So in the log, I can see it gets al the states of the sensors etc. I also figured out that the command to start download mode is 0d 24 00 00 48 93 00 00 00 00 00 00 00 0a. Thats a little differend from the command as defined in pyvisonic.py. But when I send this command via e.g. putty to the panel it starts the download mode.

So, could it be that the protocol of the powermax panel is a little different from other (newer) visonic panels?

[pocket (Rob)]

@CorjanV

Voltages looks OK. They are between 0 and 5 Volts, both at FDTI and panel side. So I thinks that is good.

Be careful; that’s not necessarily healthy. I know it sounds like a useless detail, particularly if everything seems to be working, but you could be overstressing some components. Bear with me.

If the idle voltages on the Tx signals are above the power supply on the Rx end, the protection clamp diodes inside the IC on the Rx end will be forward biased. That’s not good for either the Tx driver or the Rx receiver ICs. If you isolate each Tx signal by disconnecting the wire to it’s respective Rx end, the Tx idle voltage should be no more than about 0.3 volts above the power supply of the Rx end. The power supply of each Rx end can be determined by measuring the idle state voltage of it’s respective Tx signal.

There is a solution which will require adding a resistor in series with the Tx signal and a resistor between the first resistor and ground toward the Rx end. The values of the resistors can be easily determined by knowing the power supply voltages on each side of the interface. Hopefully, the power supply voltages are within a few tenths of a volt of one another. Additionally, if they are too far apart, there is a chance the Tx signal from the side with the lower voltage power supply will not cross the digital threshold of the Rx device on the side with the higher voltage. The easier and ‘cleaner’ fix for either of these problems is to select the USB adapter cable or the power supply configuration of the USR to match the alarm panel interface.

So, could it be that the protocol of the powermax panel is a little different from other (newer) visonic panels?

Yes, that’s very possible. See post 239. The good news is you have a setup allowing Dave to know exactly how your panel responds. He’s been both gracious and patient in sorting out similar issues.

[davesmeghead (Dave)]

@CorjanV

I also figured out that the command to start download mode is 0d 24 00 00 48 93 00 00 00 00 00 00 00 0a . Thats a little differend from the command as defined in pyvisonic.py. But when I send this command via e.g. putty to the panel it starts the download mode.

Not sure I can help much at this stage and pocket seems to be doing better than me with the voltages and such!
What I can answer is that the 48 93 in your download command is the space for the download code, this is normally 56 50 (hex), this is “VP” in ascii for visonic panel. Note that in my code the 99 99 gets replaced with 56 50 when the command is sent. I use 99 99 as a place holder, this isn’t actually used. You’ll also need to calculate the checksum, this is the value just before the terminator 0A. I don’t think that the protocol is different but I’m no expert on this, you could be right.

[davesmeghead (Dave)]

@CorjanV

Therefore, I installed a serial connection sniffer and watched data traffic between PC and panel while remote program software was doing a download. This is the first part of the output:

00000053	2019-05-04 15:44:13,2292535	+0,0000053	IRP_MJ_WRITE	DOWN	0x00000000	0d 24 00 00 48 93 00 00 00 00 00 00 00 0a 	.$..H.........
00000076	2019-05-04 15:44:13,3465332	+0,0000026	IRP_MJ_READ	UP	0x00000000	0d 02 fd 0a 0d 22 fd 0a 01 16 15 00 0d 00 00 00 9c 0a 	....."............
00000083	2019-05-04 15:44:13,3492847	+0,0000042	IRP_MJ_WRITE	DOWN	0x00000000	0d 02 fd 0a 	....
00000103	2019-05-04 15:44:14,3662742	+0,0000086	IRP_MJ_WRITE	DOWN	0x00000000	0d 5a ba 09 04 00 00 00 00 00 00 00 dd 0a 	.Z............
00000126	2019-05-04 15:44:14,4857858	+0,0000056	IRP_MJ_READ	UP	0x00000000	0d 33 fd 0a 13 18 63 00 00 00 00 00 36 0a 	.3....c.....6.
00000133	2019-05-04 15:44:14,4924121	+0,0000110	IRP_MJ_WRITE	DOWN	0x00000000	0d 02 fd 0a 	....

So, to try and explain:

0d is used as the message header, it is the start of a message
0a is the footer or terminator, it is the end of the message
the value before the 0a is the checksum
0a is allowed inside messages, check the checksum for validity and if not valid then keep going!
the value after the 0d header is the command i.e the message type

The PC sends a Download command (24) with download code 48 93. I’m not sure where it gets that download code, as I said in my previous post this is usually 56 50. Also, the checksum is “00” which is unusual but not impossible.
EDIT: The checksum is 00, it is valid

The panel then sends “0d 02 fd 0a”, this is an acknowledge

The panel then sends “0d 22 fd 0a 01 16 15 00 0d 00 00 00 9c 0a”.
NOTE: It could be “0d 22 fd 0a” followed by an illegal message but lets assume that it isn’t.
This is a panel status “22”, I have never seen this sequence from the panel before.

The PC then sends an acknowledge “0d 02 fd 0a”

The PC then sends “0d 5a ba 09 04 00 00 00 00 00 00 00 dd 0a”
A “5A” command kicks off the downloading of EPROM data.

The panel then starts to stream the EPROM data as “0d 33 fd 0a 13 18 63 00 00 00 00 00 36 0a”
Each “33” is followed by an acknowledge from the PC “0d 02 fd 0a”

Lots more “33” downloads, each followed by an acknowledge

Hope this helps

[CorjanV]

OK, thanks both for explanation, it makes it a lot clearer. I will have a look at it this evening or maybe tomorrow.

[CorjanV]

@pocket

If the idle voltages on the Tx signals are above the power supply on the Rx end, the protection clamp diodes inside the IC on the Rx end will be forward biased. That’s not good for either the Tx driver or the Rx receiver ICs. If you isolate each Tx signal by disconnecting the wire to it’s respective Rx end, the Tx idle voltage should be no more than about 0.3 volts above the power supply of the Rx end. The power supply of each Rx end can be determined by measuring the idle state voltage of it’s respective Tx signal.

I have measured all the pins, there was none connection between ftdi and panel. These are the results (all voltages are measured from GND as reference):

	VCC	TX	RX
FDTI	5.08 V	5.08 V	5.03 V
PowerMax	0.01 V	4.98 V	0.29 V

@CorjanV

For the VCC of the PowerMax, I measured the voltage over the right pin (GND) and the left pin (VCC). But when I see at the results (0.01V for PowerMax’s VCC), I’m not sure if this is correct.