Paradox EVO Binding

What kind of Paradox EVO are you using is it 96 or 192?

It is an EVO 192 with IP150+

So it seems PAI can bypass zones etc:

Yes. PAI can bypass zones and clear bypass. See: MQTT Interface · ParadoxAlarmInterface/pai Wiki · GitHub

Also got sent the following:

3 blocks
ZoneActionBitOperation
PerformZoneAction
PerformZoneActionResponse

Tests:

Thanks. I’ll have a look later when I have some time…
If you could compare the payloads and figure something just let me know… Seems like they start with something static like with partitions and at the end is put the checksum which is pretty much what we have.
Also I figured that when you bypass a 08 is passed and when you clear bypass 00 is passed in one of the bytes. Not sure what happens with zones above 10 though… with 20+ the numbers become strange.

1 Like

OK So from your responses and the PerformZoneAction struct it seems the following should be the deal:
D0 is constant for command
1F is the packet length - 31 bytes
08 the zone bit flags which is translated to 0000 1000 if we check the flags definition in the structure for these bits, the fifth bit is “bypassed” value set to 1/true.
00/08 is operation => unset/set
00 00 is padding empty two bytes
<then comes a value based on the particular zone 01, 02, 20, 40, etc> - this is what I need to figure how is done this is the part “zones” / BitsSwapped(Bitwise(EnumerationAdapter(Array(192, Flag)))),

Probably like with the partitions there are some masks,shifts and other magic applied to the decimal value so you get with this weird numbers :slight_smile:

So I have 24 Zones only - 2 of which are used for Remotes, so not “real” Zones.
I have done packet captures for all Zones that support BYPASS, and the result is the following pattern:

Not sure how this would be coded though?

So it looks like every bit of the byte represents a zone… will try to code that. Shouldn’t be a big deal.

I will also create a unit test like the one for the partitions (and like the test they also have in python) and will test it against the values you provided above.

Thanks for the shared observation and analysis. Will inform you once I have any progress…

1 Like

Hi, I think I have a rough idea how it should look like and now I’m trying to polish the test so I’m sure that I always construct proper payload, before I try to do it with the real system.
Could you please do a check for me for CLEAR BYPASS on zone 5 and let me know if the checksum (last byte) is 0x07? Whole payload = D01F080000001000 0000000000000000 0000000000000000 00000000000007

Also same for zone 23 - according to my encoder the value should be 0x37 and the total value should be D01F080000000000 4000000000000000 0000000000000000 00000000000037

It’s just to cross-check against the real values…

Hi

The UNBYPASS on Zone 5:

Payload bytes: d01f0800000010000000000000000000000000000000000000000000000007

And UNBYPASS for Zone 23:

Payload bytes: d01f0800000000004000000000000000000000000000000000000000000037

Thank you so much

1 Like

Hi,
A little bit update from my side.
Very busy last 10 days or so… no progress so far as I had zero time…

So your response confirms that overall the coding works, right? Thanks for testing!

Now the other issue - OpenHAB is moving to 4.0.0 version and I started implementing the new operation in the 4.0.0 branch, because I started directly from main branch (didn’t notice the difference). The problem is that 4.0.0 has mandatory requirement for no lower than JDK 17 which I don’t have in my 3.4.x docker environment… also this requirement will probably make the new feature strictly released with OH 4.x which is probably somewhere in the future. I will try to move my changes to the 3.4 branch so I can make the pull request for 3.4.

Best regards,
K.

Thank you so much.
I am currently on 3.4 but was planning to move to 4.0 M1 at the end of tge month when it is released. But happy to wait if that would be better.
Happy to be guided by you.

Hi Mark,

as I coded most of the stuff (still only locally and nothing is tested) but I’m lacking knowledge about the response, may I ask you again to do some tests and now try to monitor the response.
Probably it should be the same for all executions and some values inside should mean “success”.
For example for the partition commands we are reading the “high nible” of the 16th byte and we expect it to be a 0x4 to be success. Then we retrieve the header and the payload. Probably we need to have something like this for the zones and we will have to check what the response contains (probably in the payload)…

Thanks in advance,
Konstantin

Hi Konstantin

I have tabled all the responses for each zone as follows. First is the response to a BYPASS and second is response to UNBYPASS

