ZWave Device Sensitive Strip 11 01 011 not recognised

NCO · December 23, 2016, 6:39pm

All,

I just included my Sensative Strip to OH2 and according to Paper UI it should be working (online) and I got the three channels which seem to be linked to the three dedicated items:
Binary Sensor
Alarm
Battery Level

However, the Binary Sensor is always “OFF” regardless of the position of the (flat) Magnet.
Furthermore there is no node8.xml in /var/lib/openhab2/zwave
and I get an error in events.log:
2016-12-23 19:20:31.794 [hingStatusInfoChangedEvent] - 'zwave:device:49ede2f3:node8' changed from OFFLINE (COMMUNICATION_ERROR): Node is not communicating with controller to ONLINE

Any suggestions?

NCO · December 23, 2016, 6:52pm

I did this and got an update in events.log:
Thing ‘zwave:device:49ede2f3:node8’ has been updated.
Additionally I changed the parameter “Accociation Groups” - 1:Lifeline to OpenHAB Controller (Node 1)??
and get:
2016-12-23 19:49:06.808 [hingStatusInfoChangedEvent] - ‘zwave:device:49ede2f3:node8’ changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE

By the way:
What does it mean if Habmin says “Untriggered” in the Binary Sensor Description?

jaydee73 · December 23, 2016, 7:42pm

This is no real error. The controller previously couldn’t communicate with the Strip, but this messages indicates that the Strip is now ONLINE. So it only changed it’s overall state (which is good ).

Having said that, this little device is a beast to get it integrated.

So if there’s no xml file for the node, the node isn’t (fully) initialized. And as long as it’s not fully initialized, you shouldn’t not pay too many attention to the binary sensor state.

So please continue to wake up the device manually using the magnet. Remember, you have to put the round magnet near the bottom of the Strip three times in ten seconds. And ONLY if the upper light flashes green EVERY time (so totally also three times), the Strip wakes up. I say this because often it flashes two times and when I put the magnet a third time near the Strip, there is no flash and I have to start over…

And you probably have to wake it up several times…and I don’t mean 2 or 3 times…

jaydee73 · December 23, 2016, 7:44pm

Untriggered means OFF (or CLOSED, depending on the channel type).

NCO · December 23, 2016, 7:47pm

Thanks.
In my UI the sensor is always “OFF”. Even if I move the magnet and the LED reports a change, there is no change.

NCO · December 23, 2016, 7:56pm

And Habmin says Node is not communicating with Controller

In Debug Mode there is lots more of errors:

2016-12-23 20:52:57.885 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 8: Sending REQUEST Message = 01 08 00 13 08 01 00 25 47 8F
2016-12-23 20:52:57.887 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 8: Response processed after 0ms/3007ms.
2016-12-23 20:52:57.905 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8
2016-12-23 20:52:57.909 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2016-12-23 20:52:57.913 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 01 13 01 E8
2016-12-23 20:52:57.916 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 04 01 13 01 E8
2016-12-23 20:52:57.920 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Response[0x01], priority=High, dest=255, callback=0, payload=01
2016-12-23 20:52:57.924 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 8: Sent Data successfully placed on stack.
2016-12-23 20:53:04.564 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 47 01 02 9B 34
2016-12-23 20:53:04.567 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2016-12-23 20:53:04.569 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 47 01 02 9B 00 00 3A
2016-12-23 20:53:04.571 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 13 47 01 02 9B 00 00 3A
2016-12-23 20:53:04.573 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=47 01 02 9B
2016-12-23 20:53:04.574 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 8: SendData Request. CallBack ID = 71, Status = Transmission complete, no ACK received(1)
2016-12-23 20:53:04.576 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 8: Node is DEAD.
2016-12-23 20:53:04.577 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveNodeStatusEvent
2016-12-23 20:53:04.578 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got an event from Z-Wave network: ZWaveNodeStatusEvent
2016-12-23 20:53:04.579 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Setting OFFLINE
2016-12-23 20:53:04.583 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 8: Node Status event during initialisation - Node is DEAD
2016-12-23 20:53:04.594 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 8: Node Status event - Node is DEAD
2016-12-23 20:53:04.596 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 8: Node is DEAD. Dropping message.
2016-12-23 20:53:04.599 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
2016-12-23 20:53:04.601 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2016-12-23 20:53:04.603 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 8: Node advancer - DETAILS: Transaction complete (SendData:Request) success(false)

Battery driven devices are really a PITA

jaydee73 · December 23, 2016, 8:37pm

