Aotec Gen 5 + Sensative Strips config problem

Add-ons Bindings
1

Hi,

until now I had openHab 1 with Aotec Usb gen 5 and sensative strip configured. Everything was working fine. I’m trying to upgrade to version 2 and I have a problem. It looks like there are no events coming from the sensative strip. The events log is empty. But if I switch logging to debug I actually see that there are messages coming from the device to openhab. Is anyone able to point me to what is not working?

2017-02-23 06:13:34.318 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Connecting to serial port '/dev/ttyACM0'
2017-02-23 06:13:34.496 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Serial port is initialized
2017-02-23 06:13:34.527 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - Controller handler not found. Cannot handle command without ZWave controller.
2017-02-23 06:13:34.529 [INFO ] [mmandclass.ZWaveSecurityCommandClass] - Update networkKey
2017-02-23 06:13:34.569 [INFO ] [ve.internal.protocol.ZWaveController] - Starting ZWave controller
2017-02-23 06:13:34.571 [INFO ] [ve.internal.protocol.ZWaveController] - ZWave timeout is set to 5000ms. Soft reset is false.
2017-02-23 06:13:36.861 [WARN ] [e.sshd.server.channel.ChannelSession] - Unknown pty opcode value: 42
2017-02-23 06:13:37.863 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 1: Node found
2017-02-23 06:13:37.867 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 2: Node found
2017-02-23 06:13:37.871 [INFO ] [age.SerialApiGetInitDataMessageClass] - ZWave Controller using Controller API
2017-02-23 06:13:37.873 [INFO ] [age.SerialApiGetInitDataMessageClass] - ZWave Controller is Primary Controller
2017-02-23 06:13:37.877 [INFO ] [age.SerialApiGetInitDataMessageClass] - ------------Number of Nodes Found Registered to ZWave Controller------------
2017-02-23 06:13:37.880 [INFO ] [age.SerialApiGetInitDataMessageClass] - # Nodes = 2
2017-02-23 06:13:37.883 [INFO ] [age.SerialApiGetInitDataMessageClass] - ----------------------------------------------------------------------------
2017-02-23 06:13:41.192 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Initialising Thing Node...
2017-02-23 06:18:46.173 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 02 03 30 03 FF 3F
2017-02-23 06:18:46.184 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-02-23 06:18:46.192 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 04 00 02 03 30 03 FF 3F
2017-02-23 06:18:46.196 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 04 00 02 03 30 03 FF 3F
2017-02-23 06:18:46.199 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 02 03 3$
2017-02-23 06:18:46.205 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 2: Application Command Request (INITIALIZING:WAIT)
2017-02-23 06:18:46.207 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Node is ALIVE. Init stage is WAIT.
2017-02-23 06:18:46.210 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveNodeStatusEvent
2017-02-23 06:18:46.213 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 2: Node Status event during initialisation - Node is ALIVE
2017-02-23 06:18:46.215 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 2: Node advancer - WAIT: queue length(0), free to send(true)
2017-02-23 06:18:46.217 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 2: Node advancer: loop - WAIT try 1: stageAdvanced(false)
2017-02-23 06:18:46.219 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 2: Node advancer: WAIT - Listening=false, FrequentlyListening=false
2017-02-23 06:18:46.221 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 2: Node advancer: WAIT - Still waiting!
2017-02-23 06:18:46.223 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got an event from Z-Wave network: ZWaveNodeStatusEvent
2017-02-23 06:18:46.225 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Setting ONLINE
2017-02-23 06:18:46.228 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 2: Node Status event - Node is ALIVE
2017-02-23 06:18:46.232 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 2: Incoming command class SENSOR_BINARY
2017-02-23 06:18:46.235 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 2: Received SENSOR_BINARY command V1
2017-02-23 06:18:46.239 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 2: Sensor Binary report, type=Unknown, value=255
2017-02-23 06:18:46.241 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveBinarySensorValueEvent
2017-02-23 06:18:46.242 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got an event from Z-Wave network: ZWaveBinarySensorValueEvent
2017-02-23 06:18:46.243 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_BINARY, value = 255
2017-02-23 06:18:46.247 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 255: Transaction not completed: node address inconsistent.  lastSent=255, incoming=255
2017-02-23 06:18:49.162 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 02 03 30 03 00 C0
2017-02-23 06:18:49.166 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-02-23 06:18:49.169 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 04 00 02 03 30 03 00 C0
2017-02-23 06:18:49.171 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 04 00 02 03 30 03 00 C0
2017-02-23 06:18:49.173 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 02 03 3$
2017-02-23 06:18:49.174 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 2: Application Command Request (ALIVE:WAIT)
2017-02-23 06:18:49.176 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 2: Incoming command class SENSOR_BINARY
2017-02-23 06:18:49.177 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 2: Received SENSOR_BINARY command V1
2017-02-23 06:18:49.178 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 2: Sensor Binary report, type=Unknown, value=0
2017-02-23 06:18:49.179 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveBinarySensorValueEvent
2017-02-23 06:18:49.180 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got an event from Z-Wave network: ZWaveBinarySensorValueEvent
2017-02-23 06:18:49.181 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_BINARY, value = 0
2017-02-23 06:18:49.183 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 255: Transaction not completed: node address inconsistent.  lastSent=255, incoming=255
2

I would assume this is a configuration issue. The strip has to be configured slighty different in OH2 to work properly.

Configuration parameter:
Notification type: Notification report

Association group:
1: Lifeline: openHAB controller

And the item type has to be CONTACT (I think in OH1 it was SWITCH)!

Other than that, is the strip fully included? It takes many, many (many…) wakeups to finalize the inclusion process.

Which OH2 version do you use? Chris made some changes to the binding some weeks ago to improve the inclusion process for the strips. And how do you do your item definitions? File based (as an OH1 user you probably do so) or UI based through PaperUI)? If file based, how does your item definition looks like?

I am using exact the same devices (strip and G5 stick) and it’s working rock solid. So it could be done. :wink:

3

Hi Stefan,

I would assume a configuration issue as well. The strips were properly initialized. Actually I was quite surprised that it actually didn’t take that much long. I think 2 wake-ups was sufficient for the initialization. Last time I was setting it on openhab 1 it took me half an hour at least. But now I see 2 parameters, description so it looks fine. I have added them thought the PaperUI. The item is defined as CONTACT although I have tried different types as well.

I have also tried last night to switch the notification type to Notification Report but that didn’t change much. I must say though that the change of parameters I had to do via the Habmin as via the PaperUI I’m getting a 404 error that the device is not found for the change command.

I’m not that familiar with the setting for association group. I don’t know what is set there. I will check that.

My configuration is the last openhabianpi on RaspberryPi 2.

4

So in the end a switch of the notification type parameter worked this time. Now everything works as expected.

5

Good to hear!

As a parameter change is only transferred to the device during regular wakeup, and as the wakeup interval for this device usually is 86400 seconds (=only once per day), it could take max. a full day until the device operates with the new parameter.

6

Thank you. I know that the parameters are not transferred immediately. But after I’ve changed the parameter I woke up the device and I have seen in the logs that the params were transferred. Somehow that didn’t work the first time. But not it’s working fine.