We have moved at community.getvera.com

Author Topic: UI5 / NX-8 zones communication trouble  (Read 2600 times)

Offline Joop12

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
UI5 / NX-8 zones communication trouble
« on: July 02, 2016, 10:53:29 am »
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:

Quote
06   05/19/16 21:28:29.567   Device_Variable::m_szValue_set device: 262 service: urn:micasaverde-com:serviceId:AlarmPartition2 variable: DetailedArmMode was: Ready now: Disarmed #hooks: 0 upnp: 0 v:0x1196510/NONE duplicate:0 <0x2b90b680>

But the sensor itself  isn't changing state:
Quote
06   05/19/16 21:28:29.643   Device_Variable::m_szValue_set device: 293 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Tripped was: 0 now: 0 #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.

Offline futzle

  • Moderator
  • Master Member
  • *****
  • Posts: 3260
  • Karma: +192/-9
Re: UI5 / NX-8 zones communication trouble
« Reply #1 on: July 03, 2016, 11:03:05 pm »
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.
« Last Edit: July 05, 2016, 01:17:44 am by futzle »

Offline Joop12

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
Re: UI5 / NX-8 zones communication trouble
« Reply #2 on: July 04, 2016, 03:41:29 am »
Quote
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:
Quote
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:
Quote
6   07/04/16 9:14:09.319   Device_Variable::m_szValue_set device: 279 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Tripped was: 0 now: 1 #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:

Quote
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>


Offline futzle

  • Moderator
  • Master Member
  • *****
  • Posts: 3260
  • Karma: +192/-9
Re: UI5 / NX-8 zones communication trouble
« Reply #3 on: July 05, 2016, 01:14:45 am »
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.

Offline Joop12

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
Re: UI5 / NX-8 zones communication trouble
« Reply #4 on: July 06, 2016, 05:08:53 pm »
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.

Offline futzle

  • Moderator
  • Master Member
  • *****
  • Posts: 3260
  • Karma: +192/-9
Re: UI5 / NX-8 zones communication trouble
« Reply #5 on: July 06, 2016, 11:16:45 pm »
This bit's interesting:

Code: [Select]
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.

Offline Joop12

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
Re: UI5 / NX-8 zones communication trouble
« Reply #6 on: July 07, 2016, 06:19:34 pm »
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?

Offline futzle

  • Moderator
  • Master Member
  • *****
  • Posts: 3260
  • Karma: +192/-9
Re: UI5 / NX-8 zones communication trouble
« Reply #7 on: July 07, 2016, 07:17:33 pm »
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.

Offline Joop12

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
Re: UI5 / NX-8 zones communication trouble
« Reply #8 on: July 08, 2016, 03:15:33 pm »
Thanks a lot. This version works!!!  :D 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:

Quote
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?
« Last Edit: July 08, 2016, 03:17:18 pm by Joop12 »

Offline futzle

  • Moderator
  • Master Member
  • *****
  • Posts: 3260
  • Karma: +192/-9
Re: UI5 / NX-8 zones communication trouble
« Reply #9 on: July 09, 2016, 09:04:12 pm »
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":
Code: [Select]
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".