Paradox EVO Binding

I have the same issue with Paradox EVOHD and was wondering if you found a solution?
For what i have read below, evoHD wasn’t supported by the original binding creator.

Found this one for evoHD support with MQTT gateway/broker below, but don’t know if somebody already build a binding based on this or how complex this is in OH3?
Works in HomeAssistant but that doesn’t help here…

Hi All
I have just stated using this Binding after my Caddx system failed and I had to change.

I am having an issue with the Partition and Zone labels not populating from my IP150+ and I am not sure if this is something I am doing wrong or something else:

From the panel I can see the Labels are set, and the Keypad shows the correct information etc.

However openHAB via Binding only sees NULL

image

As far as I can tell all the other values seem to be updated.

I have not tried sending commands to the panel yet - that will be my next task as I hope to do this via the widget I am creating as I go along.

Maybe someone can just clarify how you send the PIN to the panel as part of the command channel?

Thanks for any assistance.
Mark

Hi,
I personally use file definitions so I’m not sure why the partition labels are not read. I guess I have to check the code of the discoverer to be able to give clear answer.
For the commands I believe you don’t need a PIN. The commands are sent as a byte value to the panel using the IP150 password and the PC password which should have been already defined in the bridge configuration.

Cheers,
Konstantin

That would be appreciated. The weird part is that it is the labels for zones as well as partitions.

This is what I see in DEBUG log - no mention of Label?

2022-12-21 17:12:41.321 [DEBUG] [nhab.binding.paradoxalarm.internal.model.Partition] - Partition House:	Disarmed
2022-12-21 17:12:41.321 [DEBUG] [nhab.binding.paradoxalarm.internal.model.Partition] - Partition Beams:	Disarmed
2022-12-21 17:12:41.321 [DEBUG] [nhab.binding.paradoxalarm.internal.model.Partition] - Partition Ceiling:	Armed
2022-12-21 17:12:41.321 [DEBUG] [nhab.binding.paradoxalarm.internal.model.Partition] - Partition Flat:	Disarmed
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone MAG Front Door state updated to:	Opened: true, Tampered: false, LowBattery: false
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone MAG Kitchen Door state updated to:	Opened: false, Tampered: false, LowBattery: false
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone PIR Kitchen state updated to:	Opened: false, Tampered: false, LowBattery: false
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone PIR Lounge state updated to:	Opened: false, Tampered: false, LowBattery: false
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone PIR Garage state updated to:	Opened: false, Tampered: false, LowBattery: false
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone PIR Main Bed state updated to:	Opened: false, Tampered: false, LowBattery: false
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone Zone 007 state updated to:	Opened: false, Tampered: false, LowBattery: false
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone Zone 008 state updated to:	Opened: false, Tampered: false, LowBattery: false
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone VX Entrance state updated to:	Opened: false, Tampered: false, LowBattery: false
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone BX Side Bedroom state updated to:	Opened: false, Tampered: false, LowBattery: false
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone BX Main Bedroom state updated to:	Opened: false, Tampered: false, LowBattery: false
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone VX Cottage state updated to:	Opened: false, Tampered: false, LowBattery: false
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone VXGarden Pole state updated to:	Opened: false, Tampered: false, LowBattery: false
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone VX Pool state updated to:	Opened: false, Tampered: false, LowBattery: false
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone VX Courtyard state updated to:	Opened: false, Tampered: false, LowBattery: false
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone VX Pond state updated to:	Opened: false, Tampered: false, LowBattery: false
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone PIR Dining Room state updated to:	Opened: false, Tampered: false, LowBattery: false
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone PIR Ceiling state updated to:	Opened: false, Tampered: false, LowBattery: false
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone Remote Panic state updated to:	Opened: false, Tampered: false, LowBattery: false
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone MAG GF  Doors state updated to:	Opened: true, Tampered: false, LowBattery: false
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone MAG GF Bedroom state updated to:	Opened: false, Tampered: false, LowBattery: false
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone MAG GF Lounge state updated to:	Opened: false, Tampered: false, LowBattery: false
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone PIR Passage state updated to:	Opened: false, Tampered: false, LowBattery: false
2022-12-21 17:12:41.321 [DEBUG] [g.openhab.binding.paradoxalarm.internal.model.Zone] - Zone Panic state updated to:	Opened: false, Tampered: false, LowBattery: false

