Initialization of AEON Labs ZW130 WallMote Quad fails

groobie · April 9, 2017, 1:43pm

Hi,
I included the device to my z-wave network. node.xml was created, but the initialization process does not finish (device shows up as unknown device in Paper UI). Any ideas?

I attached the logs below. It’s node 8. I am using z-wave binding version 2.0.0 from the openhab 2.0 stable release.

Many thanks for your support.

15:35:11.240 [WARN ] [l.serialmessage.SendDataMessageClass] - NODE 8: Already processed another send data request for this callback Id, ignoring.
15:35:16.212 [ERROR] [ocol.ZWaveController$ZWaveSendThread] - NODE 8: Timeout while sending message. Requeueing - 1 attempts left!
15:35:16.212 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 8: Is sleeping
15:35:16.212 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 8: Putting message SendData in wakeup queue.
15:35:16.212 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
15:35:16.212 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 8: Message already on the wake-up queue. Removing original.
15:35:16.212 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 8: Putting message SendData in wakeup queue.
15:35:19.908 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 1B 00 49 84 08 15 04 18 01 5E 85 59 8E 60 86 70 72 5A 73 84 80 5B 71 7A EF 25 26 50
15:35:19.909 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
15:35:19.909 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 1B 00 49 84 08 15 04 18 01 5E 85 59 8E 60 86 70 72 5A 73 84 80 5B 71 7A EF 25 26 50
15:35:19.909 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 1B 00 49 84 08 15 04 18 01 5E 85 59 8E 60 86 70 72 5A 73 84 80 5B 71 7A EF 25 26 50
15:35:19.909 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationUpdate[0x49], type=Request[0x00], priority=High, dest=255, callback=0, payload=84 08 15 04 18 01 5E 85 59 8E 60 86 70 72 5A 73 84 80 5B 71 7A EF 25 26
15:35:19.910 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 8: Application update request. Node information received.
15:35:19.910 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 8: Is awake with 2 messages in the wake-up queue.
15:35:19.910 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveWakeUpEvent
15:35:19.910 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 8: Wakeup during initialisation.
15:35:19.910 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 8: Node advancer - STATIC_VALUES: queue length(70), free to send(false)
15:35:19.910 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 8: Node advancer - queued packet. Queue length is 70
15:35:19.910 [DEBUG] [ve.internal.protocol.ZWaveController] - Message queued. Queue length = 1. Queue={}
15:35:19.910 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got an event from Z-Wave network: ZWaveWakeUpEvent
15:35:19.910 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
15:35:19.911 [DEBUG] [ve.internal.protocol.ZWaveController] - Message queued. Queue length = 1. Queue={}
15:35:19.911 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Message has Ack Pending: Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=8, callback=145, payload=08 08 60 0D 01 01 59 05 00 04
15:35:19.911 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0F 00 13 08 08 60 0D 01 01 59 05 00 04 25 91 62
15:35:19.911 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 8: Sending REQUEST Message = 01 0F 00 13 08 08 60 0D 01 01 59 05 00 04 25 91 62
15:35:19.919 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8
15:35:19.920 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
15:35:19.920 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 01 13 01 E8
15:35:19.920 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 04 01 13 01 E8
15:35:19.920 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Response[0x01], priority=High, dest=255, callback=0, payload=01
15:35:19.920 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 8: Sent Data successfully placed on stack.
15:35:19.936 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 91 00 00 03 79
15:35:19.937 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
15:35:19.937 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 91 00 00 03 00 00 77
15:35:19.937 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 13 91 00 00 03 00 00 77
15:35:19.938 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=91 00 00 03
15:35:19.938 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 8: SendData Request. CallBack ID = 145, Status = Transmission complete and ACK received(0)
15:35:19.939 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=8, callback=145, payload=08 08 60 0D 01 01 59 05 00 04
15:35:19.939 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=91 00 00 03
15:35:19.940 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=SendData, callback id=145, expected=ApplicationCommandHandler, cancelled=false MISMATCH
15:35:24.911 [ERROR] [ocol.ZWaveController$ZWaveSendThread] - NODE 8: Timeout while sending message. Requeueing - 0 attempts left!
15:35:24.912 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 8: Is sleeping
15:35:24.912 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 8: Message already on the wake-up queue. Removing original.
15:35:24.912 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 8: Putting message SendData in wakeup queue.
15:35:24.912 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
15:35:24.912 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 8: Putting message SendData in wakeup queue.
15:35:53.891 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 04 08 0A 71 05 00 00 00 FF 08 0D 00 00 63
15:35:53.892 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
15:35:53.892 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 10 00 04 04 08 0A 71 05 00 00 00 FF 08 0D 00 00 63
15:35:53.892 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 10 00 04 04 08 0A 71 05 00 00 00 FF 08 0D 00 00 63
15:35:53.892 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=04 08 0A 71 05 00 00 00 FF 08 0D 00 00
15:35:53.892 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 8: Application Command Request (ALIVE:STATIC_VALUES)
15:35:53.892 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 8: Incoming command class ALARM
15:35:53.892 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 8: Received ALARM command V4
15:35:53.892 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 8: Process NOTIFICATION_REPORT V4
15:35:53.892 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 8: NOTIFICATION report - 0 = 0, event=13, status=255
15:35:53.893 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 8: Alarm Type = POWER_MANAGEMENT (0)
15:35:53.893 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmValueEvent
15:35:53.893 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got an event from Z-Wave network: ZWaveAlarmValueEvent
15:35:53.893 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
15:35:53.893 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Message has Ack Pending: Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=8, callback=146, payload=08 08 60 0D 01 01 59 05 00 05
15:35:53.925 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 04 08 03 80 03 64 1A
15:35:53.925 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
15:35:53.925 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 04 04 08 03 80 03 64 1A
15:35:53.925 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 04 04 08 03 80 03 64 1A
15:35:53.926 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=04 08 03 80 03 64
15:35:53.926 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 8: Application Command Request (ALIVE:STATIC_VALUES)
15:35:53.926 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 8: Incoming command class BATTERY
15:35:53.926 [DEBUG] [ommandclass.ZWaveBatteryCommandClass] - NODE 8: Received Battery Request
15:35:53.926 [DEBUG] [ommandclass.ZWaveBatteryCommandClass] - NODE 8: Battery report value = 100
15:35:53.926 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
15:35:53.926 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
15:35:53.926 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got a value event from Z-Wave network, endpoint = 0, command class = BATTERY, value = 100
15:35:53.926 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Message has Ack Pending: Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=8, callback=146, payload=08 08 60 0D 01 01 59 05 00 05

