UI5 / NX-8 zones communication trouble

Joop12 · July 2, 2016, 2:53pm

Hello,

After a long period of reading and understanding the (hidden) features of my VeraLite I can’t solve a communication problem with my NX-8E panel.
Well, and of course, sorry for my broken english and probably posting the wrong version of logfile

The problem is that only the status of the first 8 zones of my 56 zone’s panel communicate.
For example, when zone 9 changes state, that causes a ready->not ready state of the panel, a message will be sent:

06 05/19/16 21:28:29.567 Device_Variable::m_szValue_set device: 262 service: urn:micasaverde-com:serviceId:AlarmPartition2 variable: e[35;1mDetailedArmModee[0m was: [b]Ready [/b]now: [b]Disarmed [/b]#hooks: 0 upnp: 0 v:0x1196510/NONE duplicate:0 <0x2b90b680>

But the sensor itself isn’t changing state:

06 05/19/16 21:28:29.643 Device_Variable::m_szValue_set device: 293 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: e[35;1mTrippede[0m was: [b]0[/b] now: [b]0[/b] #hooks: 1 upnp: 0 v:0x11b60f0/NONE duplicate:0 <0x2b90b680>

I checked several times the serial configurtion:
LOCATION #207 - 1 ON (Serial Port Enable for Home Automation)
LOCATION #208 - 4 ON (Serial Port Baud Rate = 38400)
LOCATION #209 - SEGMENT #1 (Set the Home Automation protocol to BINARY) 1 OFF
LOCATION #210 - SEGMENT #1 2 5 6 7 8 ON
LOCATION #210 - SEGMENT #2 1 3 4 ON
LOCATION #211 - SEGMENT #1 2 4 5 6 7 8 ON
LOCATION #211 - SEGMENT #2 1 3 4 5 ON
LOCATION #211 - SEGMENT #3 1 2 3 5 7 ON
LOCATION #211 - SEGMENT #4 3 4 5 6 7 ON (8 = Bypass is off!)

I’m running out of options, meanwhile I see the great advantages to finally can use my PIR to switch the lights etc. etc.

Can someone give me some tips? Thanking you in advance,

greetings,

Joop.

futzle · July 4, 2016, 3:03am

There was a bug in very old versions of the plugin where the Zones Summary message got misread, causing an event on Zone 9 17 to get interpreted as an event on Zone 1 instead. But that was a very old version which nobody should be on any more. Besides, the bug should not appear if you have turned on the Zone Status message.

I’m mobile so I’m not able to read your log right now. Edit: Your log contains a successful startup message for the plugin but not much else. Enable Debug To Luup Log in the plugin’s Configure tab, and then catch a log while you are tripping a zone > 8. I just need that bit.

Edit: Fixed the zone numbers in my explanation.

Joop12 · July 4, 2016, 7:41am

Card.Address Zone description zwave id 1.1 1 RM woonkamer 264 1.2 2 RM keuken 265 1.3 3 RM sk zuid 266 1.4 4 RM kantoor 267 1.5 5 RM bijkeuken 268 1.6 6 RM overloop 269 1.7 7 RM oudersk 270 1.8 8 RM waskamer 271 2.9 9 RM sk 272 2.10 10 RM zolder 273 2.11 11 RM sk 274 2.12 12 MC voordeur 275 2.13 13 MC bel voordeur 276 2.14 14 MC meterkast 277 2.15 15 MC kantoor 278 2.16 16 MC inbouwkast 279 2.17 17 MC achterdeur 280 2.18 18 MC bel achterdeur 281 2.19 19 MC bijkeuken 282 . . .

Triggering zone 8:

07 07/04/16 8:34:30.151 Event::Evaluate 16 RmWaskamerTrip scene BrandWaskamer is false repeat 0/-1 <0x2e7d7680>

But the strange thing is, for example, zone 16 is working correct:

6 07/04/16 9:14:09.319 Device_Variable::m_szValue_set device: 279 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Tripped was: [b]0[/b] now: [b]1[/b] #hooks: 1 upnp: 0 v:0x117d6d0/NONE duplicate:0 <0x2e7d7680> 06 07/04/16 9:14:09.320 Device_Variable::m_szValue_set device: 279 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: LastTrip was: 1467616372 now: 1467616449 #hooks: 0 upnp: 0 v:0x117e6a8/NONE duplicate:0 <0x2e7d7680> 50 07/04/16 9:14:09.321 luup_log:261: Armed: 1 <0x2e7d7680> 06 07/04/16 9:14:09.322 Device_Variable::m_szValue_set device: 279 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Armed was: 1 now: 1 #hooks: 0 upnp: 0 v:0x117e6c8/NONE duplicate:1 <0x2e7d7680>

When I trigger a zone higher then 16, for example 30, no message is received:

50 07/04/16 9:38:59.594 luup_log:261: Setting state for zone 6 <0x2e7d7680> 50 07/04/16 9:38:59.595 luup_log:261: Tripped: 0 <0x2e7d7680> 06 07/04/16 9:38:59.595 Device_Variable::m_szValue_set device: 269 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Tripped was: 0 now: 0 #hooks: 1 upnp: 0 v:0x117d6d0/NONE duplicate:0 <0x2e7d7680> 50 07/04/16 9:38:59.596 luup_log:261: Armed: 1 <0x2e7d7680> 06 07/04/16 9:38:59.596 Device_Variable::m_szValue_set device: 269 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Armed was: 1 now: 1 #hooks: 0 upnp: 0 v:0x117e6c8/NONE duplicate:1 <0x2e7d7680> 50 07/04/16 9:38:59.597 luup_log:261: Sending message: 0x1D Positive Acknowledge <0x2e7d7680> 50 07/04/16 9:38:59.597 luup_log:261: Message: Outgoing: 0x7e 0x01 0x1d 0x1e 0x1f <0x2e7d7680> 50 07/04/16 9:38:59.676 luup_log:261: Received good message 0x05, acknowledge requested <0x2e7d7680> 50 07/04/16 9:38:59.677 luup_log:261: Message: Incoming message body: 0x01 0x80 0x90 0x00 0x00 0x10 0x00 0x10 0x00 <0x2e7d7680> 50 07/04/16 9:38:59.677 luup_log:261: Handling message: 0x05 Zones Snapshot <0x2e7d7680> 50 07/04/16 9:38:59.678 luup_log:261: Sending message: 0x1D Positive Acknowledge <0x2e7d7680> 50 07/04/16 9:38:59.679 luup_log:261: Message: Outgoing: 0x7e 0x01 0x1d 0x1e 0x1f <0x2e7d7680> 50 07/04/16 9:39:01.941 luup_log:261: Received good message 0x04, acknowledge requested <0x2e7d7680> 50 07/04/16 9:39:01.942 luup_log:261: Message: Incoming message body: 0x05 0x01 0x01 0x05 0xc4 0x00 0x00 <0x2e7d7680> 50 07/04/16 9:39:01.943 luup_log:261: Handling message: 0x04 Zone Status <0x2e7d7680> 50 07/04/16 9:39:01.943 luup_log:261: Valid zone 6 <0x2e7d7680> 50 07/04/16 9:39:01.943 luup_log:261: Setting state for zone 6 <0x2e7d7680> 50 07/04/16 9:39:01.944 luup_log:261: Tripped: 0 <0x2e7d7680> 06 07/04/16 9:39:01.944 Device_Variable::m_szValue_set device: 269 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Tripped was: 0 now: 0 #hooks: 1 upnp: 0 v:0x117d6d0/NONE duplicate:0 <0x2e7d7680> 50 07/04/16 9:39:01.945 luup_log:261: Armed: 1 <0x2e7d7680> 06 07/04/16 9:39:01.946 Device_Variable::m_szValue_set device: 269 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Armed was: 1 now: 1 #hooks: 0 upnp: 0 v:0x117e6c8/NONE duplicate:1 <0x2e7d7680> 50 07/04/16 9:39:01.946 luup_log:261: Sending message: 0x1D Positive Acknowledge <0x2e7d7680> 50 07/04/16 9:39:01.947 luup_log:261: Message: Outgoing: 0x7e 0x01 0x1d 0x1e 0x1f <0x2e7d7680> 50 07/04/16 9:39:02.046 luup_log:261: Received good message 0x05, acknowledge requested <0x2e7d7680> 50 07/04/16 9:39:02.046 luup_log:261: Message: Incoming message body: 0x01 0x80 0x90 0x00 0x00 0x10 0x00 0x00 0x00 <0x2e7d7680> 50 07/04/16 9:39:02.047 luup_log:261: Handling message: 0x05 Zones Snapshot <0x2e7d7680> 50 07/04/16 9:39:02.047 luup_log:261: Sending message: 0x1D Positive Acknowledge <0x2e7d7680> 50 07/04/16 9:39:02.048 luup_log:261: Message: Outgoing: 0x7e 0x01 0x1d 0x1e 0x1f <0x2e7d7680>

futzle · July 5, 2016, 5:14am

Almost certainly you are running the version of the plugin with the bug I mentioned. You can verify that by viewing the local copy of L_CaddxNX584Security.lua on your Vera and seeing what line 704 contains. I’ll wager it’s the old wrong code (2), not the correct code (1).

You are on UI5 so do not simply install the most recent version of the plugin. Download exactly this version and install the files through the Vera web interface.

That’ll hopefully resolve the Zone 30 problem. It probably won’t resolve the problem with zone 9 (or is it 8?) but we can look at that next. Keep the debugging messages on; the “received good message” and “Incoming message body” debug lines are very useful in knowing what the alarm panel is telling the plugin.

Joop12 · July 6, 2016, 9:08pm

Thanks for your help so far Futzle.

Unfortunately, replacing the files did not work. For your information, I checked the Lua file before and the mentioned bug was not there.

For now, the error messages in the log are different, therefore, please see the attached logfile.

futzle · July 7, 2016, 3:16am

This bit’s interesting:

50 07/06/16 22:56:00.752 luup_log:261: Received good message 0x05, acknowledge requested <0x2dcdb680> 50 07/06/16 22:56:00.753 luup_log:261: Message: Incoming message body: 0x01 0x80 0x90 0x00 0x00 0x10 0x00 0x10 0x00 <0x2dcdb680> 50 07/06/16 22:56:00.753 luup_log:261: Handling message: 0x05 Zones Snapshot <0x2dcdb680> 50 07/06/16 22:56:00.754 luup_log:261: Sending message: 0x1D Positive Acknowledge <0x2dcdb680>

That’s the status for zones 17-32, and the plugin is just ignoring it.

Ah. Found it. Try this attached version of the Lua file.

Joop12 · July 7, 2016, 10:19pm

Thanks again Futzle,

I’m sorry to say it didn’t work.
At least, I uninstalled the complete app, and reinstalled again, including you’re updated Lua file.

Except the zwave ID’s the complete logging seems to be the same.

Wat can I debug / log anymore?

futzle · July 7, 2016, 11:17pm

Just install the new file. It’s pointless and prone to introduce new errors if you do more.

Here is a version with a ton of debug statements around the relevant section of code.

All I need from the log is from a section of time spanning you tripping a zone in the range 17-32.

Joop12 · July 8, 2016, 7:15pm

Thanks a lot. This version works!!! After 2 years of spending so much time, finally! I should have contact the architect of this plugin earlier ;D

The Motion and Door type zones are working flawless now, but I have a question about the Smoke-zones. For example, when I trigger zone 4, (id 317), nothing happens:

50 07/08/16 21:03:11.771 luup_log:311: Received good message 0x04, acknowledge requested <0x2f51b680> 50 07/08/16 21:03:11.772 luup_log:311: Message: Incoming message body: 0x03 0x01 0x01 0x05 0xc4 0x04 0x00 <0x2f51b680> 50 07/08/16 21:03:11.772 luup_log:311: Handling message: 0x04 Zone Status <0x2f51b680> 50 07/08/16 21:03:11.772 luup_log:311: Valid zone 4 <0x2f51b680> 50 07/08/16 21:03:11.773 luup_log:311: Setting state for zone 4 <0x2f51b680> 50 07/08/16 21:03:11.774 luup_log:311: Tripped: 0 <0x2f51b680> 06 07/08/16 21:03:11.774 Device_Variable::m_szValue_set device: 317 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Tripped was: 0 now: 0 #hooks: 3 upnp: 0 v:0xab0048/NONE duplicate:0 <0x2f51b680> 07 07/08/16 21:03:11.774 Event::Evaluate 24 tripped scene tripped is false repeat 0/-1 <0x2f51b680> 07 07/08/16 21:03:11.775 Event::Evaluate 25 not tripped scene not tripped is true users:854406 allow:1 <0x2f51b680> 08 07/08/16 21:03:11.775 Scene::RunScene running 88 not tripped <0x2f51b680> 50 07/08/16 21:03:11.776 luup_log:311: Armed: 1 <0x2f51b680> 06 07/08/16 21:03:11.776 Device_Variable::m_szValue_set device: 317 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Armed was: 1 now: 1 #hooks: 0 upnp: 0 v:0xab0c88/NONE duplicate:1 <0x2f51b680> 50 07/08/16 21:03:11.776 luup_log:311: Sending message: 0x1D Positive Acknowledge <0x2f51b680> 50 07/08/16 21:03:11.777 luup_log:311: Message: Outgoing: 0x7e 0x01 0x1d 0x1e 0x1f <0x2f51b680> 50 07/08/16 21:03:11.811 luup_log:311: Received good message 0x05, acknowledge requested <0x2f51b680> 50 07/08/16 21:03:11.812 luup_log:311: Message: Incoming message body: 0x00 0x00 0x40 0x00 0x80 0x00 0x00 0x10 0x00 <0x2f51b680>

For your information, please find attached the logfile. Should I have to update the Lua file without the additional debugging info?

futzle · July 10, 2016, 1:04am

Stick with the version that works, even with the debug statements. You can turn off Debug To Luup Log in the plugin’s Configure tab once it’s all working to your satisfaction. That will stop the debug messages too.

Your smoke detector zones don’t report “Tripped”:

50   07/08/16 21:03:11.772   luup_log:311: Message: Incoming message body: 0x03 0x01 0x01 0x05 0xc4 0x04 0x00 <0x2f51b680>

The 0x04 towards the end would be 0x01 if they did. 0x04 is “Trouble”, which the plugin doesn’t presently react to. This presents a dilemma. There’s no field in the SecuritySensor device type that would map to “Trouble”. I think it would be a mistake to assume that “Trouble” == “Tripped”; indeed, the Caddx protocol lumps “Trouble” in with “low battery” and “Tamper” in the Zones Snapshot message, not with “Tripped”. To subvert this expectation could present unintended side-effects, because I don’t know when other sensor types produce “Trouble” signals.

I’m tempted to argue that having the plugin recognize the state of a smoke sensor is asking for (pardon the pun) trouble, in that it will encourage users to try to automate reacting to a fire situation. Given Vera’s reliability I’d file that under “death trap”.