Hi All
I have another question - Is there any way to BYPASS and UNBYPASS zones via the binding?
I see there is no command channel on the Zones, however it looks like the API could support the option?

Many Thanks
Mark

Hi,
what is this API you’re referring to?
Currently the binding is using byte code to call the IP150. If there is an official API that could be worthy to rewrite the binding with modern stuff. This could also lead to support of unsupported panels.
Can you share the docs you’re reading?

Cheers,
K.

Hi Konstantin
I have PM you the document (link via Google Drive).

Seems very similar to what is implemented in the binding, so I assumed binding was based on that. It is an old document though.

Thanks
Mark

Oh. I’ve seen this. This is expected to work on Windows (the DLLs and stuff). Unfortunately I cannot use it. Would have been so much better if Paradox implements a normal REST API on their IP150 and document it… :weary:

Agreed.
Is there anything I can do to try and assist in getting information to add BYPASS etc? I am not a coder by any means. But not bad at network sniffing etc.

Just to show you my WIP widget:

Paradox WIP

Still a way to go.

1 Like

Well… I’m currently very busy with other topics so could not invest much time in something like this and the development of this binding was extremely difficult to me due to the lack of API. Thanks to the guys who already reverse engineered the protocol I managed to do that but I prefer not to invest in more functionality at the moment.

For the discovery issue it’s really strange because from what I see in the debug indeed we’re parsing the partition correctly and inside the Partition object the label should have been retrieved from the Panel. Could you please check the debug logs during discovery for lines containing “Parittion DiscoveryResult=”.
Looking in the code it should work. Maybe it will add for you Partition “then the actual” label but that shouldn’t be much of an issue…

 DiscoveryResult result = DiscoveryResultBuilder.create(thingUID).withBridge(bridgeUid)
                    .withLabel("Partition " + label).withProperty(PARTITION_THING_TYPE_ID, thingId)
                    .withProperty("id", partition.getId()).build();
            logger.debug("Partition DiscoveryResult={}", result);

Cheers,
K.

Thank you.
That is unfortunate, but I fully understand. Just wish I was capable to do it…

2022-12-22 11:18:38.915 [DEBUG] [oxalarm.internal.discovery.ParadoxDiscoveryService] - Partition DiscoveryResult=DiscoveryResult [thingUID=paradoxalarm:partition:ParadoxIP150:partition1, properties={partition=partition1, id=1}, representationProperty=null, flag=NEW, label=Partition House, bridgeUID=paradoxalarm:ip150:ParadoxIP150, ttl=-1, timestamp=1671700718915]
2022-12-22 11:18:38.915 [DEBUG] [oxalarm.internal.discovery.ParadoxDiscoveryService] - Partition DiscoveryResult=DiscoveryResult [thingUID=paradoxalarm:partition:ParadoxIP150:partition2, properties={partition=partition2, id=2}, representationProperty=null, flag=NEW, label=Partition Beams, bridgeUID=paradoxalarm:ip150:ParadoxIP150, ttl=-1, timestamp=1671700718915]
2022-12-22 11:18:38.915 [DEBUG] [oxalarm.internal.discovery.ParadoxDiscoveryService] - Partition DiscoveryResult=DiscoveryResult [thingUID=paradoxalarm:partition:ParadoxIP150:partition3, properties={partition=partition3, id=3}, representationProperty=null, flag=NEW, label=Partition Ceiling, bridgeUID=paradoxalarm:ip150:ParadoxIP150, ttl=-1, timestamp=1671700718915]
2022-12-22 11:18:38.915 [DEBUG] [oxalarm.internal.discovery.ParadoxDiscoveryService] - Partition DiscoveryResult=DiscoveryResult [thingUID=paradoxalarm:partition:ParadoxIP150:partition4, properties={partition=partition4, id=4}, representationProperty=null, flag=NEW, label=Partition Flat, bridgeUID=paradoxalarm:ip150:ParadoxIP150, ttl=-1, timestamp=1671700718915]
2022-12-22 11:18:38.915 [DEBUG] [oxalarm.internal.discovery.ParadoxDiscoveryService] - Zone DiscoveryResult=DiscoveryResult [thingUID=paradoxalarm:zone:ParadoxIP150:MAG_Front_Door, properties={zone=MAG_Front_Door, id=1}, representationProperty=null, flag=NEW, label=Zone MAG Front Door, bridgeUID=paradoxalarm:ip150:ParadoxIP150, ttl=-1, timestamp=1671700718915]
2022-12-22 11:18:38.915 [DEBUG] [oxalarm.internal.discovery.ParadoxDiscoveryService] - Zone DiscoveryResult=DiscoveryResult [thingUID=paradoxalarm:zone:ParadoxIP150:MAG_Kitchen_Door, properties={zone=MAG_Kitchen_Door, id=2}, representationProperty=null, flag=NEW, label=Zone MAG Kitchen Door, bridgeUID=paradoxalarm:ip150:ParadoxIP150, ttl=-1, timestamp=1671700718915]