chris · April 9, 2017, 1:59pm

There’s an issue with the database that is preventing this. It will be updated once the builds are working again.

p.s. please format logs using the </> button so that they are readable.

groobie · April 9, 2017, 3:56pm

Hi Chris. Many thanks for your great support. Does it mean I need to upgrade to the latest Snapshot version once builds are working again? If yes, only the binding or the whole OpenHab installation?

chris · April 9, 2017, 4:20pm

Yes - you only need to update the binding to the latest snapshot.

Cheers
Chris

OMR · May 26, 2017, 7:17am

@chris is this device fully supported now, even in development version of Z-Wave binding?

OMR · May 30, 2017, 11:09pm

@chris Got this device today.
It shows up as Unknown even after several wake-ups. No xml file created.
No Manufacturer/Type or Id:

When pressing buttons, debug log show CentralScene action:

2017-05-31 00:56:27.651 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 44: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2017-05-31 00:56:27.651 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 44: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_CENTRAL_SCENE, value = 1.0
2017-05-31 00:56:35.200 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 44: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2017-05-31 00:56:35.200 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 44: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_CENTRAL_SCENE, value = 1.2
2017-05-31 00:56:35.280 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 44: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2017-05-31 00:56:35.280 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 44: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_CENTRAL_SCENE, value = 1.2
2017-05-31 00:56:35.480 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 44: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2017-05-31 00:56:35.480 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 44: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_CENTRAL_SCENE, value = 1.2

I’m on the development binding from 23. April

OMR · May 31, 2017, 8:36pm

After a full night and numerous wake-ups I deleted the item in Habmin, started a new Z-Wave search in Paper UI and held the action button on the remote pressed for 3s.
Viola:

Is it correct that this battery device does Routing?

