Visonic Powerlink RS232 Hack

[Odin]

so, I should send 0D AB 0A 00 01 00 00 00 00 00 00 00 43 06 0A once only as soon as my serial link opens the connection?

this is what my diagnostic client is doing:
1. sent to pm: {0D}{AB}{0A}{00}{01}{00}{00}{00}{00}{00}{00}{00}{43}{06}{0A}
2. received from pm: {0D}{02}{43}{BA}{0A}

What should I do next?

[Bwired]

just give ack and messages (A5, A7 etc) should start to come in

[Odin]

Ok so I send ack msg 0D02FD0A and all I get are 05 messages from the panel.

damn...

[Bwired]

damn? you mean you are happy now

[Odin]

lol no, damn meaning I can't get it to work properly..

interestingly, when I connect my powerlink, I do get A7 msgs spitting out. So, there must be a way of tricking my PM Complete panel in thinking it has a powerlink

here is what reponses I get when connecting the powerlink

Code: Select all

[Thu Aug 25 11:28:55 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0d0243ba
[Thu Aug 25 11:30:17 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0d0243bb
[Thu Aug 25 11:30:17 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0d02fe
[Thu Aug 25 11:30:28 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0d02fe
[Thu Aug 25 11:30:28 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0d02fe
[Thu Aug 25 11:30:28 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 00b0ffffffffffffffff0031140b080bffff021e3c1e04010201000005001e000000000000b400030000000f24c102840000ffffffffffffffff001234ffffffffffffffff00567807917100793fffff07747640836fffff01932568513fffffffffffffffffffffffffffffffffffffffffffffffffffff0100000008010103000c000043ffffffff01ffffffffffffffff000000000100ff0000000501f7917100793ffffff77476408360000fffffffff05
[Thu Aug 25 11:30:29 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0d3fa001b0ffffffffffffffffffffffff46656c6c6f77477265656e416c657274000000000000001cffff00ffffffffffffffffffffffffffffffffffffffffff0100000000000000ffffffffffffff00000000ffffffffffffffffffffff2712000000000000000000000000000097369735aaaabbbb776b0700130001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005b
[Thu Aug 25 11:30:29 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0d3f5002b0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002020202020202020202020202020202000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ffff000000ffffffffffffffffffffffffff01000c00ff91
[Thu Aug 25 11:30:29 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0d3f0003b00001010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0f0101010101010101010101ff01010101010101010101010101010101ffffffffffffffffffffffffffffffffffffffff00ffffffffffffffffffffffffffffffff00000000ffffffff00000000ffffffffffffffffffffffffffffffff00b5
[Thu Aug 25 11:30:29 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 000000004a533730303432312076312e302e30324a2d3730313333342076322e302e36314a533730313639302076322e302e3637ffffffffffffffffffffffffffffffff1311045867ff1205ffffffffffffffffff0000000000000000000000000000000000000000000000000000000000000047
[Thu Aug 25 11:30:30 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffbfbf0104170501001f5101190706010020551d
[Thu Aug 25 11:30:30 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0d3f0009b0e62f9627524a932c68cd9627df4a932ce47795279854e32c535d932c5d4d932c023096270000000c0000000c0000000b0000000300000002000000000000000700000007000000070000000700000007000000070000000700000007000000070000000700000007000000
[Thu Aug 25 11:30:30 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0d3fb009b00000000000000000ff010000040405070706060707070606070706070707070b0b01010909
[Thu Aug 25 11:30:30 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 00000000000000ffffffffffffffff00000000000000000000000000000000ffffffffffffffffffffffffffffffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000009f
[Thu Aug 25 11:30:30 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff24
[Thu Aug 25 11:30:30 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 1f1f1f1f1f0c101317011108131615141711020c1a1b1c1d1e0f0e16120019
[Thu Aug 25 11:30:31 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 323334353633323334353637383930313233343536ffffffffffffffbc
[Thu Aug 25 11:30:31 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 000000000000000000000000000000000000000000000000b5
[Thu Aug 25 11:30:31 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffd
[Thu Aug 25 11:30:31 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff4d
[Thu Aug 25 11:30:31 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff9c
[Thu Aug 25 11:30:32 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffeb
[Thu Aug 25 11:30:32 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 3fc015b0ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff3b
[Thu Aug 25 11:30:32 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0d3f7016b0ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff000000000000000000000200000000000000000000000000000000000000000088
[Thu Aug 25 11:30:32 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0d3f20176a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020
[Thu Aug 25 11:30:32 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0d02fe
[Thu Aug 25 11:30:32 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 01ff0000000043a0
[Thu Aug 25 11:30:32 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da7ff00000700ff00000000430f
[Thu Aug 25 11:30:34 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da500040046000040020000438b
[Thu Aug 25 11:30:34 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da7ff00001c00ff0002000043f7
[Thu Aug 25 11:30:34 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da7ff00001c00ff0002000043f7
[Thu Aug 25 11:30:34 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da7ff00001c00ff0002000043f7
[Thu Aug 25 11:30:38 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0d0243bb
[Thu Aug 25 11:30:46 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0d0243bb
[Thu Aug 25 11:30:52 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0d0243bb
[Thu Aug 25 11:30:52 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 89
[Thu Aug 25 11:30:53 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da50d04000600004002000043be
[Thu Aug 25 11:30:53 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0d0800000000000000004303
[Thu Aug 25 11:30:53 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da50d0b000000000000000043ff
[Thu Aug 25 11:31:22 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0dab03001e003230363700004321
[Thu Aug 25 11:31:52 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0dab03001e003230363700004321
[Thu Aug 25 11:32:22 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0dab03001e003230363700004321
[Thu Aug 25 11:32:36 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da5000200000000000000004316
[Thu Aug 25 11:32:52 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0dab03001e003230363700004321
[Thu Aug 25 11:32:55 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da5000200000000000000004316
[Thu Aug 25 11:33:22 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0dab03001e003230363700004321
[Thu Aug 25 11:33:42 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da5000200000000000000004316
[Thu Aug 25 11:33:52 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0dab03001e003230363700004321
[Thu Aug 25 11:34:08 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da500040046000040020000438b
[Thu Aug 25 11:34:16 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da500040046000040020000438b
[Thu Aug 25 11:34:22 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0dab03001e003230363700004321


Logging off...

[Bwired]

strange
i dont expect the complete to be different.
But you know you only get A7 when you do something like arm and disarm.... i quess you do
after powerlink connection reset again first

[Willem4ever]

here is what reponses I get when connecting the powerlink

Code: Select all

[Thu Aug 25 11:28:55 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0d0243ba
[Thu Aug 25 11:30:17 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0d0243bb
[Thu Aug 25 11:30:17 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0d02fe

How do you snif ? The response look strange , second message has a checksum error ... I never see the close 0a byte at the end of each message. Bare in mind that 0a cannot simply be used as an end of 'string'.

I'm not so sure if we really see what is happening on link between pm and pl unless, which is hard to believe, the complete differs from the other powermax.

[Odin]

yes strange one isn't it? My powerlink module is V2

I sniff by using a perl function to grab the current serial port line as follows but the perl 'lookfor' function always 'looks for' a carriage return as a terminator and in our case 0A is hex for it.. Hence why perl is chopping off the 0A byte. This can be a problem as said on lines where 0A is part of the msg.. Is there a better way of doing this?

my $receivedChars = unpack('H*',$Port->lookfor());

I ruled out my code by using a utility client app called Hercules which allows to send/receive hex on screen - same thing - I arm the alarm but no A7 msg, only A5.

[Odin]

I rewrote my code so it picks away at the complete byte stream instead - byproduct being faster code! Still no A7 msg though. looks like I'll have to do something else.

here's another 'funny' - status request generates the following:

Code: Select all

[Fri Aug 26 00:00:18 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0d0243ba0a0da50d01000000000000000043090a
[Fri Aug 26 00:00:18 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da50d02000000000000000043080a
[Fri Aug 26 00:00:19 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da50d03000000000000000043070a
[Fri Aug 26 00:00:19 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da50d04040100000006000043fa0a
[Fri Aug 26 00:00:19 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da50d050000001f00001234439f0a
[Fri Aug 26 00:00:19 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da50d06ff0100000000000043030a
[Fri Aug 26 00:00:19 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da50d07000000000003000043000a
[Fri Aug 26 00:00:19 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da50d08000000000000000043020a
[Fri Aug 26 00:00:19 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da50d09000000000000000043010a
[Fri Aug 26 00:00:19 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da50d0a000000000000000043000a
[Fri Aug 26 00:00:19 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da50d0b000000000000000043fe0a
[Fri Aug 26 00:00:19 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da50d0c000000000000000043fd0a
[Fri Aug 26 00:00:20 2011] - Unrecognised Msg Received From Alarm Subsystem: msg key is: 0da50d0d000000000000000043fc0a

[Willem4ever]

Hi Odin,

First line is actually two nessages ... an ack and the first line of 13 (0x0d) messages. In case of a PMpro you get only 9 lines ... you can check if the 0xa5 decoded lines for PMpro are equal to yours - I guess they here are just a few lines more for future expansion perhaps ?

[Odin]

Hi Odin,

First line is actually two nessages ... an ack and the first line of 13 (0x0d) messages. In case of a PMpro you get only 9 lines ... you can check if the 0xa5 decoded lines for PMpro are equal to yours - I guess they here are just a few lines more for future expansion perhaps ?

Hi Willem4ever,

the '0d0243ba0a0da50d01000000000000000043090a' event - you are correct in that this is two msgs. However, it looks like my panel sends an ack to the caller upon receiving the request for status and then immediately sends the first status msg without waiting for the response from the caller! I would have to put in extra processing to trap for this.

the 'Funny' here is the protocol spec suggests the status msgs should be 0xA5 0x09 whereas mine are 0xA5 0x0d

Possibly linked to not being able to get the A7 msgs too.

[Willem4ever]

Odin,

Something struck me, I never managed to get my emulator registered properly with the PMpro, hence there is no possibily to delete the registration. If I understand correctly you have a PL2 and I guess you have registered it with the PMcomplete. Have you already tried to delete the registration on your PMcomplete perhaps that changes the behaviour to what we are seeing.

BTW You should not ack with an ack again, so the sequence as you observe is right. You ask for the status, you receive an ack - message understood by PM- followed by the status data.

[Odin]

Odin,

Something struck me, I never managed to get my emulator registered properly with the PMpro, hence there is no possibily to delete the registration. If I understand correctly you have a PL2 and I guess you have registered it with the PMcomplete. Have you already tried to delete the registration on your PMcomplete perhaps that changes the behaviour to what we are seeing.

Hi Willem4ever,

On the PMComplete, there is auto registration for Plink now - Visonic appear to have changed the menu options here for the pmcomplete and plink. When you plug in the plink, the panel automatically registers to it. Only thing you need to do is configure the ip address in the panel to be the ip address of the Plink in order to get emails etc from plink. When the plink is unconnected, the panel auto disconnects.

BTW You should not ack with an ack again, so the sequence as you observe is right. You ask for the status, you receive an ack - message understood by PM- followed by the status data.

OK, so the sequence is:

1. client issues status request to panel (0DA200000000000000000000431A0A)
2. client waits for acknowledgement from panel (0d0243ba)
3. client waits for first row of status msg from panel (0da50d01000000000000000043090a)

[Willem4ever]

On the PMComplete, there is auto registration for Plink now - Visonic appear to have changed the menu options here for the pmcomplete and plink. When you plug in the plink, the panel automatically registers to it. Only thing you need to do is configure the ip address in the panel to be the ip address of the Plink in order to get emails etc from plink. When the plink is unconnected, the panel auto disconnects.

Would be interesting to see that sequence, any way of capturing that ?

OK, so the sequence is:
1. client issues status request to panel (0DA200000000000000000000431A0A)
2. client waits for acknowledgement from panel (0d0243ba)
3. client waits for first row of status msg from panel (0da50d01000000000000000043090a)

Correct

[Odin]

On the PMComplete, there is auto registration for Plink now - Visonic appear to have changed the menu options here for the pmcomplete and plink. When you plug in the plink, the panel automatically registers to it. Only thing you need to do is configure the ip address in the panel to be the ip address of the Plink in order to get emails etc from plink. When the plink is unconnected, the panel auto disconnects.

Would be interesting to see that sequence, any way of capturing that ?

OK, so the sequence is:
1. client issues status request to panel (0DA200000000000000000000431A0A)
2. client waits for acknowledgement from panel (0d0243ba)
3. client waits for first row of status msg from panel (0da50d01000000000000000043090a)

Correct

how do I capture? I can only capture the output from the PMComplete panel on the serial port - plink attaches to another port. I assume I would need another cable to 'split' the plink to panel cable?

How does Rene capture the plink transmissions?