You already said it yourself: There is no xml file and habmin says the device is not communicating. How should there be correct sensor states…

NCO · December 23, 2016, 8:39pm

I see… Thanks.
So does this mean I need to delete the node every time I re-include the strip (with the round magnet triple trigger) or do I just re-do the magnet-thing again and again without deleting the node in between?

Actually I tried it just right now (again) and got the led flashing all three times.
No change.
And by the way: The alarm is always ON - does this ring a bell??

NCO · December 23, 2016, 8:42pm

So you mean there MUST be a node8.xml before the strip will work properly?
I thought it might be OH2 related and the information / configuration is stored in the internal DB (like the things created with Paper UI are not in the “Things” folder!??

NCO · December 23, 2016, 9:10pm

When I try to change the Parameter 1 (e.g. binary sensor report to Basic sensor report) I get:

2016-12-23 21:57:15.900 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Configuration update received
2016-12-23 21:57:15.960 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Configuration update action_heal to -232323
2016-12-23 21:57:15.962 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Configuration update config_1_1 to 2
2016-12-23 21:57:15.963 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Error getting configurationCommandClass
2016-12-23 21:57:15.964 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Configuration update config_2_1 to 1
2016-12-23 21:57:15.965 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Error getting configurationCommandClass
2016-12-23 21:57:15.966 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Configuration update action_failed to -232323
2016-12-23 21:57:15.967 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Configuration update action_remove to -232323
2016-12-23 21:57:15.968 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Configuration update group_1 to null

What is group_1 ??

Obviously there is something happening:
Opening the window leads to:

2016-12-23 22:14:13.854 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Updating channel state zwave:device:49ede2f3:node8:alarm_general to ON [OnOffType]

Closing leads to:

2016-12-23 22:16:44.608 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Updating channel state zwave:device:49ede2f3:node8:alarm_general to ON [OnOffType]

So Alarm_general is always ON, but gets updated on opening / closing the window.
But I don’t see the other channels in the log

Nicholas_Waterton · December 23, 2016, 11:06pm

So is it working now?

I’m actually using the zwave 1 binding in OH2. I’ll wait until it’s a bit more baked before I jump into moving to the OH2 binding. I have way too many OH1 items to make an easy transition.

Nick Waterton P.Eng

NCO · December 24, 2016, 6:35am

Actually no. Sorry for the confusion @Nicholas_Waterton.

I just recognized that SOME messages are transmitted somehow correctly (even if always alarm ON does not make sense to me).
I still did not get a node8.xml until yesterday evening nor a change of the sensor_binary…

NCO · December 24, 2016, 7:10am

This morning I deleted the Node 8 again and started with the inclusion (at least the 20th time).
(Running OH2 with Habmin2 - because this obviously makes a difference according to the discussions above.

This time I did the inclusion VERY close to the zwave controller (< 1 m). All my previous zwave devices I included from my desk (~3-4 m away).
And I finally got the node8.xml and the strip seems to be recognized correctly.

I changed the parameter 1 to 0 (sensor_binary).

However, I just get a signal back from the alarm handling:
Closing the Window:

2016-12-24 08:04:46.470 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 8: Application Command Request (ALIVE:DYNAMIC_VALUES)
2016-12-24 08:04:46.473 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 8: Incoming command class ALARM
2016-12-24 08:04:46.476 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 8: Received ALARM command V4
2016-12-24 08:04:46.478 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 8: Process NOTIFICATION_REPORT V4
2016-12-24 08:04:46.481 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 8: NOTIFICATION report - 0 = 0, event=23, status=255
2016-12-24 08:04:46.484 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 8: Alarm Type = ACCESS_CONTROL (0)
2016-12-24 08:04:46.487 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmValueEvent
2016-12-24 08:04:46.489 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2016-12-24 08:04:46.491 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
2016-12-24 08:04:46.494 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2016-12-24 08:04:46.496 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 23, type OnOffType
2016-12-24 08:04:46.497 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Updating channel state zwave:device:49ede2f3:node8:alarm_general to ON [OnOffType]
2016-12-24 08:04:46.509 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 4: Transaction not completed: node address inconsistent.  lastSent=4, incoming=255

Opening the window:

2016-12-24 08:05:58.722 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 8: Application Command Request (ALIVE:DYNAMIC_VALUES)
2016-12-24 08:05:58.733 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 8: Incoming command class ALARM
2016-12-24 08:05:58.736 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 8: Received ALARM command V4
2016-12-24 08:05:58.737 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 8: Process NOTIFICATION_REPORT V4
2016-12-24 08:05:58.738 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 8: NOTIFICATION report - 0 = 0, event=22, status=255
2016-12-24 08:05:58.740 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 8: Alarm Type = ACCESS_CONTROL (0)
2016-12-24 08:05:58.741 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmValueEvent
2016-12-24 08:05:58.743 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2016-12-24 08:05:58.744 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
2016-12-24 08:05:58.746 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2016-12-24 08:05:58.747 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 22, type OnOffType
2016-12-24 08:05:58.750 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Updating channel state zwave:device:49ede2f3:node8:alarm_general to ON [OnOffType]
2016-12-24 08:05:58.755 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 4: Transaction not completed: node address inconsistent.  lastSent=4, incoming=255

(Does the last NODE 4 message mean anything?

jaydee73 · December 24, 2016, 8:35am

No, the alarm channel is not correct. I am getting events from the binary sensor when I open/close the door/window.

Can you post all (!) your configuration options from habmin2 (Description, Configuration parameters, Association groups, device configuration, wakeup, channels and Attributes)?

Which version do you use? Latest snapshot of OH2 or the Beta 4? And which version of the zwave binding (although I doubt this is relevant here…)?

Regarding Node 4: Do you have any other zwave devices configured?

NCO · December 24, 2016, 9:54am

I just made an update / upgrade and all things are gone.
So it will take a while until I am back on track

NCO · December 24, 2016, 12:30pm

Thanks for your help, @jaydee73.

I am using 2.0.0-SNAPSHOT Build #672 after the upgrade today.
The zwave Version is Version 2.0.0.201612232333

I have 4 other Nodes (2 Fibaro Wall Plugs, one Fibaro Dual Wall-Switch and one Fibaro Rollershutter) which are working without issues since about a year now.

My config is as follows:

jaydee73 · December 24, 2016, 12:56pm

No problem. We will get your strip going together. I found some differences between our configurations.

First: You haven’t set the openHAB Controller as Lifeline in “Association Groups”. This could be relevant (AFAIK).

Second: During initial configuration, I’ve set the wakeup time to 4 hours (=14400). As a manual wakeup is somehow tricky, I just wanted to make sure that the device wakes up more often automatically. But this is surely not a “must”.

But regarding manual wakeup: habmin shows a timestamp, when the device woke up the last time (under Attributes). But there is no timestamp in your configuration! Was the device re-included (or at least re-initialized) the last hours? Otherwise there wasn’t a single wake up until now! See my config:

So you should check this. Furthermore you can see that I have an older firmware version. But I hope this doesn’t matter and Sensative hasn’t changed anything meaningful with the new firmware.

Last thing: Do you have any configuration options where there is an orange “pending…” on the right side? This means that this setting is not yet active and wasn’t yet transmitted to the strip.

Other than that, your config looks ok. The binary sensor channel exists and you have an item for it. But the fact, that for example there isn’t a battery value yet, shows me that the device needs some more time…and wake ups…

NCO · December 25, 2016, 9:27am

That’s some good hints - thangs (again

I had Association Group to the OpenHAB Controller, but this was while playing around in one of the previous include sessions. (I removed the strip several times and re-included it).
-> I will set it back to OpenHAB Controller -> check
Wakeup time changed to 14400 -> check
Last Wakeup time: Yes, I just re-included it about two hours before I send this information. However, there is still no timestamp yet. I hope the change above (4 hrs) will bring some light into this point.
Pending: I saw this (just after changing to 4 hrs wakeup time and Association group).
And it’s still there (even after 20 minutes).
I also opened and closed the sensor to force a wakeup (which should be the case, right?)

EDIT:
I just performed a manual wake up (3 times triggering with the round magnet with a short flash of the LED for each of the three).
-> in Habmin I see Node initializing: DYNAMIC_VALUES
Whatever that means… but after that '“pending…” was gone (for both of the above)
Still no Last Wakeup time stamp though…

jaydee73 · December 25, 2016, 11:40am

No. A trigger of an event doesn’t mean a wake up.

Of course it is. It will transfer the new settings to the device as soon as it wakes up. And as the new 4h setting hasn’t been transferred yet, it will be transferred when the old wakeup cycle occurs.

This is good. The device needs multiple (!!) wake ups for all data to be transferred (at least during the first initial setup). And the pending data was also transferred.

You can now wait until tomorrow without doing anything. Because of the shorter wake up all data should be transferred until then. Or you wake up the device manually some more times.

NCO · December 25, 2016, 1:41pm

Alright, thanks.
I will wait some longer an see if I will get a timestamp after the next 4 hrs.
Will keep you posted