IS that what you needed?

Hi Konstantin

Would really love to see some added functionality as well as some fixes to the binding. |I fully understand your reluctance, but hope to either get your buy-in or your assistance?

Not sure if you are aware of the following dissector for Wireshark (only works with 3.4.x)?

This is a WIP that has stalled, however still provides useful information.
As long as you capture the full TCP stream from Babyware etc the traffic is all decrypted and seemingly ready for passing to the Paradox by the binding?
So for example, here is a capture of the BYPASS Zone command on Zone 1:


The acknowledgement:
image
The UNBYPASS:

and acknowledgement:
image

And just for completeness since you already implemented these, DISARM and ARM Partition 3:

image
image
Which seems to tie up with what the binding does?

2022-12-28 07:47:59.477 [DEBUG] [nhab.binding.paradoxalarm.internal.model.Partition] - Submitting command=DISARM for partition=[Entity [id=3, label=Ceiling]]

2022-12-28 07:47:59.477 [TRACE] [ding.paradoxalarm.internal.communication.SyncQueue] - Adding to queue request=Request [packet=ParadoxIPPacket [[REDACT] 01EEEEEEEEEEEEEE 400F000000000060 000000000000AF], timestamp=0, type=PARTITION_COMMAND]

2022-12-28 07:47:59.477 [TRACE] [xalarm.internal.communication.AbstractCommunicator] - Sending packet with request=Request [packet=ParadoxIPPacket [[REDACT] 01EEEEEEEEEEEEEE 400F000000000060 000000000000AF], timestamp=0, type=PARTITION_COMMAND]

2022-12-28 07:47:59.477 [TRACE] [hab.binding.paradoxalarm.internal.util.ParadoxUtil] - Packet payload size: 15

2022-12-28 07:47:59.477 [TRACE] [hab.binding.paradoxalarm.internal.util.ParadoxUtil] - Tx Packet: [REDACT] 01EEEEEEEEEEEEEE 400F000000000060 000000000000AF

image
image

2022-12-28 07:48:07.936 [DEBUG] [nhab.binding.paradoxalarm.internal.model.Partition] - Submitting command=ARM for partition=[Entity [id=3, label=Ceiling]]

2022-12-28 07:48:07.936 [TRACE] [ding.paradoxalarm.internal.communication.SyncQueue] - Adding to queue request=Request [packet=ParadoxIPPacket [[REDACT] 01EEEEEEEEEEEEEE 400F000000000020 0000000000006F], timestamp=0, type=PARTITION_COMMAND]

2022-12-28 07:48:07.936 [TRACE] [xalarm.internal.communication.AbstractCommunicator] - Sending packet with request=Request [packet=ParadoxIPPacket [[REDACT] 01EEEEEEEEEEEEEE 400F000000000020 0000000000006F], timestamp=0, type=PARTITION_COMMAND]

2022-12-28 07:48:07.936 [TRACE] [hab.binding.paradoxalarm.internal.util.ParadoxUtil] - Packet payload size: 15

2022-12-28 07:48:07.936 [TRACE] [hab.binding.paradoxalarm.internal.util.ParadoxUtil] - Tx Packet: [REDACT] 01EEEEEEEEEEEEEE 400F000000000020 0000000000006F

I am hoping that the dissector would make your task easier as in theory the payload etc would already be there?

Failing that would you be able to point me to the data used for the decoded packets you used in development? It seems that all the dropbox links etc are no longer valid? Maybe you could share an example of the ARM/DISARM command so that I can try see how it compares to what the dissector provides?

Maybe I could then try and make the additions myself (not a coder so this may well not work), or try and entice someone with a bounty?

The regarding the Partition and Zone labels - Should the channels be populated? Or are you saying that the label is only used to create the THING? (Was not sure based on your response above?)
image

Thanks so much
Mark

Hi,
I used mostly what JPBaracca made into his python scripts and just coded it with Java (see the very first topic - GitHub - ParadoxAlarmInterface/pai: Paradox Magellan, Spectra and EVO, with MQTT, Signal, Pushbullet, Pushover and others).

All in all in the trace/debug level you should be able to see all the packets written as HEX so this is what I send to the paradox indeed (for the partitions). I can have a look into the code and try to understand again what I did :slight_smile:
What exactly you’re interested into? Is it the arm/disarm commands for the partitions?

The regarding the Partition and Zone labels - Should the channels be populated? Or are you saying that the label is only used to create the THING? (Was not sure based on your response above?)

When I do the discovery, I retrieve the labels from the paradox system and then I create them as a part of the result. It seems that even though I’m building the discovery result with the “withLabel()” method it does not get used in the UI for some reason. Maybe what I could do is to add additional property “label” and put it there so you can see it as a channel… or maybe better to check with the framework developers about this. In my opinion this does not look as expected…

Cheers,
K.

The logic for how we build the partition command is in this class:

From what I see we’re building a static payload and we only change the part in the calculateMessagBytes() method based on the partition. It seems that we build an array of 4 bytes and based on the partition number and whether it’s odd or even we send particular value.
The commands are extracted in a separate enum, called PartitionCommand.java where for each command there is a respective byte value it seems (openhab-addons/PartitionCommand.java at main · openhab/openhab-addons · GitHub)

Please have a look into this. Java is pretty easy to read language (besides these byte maskings and shifts left/right) :smiley:

Hi Konstantin
I really appreciate you getting back on this.

So for me the ARM/DISARM (or Partitions) are working well. I am able to use both of those just fine.

What have found to not be working is the Partiton/Zone Label Channel - this value is always NULL:

I appears that you do receive the Label from the panel, and this is used to construct the Partition/Zone THING, but the Labels are not populated.

I have worked around this using the Partition/Zone THING Name, which seems to be OK, but it would be nice to have the Channel populated.

What I would REALLY love to be able to do is related to the ZONES, so be able to BYPASS/UNBYPASS zones and to see the BYPASS state of the Zones.

This seems to be possible when I look at the Babyware packet captures with Wireshark, but I have no idea how/where to implement this and would know where to start. I have decrypted the packets and think I can see what needs to be sent to the ZONE to achieve this.

Thanks again.
Mark

Thanks for pointing me here. Will look again and see if I can make any headway. My concern howvere if that the BYPASS/UNBYPASS would be on the ZONE, not the PARTITION, so may be a bit more challenging?