ZONE 1 d 2 0 7 0 8 0 8 0 0 0 0 e 9
d 2 0 7 0 8 0 0 0 0 0 0 e 1
ZONE 2 d 2 0 7 0 8 0 8 0 0 0 0 e 9
d 2 0 7 0 8 0 0 0 0 0 0 e 1
ZONE 3 d 2 0 7 0 8 0 8 0 0 0 0 e 9
d 2 0 7 0 8 0 0 0 0 0 0 e 1
ZONE 4 d 2 0 7 0 8 0 8 0 0 0 0 e 9
d 2 0 7 0 8 0 0 0 0 0 0 e 1
ZONE 5 d 2 0 7 0 8 0 8 0 0 0 0 e 9
d 2 0 7 0 8 0 0 0 0 0 0 e 1
ZONE 6 d 2 0 7 0 8 0 8 0 0 0 0 e 9
d 2 0 7 0 8 0 0 0 0 0 0 e 1
ZONE 9 d 2 0 7 0 8 0 8 0 0 0 0 e 9
d 2 0 7 0 8 0 0 0 0 0 0 e 1
ZONE 10 d 2 0 7 0 8 0 8 0 0 0 0 e 9
d 2 0 7 0 8 0 0 0 0 0 0 e 1
ZONE 11 d 2 0 7 0 8 0 8 0 0 0 0 e 9
d 2 0 7 0 8 0 0 0 0 0 0 e 1

Is this what you needed?

Also, a typical response in detail (ZONE 1 Response):

BYPASS:

Frame 392: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) on interface \Device\NPF_{FCD2D00D-8F84-4466-AC8C-5E73DB79E516}, id 0
Ethernet II, Src: ParadoxS_17:e4:ea (00:19:ba:17:e4:ea), Dst: HewlettP_bf:12:bd (c4:65:16:bf:12:bd)
Internet Protocol Version 4, Src: 10.163.199.226, Dst: 10.163.199.247
Transmission Control Protocol, Src Port: 10000, Dst Port: 53433, Seq: 13409, Ack: 5601, Len: 32
Paradox Alarm IP message
    Header fields
    Command: Serial passthrough response
    Encrypted payload bytes: 872022f54b16bbcbc196054f77483ac6
    Payload bytes: d20708080000e9
Paradox alarm serial message
    Response: PerformZoneAction (0xd0)
    Status flags: 0x02 (winload)
    Unknown: 0708080000
    Checksum: 0xe9

UNBYPASS:

Frame 395: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) on interface \Device\NPF_{FCD2D00D-8F84-4466-AC8C-5E73DB79E516}, id 0
Ethernet II, Src: ParadoxS_17:e4:ea (00:19:ba:17:e4:ea), Dst: HewlettP_bf:12:bd (c4:65:16:bf:12:bd)
Internet Protocol Version 4, Src: 10.163.199.226, Dst: 10.163.199.247
Transmission Control Protocol, Src Port: 10000, Dst Port: 53433, Seq: 13441, Ack: 5649, Len: 32
Paradox Alarm IP message
    Header fields
    Command: Serial passthrough response
    Encrypted payload bytes: c233ff87fc38b292516b7f4852d4a1e7
    Payload bytes: d20708000000e1
Paradox alarm serial message
    Response: PerformZoneAction (0xd0)
    Status flags: 0x02 (winload)
    Unknown: 0708000000
    Checksum: 0xe1

Thank you very much!

So it seems that the 7th byte’s high nible 0xE means success and probably the low nible 0x1 means bypassed, 0x9 means cleared bypass… something like that. Maybe I could also check the first two bytes to be 0xD2, 0x07, 0x08… I’ll check about that.
Thanks a lot for the capture!

I will code it this way now and we will see if it works when I manage to setup my second container with OH 4.0.0. Decided not to move the changes to 3.4.x as probably 4.0.0 is good enough and not so far away from release…

Cheers,
K.

From the trace the 4th byte also seems to change depending on BYPASS or UNBYPASS?

image

Yep. But these two 08 08 bytes look very much like the request. Maybe I should take them into consideration too… I’ll think about it when I start the implementation.

Cheers,
K.