Error connecting Living Connect thermostat

Hello. I’m having trouble with connecting living connect thermostat. Using yesterday’s snapshot.
I can add thermostat, but I can’t see wakeup options after, cause of error below. (full debug log: )

2017-01-09 20:58:26.997 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘zwave:device:zwave:node2’ to inbox.
2017-01-09 20:58:35.921 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Initialising Thing Node…
2017-01-09 20:58:46.350 [WARN ] [tocol.commandclass.ZWaveCommandClass] - NODE 2: Unknown command class 0x91
2017-01-09 20:58:46.386 [WARN ] [tocol.commandclass.ZWaveCommandClass] - NODE 2: Unknown command class 0x91
2017-01-09 20:58:46.435 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Initialising Thing Node…
2017-01-09 20:58:46.445 [ERROR] [ve.internal.protocol.ZWaveController] - Exception during ZWave thread: Input 2. {}
java.lang.IllegalStateException: Could not update status, because callback is missing
at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.updateStatus([105:org.eclipse.smarthome.core.thing:]
at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.updateStatus([105:org.eclipse.smarthome.core.thing:]
at org.openhab.binding.zwave.handler.ZWaveThingHandler.ZWaveIncomingEvent([182:org.openhab.binding.zwave:]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.notifyEventListeners([182:org.openhab.binding.zwave:]
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.advanceNodeStage([182:org.openhab.binding.zwave:]
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.handleNodeQueue([182:org.openhab.binding.zwave:]
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.ZWaveIncomingEvent([182:org.openhab.binding.zwave:]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.notifyEventListeners([182:org.openhab.binding.zwave:]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingResponseMessage([182:org.openhab.binding.zwave:]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingMessage([182:org.openhab.binding.zwave:]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.access$7([182:org.openhab.binding.zwave:]
at org.openhab.binding.zwave.internal.protocol.ZWaveController$[182:org.openhab.binding.zwave:]
2017-01-09 20:58:46.450 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Initialising Thing Node…
2017-01-09 20:58:51.430 [ERROR] [ocol.ZWaveController$ZWaveSendThread] - NODE 255: Timeout while sending message. Requeueing - 2 attempts left!

Is this device already fully initialized? The options are only available if the initialization was fully finished. You can check first if the xml file for this node was already created. Otherwise you should manually wakeup the device some more times.

I can see channels, but can’t see wakeup. I think this is cause device can’t be fully initialized due to exception in main zwave thread.

An exception of course seems to be an error, but this doesn’t mean that the initialization process was finally aborted.

Again my questions: Was there an XML file created for this node? And have you made manual wakeups?

It’s hard to help when I ask questions and they stay unanswered in the reply…

Sorry. I will be more concrete.

This is xml for node1 (controller):
This is xml for node2 (living connect):

It looks like node2 is not really fully initialized.

All steps:

  • Unpack openhab and launch
  • Install zwave binding and habmin
  • In paper ui add zwave stick (aeon labs) with all default params (just setted up port /dev/ttyACM0)
  • In habmin started discovery.
  • Pressed central (wakeup) button on Thermostat. And node2 appeared in list.
  • Added node2, but it was shown as ‘unknown node’
  • I’ve pressed wakeup button on thermostat once more. And ‘unknown node’ transformed to ‘LC-13 Living Connect thermostat’. And I was able to see exception in log right in that moment.

I’ve one more openhab-2 install (late november snapshot) in other place with such thermostat and node’s xml really differs.

Looks all good (except the exception :slight_smile: ). If the xml is there and the node changed from unknown to LC-13, I think it is fully initialized.

Can you post a screenshot from your available configuration options of the device in habmin? So I can see if that differs to my options (I have several working LC-13 here).

This is not so uncommon. The binding is in active development and there could have been changes from late november to now which result in other xml files.

It seems that my messages were treated like a spam by other members unfortunatelly…
My apologies…

Here goes part of ‘working’ Living Connect node xml


And one which is not working:


It really looks like device was not properly initialized :frowning:
Thermostats are of the same hardware and firmware.

Seems I’m wrong about hardware equality… One thermostat is 0005:0004 (working one) and second one is 8005:0002, but both of them are in database.

Yes, you are right. This xml doesn’t seem to be complete.

I would suggest: delete the xml file (only the node 2 file, not the controller node 1 file), delete the node 2 thing in habmin. Then re-add the device again (no new inclusion, only re-add it). Do 2-3 manual wakeups, until the xml is created and until the thing is properly discovered in habmin. After that, have a look at the xml file and at the configuration options in habmin to see, if everything has worked out. Furthermore, have a look at the log during this process to see, if the exception comes up again.

If this doesn’t help, we have to ask Chris (the binding developer) if he can help. But for sure he want’s a DEBUG log then.

Thanks. I will do that and will get back. Hopefully this thread will be helpfull for others.

Also I’ve tried to do hard reset of zwave stick before the experiment, but according to logs there may be chance that stick was not resetted. May be this is also the case. I will try to redo all from the beginning once more.

p.s.: I’ve already ‘added’ full debug log in first post.

I’ve analyzed debug log myself and found strange stuff. It seems that thermostat does not report any valid command class except MANUFACTURER_PROPRIETARY…

Maybe the device itself has a malfunction?

I’m going to patch .xml for LC-13 and to force all missing command classes. Maybe it’s a firmware bug and forced command classes will work…

Seems that this is not firmware bug. It’s danfoss who created SW3.02 which is not compatible with usual z-wave commands. Thanks for help!

Can you please post the Danfoss part number of your device? Should be 014Gxxxxxx.


It’s my brother’s thermostats. I will post full number in a few days. For now I was able to see only SW3.02 label on the thermostat.

According to this Danfoss software versions SW 3.02 is not compatible with Z-wave (bottom of page five).

Yes. That’s what I had in mind when I asked him about the part number. There are different versions (hw and sw) of the Thermostat and some of them don’t speak zwave. Now we know for sure. Thanks.

Sorry for misunderstanding at the beginning.
Generally they ‘speak’ zwave (radio is zwave compatible), but with custom binary protocol. And this makes them unusable for usual software.