Hi Mark,
I’m giving you some hints just so you know what we do where. If you could trace the exact differences in HEX in the request/response for the zones, I guess I can code it myself but I’m really not into the low-level protocols.
My idea is so you know what the HEX-es mean for the partition, maybe you could do the reverse-engineer for the zones. You’re right that currently the “Command” class relies on partitions (because the partition number is used in the way the HEX part is generated. For the zones I will have to create maybe a separate class or extend this one but that’s not currently what we need. We need to know what the bypass zone looks like as a request (and maybe a response). Once we know what to put where, the Java coding can be done.

Do you think you can do this for me and maybe from there we can move on with the feature implementation… also if you have python knowledge maybe you could check the other repo I posted. Maybe JPBaracca already did this and we can port that to Java.
I’m just currently really lacking time so can’t do much investigation myself…

(P.S. Just checked - it seems they do support it: Toggle for zone bypass · Issue #317 · ParadoxAlarmInterface/pai · GitHub)

(For the label issue I will open a topic in the developers forum and will reference your issue. Let’s see what the framework developers will say about this)

Cheers,
K.

Thanks Konstantin

I have posted a question regarding ZONE actions on the GITTER for PIA - so hopefully get a response.

I have looked at the Pytjon etc, but sadly beyond my capabilities.

So I have done a few traces on BYPASS and UNBYPASS using Babyware and then decoded using wireshark, so the payloads should be unencrypted.

The following is a BYPASS request to ZONE 1:
Request -

Frame 391: 102 bytes on wire (816 bits), 102 bytes captured (816 bits) on interface \Device\NPF_{FCD2D00D-8F84-4466-AC8C-5E73DB79E516}, id 0
    Interface id: 0 (\Device\NPF_{FCD2D00D-8F84-4466-AC8C-5E73DB79E516})
        Interface name: \Device\NPF_{FCD2D00D-8F84-4466-AC8C-5E73DB79E516}
        Interface description: Ethernet 4
    Encapsulation type: Ethernet (1)
    Arrival Time: Dec 22, 2022 13:59:31.476719000 South Africa Standard Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1671710371.476719000 seconds
    [Time delta from previous captured frame: 9.696055000 seconds]
    [Time delta from previous displayed frame: 9.696055000 seconds]
    [Time since reference or first frame: 43.195331000 seconds]
    Frame Number: 391
    Frame Length: 102 bytes (816 bits)
    Capture Length: 102 bytes (816 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:tcp:paradoxip]
    [Coloring Rule Name: TCP]
    [Coloring Rule String: tcp]
Ethernet II, Src: HewlettP_bf:12:bd (c4:65:16:bf:12:bd), Dst: ParadoxS_17:e4:ea (00:19:ba:17:e4:ea)
Internet Protocol Version 4, Src: 10.163.199.247, Dst: 10.163.199.226
Transmission Control Protocol, Src Port: 53433, Dst Port: 10000, Seq: 5553, Ack: 13409, Len: 48
Paradox Alarm IP message
    Header fields
        Start marker: 0xaa
        Message length: 31
        Message Type: Serial pass-thru Request (4)
        Flags: 0x09 (installer_mode encrypted)
            0... .... = bit8: False
            .0.. .... = keep_alive: False
            ..0. .... = live_events: False
            ...0 .... = neware: False
            .... 1... = installer_mode: True
            .... .0.. = bit3: False
            .... ..0. = upload_download: False
            .... ...1 = encrypted: True
        Command: Passthrough (0x00)
        Sub-command: Unknown (0x00)
        WT: 100
        SB: 0
        Encryption Type: aes_256_ecb (1)
        Unused bytes: eeeeeeeeb1
        SequenceID: 0x14
    Command: Serial passthrough request
    Encrypted payload bytes: 77cc1efb1b3c3168eeee0138b8b955f75ebd673d104355d79e548a1adb3d8ef6
    Payload bytes: d01f0808000001000000000000000000000000000000000000000000000000
Paradox alarm serial message
    Request: ReadEEPROM (0x50)
    Unknown: 1f08080000010000000000000000000000000000000000000000000000
    Checksum: 0x00

Response -

Frame 392: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) on interface \Device\NPF_{FCD2D00D-8F84-4466-AC8C-5E73DB79E516}, id 0
    Interface id: 0 (\Device\NPF_{FCD2D00D-8F84-4466-AC8C-5E73DB79E516})
        Interface name: \Device\NPF_{FCD2D00D-8F84-4466-AC8C-5E73DB79E516}
        Interface description: Ethernet 4
    Encapsulation type: Ethernet (1)
    Arrival Time: Dec 22, 2022 13:59:31.493857000 South Africa Standard Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1671710371.493857000 seconds
    [Time delta from previous captured frame: 0.017138000 seconds]
    [Time delta from previous displayed frame: 0.017138000 seconds]
    [Time since reference or first frame: 43.212469000 seconds]
    Frame Number: 392
    Frame Length: 86 bytes (688 bits)
    Capture Length: 86 bytes (688 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:tcp:paradoxip]
    [Coloring Rule Name: TCP]
    [Coloring Rule String: tcp]
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
        Start marker: 0xaa
        Message length: 7
        Message Type: Serial pass-thru Response (2)
        Flags: 0x63 (keep_alive live_events upload_download encrypted)
            0... .... = bit8: False
            .1.. .... = keep_alive: True
            ..1. .... = live_events: True
            ...0 .... = neware: False
            .... 0... = installer_mode: False
            .... .0.. = bit3: False
            .... ..1. = upload_download: True
            .... ...1 = encrypted: True
        Command: Passthrough (0x00)
        Sub-command: Unknown (0x00)
        WT: 0
        SB: 3
        Encryption Type: old_module (238)
        Unused bytes: 00eeeeeec0
        SequenceID: 0x0b
    Command: Serial passthrough response
    Encrypted payload bytes: 872022f54b16bbcbc196054f77483ac6
    Payload bytes: d20708080000e9
Paradox alarm serial message
    Response: PerformZoneAction (0xd0)
    Status flags: 0x02 (winload)
        .... 0... = reserved: False
        .... .0.. = alarm_reporting_pending: False
        .... ..1. = Winload_connected: True
        .... ...0 = NeWare_connected: False
    Unknown: 0708080000
    Checksum: 0xe9

and UNBYPASS ZONE 1:
Request -

Frame 394: 102 bytes on wire (816 bits), 102 bytes captured (816 bits) on interface \Device\NPF_{FCD2D00D-8F84-4466-AC8C-5E73DB79E516}, id 0
    Interface id: 0 (\Device\NPF_{FCD2D00D-8F84-4466-AC8C-5E73DB79E516})
        Interface name: \Device\NPF_{FCD2D00D-8F84-4466-AC8C-5E73DB79E516}
        Interface description: Ethernet 4
    Encapsulation type: Ethernet (1)
    Arrival Time: Dec 22, 2022 13:59:43.141219000 South Africa Standard Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1671710383.141219000 seconds
    [Time delta from previous captured frame: 11.603979000 seconds]
    [Time delta from previous displayed frame: 11.603979000 seconds]
    [Time since reference or first frame: 54.859831000 seconds]
    Frame Number: 394
    Frame Length: 102 bytes (816 bits)
    Capture Length: 102 bytes (816 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:tcp:paradoxip]
    [Coloring Rule Name: TCP]
    [Coloring Rule String: tcp]
Ethernet II, Src: HewlettP_bf:12:bd (c4:65:16:bf:12:bd), Dst: ParadoxS_17:e4:ea (00:19:ba:17:e4:ea)
Internet Protocol Version 4, Src: 10.163.199.247, Dst: 10.163.199.226
Transmission Control Protocol, Src Port: 53433, Dst Port: 10000, Seq: 5601, Ack: 13441, Len: 48
Paradox Alarm IP message
    Header fields
        Start marker: 0xaa
        Message length: 31
        Message Type: Serial pass-thru Request (4)
        Flags: 0x09 (installer_mode encrypted)
            0... .... = bit8: False
            .0.. .... = keep_alive: False
            ..0. .... = live_events: False
            ...0 .... = neware: False
            .... 1... = installer_mode: True
            .... .0.. = bit3: False
            .... ..0. = upload_download: False
            .... ...1 = encrypted: True
        Command: Passthrough (0x00)
        Sub-command: Unknown (0x00)
        WT: 100
        SB: 0
        Encryption Type: aes_256_ecb (1)
        Unused bytes: eeeeeeeed0
        SequenceID: 0x15
    Command: Serial passthrough request
    Encrypted payload bytes: 43e6dc118cff6de680c144b1a5d89e8844b33eb5edbe0204ac5a6f7a7111a470
    Payload bytes: d01f08000000010000000000000000000000000000000000000000000000f8
Paradox alarm serial message
    Request: ReadEEPROM (0x50)
    Unknown: 1f08000000010000000000000000000000000000000000000000000000
    Checksum: 0x78

Response -

Frame 395: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) on interface \Device\NPF_{FCD2D00D-8F84-4466-AC8C-5E73DB79E516}, id 0
    Interface id: 0 (\Device\NPF_{FCD2D00D-8F84-4466-AC8C-5E73DB79E516})
        Interface name: \Device\NPF_{FCD2D00D-8F84-4466-AC8C-5E73DB79E516}
        Interface description: Ethernet 4
    Encapsulation type: Ethernet (1)
    Arrival Time: Dec 22, 2022 13:59:43.162553000 South Africa Standard Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1671710383.162553000 seconds
    [Time delta from previous captured frame: 0.021334000 seconds]
    [Time delta from previous displayed frame: 0.021334000 seconds]
    [Time since reference or first frame: 54.881165000 seconds]
    Frame Number: 395
    Frame Length: 86 bytes (688 bits)
    Capture Length: 86 bytes (688 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:tcp:paradoxip]
    [Coloring Rule Name: TCP]
    [Coloring Rule String: tcp]
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
        Start marker: 0xaa
        Message length: 7
        Message Type: Serial pass-thru Response (2)
        Flags: 0x63 (keep_alive live_events upload_download encrypted)
            0... .... = bit8: False
            .1.. .... = keep_alive: True
            ..1. .... = live_events: True
            ...0 .... = neware: False
            .... 0... = installer_mode: False
            .... .0.. = bit3: False
            .... ..1. = upload_download: True
            .... ...1 = encrypted: True
        Command: Passthrough (0x00)
        Sub-command: Unknown (0x00)
        WT: 0
        SB: 3
        Encryption Type: old_module (238)
        Unused bytes: 00eeeeeed5
        SequenceID: 0x0d
    Command: Serial passthrough response
    Encrypted payload bytes: c233ff87fc38b292516b7f4852d4a1e7
    Payload bytes: d20708000000e1
