ZWave-binding - Battery operated zwave-devices and OH2

Hello everyone and @chris

perhaps someone can give me some hints to get my zwave (battery) operated devices working as expected or like before with openHAB1/former versions of the zwave-binding.

After migrating to openHAB2 (online version; Build #502) and installing the zwave-binding I tried to configure all of my devices. I played a bit with Item linking-mode and ended up not using the simple mode, because I then could name my items as before and all of my rules should work like before. Most of them actually do.

Now the problem:
2 of 5 battery operated devices doesn’t show their battery status right now. My most important device, an Everspring SP103 Motion Detector, just gives a state update, when motion is detected and doesn’t change its state. The state is always OFF. So I updated my rule (from changed from OPEN to CLOSED) to be triggered on any received update. But the update happens too, when the device wakes up regularly. I set that up to happen every 30 minutes. First steps to configure the device were deleting the node.xml file(s) and to wake it up multiple times.

In the logs I can’t see any interesting entries. Items, links, and the things look good. Another Vision - shock and vibration sensor doesn’t do anything right now.

Some other weird things with my fibaro motion (multi) sensor. I get luminance and temperature values, but no battery and motion values.


I don’t have any item configuration in my *.items file. There are just dummy items. I used the paperUI and HABmin2 to set everything up.

It feels like I cannot see the depth of information in logs like with former versions of the binding, even after starting start_debug.sh.

Starting an old version of openHAB and the zwave binding results in working like expected and before.

I’ll be happy to provide more information if needed. I am using an Aeotec USB Z-Stick S2 (older version, not Gen5, black one).

Thanks in advance.

Regards,
André

Hi,

I think, you face some different problems who are not necessarily related to each other.

First of all: Are all battery operated devices included sucessfully? Or are they maybe still in initialization process?

Second:
I noticed, that for some command classes in OH2 the item type changed. I used a motion sensor as CONTACT in OH1, but it only worked as a SWITCH in OH2. You should also check this for your devices.

Third;
You wrote that you ended up not using the simple mode (which is indeed preferrable for OH1 users migrating over). But in another sentence you wrote that you don’t use item files. From my understanding it has to be one or the other?!

Fourth:
You should take some time and read docs.openhab.org and also the migration tutorial from Rich, which can be found here in the forum. Both deliver many, many useful hints for any kind of problems.

Fifth:
Debugging doesn’t work with only starting start_debug.sh. You have to specify the DEBUG log level in a configuration file. How to? Read the docs. :wink:

Concerning the battery status: When did you include the devices? For battery devices it could take some time (hours, even days), before the battery status gets updated. Do you see the battery status in HABmin?

Again: I would clearly suggest you to use the file based configurations (item files, persistence files and so on) like you did in OH1. You are familiar with this and it seems to be the easier way. Again: Take a look at the migration tutorial.

BR,
Stefan

Thank you for your answer :slight_smile: :

Yes. They are. Besides one which works properly. Besides its battery state.

I noticed that too and changed them accordingly.

No. You can use HABmin to add items and link them to thte channels using the channels menu/config-options of a thing. And without the simple mode in PaperUI you have another menu entry items. With those two options you even don’t have to use any items-file. But sometimes for OH1 users it’s easier to use them.

Yes you’re right. I read the docs and those for migration too. I tried several things. Migration with old item-files and changing the channel-linking. Setting up everything from zero on without any config file. This is now my status. Most things work really nice. But some things went better with OH1. But I like the way which OH2 takes to get more people to use it. Especially less technical experienced people.

Yes. You are absolutely right. Regarding to this How do I turn on debug mode in openhab2? I found that post: Logging under OH2 / Karaf
This helped me and now I have set up the DEBUG mode. Thanks.[quote=“jaydee73, post:2, topic:15425”]
Concerning the battery status: When did you include the devices? For battery devices it could take some time (hours, even days), before the battery status gets updated. Do you see the battery status in HABmin?
[/quote]

I know. The devices worked properly before. So why not now. I just switched to OH2. I didn’t change anything. I know that the battery values take some time to be transmitted to OH or its corresponding binding, because of the wakeup interval.

I want to use and try the new way. I backed up everything and I can switch back at any time. But with OH2 there are new ways to achieve things. So I think it’s the way to go and to try. And perhaps to help to test it as it still in beta status. In some time OH1 will be EOL so why not trying the new way. And if I am right there are some discussions here which suggest to use the way without the config files, because they are relicts from OH1. Not saying that they aren’t be used anymore :wink:

Best regards,
André

Ok, as you now can use debug logging, I would suggest to let it log for about a day and see, if there are any battery values polled from OH2 and/or transferred from the devices.

Again: Can you see a battery value in HABmin when configuring the appropriate thing? Maybe a screenshot would help. I would provide a screenshot from my own OH2 installation, but currently I switched back to OH1. I made about half a dozen tries about the last two month or so, but I couldn’t get it to go like my OH1 installation. I found something that did not work every time…

But I like OH2 and I will try again when the issues got resolved.

Yes. That is the next step.

No I can’t. Otherwise I would have misconfigured the links. That would be good, because then I could fix it by myself :slight_smile:

I try to avoid switching back, because I want to go with the new version. But I know what you mean. By now I am running OH2 all the time. Only with the way I described above I was able to use it like I almost want to use my home automation. I mean trying with Simple Mode - ON and OFF.

Are you just using ZWAVE technology or another technology too? Perhaps we can share some more infos to get our both installations to work like we want it to.

regards
André

Hello again,

@chris I have to bring up this thread again. After upgrading to the latest nightly build from yesterday 2017-01-12 the problem with my Everspring Motion Sensor SP103 still exists. Everything else seems to work just fine right now.

The issue is: There seems to be no difference between waking up and detecting/notifying a motion. So it is not possible to react in a rule. Here are some more information out of my zwave.log (after enabling logging, thanks for that again @jaydee73).

Motion event:

2017-01-13 08:27:09.734 [ZWaveController           ] - Process Message = 01 09 00 04 00 07 03 20 01 00 D7 
2017-01-13 08:27:09.734 [ZWaveController           ] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 07 03 20 01 00 
2017-01-13 08:27:09.734 [ZWaveController           ] - Incoming Message type = REQUEST
2017-01-13 08:27:09.735 [icationCommandMessageClass] - Handle Message Application Command Request
2017-01-13 08:27:09.735 [icationCommandMessageClass] - NODE 7: Application Command Request (ALIVE:DONE)
2017-01-13 08:27:09.735 [ZWaveNodeInitStageAdvancer] - NODE 7: Starting initialisation from DONE
2017-01-13 08:27:09.735 [ZWaveController           ] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@1b392bc already registered
2017-01-13 08:27:09.735 [icationCommandMessageClass] - NODE 7: Incoming command class BASIC
2017-01-13 08:27:09.736 [icationCommandMessageClass] - NODE 7: Found Command Class BASIC, passing to handleApplicationCommandRequest
2017-01-13 08:27:09.736 [ZWaveBasicCommandClass    ] - NODE 7: Received Basic Request
2017-01-13 08:27:09.736 [ZWaveBasicCommandClass    ] - NODE 7: Basic Set sent to the controller will be processed as Basic Report
2017-01-13 08:27:09.736 [ZWaveBasicCommandClass    ] - NODE 7: Basic report, value = 0x00
2017-01-13 08:27:09.736 [ZWaveController           ] - Notifying event listeners: ZWaveCommandClassValueEvent
2017-01-13 08:27:09.737 [ZWaveThingHandler         ] - NODE 7: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2017-01-13 08:27:09.737 [ZWaveThingHandler         ] - NODE 7: Got a value event from Z-Wave network, endpoint = 0, command class = BASIC, value = 0
2017-01-13 08:27:09.737 [ZWaveThingHandler         ] - NODE 7: Updating channel state zwave:device:d00c896c:node7:sensor_binary to OFF [OnOffType]

Wake Up event:

2017-01-12 22:03:37.002 [ZWaveController           ] - Process Message = 01 08 00 04 00 07 02 84 07 75 
2017-01-12 22:03:37.002 [ZWaveController           ] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 07 02 84 07 
2017-01-12 22:03:37.003 [ZWaveController           ] - Incoming Message type = REQUEST
2017-01-12 22:03:37.003 [icationCommandMessageClass] - Handle Message Application Command Request
2017-01-12 22:03:37.003 [icationCommandMessageClass] - NODE 7: Application Command Request (ALIVE:DONE)
2017-01-12 22:03:37.003 [ZWaveNodeInitStageAdvancer] - NODE 7: Starting initialisation from DONE
2017-01-12 22:03:37.004 [ZWaveController           ] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@1b392bc already registered
2017-01-12 22:03:37.004 [icationCommandMessageClass] - NODE 7: Incoming command class WAKE_UP
2017-01-12 22:03:37.004 [icationCommandMessageClass] - NODE 7: Found Command Class WAKE_UP, passing to handleApplicationCommandRequest
2017-01-12 22:03:37.004 [ZWaveWakeUpCommandClass   ] - NODE 7: Received Wake Up Request
2017-01-12 22:03:37.005 [ZWaveWakeUpCommandClass   ] - NODE 7: Received WAKE_UP_NOTIFICATION
2017-01-12 22:03:37.005 [ZWaveWakeUpCommandClass   ] - NODE 7: Is awake with 3 messages in the wake-up queue.
2017-01-12 22:03:37.005 [ZWaveController           ] - Notifying event listeners: ZWaveWakeUpEvent
2017-01-12 22:03:37.006 [ZWaveThingHandler         ] - NODE 7: Got an event from Z-Wave network: ZWaveWakeUpEvent
2017-01-12 22:03:37.006 [ZWaveController           ] - Callback ID = 23
2017-01-12 22:03:37.007 [ZWaveController           ] - Message queued. Queue length = 1. Queue={}
2017-01-12 22:03:37.007 [Controller$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
2017-01-12 22:03:37.007 [icationCommandMessageClass] - NODE 4: Transaction not completed: node address inconsistent.  lastSent=4, incoming=255
2017-01-12 22:03:37.008 [SerialMessage             ] - Calculated checksum = 0xE0
2017-01-12 22:03:37.008 [SerialMessage             ] - Assembled message buffer = 01 09 00 13 07 02 30 02 25 17 E0 
2017-01-12 22:03:37.009 [ZWaveSerialHandler        ] - NODE 7: Sending REQUEST Message = 01 09 00 13 07 02 30 02 25 17 E0 
2017-01-12 22:03:37.011 [ZWaveSerialHandler        ] - Message SENT
2017-01-12 22:03:37.013 [Handler$ZWaveReceiveThread] - Received ACK
2017-01-12 22:03:37.016 [Handler$ZWaveReceiveThread] - Received SOF
2017-01-12 22:03:37.017 [Handler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8 
2017-01-12 22:03:37.018 [SerialMessage             ] - NODE 255: Creating new SerialMessage from buffer = 01 04 01 13 01 E8 
2017-01-12 22:03:37.019 [SerialMessage             ] - Calculated checksum = 0xE8
2017-01-12 22:03:37.019 [SerialMessage             ] - NODE 255: Checksum matched
2017-01-12 22:03:37.020 [SerialMessage             ] - NODE 255: Message payload = 01 
2017-01-12 22:03:37.020 [Handler$ZWaveReceiveThread] - Message is valid, sending ACK
2017-01-12 22:03:37.022 [Handler$ZWaveReceiveThread] - Response SENT
2017-01-12 22:03:37.022 [ZWaveController           ] - Receive queue TAKE: Length=0
2017-01-12 22:03:37.023 [SerialMessage             ] - Calculated checksum = 0xE8
2017-01-12 22:03:37.023 [SerialMessage             ] - Assembled message buffer = 01 04 01 13 01 E8 
2017-01-12 22:03:37.023 [ZWaveController           ] - Process Message = 01 04 01 13 01 E8 
2017-01-12 22:03:37.024 [ZWaveController           ] - Message: class=SendData[0x13], type=Response[0x01], priority=High, dest=255, callback=0, payload=01 
2017-01-12 22:03:37.024 [ZWaveController           ] - Incoming Message type = RESPONSE
2017-01-12 22:03:37.024 [SendDataMessageClass      ] - Handle Message Send Data Response
2017-01-12 22:03:37.024 [SendDataMessageClass      ] - NODE 7: Sent Data successfully placed on stack.
2017-01-12 22:03:37.025 [SerialMessage             ] - Ack Pending cleared
2017-01-12 22:03:37.028 [Handler$ZWaveReceiveThread] - Received SOF
2017-01-12 22:03:37.030 [Handler$ZWaveReceiveThread] - Receive Message = 01 05 00 13 17 00 FE 
2017-01-12 22:03:37.030 [SerialMessage             ] - NODE 255: Creating new SerialMessage from buffer = 01 05 00 13 17 00 FE 
2017-01-12 22:03:37.031 [SerialMessage             ] - Calculated checksum = 0xFE
2017-01-12 22:03:37.032 [SerialMessage             ] - NODE 255: Checksum matched
2017-01-12 22:03:37.033 [SerialMessage             ] - NODE 255: Message payload = 17 00 
2017-01-12 22:03:37.033 [Handler$ZWaveReceiveThread] - Message is valid, sending ACK
2017-01-12 22:03:37.035 [Handler$ZWaveReceiveThread] - Response SENT
2017-01-12 22:03:37.035 [ZWaveController           ] - Receive queue TAKE: Length=0
2017-01-12 22:03:37.035 [SerialMessage             ] - Calculated checksum = 0xFC
2017-01-12 22:03:37.036 [Handler$ZWaveReceiveThread] - Received SOF
2017-01-12 22:03:37.036 [SerialMessage             ] - Assembled message buffer = 01 07 00 13 17 00 00 00 FC 
2017-01-12 22:03:37.036 [ZWaveController           ] - Process Message = 01 07 00 13 17 00 00 00 FC 
2017-01-12 22:03:37.037 [ZWaveController           ] - Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=17 00 
2017-01-12 22:03:37.037 [ZWaveController           ] - Incoming Message type = REQUEST
2017-01-12 22:03:37.038 [SendDataMessageClass      ] - Handle Message Send Data Request
2017-01-12 22:03:37.038 [SendDataMessageClass      ] - NODE 7: SendData Request. CallBack ID = 23, Status = Transmission complete and ACK received(0)
2017-01-12 22:03:37.039 [ZWaveNodeInitStageAdvancer] - NODE 7: Starting initialisation from DONE
2017-01-12 22:03:37.041 [ZWaveController           ] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@1b392bc already registered
2017-01-12 22:03:37.042 [ZWaveCommandProcessor     ] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=7, callback=23, payload=07 02 30 02 
2017-01-12 22:03:37.042 [ZWaveCommandProcessor     ] - Checking transaction complete: Recv Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=17 00 
2017-01-12 22:03:37.043 [ZWaveCommandProcessor     ] - Checking transaction complete: class=SendData, callback id=23, expected=ApplicationCommandHandler, cancelled=false      MISMATCH
2017-01-12 22:03:37.049 [Handler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 07 03 30 03 00 C5 
2017-01-12 22:03:37.050 [SerialMessage             ] - NODE 255: Creating new SerialMessage from buffer = 01 09 00 04 00 07 03 30 03 00 C5 
2017-01-12 22:03:37.051 [SerialMessage             ] - Calculated checksum = 0xC5
2017-01-12 22:03:37.051 [SerialMessage             ] - NODE 255: Checksum matched
2017-01-12 22:03:37.052 [SerialMessage             ] - NODE 255: Message payload = 00 07 03 30 03 00 
2017-01-12 22:03:37.052 [Handler$ZWaveReceiveThread] - Message is valid, sending ACK
2017-01-12 22:03:37.054 [Handler$ZWaveReceiveThread] - Response SENT
2017-01-12 22:03:37.055 [ZWaveController           ] - Receive queue TAKE: Length=0
2017-01-12 22:03:37.055 [SerialMessage             ] - Calculated checksum = 0xC5
2017-01-12 22:03:37.056 [SerialMessage             ] - Assembled message buffer = 01 09 00 04 00 07 03 30 03 00 C5 
2017-01-12 22:03:37.056 [ZWaveController           ] - Process Message = 01 09 00 04 00 07 03 30 03 00 C5 
2017-01-12 22:03:37.056 [ZWaveController           ] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 07 03 30 03 00 
2017-01-12 22:03:37.057 [ZWaveController           ] - Incoming Message type = REQUEST
2017-01-12 22:03:37.057 [icationCommandMessageClass] - Handle Message Application Command Request
2017-01-12 22:03:37.057 [icationCommandMessageClass] - NODE 7: Application Command Request (ALIVE:DONE)
2017-01-12 22:03:37.057 [ZWaveNodeInitStageAdvancer] - NODE 7: Starting initialisation from DONE
2017-01-12 22:03:37.058 [ZWaveController           ] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@1b392bc already registered
2017-01-12 22:03:37.058 [icationCommandMessageClass] - NODE 7: Incoming command class SENSOR_BINARY
2017-01-12 22:03:37.058 [icationCommandMessageClass] - NODE 7: Found Command Class SENSOR_BINARY, passing to handleApplicationCommandRequest
2017-01-12 22:03:37.058 [veBinarySensorCommandClass] - Handle Message Sensor Binary Request
2017-01-12 22:03:37.059 [veBinarySensorCommandClass] - NODE 7: Received SENSOR_BINARY command V1
2017-01-12 22:03:37.059 [veBinarySensorCommandClass] - Process Sensor Binary Report
2017-01-12 22:03:37.059 [veBinarySensorCommandClass] - NODE 7: Sensor Binary report, type=Unknown, value=0
2017-01-12 22:03:37.059 [ZWaveController           ] - Notifying event listeners: ZWaveBinarySensorValueEvent
2017-01-12 22:03:37.060 [ZWaveThingHandler         ] - NODE 7: Got an event from Z-Wave network: ZWaveBinarySensorValueEvent
2017-01-12 22:03:37.060 [ZWaveThingHandler         ] - NODE 7: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_BINARY, value = 0
2017-01-12 22:03:37.060 [ZWaveThingHandler         ] - NODE 7: Updating channel state zwave:device:d00c896c:node7:sensor_binary to OFF [OnOffType]
2017-01-12 22:03:37.062 [ZWaveCommandProcessor     ] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=7, callback=23, payload=07 02 30 02 
2017-01-12 22:03:37.063 [ZWaveCommandProcessor     ] - Checking transaction complete: Recv Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 07 03 30 03 00 
2017-01-12 22:03:37.064 [ZWaveCommandProcessor     ] - Checking transaction complete: class=ApplicationCommandHandler, callback id=23, expected=ApplicationCommandHandler, cancelled=false        transaction complete!
2017-01-12 22:03:37.064 [ZWaveController           ] - Notifying event listeners: ZWaveTransactionCompletedEvent
2017-01-12 22:03:37.064 [ZWaveController           ] - Callback ID = 24
2017-01-12 22:03:37.065 [ZWaveController           ] - Message queued. Queue length = 1. Queue={}
2017-01-12 22:03:37.065 [ZWaveThingHandler         ] - NODE 7: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2017-01-12 22:03:37.065 [ZWaveController           ] - Released. Transaction completed permit count -> 1
2017-01-12 22:03:37.065 [Controller$ZWaveSendThread] - NODE 7: Response processed after 54ms/4814ms.
2017-01-12 22:03:37.066 [Controller$ZWaveSendThread] - Acquired. Transaction completed permit count -> 0
2017-01-12 22:03:37.066 [Controller$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
2017-01-12 22:03:37.067 [SerialMessage             ] - Calculated checksum = 0xAB
2017-01-12 22:03:37.068 [SerialMessage             ] - Assembled message buffer = 01 0C 00 13 07 05 71 04 00 01 00 25 18 AB 
2017-01-12 22:03:37.068 [ZWaveSerialHandler        ] - NODE 7: Sending REQUEST Message = 01 0C 00 13 07 05 71 04 00 01 00 25 18 AB 
2017-01-12 22:03:37.069 [ZWaveSerialHandler        ] - Message SENT
2017-01-12 22:03:37.072 [Handler$ZWaveReceiveThread] - Received ACK
2017-01-12 22:03:37.075 [Handler$ZWaveReceiveThread] - Received SOF
2017-01-12 22:03:37.076 [Handler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8 
2017-01-12 22:03:37.077 [SerialMessage             ] - NODE 255: Creating new SerialMessage from buffer = 01 04 01 13 01 E8 
2017-01-12 22:03:37.077 [SerialMessage             ] - Calculated checksum = 0xE8
2017-01-12 22:03:37.077 [SerialMessage             ] - NODE 255: Checksum matched
2017-01-12 22:03:37.078 [SerialMessage             ] - NODE 255: Message payload = 01 
2017-01-12 22:03:37.078 [Handler$ZWaveReceiveThread] - Message is valid, sending ACK
2017-01-12 22:03:37.079 [Handler$ZWaveReceiveThread] - Response SENT
2017-01-12 22:03:37.079 [ZWaveController           ] - Receive queue TAKE: Length=0
2017-01-12 22:03:37.080 [SerialMessage             ] - Calculated checksum = 0xE8
2017-01-12 22:03:37.081 [SerialMessage             ] - Assembled message buffer = 01 04 01 13 01 E8 
2017-01-12 22:03:37.081 [ZWaveController           ] - Process Message = 01 04 01 13 01 E8 
2017-01-12 22:03:37.082 [ZWaveController           ] - Message: class=SendData[0x13], type=Response[0x01], priority=High, dest=255, callback=0, payload=01 
2017-01-12 22:03:37.082 [ZWaveController           ] - Incoming Message type = RESPONSE
2017-01-12 22:03:37.083 [SendDataMessageClass      ] - Handle Message Send Data Response
2017-01-12 22:03:37.083 [SendDataMessageClass      ] - NODE 7: Sent Data successfully placed on stack.
2017-01-12 22:03:37.083 [SerialMessage             ] - Ack Pending cleared
2017-01-12 22:03:37.087 [Handler$ZWaveReceiveThread] - Received SOF
2017-01-12 22:03:37.091 [Handler$ZWaveReceiveThread] - Receive Message = 01 05 00 13 18 00 F1 
2017-01-12 22:03:37.092 [SerialMessage             ] - NODE 255: Creating new SerialMessage from buffer = 01 05 00 13 18 00 F1 
2017-01-12 22:03:37.093 [SerialMessage             ] - Calculated checksum = 0xF1
2017-01-12 22:03:37.093 [SerialMessage             ] - NODE 255: Checksum matched
2017-01-12 22:03:37.094 [SerialMessage             ] - NODE 255: Message payload = 18 00 
2017-01-12 22:03:37.094 [Handler$ZWaveReceiveThread] - Message is valid, sending ACK
2017-01-12 22:03:37.096 [Handler$ZWaveReceiveThread] - Response SENT
2017-01-12 22:03:37.096 [ZWaveController           ] - Receive queue TAKE: Length=0
2017-01-12 22:03:37.097 [SerialMessage             ] - Calculated checksum = 0xF3
2017-01-12 22:03:37.098 [SerialMessage             ] - Assembled message buffer = 01 07 00 13 18 00 00 00 F3 
2017-01-12 22:03:37.098 [ZWaveController           ] - Process Message = 01 07 00 13 18 00 00 00 F3 
2017-01-12 22:03:37.099 [ZWaveController           ] - Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=18 00 
2017-01-12 22:03:37.099 [ZWaveController           ] - Incoming Message type = REQUEST
2017-01-12 22:03:37.099 [SendDataMessageClass      ] - Handle Message Send Data Request
2017-01-12 22:03:37.100 [SendDataMessageClass      ] - NODE 7: SendData Request. CallBack ID = 24, Status = Transmission complete and ACK received(0)
2017-01-12 22:03:37.100 [ZWaveNodeInitStageAdvancer] - NODE 7: Starting initialisation from DONE
2017-01-12 22:03:37.101 [ZWaveController           ] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@1b392bc already registered
2017-01-12 22:03:37.102 [ZWaveCommandProcessor     ] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=7, callback=24, payload=07 05 71 04 00 01 00 
2017-01-12 22:03:37.102 [ZWaveCommandProcessor     ] - Checking transaction complete: Recv Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=18 00 
2017-01-12 22:03:37.103 [ZWaveCommandProcessor     ] - Checking transaction complete: class=SendData, callback id=24, expected=ApplicationCommandHandler, cancelled=false      MISMATCH
2017-01-12 22:03:42.069 [Controller$ZWaveSendThread] - NODE 7: Timeout while sending message. Requeueing - 2 attempts left!
2017-01-12 22:03:42.069 [SendDataMessageClass      ] - NODE 7: Handling failed message.
2017-01-12 22:03:42.070 [ZWaveWakeUpCommandClass   ] - NODE 7: Is sleeping
2017-01-12 22:03:42.070 [ZWaveWakeUpCommandClass   ] - NODE 7: Putting message SendData in wakeup queue.

Most interesting lines in my opinion are:

2017-01-13 08:27:09.737 [ZWaveThingHandler         ] - NODE 7: Updating channel state zwave:device:d00c896c:node7:sensor_binary to OFF [OnOffType]
2017-01-12 22:03:37.060 [ZWaveThingHandler         ] - NODE 7: Updating channel state zwave:device:d00c896c:node7:sensor_binary to OFF [OnOffType]

So how should my trigger for the rule be to just react on a motion, but not on a normal wakeup?

Thanks again

I always do it the easy way:

Take a look in your events.log (FibEye1_Motion_S is the name for my motion sensor) when the motion got triggered:
2017-01-14 10:57:58.930 [ItemStateChangedEvent ] - FibEye1_Motion_S changed from OFF to ON

then I trigger my rule on

Item FibEye1_Motion_S received update ON

or

Item FibEye1_Motion_S changed to ON

See the docs here and here for more details on received and changed triggers.

Right. Thanks @sihui
I’ve been doing that for all items, but with this sensor it doesn’t work anymore (like it did in OH1.*).

There is nothing concerning the Everspring SP103 sensor in that log.

Just:

  • Thing added
  • INITIALIZING stati
  • Thing has been updated
  • Link has been added
  • changed from ONLINE to OFFLINE (COMMUNICATION_ERROR)
  • etc.

But it does work. It wakes up, it detects motion and so on. Perhaps the behaviour was in OH1 the same but I didn’t notice that, because of a bigger wakekup interval. During testing of OH2 I changed the wakeup period to 30 minutes.

For my Fibaro Multisensor I can see status changes in events.log. But not for the Everspring motion sensor. Very weird.

Flat battery? Or the sensor hasn’t finished initialization yet: wake it up manually a few more times …

I don’t think so, because it wakes up regularly and works with motion. But when I look at the battery level right now I don’t get a value. And the device itself drains the battery really quickly (another annoying problem).

Initialization was fine and I manually woke my battery operated devices up multiple times to achieve that. And in my logs I could see the successful initialization.

Perhaps I should try the sensor with the razberry shield and see whether it works there like expected. Because of the battery drain I would like to exchange the sensor anyway. But I could really find an outdoor sensor like that. Perhaps right now there are newer/better sensors.

Thanks @sihui :thumbsup: