Paradox EVO Binding

polychronov · January 12, 2023, 9:49am

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

Mark_VG · January 12, 2023, 10:34am

It is an EVO 192 with IP150+

Mark_VG · January 12, 2023, 10:42am

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:

github.com

ParadoxAlarmInterface/pai/blob/639c273051eb6a4ae7006bbc2df7368efacb7521/paradox/hardware/evo/parsers.py#L732


      
                              "NeWare_connected" / Flag,
                          ),
                      ),
                      "packet_length" / PacketLength(Int8ub),
                      "_not_used0" / Padding(4),
                  )
              ),
              "checksum" / PacketChecksum(Bytes(1)),
          )
          
          
ZoneActionBitOperation = Enum(Int8ub, set=0x08, clear=0x00)
          
          
PerformZoneAction = Struct(
              "fields"
              / RawCopy(
                  Struct(
                      "po" / Struct("command" / Const(0xD0, Int8ub)),
                      "packet_length" / PacketLength(Int8ub),
                      "flags" / ZoneFlagBitStruct,
                      "operation" / ZoneActionBitOperation,
                      "_not_used" / Padding(2),

3 blocks
ZoneActionBitOperation
PerformZoneAction
PerformZoneActionResponse

Tests:

github.com

ParadoxAlarmInterface/pai/blob/639c273051eb6a4ae7006bbc2df7368efacb7521/tests/hardware/evo/test_action.py#L34


      
                  {"fields": {"value": {"partitions": commands, "instant": True}}}
              )
          
          
    print(hexlify(a))
          
          
    assert a == unhexlify(b"400f00000000000000020100000052")
          
          
    assert len(a) == 15
          
          

          
def test_zone_bypass_zone_5():
              expected = b"d01f080800001000000000000000000000000000000000000000000000000f"
          
          
    a = PerformZoneAction.build(
                  {
                      "fields": {
                          "value": {"flags": {"bypassed": True}, "operation": "set", "zones": [5]}
                      }
                  }
              )

polychronov · January 12, 2023, 12:02pm

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.

polychronov · January 12, 2023, 2:13pm

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

Mark_VG · January 12, 2023, 5:15pm

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?

polychronov · January 13, 2023, 8:01am

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…

polychronov · January 13, 2023, 3:21pm

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…

Mark_VG · January 13, 2023, 3:57pm

Hi

The UNBYPASS on Zone 5:

Payload bytes: d01f0800000010000000000000000000000000000000000000000000000007

And UNBYPASS for Zone 23:

Payload bytes: d01f0800000000004000000000000000000000000000000000000000000037

Thank you so much

polychronov · January 21, 2023, 4:32pm

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.

Mark_VG · January 21, 2023, 4:41pm

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.

polychronov · January 24, 2023, 4:21pm

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

Mark_VG · January 25, 2023, 5:24am

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	7	8	8	e	9
	d	2	7	8	0	e	1
ZONE 2	d	2	7	8	8	e	9
	d	2	7	8	0	e	1
ZONE 3	d	2	7	8	8	e	9
	d	2	7	8	0	e	1
ZONE 4	d	2	7	8	8	e	9
	d	2	7	8	0	e	1
ZONE 5	d	2	7	8	8	e	9
	d	2	7	8	0	e	1
ZONE 6	d	2	7	8	8	e	9
	d	2	7	8	0	e	1
ZONE 9	d	2	7	8	8	e	9
	d	2	7	8	0	e	1
ZONE 10	d	2	7	8	8	e	9
	d	2	7	8	0	e	1
ZONE 11	d	2	7	8	8	e	9
	d	2	7	8	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

polychronov · January 25, 2023, 7:39am

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.

Mark_VG · January 25, 2023, 8:30am

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

polychronov · January 25, 2023, 10:36am

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.

polychronov · February 10, 2023, 1:16pm

Jumping here to give a brief update… I’m implementing now the read of the new states as it seems I didn’t implement it last time.
When I do everything it will be ready for testing. Probably I could have done this faster but I can currently invest not more than 2-3 hours weekly into this but at least it seems to be doable without huge effort. The initial model that I’ve created fits the new stuff.
Stay tuned

Mark_VG · February 10, 2023, 3:22pm

Thank you for taking the time to make the changes.
Can you elaborate on reading new states?

polychronov · February 13, 2023, 3:49pm

A certain part of the EVO RAM map is designated for what I called in the binding “special states”. These are from Jean Henning’s excel zone flags:

Zone supervision trouble
Zone in TX delay
Zone shutted down
Zone bypassed
Zone activated intellizone delay
Zone activated entry delay
Zone presently in alarm
Zone generated an alarm

Since we’re currently implementing a command for one of these, I want to make sure that the binding also can read these states and show them as a separate channels. So far it was not implemented but we will need it in order to see when we set a certain zone is in bypassed state.

Cheers,
Konstantin

Mark_VG · February 13, 2023, 5:11pm

Thank you. That makes perfect sense and they will be great to have, edpecialy bupass and alsrm state.
I had confused the zone and partition states in my mind.
Happy to test anything you need. Though still on 3.4.1. Plan to move to 4.0 as soon as milestone released