So yes, the development binding supports this device, but I can not get the Sliding function to work. @chris log says unknown command:

2017-05-31 22:37:32.343 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0C 00 04 00 2C 06 26 04 78 00 02 00 85
2017-05-31 22:37:32.344 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
2017-05-31 22:37:32.344 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage inputMessage: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=44, callback=0, payload=00 2C 06 26 04 78 00 02 00
2017-05-31 22:37:32.344 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lockMessage: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=44, callback=0, payload=00 2C 06 26 04 78 00 02 00
2017-05-31 22:37:32.344 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=44, callback=0, payload=00 2C 06 26 04 78 00 02 00
2017-05-31 22:37:32.344 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2017-05-31 22:32:58.376 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 44: Application Command Request (ALIVE:DONE)
2017-05-31 22:32:58.376 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 44: resetResendCount initComplete=true isDead=false
2017-05-31 22:32:58.376 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 44: Incoming command class COMMAND_CLASS_SWITCH_MULTILEVEL, endpoint 0
2017-05-31 22:32:58.376 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 44: SECURITY not supported
2017-05-31 22:32:58.376 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 44: Received COMMAND_CLASS_SWITCH_MULTILEVEL V0 unknown command 4
2017-05-31 22:32:58.376 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 44: Commands processed 1.
2017-05-31 22:32:58.376 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 44: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@3e3705a9.
2017-05-31 22:32:59.505 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 44: Application Command Request (ALIVE:DONE)
2017-05-31 22:32:59.505 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 44: resetResendCount initComplete=true isDead=false
2017-05-31 22:32:59.505 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 44: Incoming command class COMMAND_CLASS_SWITCH_MULTILEVEL, endpoint 0
2017-05-31 22:32:59.505 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 44: SECURITY not supported
2017-05-31 22:32:59.505 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 44: Received COMMAND_CLASS_SWITCH_MULTILEVEL V0 unknown command 5
2017-05-31 22:32:59.505 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 44: Commands processed 1.
2017-05-31 22:32:59.505 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 44: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@20ff4c17.

chris · June 1, 2017, 6:16am

Yes - most (at least modern) devices will do routing - otherwise it would only work when the device was directly in range of the controller.

I will take a look at this when I get a chance, but I have a number of things on at the moment. It’s strange that it shows V0 - this indicates something probably is wrong somewhere in the initialisation stages.

OMR · June 6, 2017, 7:19pm

Here is the .xml file produced.
https://1drv.ms/u/s!Ak62_W4agNNTiRsfmdxO2pHy9oPq

In paperUI no value for battery level is shown either.

Also, when restarting OH2 I get these errors in the log:

2017-06-05 16:17:19.326 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 44: Node found
2017-06-05 16:17:19.327 [INFO ] [age.SerialApiGetInitDataMessageClass] - ZWave Controller using Controller API
2017-06-05 16:17:19.327 [INFO ] [age.SerialApiGetInitDataMessageClass] - ZWave Controller is Primary Controller
2017-06-05 16:17:19.327 [INFO ] [age.SerialApiGetInitDataMessageClass] - ------------Number of Nodes Found Registered to ZWave Controller------------
2017-06-05 16:17:19.328 [INFO ] [age.SerialApiGetInitDataMessageClass] - # Nodes = 39
2017-06-05 16:17:19.328 [INFO ] [age.SerialApiGetInitDataMessageClass] - ----------------------------------------------------------------------------
2017-06-05 16:17:20.026 [ERROR] [ve.internal.protocol.ZWaveController] - NODE 44: Restore from config: Error deserialising XML file. com.thoughtworks.xstream.converters.ConversionException:  : ParseError at [row,col]:[79,21]
Message: Character reference "&# :  : ParseError at [row,col]:[79,21]
Message: Character reference "&#
---- Debugging information ----
message             :  : ParseError at [row,col]:[79,21]
Message: Character reference "&#
cause-exception     : com.thoughtworks.xstream.io.StreamException
cause-message       :  : ParseError at [row,col]:[79,21]
Message: Character reference "&#
class               : java.lang.String
required-type       : java.lang.String
converter-type      : com.thoughtworks.xstream.converters.SingleValueConverterWrapper
wrapped-converter   : com.thoughtworks.xstream.converters.basic.StringConverter
path                : /node/associationGroups/entry[4]/associationGroup/name
line number         : 79
class[1]            : org.openhab.binding.zwave.internal.protocol.ZWaveAssociationGroup
converter-type[1]   : com.thoughtworks.xstream.converters.reflection.ReflectionConverter
class[2]            : java.util.HashMap
converter-type[2]   : com.thoughtworks.xstream.converters.collections.MapConverter
class[3]            : org.openhab.binding.zwave.internal.protocol.ZWaveNode
version             : 1.4.7
-------------------------------

