Battery node not initialised after reboot

Yes - rename to XML or something. That will still only allow short files - the other alternative is to use dropbox or something.

Anyway, this image is probably ok - I can see what is be going on. It will need a binding update to resolve this as it seems to be a new feature of these devices.

ok sounds good to me! I understand that you don’t need my log anymore?
Please let me know if I can do something!
And apart from that let me say thank you for the great job you do!!!

In hind site, I’d quite like to see the log :wink: . Can you email it to me (chris -at-


logs are on the way to you


Is there an XML file being created for this device? It would be in the {userdata}/zwave folder.

If not, can you click on the button a few times (say 4 or 5 times, each 5 or 10 seconds apart) so that I can see the device initialisation. I suspect that something else is going wrong somewhere…

yes there are XML files ceated. I sent all per mail (XML configs and log after click button on node 15)

It’s strange…

Your log shows the following on startup -:

2017-09-16 19:35:53.749 [INFO ] [age.SerialApiGetInitDataMessageClass] - ------------Number of Nodes Found Registered to ZWave Controller------------
2017-09-16 19:35:53.750 [INFO ] [age.SerialApiGetInitDataMessageClass] - # Nodes = 9
2017-09-16 19:35:53.751 [INFO ] [age.SerialApiGetInitDataMessageClass] - ----------------------------------------------------------------------------
2017-09-16 19:35:53.771 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 1: Init node thread start
2017-09-16 19:35:53.781 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 2: Init node thread start
2017-09-16 19:35:53.784 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 3: Init node thread start
2017-09-16 19:35:53.790 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 5: Init node thread start
2017-09-16 19:35:53.797 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 6: Init node thread start
2017-09-16 19:35:53.802 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 8: Init node thread start
2017-09-16 19:35:53.803 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 13: Init node thread start
2017-09-16 19:35:53.817 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 18: Init node thread start
2017-09-16 19:35:53.858 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 17: Init node thread start

The binding says that the stick knows about 9 nodes, and then the log lists these nodes - none of which are your Danfoss devices. This is the root cause of the issue.

The only time I’ve seen this sort of thing is if the devices aren’t actually included - of they were removed and the devices were not excluded so they continue to send data. I would try to exclude one device and add it back in to see if it is properly included.

excluding node 14:

2017-09-16 21:12:46.826 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Controller status changed to ONLINE.
2017-09-16 21:12:46.829 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Controller is ONLINE. Starting device initialisation.
2017-09-16 21:12:50.362 [DEBUG] [serialmessage.RemoveNodeMessageClass] - NODE 14: Removing slave.
2017-09-16 21:12:50.433 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 14: Excluding node.
2017-09-16 21:12:50.436 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 14: Excluding node that doesn't exist.

but it’s still present under things in Habmin and PaperUI?

Yes - you need to delete the thing yourself. In the past the binding was able to do this, but it’s now lot allowed :frowning: .

I delete it… start including and now it is in the inbox with same name and node id.

The log you sent still doesn’t show the device in the controllers list of known devices - just the same 9 nodes.

I would completely reset the device if possible - just to make sure it’s reset and excluded. It should come up with a new node ID - 19 or 20 maybe…

I exlude node 15, remove it from things and try a factory reset by ‘remove the battery cover and take out one battery.
Press and hold for approx. 5 seconds, while reinserting the battery. living connect® Z is now factory reset and in mounting mode.’

Now its included as node 20 and shown as “online” but no sensor values are transmitted at the moment.

Looking at the log, it might need waking up - press the button a couple of times (say) 10 seconds apart and hopefully it will complete initialisation. Then I’d try to restart to see if it works - I think it will as it’s showing up in the nodes list from the controller now.

I’ve been testing since my last post. Excluding, removing, factory reset, including after that only one of the three working correct now. The other two are still offline after restart. They have new ids but are not listed under ‘Number of Nodes Found Registered to ZWave Controller’ in the log and following logentry ‘NODE 27: Not initialized yet, ignoring message.’.

After many retries I give up, install z-way and factory reset the controller, exclude and include all devices again.

  • node 3 works fine,

  • meanwhile node 2 works fine too

  • node 4 is offline. It seems node 4 is not initialized properly:


I push the button several times is there another possibility to force the initialisation?

You should open a new thread and tag it with z-way instead of zwave to get any attention …

I only installed z-way to factory reset the controller, because I havnt’t see any possibilty to do this within Habmin!
After excluding, including, reinitilize, wakeup the last device several times all devices work as aspected since yesterday

There is an option under the Controller menu to do this (you need to enable advanced mode).

As mentioned previously, it seems that these devices aren’t properly included for some reason.

I was not sure what soft-/hard reset are doing…

of course you were right :grinning:
As mentioned, excluding and including didn’t help only when I factory reset the contoller it works

Soft reset is like removing the stick and adding it back in, a hard reset is a total reset of the stick (what you are calling a factory reset).