Paradox alarm serial message
    Response: PerformZoneAction (0xd0)
    Status flags: 0x02 (winload)
        .... 0... = reserved: False
        .... .0.. = alarm_reporting_pending: False
        .... ..1. = Winload_connected: True
        .... ...0 = NeWare_connected: False
    Unknown: 0708000000
    Checksum: 0xe1

I can do more if that would help?

Thanks So Much

Can you try to identify what is changed based on the different zone number in the request/response so maybe we know which HEX is changed in what way when the particular zone is bypassed, i.e. maybe if it’s zone 1 → 01, zone2 → 02… zone 192 → C0 and what is the relation to bypass/unbypass? Basically what in this byte stream differs when you’re changing zone and command.

Something like this?

BYPASS Zone 1:
Request:

Frame 391: 102 bytes on wire (816 bits), 102 bytes captured (816 bits) on interface \Device\NPF_{FCD2D00D-8F84-4466-AC8C-5E73DB79E516}, id 0
Ethernet II, Src: HewlettP_bf:12:bd (c4:65:16:bf:12:bd), Dst: ParadoxS_17:e4:ea (00:19:ba:17:e4:ea)
Internet Protocol Version 4, Src: 10.163.199.247, Dst: 10.163.199.226
Transmission Control Protocol, Src Port: 53433, Dst Port: 10000, Seq: 5553, Ack: 13409, Len: 48
Paradox Alarm IP message
    Header fields
    Command: Serial passthrough request
    Encrypted payload bytes: 77cc1efb1b3c3168eeee0138b8b955f75ebd673d104355d79e548a1adb3d8ef6
    Payload bytes: d01f0808000001000000000000000000000000000000000000000000000000