Regarding Repeater/Beaming, the Aeon tach spec says:

My switch has been mostly inactive since I fully charged it, but when connecting the charger today it sent an update indicating 54%. Are we sure activating Repeater is battery efficient? My 2 other NodOn wall remotes have it turned off:

OMR · June 10, 2017, 9:52am

@chris the firmware version listed in HABmin properties, is that the actual version pulled from the device, or is it from the database? Reason I ask is that HABmin shows firmware version 1.7 and the latest Firmware version is 1.07 that fixed battery drain problem. I experience that. One charge only last 1 week. Should I do a FW update or are we 100% certain v1.07 is already on the device?

chris · June 10, 2017, 10:23am

The version in the database is downloaded from the device from the person who created the database entry. In general, I wouldn’t worry about this as it’s only used if there are differences - i.e. if the manufacturer creates multiple versions that are “externally” different. By this I mean it has different parameters, or different command classes. This happens occasionally, but most of the time changes don’t affect the external interfaces.

In your case, 1.7 will be the same as 1.07 so you’re fine. Version numbering is actually two separate numbers - a major an minor version - separated by the decimal. So, 1.7 is the same as 1.07 or 1.007, but 1.70 is a higher version number (70 being higher than the previous numbers which are all 7). I hope that make sense ;).

OMR · June 10, 2017, 11:13am

Quite, but that means I’m stuck with a device that only keeps the charge for 1 week and I’m already on the FW version that is supposed to fix it

chris · June 10, 2017, 11:43am

Sorry - not sure I can help there. You can always update the firmware to see if it changes, but I’m pretty confident that version 1.7 == 1.07.

OMR · June 24, 2017, 9:34am

I did update the FW, but still a charge only lasts 2 weeks.
Since I had to remove it from the net in order to update it, it received a new node number when included again.
Was node44, became node45.
@chris in these 14 days, no XML file for node 45 has been made, but the one from when it was 44 remains.
Could that have something to do with excess battery usage do you think?
When you tested this device, did you test battery life?

chris · June 24, 2017, 10:02am

Hard to say without seeing the log, but I would think that, yes, it could be a problem. If the initialisation is not complete, then the binding will continue to try and get something from the device, so this is likely to reduce the battery.

No - I’ve not used it ‘live’ in my system - just for testing.

Maybe there’s something different about yours (ie different than mine). Can you get a log of what’s happening so we can see why it’s not completing the initialisation.

OMR · June 24, 2017, 11:12am

Here, some minutes worth with debug on, its NODE 45: Microsoft OneDrive
Numerous wake-ups.
Appreciate it!

chris · June 24, 2017, 12:06pm

The binding did not send anything to the device in this log, so based on this, it shouldn’t be impacting the battery.

We should still try to find out why it’s not completing initialisation - there may still be issues that impact the battery - just not in this log. I’d suggest to get a longer log during startup so I can see where it’s getting stuck…

OMR · June 24, 2017, 12:53pm

Here is one from just before a openhab2 service restart: https://1drv.ms/u/s!Ak62_W4agNNTiR7mm-wIKdKXQmn9

OMR · June 24, 2017, 1:25pm

Just realized that my z-wave network didn’t respond.
Here is a log from a system reboot.
Started to work, but a bit sluggish. Could be because of all the DEBUG logging?

https://1drv.ms/u/s!Ak62_W4agNNTiR9HeTHaU6TXLd28

chris · June 24, 2017, 5:51pm

There’s next to nothing in this log for node 45 - just two packets received and nothing relating to the initialisation from the binding.