Hello Jossuar and rest.
I am like some other people here considering moving from my Vera to Openhab. I have an NX10 integrated with my Vera via serial and mostly works ok (i have a USB extender to make things work best and it is the only failure piont as it losses connection from time to time.)
does you binding work via the 595 or is it only serial (apologies regarding the newbie quesitons) - I have an NX10 and too many devices to count 
Hi @alexkarageorgis,
the binding only works with the serial interface via the NX-584 protocol.
The NX595 does not have an open specification for the protocol it uses to communicate over TCP/IP afaik. My attempts to communicate via the Web interface of the card resulted in the card being sent back to support to be reflashed again. So i stopped trying to integrate the card and removed it from the panel.
Hi @Jo0p,
give it a try with the below jar:
Latest
You should see something like the below which is from my logfile:
2020-12-07 10:31:50.111 [DEBUG] [ing.caddx.internal.CaddxCommunicator] - <-: Zone Status Message [Zone: 11]
2020-12-07 10:31:50.114 [DEBUG] [ing.caddx.internal.CaddxCommunicator] - <-: 7E 08 84 0A 01 58 53 F8 11 00 4D CC
2020-12-07 10:31:50.117 [DEBUG] [.internal.handler.CaddxBridgeHandler] - Zone 11 Transition ignored.
2020-12-07 10:31:50.120 [DEBUG] [ing.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
2020-12-07 10:31:50.123 [DEBUG] [ing.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
2020-12-07 10:31:50.152 [DEBUG] [ing.caddx.internal.CaddxCommunicator] - <-: Zones Snapshot Message
2020-12-07 10:31:50.155 [DEBUG] [ing.caddx.internal.CaddxCommunicator] - <-: 7E 0A 85 00 80 00 00 00 00 03 00 00 13 B2
2020-12-07 10:31:50.158 [DEBUG] [x.internal.handler.ThingHandlerPanel] - Flags for zone 1. faulted:false, bypassed:false, trouble:false, alarm_memory:false
2020-12-07 10:31:50.161 [DEBUG] [x.internal.handler.ThingHandlerPanel] - Thing found for zone 1.
2020-12-07 10:31:50.168 [DEBUG] [x.internal.handler.ThingHandlerPanel] - Flags for zone 2. faulted:false, bypassed:false, trouble:false, alarm_memory:true
2020-12-07 10:31:50.171 [DEBUG] [x.internal.handler.ThingHandlerPanel] - Flags for zone 3. faulted:false, bypassed:false, trouble:false, alarm_memory:false
2020-12-07 10:31:50.174 [DEBUG] [x.internal.handler.ThingHandlerPanel] - Flags for zone 4. faulted:false, bypassed:false, trouble:false, alarm_memory:false
2020-12-07 10:31:50.177 [DEBUG] [x.internal.handler.ThingHandlerPanel] - Flags for zone 5. faulted:false, bypassed:false, trouble:false, alarm_memory:false
2020-12-07 10:31:50.180 [DEBUG] [x.internal.handler.ThingHandlerPanel] - Flags for zone 6. faulted:false, bypassed:false, trouble:false, alarm_memory:false
2020-12-07 10:31:50.183 [DEBUG] [x.internal.handler.ThingHandlerPanel] - Flags for zone 7. faulted:false, bypassed:false, trouble:false, alarm_memory:false
2020-12-07 10:31:50.186 [DEBUG] [x.internal.handler.ThingHandlerPanel] - Flags for zone 8. faulted:false, bypassed:false, trouble:false, alarm_memory:false
2020-12-07 10:31:50.189 [DEBUG] [x.internal.handler.ThingHandlerPanel] - Flags for zone 9. faulted:false, bypassed:false, trouble:false, alarm_memory:false
2020-12-07 10:31:50.192 [DEBUG] [x.internal.handler.ThingHandlerPanel] - Flags for zone 10. faulted:false, bypassed:false, trouble:false, alarm_memory:false
2020-12-07 10:31:50.195 [DEBUG] [x.internal.handler.ThingHandlerPanel] - Flags for zone 11. faulted:true, bypassed:true, trouble:false, alarm_memory:false
2020-12-07 10:31:50.198 [DEBUG] [x.internal.handler.ThingHandlerPanel] - Flags for zone 12. faulted:false, bypassed:false, trouble:false, alarm_memory:false
2020-12-07 10:31:50.201 [DEBUG] [x.internal.handler.ThingHandlerPanel] - Flags for zone 13. faulted:false, bypassed:false, trouble:false, alarm_memory:false
2020-12-07 10:31:50.204 [DEBUG] [x.internal.handler.ThingHandlerPanel] - Flags for zone 14. faulted:false, bypassed:false, trouble:false, alarm_memory:false
2020-12-07 10:31:50.207 [DEBUG] [x.internal.handler.ThingHandlerPanel] - Flags for zone 15. faulted:false, bypassed:false, trouble:false, alarm_memory:false
2020-12-07 10:31:50.210 [DEBUG] [x.internal.handler.ThingHandlerPanel] - Flags for zone 16. faulted:false, bypassed:false, trouble:false, alarm_memory:false
2020-12-07 10:31:50.255 [DEBUG] [ing.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
2020-12-07 10:31:50.258 [DEBUG] [ing.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
On the console you should see the below version:
openhab> bundle:list | grep -i caddx
255 x Active x 80 x 2.5.11.202012132150 x openHAB Add-ons :: Bundles :: Caddx Binding
Hi Jossuar,
Hereby the results of a quick test:
23:44:36.585 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zone Status Message [Zone: 6]
23:44:36.586 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 08 84 05 01 01 05 C4 00 00 5D FC
23:44:36.587 [DEBUG] [x.internal.handler.CaddxBridgeHandler] - Zone 6 Transition ignored.
23:44:36.588 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
23:44:36.589 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
23:44:36.626 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zones Snapshot Message
23:44:36.627 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 0A 85 01 00 00 00 00 00 00 10 00 A0 CE
23:44:36.637 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
23:44:36.638 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
23:44:38.987 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zone Status Message [Zone: 6]
23:44:38.988 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 08 84 05 01 01 05 C4 00 00 5D FC
23:44:38.989 [DEBUG] [x.internal.handler.CaddxBridgeHandler] - Zone 6 Transition ignored.
23:44:38.990 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
23:44:38.992 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
23:44:39.028 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zones Snapshot Message
23:44:39.029 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 0A 85 01 00 00 00 00 00 00 00 00 90 AE
23:44:39.038 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
23:44:39.039 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
openhab> bundle:list | grep -i caddx
openhab> bundle:list | grep -i caddx
278 │ Active │ 80 │ 2.5.11.202012132150 │ openHAB Add-ons :: Bundles :: Caddx BindingHi Jossuar,
Have you found some way to resolve the bug, or is there any way to provide you more information to help you?
Best holiday wishes, thank you for your great contribution this year! 
Johan.
I need some help to understand the working of arm/stay/disarm. I have created a button to arm the panel with code below:
rule “ARM paneel”
when
Item Caddx_ARM changed from OFF to ON
then
val actions = getActions(“caddx”,“caddx:panel:12345678:panel”)
if (null === actions) {
logWarn(“actions”, “Actions not found, check thing ID for the Partition”)
return
}
actions.exit()
logInfo(“scene”, "Caddx_ARM = " + Caddx_ARM.state.toString() + “=> Alarmpaneel is GEWAPEND”)
end
When pressed the button stays ON. Is this correct working or is just a pulse needed to arm (ON command followed by sending command OFF to Caddx_ARM item once armed? => thus emulating a physical push button in stead of a switch)
If this should work as a push button, How can I reflect on Caddx_ARM the status armed?
Thanks!
I use the following in a sitemap to create an EXIT button (with a the first three items to display current “arm” status:
Text item=Partition1_Armed icon=armed label="Partition 1 Armed [%s]"
Text item=Partition1_EntryGuard icon=stay label="Partition 1 Stay / Entry Guard [%s]"
Text item=Partition1_ReadyToArm icon=ready label="Partition 1 Ready to Arm [%s]"
Switch item=Partition1_Exit mappings=[ON="EXIT"] label="Partition 1 Exit"
With the following rule to back it up:
rule "Partion 1 Arm in EXIT"
when
Item Partition1_Exit received command ON
then
if (Partition1_ReadyToArm.state == OFF) {
logWarn("actions", "Ready to ARM is OFF")
Alarm_Feedback.postUpdate("Ready to ARM is OFF")
createTimer(now.plusSeconds(5), [
Alarm_Feedback.postUpdate("")
])
}
else if (Partition1_Armed.state == ON) {
logWarn("actions", "Alarm is already ARMED")
Alarm_Feedback.postUpdate("Alarm is already ARMED")
createTimer(now.plusSeconds(5), [
Alarm_Feedback.postUpdate("")
])
}
else {
val actions = getActions("caddx","caddx:partition:12345678:partition1")
if (null === actions) {
logWarn("actions", "Actions not found, check thing ID for bridge")
return
}
logWarn("actions", "Ready to ARM is ON ")
actions.exit()
}
end
Hope this helps?
Mark
Hi @jossuar and everyone else.
I have upgraded to Openhab 3.0 and have come across a couple of oddities with the upgrade.
Not all my Zones have had their Labels transferred correctly. Many are still labeled as Zone1, Zone 2 etc. Some have the 2.5 labels (MAG Front Door). This is not a train smash - just weird that some have come across. Will go through and manually edit them back to what they should be.
EDIT: Strangely the logs still show the defined names? And adding labels forces the Zone offline as mentioned below and requires a Binding restart to get back online (Using the Bypass method)
The more problematic issue is that the Binding does not seem to pick up the Zones etc as being ONLINE, until there is some sort of activity on the zone. either OPEN/CLOSE, etc. Found a quick way to force the ZONE online is to BYPASS and UNBYPASS. This was not an issue with 2.5.
@jossuar do you have a more updated build that that which ships with OH3.0 that may be better to use?
I am currently on:
openhab> bundle:list -s |grep caddx
214 | Active | 80 | 3.0.0 | org.openhab.binding.caddx
openhab>
Many thanks and best wishes for the New Year.
Mark
Thanks Mark, much appreciated!
Hi all and a happy new year,
sorry for the delay in responding. I will have a look into the issues during the next weeks. I currently have 2.5 installed in my home, once i get back (I’m currently away from home) i will upgrade to version 3 and test everything.
The 2.5 version will not get any new update.
My last Pull Request to incorporate the thing actions (new functionality) was rejected. Essentially that means: no more official updates for the 2.5 version.
@Jo0p do you still use 2.5?
Hi @jossuar
Thank you for the confirmation. I have done some more testing etc. with V3.00 and the issues I have are as follows:
When the Caddx Bridge is started the other things (Partitions , Zones etc.) do not update and require manual intervention to come ONLINE. This was not an issue on 2.5 as I recall (though occasionally the Bridge had to be restarted to force Things online. Sometimes even changing the Label on a THING can take it offline in OH3.
As I mentioned above this can sometimes be resolved by doing a Bypass, UnBypass on a Zone etc. Though if a Partiton goes Offline the only way to bring back is to restart the bridge, then requiring the whole zone activity exercise.
It appears that the ZoneBypassed switch at the Partition level does not update. If I Bypass Zone 1 on Partition 1 I can see that the Bypassed switch updates at the Zone level, however the ZoneBypassed at the Partition level does not change. The LED on the Keypad etc. however lights up as expected.
Then there is the Silence _Alarm oddity I mentioned above, which seems to disarm all the Partitions and not just silence the alarm. I know this was going to be a difficult one to address as you only have 1 Partition?
This might also be a difficult one if you only have 1 Partition. I am also not sure if this is a Binding issue or a OH3 issue?
No matter how I create my Partion1_Armed item, it displays as a switch and not a contact. I have 4 Partitions and the other 3 all create as contact (So display and ON/OFF).
Not sure if this is related to a DB name not being cleared, or to something in the Binding. But if I create the item as Partition1_Armed_2 it comes through as a contact.
Pretty sure this should be a contact and not a switch as you cannot Arm the partition using this Item.
Please let me know if you need any logs etc. to help?
Appreciate your work. And am still learning all the features of your Binding as well as OH3.
Cheers
Mark
Hi jossuar,
I hope you had a nice holiday!
Some delay in my response also, because I had to rig a new OH3 enviroment, which was new to me.
Besides a ‘production’ instance on a Synology, version 2.5.2, now I have a RPi4 with Openhabian 3.0.0 for testing purposes running, including the 3.0.0 version of your Caddx binding. In this version, I can’t find the “Ignore Zone Status Transitions” variable.
On OH3, the outcome of de serial communication with the NX8E is the same (in parallel, hereby zone30 again):
14:37:24.796 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zone Status Message [Zone: 6]
14:37:24.810 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 08 84 05 01 01 05 C4 00 00 5D FC
14:37:24.819 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
14:37:24.824 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
14:37:24.839 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zones Snapshot Message
14:37:24.843 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 0A 85 01 00 10 00 00 10 00 10 00 C0 7F
14:37:24.914 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
14:37:24.918 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
Best regards,
Johan.
Hi @Jo0p,
the changes i did for your use case are not yet in the openhab3 binding.
I will stop developing for 2.5 and continue only with version 3.
I have also just switched to openhab3 in my home and I’m looking into the issues that @Mark_VG mentions. Thanks Mark for collecting everything in one place.
Hi @jossuar
Hope you are having a good year.
Just wondered if you have had any time to look at some of the issues we have outlined? Or if I can send you any logs etc to assist?
Done quite a lot of integration into OH3, and looks good.
Thanks
Mark
Hi @Mark_VG,
yes, i did look into it last week. I just had no time to post an update. (Writing it now 
)
This issue should be solved now. It seems that OH3 does not send on startup Refresh commands to the various channels. From a search in the forum i did not see something relevant being referenced.
This i have tested. When I bypass a zone, the panel sends a partition status message on which only the partition_cancel_report_is_in_the_stack changes value. The partition_zone_bypassed switch does not change. I don’t know if it is supposed to work like this or if this is a problem of the panel.
Yes i only have one partition and i cannot test it. Nevertheless i will have a look if something is wrong with the code, but i suspect this is how the panel behaves.
This i suspect is a OH3 issue. It happened also to me when i created the zone1_tampered, zone2_tampered and zone3_tampered switch. I deleted the items and created them again and they displayed as ON/OFF. (I don’t remember what i did exactly)
Also i need your help:
What channels do you use on the various things? (I want to mark the rest of the channels that are not usually used as “advanced” channels)
Can you also post some screenshots? I’m curious how you built the model.
I will update the first post with a link to the latest version.
Thanks.
Hi @jossuar
Thanks for the update.
Yes, this does seem much better. All Channels seem to stay online now. But will keep monitoring for a while.
Do you know when this version will reach the Official Builds of OH3? I am not clear how that process works.
I was hoping for some Partition Level indication (same as on the Keypad) to indicate when there are Bypassed Zones in a Specific Partition. I have looked through the “Networx NX-584 RS-232 Gateway Interface Protocol” but do not see anything that would provide this information. I guess I could achieve this with a Group… Can you clarify what the following channel is supposed to provide?
partition_zone_bypassed Switch Partition Condition Zone bypassed
From the naming - Silence Alarm I would expect that this does not Disarm the system, but silences the alarm? Also don’t see anything in the “Networx NX-584 RS-232 Gateway Interface Protocol” document.
This did turn out to be an OH3 issue. When I received your response I looked at all the “armed” items in OH3, and for the first time found a “misconfigured” Partition1_Armed device (there were 2) which I deleted and all came right. Pity I did not look more closely before deleting as my plan was to delete and recreate - But bottom line is it is working.
Sure… No problem at all. Will send something this week-end detailing what I have done… And how. I still have quite a bit I want to do. But working through all as I can.
Thanks again.
Mark
Hi @jossuar
The following are screen shots of the Pages I have setup related to my Alarm system. I have made use of Yannick’s Pin Code Widget to allow secure disarm which seems to work well. Have not really used the default cards. I preferred to have more control over the layout.
I have linked Items to most of the channels as I have been trying to work out what is available and what is useful.
I am sure there are better ways of doing what I have done - so happy to hear any comments.
Main Page - which allows linking to the Partition pages.
Select the Partition 1 Armed will give you the next page which allows actions on that Partition.
Can Bypass Zones, ARM, DISARM etc. Also link to the details of the Motion Sensor and Doors Groups.
The YAML code for the Partiton 1 Page is:
config:
label: Partition 1 Actions
sidebar: true
visibleTo:
- role:administrator
- role:user
order: "2"
blocks: []
masonry:
- component: oh-masonry
slots:
default:
- component: oh-list-card
config:
title: Partition 1 Control
slots:
default:
- component: oh-label-item
config:
item: Partition1_Armed
title: Partition 1 Armed
action: analyzer
actionAnalyzerItems:
- Partition1_Armed
- component: oh-label-item
config:
item: Partition1_ReadyToArm
title: Partition 1 Ready To Arm
icon: oh:house
iconUseState: true
- component: oh-label-item
config:
item: Partition1_EntryGuard
title: Partition 1 Stay / Entry Guard
- component: oh-label-item
config:
action: group
actionGroupPopupItem: Doors1
item: Doors1
title: Doors 1
icon: oh:motion
iconUseState: true
- component: oh-label-item
config:
action: group
actionGroupPopupItem: MotionSensors1
item: MotionSensors1
title: Motion Sensors 1
icon: oh:motion
iconUseState: true
- component: oh-list-item
config:
action: command
actionCommand: ON
actionItem: Partition1_Disarm
title: DISARM
listButton: true
- component: oh-list-item
config:
action: command
actionCommand: ON
actionItem: Partition1_Exit
title: EXIT
listButton: true
- component: oh-list-item
config:
action: command
actionCommand: ON
actionItem: Partition1_Stay
title: STAY
listButton: true
- component: oh-label-item
config:
item: Pin_Number
title: Pin Number
icon: oh:alarm
- component: oh-label-item
config:
item: Alarm_Feedback
title: "NB:"
- component: widget:keypad
config:
item: Pin_Number
- component: oh-list-card
config:
title: Partition 1 Bypass
slots:
default:
- component: oh-label-item
config:
item: Partition1_ZoneBypassed
title: Partition 1 Zone Bypassed
- component: oh-toggle-item
config:
item: MAG_FRONT_DOOR_Bypassed
title: MAG FRONT DOOR Bypassed
iconUseState: true
- component: oh-toggle-item
config:
item: MAG_KITCHEN_DOOR_Bypassed
title: MAG KITCHEN DOOR Bypassed
- component: oh-toggle-item
config:
item: PIR_KITCHEN_Bypassed
title: PIR KITCHEN Bypassed
- component: oh-toggle-item
config:
item: PIR_LOUNGE_Bypassed
title: PIR LOUNGE Bypassed
- component: oh-toggle-item
config:
item: PIR_GARAGE_Bypassed
title: PIR GARAGE Bypassed
- component: oh-toggle-item
config:
item: PIR_MAIN_BEDROOM_Bypassed
title: PIR MAIN BEDROOM Bypassed
- component: oh-toggle-item
config:
item: PIRDiningRoom17_Bypassed
title: PIR Dining Room Bypassed
- component: oh-toggle-item
config:
item: PIR_PASSAGE_Bypassed
title: PIR PASSAGE Bypassed
- component: oh-label-card
config:
title: HOME
action: navigate
actionPage: page:MackeurtanAve
actionPageTransition: f7-circle
label: Go Back to Main Page
fontSize: 15px
Hope this is what you were looking for?
Mark
Hi @Mark_VG,
When someone finishes a change to the code, he submits a “Pull Request” (abbr. PR) to the master code repository of openhab. Then a maintainer reviews the changed files and makes comments. The PR submitter has to take these comments into account and make the appropriate changes to the code. The changes are then again reviewed, new comments are made, etc. This cycle ends when then maintainer accepts the PR. If the PR is large (e.g. a new binding, or a large change) then a 2nd maintainer reviews the code again. Again the cycle comments/changes until also the 2nd maintainer accepts the changes. Then the code is commited to the master code repository and marked to be included in the next release.
Yes, thanks.
I have not yet built pages, due to lack of time and i was looking for a headstart.
On my panel this flag does not change when a zone is bypassed [Firmware 5.37]. We can also check this on your panel from the logs.
When you bypass a zone, a Partition Status Message is sent from the panel. Switch a zone back and forth and we should see in the logs, two Partition Status Messages. We can then check from the messages which bits have changed. On my panel only Byte 9, Bit 5 “Cancel report is in the stack” changes.
As to what exactly all the bits in all the messages mean, your guess is as good as mine. I only have the document with the protocol which does not explain much.
Hi @jossuar
Thanks you. I have PM’d you a copy of the log file when doing a Bypass and Unbypass on Partition 1 , Zone 1.
Thinkl these aare the relevant lines:
22:17:59.274 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Partition Status Message [Partition: 1]
22:17:59.274 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 09 86 00 00 00 00 40 63 04 E0 18 29
22:18:03.371 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Partition Status Message [Partition: 1]
22:18:03.371 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 09 86 00 00 00 00 40 63 04 C0 F7 09
Thanks
Mark