Paradox alarm serial message
    Request: ReadEEPROM (0x50)
    Unknown: 1f08080000010000000000000000000000000000000000000000000000
    Checksum: 0x00

BYPASS Zone 2:
Request:

Frame 395: 102 bytes on wire (816 bits), 102 bytes captured (816 bits) on interface \Device\NPF_{FCD2D00D-8F84-4466-AC8C-5E73DB79E516}, id 0
Ethernet II, Src: HewlettP_bf:12:bd (c4:65:16:bf:12:bd), Dst: ParadoxS_17:e4:ea (00:19:ba:17:e4:ea)
Internet Protocol Version 4, Src: 10.163.199.247, Dst: 10.163.199.226
Transmission Control Protocol, Src Port: 53601, Dst Port: 10000, Seq: 5585, Ack: 13441, Len: 48
Paradox Alarm IP message
    Header fields
    Command: Serial passthrough request
    Encrypted payload bytes: dbd5e62835fc53ad89019adce243887998e86b910644474400c16cb1a4b457e5
    Payload bytes: d01f0808000002000000000000000000000000000000000000000000000001
Paradox alarm serial message
    Request: ReadEEPROM (0x50)
    Unknown: 1f08080000020000000000000000000000000000000000000000000000
    Checksum: 0x01

BYPASS Zone 20:
Request:

