Hi,
I’ve added the following bug to github: https://github.com/openhab/openhab-addons/issues/13628
I believe I know the reason… wondering how to send you to test the fix.
They have implemented some option to use a marketplace or something… will see how this works.
Cheers,
K.
Ok. I have created a pull request with the fix: https://github.com/openhab/openhab-addons/pull/13629
The pull request above did not solve the multi panel problem and we have moved to different issue on GitHub, https://github.com/openhab/openhab-addons/issues/13640.
With last commit of https://github.com/openhab/openhab-addons/pull/13641 pull request, we have fixed support for multiple panels (bridges).
Hope it will be merged soon.
Hi,
I just updated to OH3.4.0.M4.
Couldn’t find any issue so far with the Paradox integration after the changes related to the singleton panel, so it looks the fix is backwards compatible so far. 
Please let me know if you find anything… Will continue to monitor the behavior the next few days
Cheers,
K.
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
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… 
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:
Still a way to go.
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:
And just for completeness since you already implemented these, DISARM and ARM Partition 3:
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
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?)
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
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) 
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?
