Home Automation Domotica Forum Europe, Bwired Forum

Hi Utz,

I was thinking about that last night, did you ever see a 0x0a or a 0x0d appearing in the message body ? I have seen protocols where e.g. an 0x0a is followed by another 0x0a when it appears in the message body which wouldn't happen when it is the pre-able of the message. (I find the 0x0a / 0x0d an odd choice anyway as they represent lf/cr).

You could do something like when you haven't received two characters within 500 ms the read pointer is reset to zero. Also another observation before the checksum we see 0x43 which happens to be a 'C' in ascii ... coincidence ..... which should be at a fixed location in data stream .... I'll give it some thought ....

Cheers Willem.

Strange thing the checksum is not correct. I have run now 4 days in a row where I check each event on the correct checksum an never had an incorrect checksum.

I used my good old HP16c (hex calculator) and got confused with the results. (I guess there might be a mistake somewhere else in you script ) So I decided to do some work with a perl script and entered some of the example data and these were the results.

EDIT: This is based on the example data made available, as long as the result of the addition stays below 0x100 your algorithm is working fine ....

@Willem

yes you would normally design a protocol such that special characters are represented such that they can appear in the stream (see slip byte stuffing). The visonic protocol is a bad design (just my opinion).

I have seen 0A and 0D in messages (For example if a sensor is installed in Zone 10 (0A)).

@utz

Yeah, couldn't wait and checked already .... I never thought it was so simple, I have reversed engineered far more complex stuff in the ancient past At the other hand it is good for us, yet another device we can integrate with our home systems ... thanks for getting this started !! now we have to wait for someone with a power link and we can untangle the more interesting stuff

I just came home and double checked the checkum algorithm and I am sure it is correct. If I feed your examples the correct checksum is calculated:
0D A7 01 00 20 55 00 00 00 03 AF 0F 43 DC 0A
0xA7 + 0x01 + 0x00 + 0x20 + 0x55 + 0x00 + 0x00 + 0x00 + 0x03 + 0xAF +0x0F + 0x43 = 167 + 1 +32 + 85 + 3 + 175 + 15 + 67 = 545
545 % 255 = 35 = 0x23 = 0010 0011
1's complement of 0010 0011 = 1101 1100 = 0xDC

You must not include the checksum itself in the sum and to get the remainder of dividing the sum by 255 you must take the modulo.

Rene, I stand corrected - not smart from me todo this with a calculator while you actually should go to sleep.

I was looking at the 8 LSB's only and not doing a mod 255, but on the bright side both algorithm's work.

Now we have a choice which one to select - when I think assembly language I could implement mine without modules or division, but who cares these days.

Wise guy

@Rene

did you get the Powerlink? Did it talk to you? What did it say?

Before the RS232 interface of my Powermax broke I was able to do some sniffing and found the commands for disarm, arm home and arm away.

Disarm:
0xA1 0x00 0x00 0x00 <pin> <pin> 0x00 0x00 0x00 0x00 0x00 0x43

Arm home:
0xA1 0x00 0x00 0x04 <pin> <pin> 0x00 0x00 0x00 0x00 0x00 0x43

Arm Away:
0xA1 0x00 0x00 0x05 <pin> <pin> 0x00 0x00 0x00 0x00 0x00 0x43

If your pin is 1357, you should replace <pin> <pin> by 0x13 0x57, do not translate your pin to hex directly!

Hopefully I have a working Powermax again tomorrow evening.

My RS232 is working now (with a LAVA Ether Serial Link):
So I can start testing tomorrow
If there's anything you guys would want me to do or test, just say so

What about the status check, Is it possibile to poll for the status?

Good to know that it works well with the Lava..

Rene wrote:Before the RS232 interface of my Powermax broke I was able to do some sniffing and found the commands for disarm, arm home and arm away.
Disarm:
0xA1 0x00 0x00 0x00 <pin> <pin> 0x00 0x00 0x00 0x00 0x00 0x43
Arm home:
0xA1 0x00 0x00 0x04 <pin> <pin> 0x00 0x00 0x00 0x00 0x00 0x43
Arm Away:
0xA1 0x00 0x00 0x05 <pin> <pin> 0x00 0x00 0x00 0x00 0x00 0x43

I assume the 0x43 is the checksum of the message and has to be calculated with the pin included?

I will try to send some commands on Friday see if it works ....

Oh I forgot mention, the codes shown are without preamble, postamble and checksum. So calculate the checksum and put the preamble in front and rhe checksum and postamble at the back.

And it works! Willem4ever, already tried and confirmed.