Frame 382: 102 bytes on wire (816 bits), 102 bytes captured (816 bits) on interface \Device\NPF_{FCD2D00D-8F84-4466-AC8C-5E73DB79E516}, id 0
Ethernet II, Src: HewlettP_bf:12:bd (c4:65:16:bf:12:bd), Dst: ParadoxS_17:e4:ea (00:19:ba:17:e4:ea)
Internet Protocol Version 4, Src: 10.163.199.247, Dst: 10.163.199.226
Transmission Control Protocol, Src Port: 53962, Dst Port: 10000, Seq: 5521, Ack: 13281, Len: 48
Paradox Alarm IP message
    Header fields
    Command: Serial passthrough request
    Encrypted payload bytes: 7bbb4f6bb79e3c7fef3cd2192186b9a68a3837827b45bf257b1b2cb7fbe87985
    Payload bytes: d01f0808000000000800000000000000000000000000000000000000000007
Paradox alarm serial message
    Request: ReadEEPROM (0x50)
    Unknown: 1f08080000000008000000000000000000000000000000000000000000
    Checksum: 0x07

BYPASS Zone 23:
Request:

Frame 463: 102 bytes on wire (816 bits), 102 bytes captured (816 bits) on interface \Device\NPF_{FCD2D00D-8F84-4466-AC8C-5E73DB79E516}, id 0
Ethernet II, Src: HewlettP_bf:12:bd (c4:65:16:bf:12:bd), Dst: ParadoxS_17:e4:ea (00:19:ba:17:e4:ea)
Internet Protocol Version 4, Src: 10.163.199.247, Dst: 10.163.199.226
Transmission Control Protocol, Src Port: 57249, Dst Port: 10000, Seq: 6641, Ack: 16625, Len: 48
Paradox Alarm IP message
    Header fields
    Command: Serial passthrough request
    Encrypted payload bytes: e49738c2da2cdcf3c3499cb095273bcd1d77e7649a645837443dbe61cf7c22fc
    Payload bytes: d01f080800000000400000000000000000000000000000000000000000003f
Paradox alarm serial message
    Request: ReadEEPROM (0x50)
    Unknown: 1f08080000000040000000000000000000000000000000000000000000
    Checksum: 0x3f