I moved to a windows PC and same as the above, except it does 10 tries on any active COM ports (COM1, 3 and 8). Looking at a serial port monitor it looks like it alternates between binary and ASCII and I am guessing does 5 different baud rates. I am pretty sure my panel is at 38400 so hopefully that matches one of the tried rates.
So I am guessing (again) that it is finding ports on the Pi, just no answer from the panel. So I am going to try a different serial port connector and cable to see if I get better results.
Any other thoughts/advice would be appreciated.
Thanks!
Update: Tried a different USB device (Edgeport 4 serial USB) and same result. Not sure if this has to do with download/access codes. Here is what I get in the COM port monitor…
the binding version you have tried has the serial port auto-detection enabled. The binding detects all the serial ports and tries every port with the various communication settings (protocol,baudrate) until it gets a valid response. The correct device under openhabian (from your log) is /dev/ttyUSB0. (/dev/ttyAMA0 is the built-in raspberry serial port)
This feature has been removed during the binding review and with the latest binding (not yet released) you have to manually specify the communication settings.
For the binding to work you don’t need the download code nor the program code, as long as the panel is correctly set-up.
Currently you can check the required panel settings on the following page (but to do that you probably would need the help of your installer):
Please wait for a few days, i’m currently testing the latest build.
If you want to play around more you can enable DEBUG logging and post it here, so that we can see what is going on. To do that in openhabian (sorry, i have no windows installation):
[11:38:17] openhabian@openHABianPi:~$ ssh openhab@localhost -p 8101
Password authentication
Password:
__ _____ ____
____ ____ ___ ____ / / / / | / __ )
/ __ \/ __ \/ _ \/ __ \/ /_/ / /| | / __ |
/ /_/ / /_/ / __/ / / / __ / ___ |/ /_/ /
\____/ .___/\___/_/ /_/_/ /_/_/ |_/_____/
/_/ 2.5.4
Release Build
Hit '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '<ctrl-d>' or type 'system:shutdown' or 'logout' to shutdown openHAB.
openhab> log:set DEBUG org.openhab.binding.caddx
openhab> log:tail
i updated the download link on the first post with the latest version of the binding. @Heatvent please try this version.
A notable thing that changed is that the bridge is not auto-discovered anymore. It has to be manually defined by the user. After the bridge is set-up, Partitions and zones are auto-discovered.
The binding becomes visible, also the communication is ok. Every action/event on the NX8-E is monitored in the logfile. For example:
13:40:07.934 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zone Status Message [Zone: 5]
13:40:07.934 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 08 84 05 01 01 05 C4 00 00 5D FC
13:40:07.937 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
13:40:07.937 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
13:40:07.976 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zones Snapshot Message
13:40:07.977 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 0A 85 01 00 10 08 00 10 00 10 00 C8 AF
13:40:07.979 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
13:40:07.980 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
But, unfortunately, not all discoveries are made. My configuration consists about the NX8-E (8 zones) and 3 expansion card (all 16 zones). Only 18 zones are discovered (without description), and some of them come online (‘at random’). After some figuring out, I was wondering, like in the example above: This is card 3.14, but also (8 bits further) 3.22, is [Zone: 5].
Do you have any idea why my zones/descriptions are not correctly discovered?
i’m currently on vacation and i have no access on my panel to check/test.
The binding adds to the inbox all the zones that do not have the “trouble” bit enabled.
The zone descriptions are set when you add the discovered items and they are moved from the “Inbox” to “Control” in PaperUI.
Try to disable and enable the bridge thing in PaperUI. [You can do it by pressing the “clock” icon. See the image on the 1st post on the following link: [SOLVED] Enabling and disabling Things from for example Basic UI]
It would help me, if you can post the debug log when you enable the thing.
there is a problem with the binding.
I misinterpreted the information in the manual on how the zone offset is calculated in the “Zones Snapshot Message”. After correcting the zone offset handling, another issue became obvious. The panel does not have an indicator if a zone is actually present or not. For that i used the zone trouble bit but this was set because of the incorrect zone offset handling.
To overcome the issue I added a new configuration parameter in the bridge [maxZoneNumber], which in your case (judging from the screenshot) should be set to the value 54.
I will update the link in the first post with the latest binding version. Can you please uninstall the current binding and test with the latest build? If the test goes well, i will open a PR.
Zones are also discovered when they are tripped. When you open/close a door or when a PIR sensor is activated, then the zone should be added in the Paper UI Inbox.
Also, are the Zone Names updated when a zone is added? [Pressing on the blue check mark in the Paper UI Inbox in front of a discovered zone]
This version with [maxZoneNumber] discovers the Panel, Partitions all the Zone’s. When adding to Things, also the zone names are replaced correctly. When approving al the items from inbox, lots and lots of variables are processed. With 50 zones, the whole GUI hung
Looking at the panel, there’s correct communiction. For example, when the partion is ‘ready to arm’: [smarthome.event.ItemStateChangedEvent] - caddx_partition_04e51230_partition1_partition_ready_to_arm changed from OFF to ON
The slider in the GUI moves.
Unfortunately, the status of the zones is not updated correctly. I think It’s only done when Enable the Thing (as you advised before):
18:53:33.358 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Partitions Snapshot Message
18:53:33.359 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 09 87 11 02 02 02 02 02 02 01 AE DD
18:53:33.360 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'caddx:panel:04e51230:panel' changed from OFFLINE to ONLINE
18:53:33.361 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
18:53:33.361 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'caddx:bridge:04e51230' changed from OFFLINE to ONLINE
18:53:33.362 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
18:53:33.409 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Partition Status Message [Partition: 0]
18:53:33.410 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 09 86 00 20 00 08 41 01 04 A2 A0 D0
18:53:33.416 [INFO ] [smarthome.event.ItemStateChangedEvent] - caddx_partition_04e51230_partition1_partition_ready_to_arm changed from OFF to ON
18:53:33.418 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
18:53:33.419 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'caddx:partition:04e51230:partition1' changed from OFFLINE to ONLINE
18:53:33.419 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
18:53:33.463 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Partition Status Message [Partition: 7]
18:53:33.464 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 09 86 07 28 00 00 41 01 00 82 83 F0
18:53:33.489 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
18:53:33.490 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
18:53:33.557 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Partitions Snapshot Message
18:53:33.558 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 09 87 13 02 02 02 02 02 02 01 B0 ED
18:53:33.560 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
18:53:33.561 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
18:53:33.609 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zone Status Message [Zone: 0]
18:53:33.610 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 08 84 00 01 01 05 C4 00 00 58 D9
18:53:33.611 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
18:53:33.612 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
18:53:33.656 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zone Status Message [Zone: 1]
18:53:33.657 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 08 84 01 01 01 05 C4 00 00 59 E0
18:53:33.662 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
18:53:33.662 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
18:53:33.709 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zone Status Message [Zone: 2]
18:53:33.710 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 08 84 02 01 01 05 C4 00 00 5A E7
18:53:33.712 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
18:53:33.712 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
18:53:33.757 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zone Status Message [Zone: 4]
18:53:33.757 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 08 84 04 01 01 05 C4 00 00 5C F5
18:53:33.759 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
18:53:33.759 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
18:53:33.809 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zone Status Message [Zone: 5]
18:53:33.810 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 08 84 05 01 01 05 C4 00 00 5D FC
18:53:33.815 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
18:53:33.815 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
18:53:33.857 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zones Snapshot Message
18:53:33.858 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 0A 85 01 00 10 03 00 10 00 20 00 D3 B1
18:53:33.864 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
18:53:33.865 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
18:53:33.910 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zones Snapshot Message
18:53:33.911 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 0A 85 02 00 00 00 00 00 03 11 11 B6 F3
18:53:33.916 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
18:53:33.917 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
18:53:36.918 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Zones Snapshot Request
18:53:36.918 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 02 25 00 27 50
18:53:36.961 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zones Snapshot Message
18:53:36.962 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 0A 05 00 00 00 00 00 00 00 00 80 8F 21
18:53:36.968 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Zones Snapshot Request
18:53:36.969 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 02 25 01 28 51
18:53:37.012 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zones Snapshot Message
18:53:37.013 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 0A 05 01 00 10 03 00 10 00 20 00 53 AC
18:53:37.019 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Zones Snapshot Request
18:53:37.019 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 02 25 02 29 52
18:53:37.061 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zones Snapshot Message
18:53:37.062 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 0A 05 02 00 00 00 00 00 03 11 11 36 EE
18:53:37.102 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Zones Snapshot Request
18:53:37.103 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 02 25 03 2A 53
18:53:37.162 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zones Snapshot Message
18:53:37.163 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 0A 05 03 00 00 00 00 00 00 00 00 12 BB
18:53:37.164 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Zones Snapshot Request
18:53:37.165 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 02 25 04 2B 54
18:53:37.212 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zones Snapshot Message
18:53:37.213 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 0A 05 04 00 00 00 00 00 00 00 00 13 C4
18:53:37.214 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Zones Snapshot Request
18:53:37.215 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 02 25 05 2C 55
18:53:37.261 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zones Snapshot Message
18:53:37.262 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 0A 05 05 00 00 00 00 00 00 00 00 14 CD
18:53:37.264 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Zones Snapshot Request
18:53:37.265 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 02 25 06 2D 56
18:53:37.312 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zones Snapshot Message
18:53:37.313 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 0A 05 06 00 00 00 00 00 00 00 00 15 D6
18:53:37.314 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Zones Snapshot Request
18:53:37.315 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 02 25 07 2E 57
18:53:37.361 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zones Snapshot Message
18:53:37.362 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 0A 05 07 00 00 00 00 00 00 00 00 16 DF
18:53:37.363 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Zones Snapshot Request
18:53:37.364 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 02 25 08 2F 58
18:53:37.412 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zones Snapshot Message
18:53:37.413 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 0A 05 08 00 00 00 00 00 00 00 00 17 E8
18:53:37.414 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Zones Snapshot Request
18:53:37.415 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 02 25 09 30 59
18:53:37.461 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zones Snapshot Message
18:53:37.462 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 0A 05 09 00 00 00 00 00 00 00 00 18 F1
18:53:37.464 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Zones Snapshot Request
18:53:37.464 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 02 25 0A 31 5A
18:53:37.512 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zones Snapshot Message
18:53:37.513 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 0A 05 0A 00 00 00 00 00 00 00 00 19 FA
18:53:37.514 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Zones Snapshot Request
18:53:37.515 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 02 25 0B 32 5B
18:53:37.561 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zones Snapshot Message
18:53:37.562 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 0A 05 0B 00 00 00 00 00 00 00 00 1A 04
18:53:37.564 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Partition Status Request [Partition: 0]
18:53:37.564 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 02 26 00 28 52
18:53:37.611 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Partition Status Message [Partition: 0]
18:53:37.612 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 09 06 00 20 00 08 41 01 04 A2 20 4C
18:53:37.623 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Partitions Snapshot Request
18:53:37.624 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 27 28 29
18:53:37.663 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Partitions Snapshot Message
18:53:37.663 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 09 07 13 02 02 02 02 02 02 01 30 69
I think something is going wrong in numbering the zones. In the log, only the first 5 zones are numbered.
For example, when I trigger zone 30, the logfile is:
19:00:19.050 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zone Status Message [Zone: 5]
19:00:19.058 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 08 84 05 01 01 05 C4 00 00 5D FC
19:00:19.060 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
19:00:19.061 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
19:00:19.107 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zones Snapshot Message
19:00:19.108 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 0A 85 01 00 10 03 00 10 00 30 00 E3 D1
19:00:19.303 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
19:00:19.304 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
19:00:21.203 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zone Status Message [Zone: 5]
19:00:21.204 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 08 84 05 01 01 05 C4 00 00 5D FC
19:00:21.206 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
19:00:21.208 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
19:00:21.253 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: Zones Snapshot Message
19:00:21.254 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - <-: 7E 0A 85 01 00 10 03 00 10 00 20 00 D3 B1
19:00:21.316 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: Positive Acknowledge
19:00:21.342 [DEBUG] [ding.caddx.internal.CaddxCommunicator] - ->: 7E 01 1D 1E 1F
When investigating this, I discovered this pattern:
Zone / Zone number in logfile
30. 5
31. 6
32. 7
33. 0
34. 1
35. 2
36. 3
37. 4
38. 5
39. 6
40. 7
etc. etc.
With 50 zones, you should probably not link all the channels.
The binding does not poll the zone statuses from panel. It is event driven. When a zone changes state, a message is sent to the binding.
You probably see only the first 5 zones in the log because they are tripped and the panel sends these messages to inform the binding. Or you have them already added to Control and their status is updated.
When you enable the bridge, the binding sends a series of "Zones Snapshot Request"s and the response from the panel holds information for a group of 16 zones. (Which are added as discovered items to the Inbox)
The curious thing is that when you trigger Zone 30, you get Zone 5 in the log.
Are you sure that the installer did not wire two or more sensors in parallel?
Also do you know what model of expander cards, you have in the panel?
When adding a thing in the Paper UI, all channels are added. Can I prevent that every channel is selected by default before adding?
I researched further witch messages are created in the logfile by adding a zone, and, by triggering a zone. This is the outcome (type is juist FYI):
zone
zone status message
zone status request
type
1
0
0
Smoke
2
1
1
Smoke
3
2
2
Smoke
4
3
3
Smoke
5
4
4
Smoke
6
5
5
Smoke
7
6
6
Smoke
8
7
7
Smoke
9
0
8
Smoke
10
1
9
Smoke
11
2
10
Smoke
12
3
11
Contact
13
4
12
Contact
14
5
13
Contact
15
6
14
Contact
16
7
15
Contact
17
0
16
Contact
18
1
17
Contact
19
2
18
Contact
20
3
19
Contact
21
4
20
Contact
22
5
21
Contact
23
6
22
Contact
24
7
23
Contact
25
0
24
Contact
26
1
25
Contact
27
2
26
Contact
28
3
27
Contact
29
4
28
PIR
30
5
29
PIR
31
6
30
PIR
32
7
31
PIR
33
0
32
PIR
34
1
33
PIR
35
2
34
PIR
36
3
35
Smoke
37
4
36
PIR
38
5
37
PIR
39
6
38
Contact
40
7
39
Contact
41
0
40
PIR
42
1
41
Smoke
43
2
42
Contact
44
3
43
Contact
Then, I discovered, when re-enabling the thing, a Zone-update is done. For example, when disabling the bridge, opening the door, and then enable the bridge, Channel ‘Faulted’ changes from CLOSED to OPEN.
(I assume ‘faulted’ is equal to ‘contact’ of the zone…)
My setup consists of a NX-8E with 3 NX-216 16 Zone hardwire expansions and 3 NX-148 keypads
Many thanks for your support, because of the odds, this must become a success!
I don’t know either. I opened a new question if there is something I can specify in the binding.
Can you send me the debug log when you open/close a few Doors and walk through a room with a PIR? I want to see the actual bytes that are being sent from the panel. There is no need to disable/enable the thing. When any zone changes status, the panel sends the Zone Update Message by itself.
The panel sends an incorrect zone number.
For example
22:52:16.510 <-: 7E 08 84 ***06*** 01 01 05 C4 00 00 5E 04
Thε 06 should have been 1E if it is PIR zone 31.
I had a look through the manual of the NX-216E.
On the board there are some dip-switches which designate the starting zone number of the expander card. Can you check that the dip switches are set correctly? [Be careful not to change anything in the panel, it needs to be powered off first] (If you don’t understand what i’m talking about, you need the help of an installer)
From what i gathered of your installation you should have for DIP1-DIP6:
1st card: ON OFF OFF OFF OFF OFF
2nd card: OFF ON OFF OFF OFF OFF
3rd card: OFF OFF ON OFF OFF OFF
If the NX-216 cards have all the DIP switches on OFF that would explain why the numbering is not correct. Unfortunately i do not have a NX-216 and cannot verify/test my hypothesis.
Thanks for investigating! I installed the whole system by myself. I’ve checked the dip-switch settings, but the’re conform the manual you’re reffering.
I’ve specially imported this panel from the USA (I live in the Netherlands) for the compatibility with the Vera controller. That was working several years till I was fed up with the Vera ecosystem.
I wonder where the problem is, can I change something else in the communication settings, or is there some other misunderstanding between the bridge and panel? :-S
About not linking all channels by default in PaperUI, you have to turn off PaperUI simple mode and then link the desired channels one by one.
For the problem with the zone number I can only hypothesize.
The binding does interpret the data from the panel. If the panel does not send the correct info, then there is nothing i can do on the binding side.
I had also a look on the programming of the NX-8E.
The DIP switch settings for the NX-216E I posted above were wrong.
According also to the NX-8E manual, they should be:
1st card: ON OFF OFF OFF OFF OFF
2nd card: ON ON OFF OFF OFF OFF
3rd card: ON OFF ON OFF OFF OFF
Can you confirm?
Also check if on the panel zone doubling is enabled and there is an overlap on the zones from the panel and the expander cards.
If the DIP switches are correctly set, I would try with “divide and conquer” on the panel side. E.g. disconnect the two expander cards, leave only the one connected and check what the panel sends. etc.
Another idea is to ask in an alarm forum. (I don’t know of any).
Yes, the dipswitches are all right, according to the manual (I didn’t mention the incorrect overview in your post ). When it was not, also the alarm panel itself doesn’t work properly either
The 3rd card has only 8 zone’s as max (dip4) but I changed it.
Now it’s time for rigourus countermeasures. Wil disable soms expander card what you suggest. Must find some time to do that.
Thanks for your support so far. I’ll let you know.
