Error connecting Living Connect thermostat

kvaster · January 10, 2017, 8:54am

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: http://pastebin.com/5DWqafig )

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(BaseThingHandler.java:388)[105:org.eclipse.smarthome.core.thing:0.9.0.201701090931]
at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.updateStatus(BaseThingHandler.java:415)[105:org.eclipse.smarthome.core.thing:0.9.0.201701090931]
at org.openhab.binding.zwave.handler.ZWaveThingHandler.ZWaveIncomingEvent(ZWaveThingHandler.java:1178)[182:org.openhab.binding.zwave:2.0.0.201701091302]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.notifyEventListeners(ZWaveController.java:567)[182:org.openhab.binding.zwave:2.0.0.201701091302]
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.advanceNodeStage(ZWaveNodeInitStageAdvancer.java:1117)[182:org.openhab.binding.zwave:2.0.0.201701091302]
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.handleNodeQueue(ZWaveNodeInitStageAdvancer.java:230)[182:org.openhab.binding.zwave:2.0.0.201701091302]
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.ZWaveIncomingEvent(ZWaveNodeInitStageAdvancer.java:1306)[182:org.openhab.binding.zwave:2.0.0.201701091302]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.notifyEventListeners(ZWaveController.java:567)[182:org.openhab.binding.zwave:2.0.0.201701091302]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingResponseMessage(ZWaveController.java:293)[182:org.openhab.binding.zwave:2.0.0.201701091302]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingMessage(ZWaveController.java:217)[182:org.openhab.binding.zwave:2.0.0.201701091302]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.access$7(ZWaveController.java:208)[182:org.openhab.binding.zwave:2.0.0.201701091302]
at org.openhab.binding.zwave.internal.protocol.ZWaveController$ZWaveInputThread.run(ZWaveController.java:1324)[182:org.openhab.binding.zwave:2.0.0.201701091302]
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!

jaydee73 · January 10, 2017, 9:15am

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.

kvaster · January 10, 2017, 11:55am

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.

jaydee73 · January 10, 2017, 12:46pm

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…

kvaster · January 10, 2017, 1:14pm

Sorry. I will be more concrete.

This is xml for node1 (controller): http://pastebin.com/N8sLrKk3
This is xml for node2 (living connect): http://pastebin.com/T5WMKmAw

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.

jaydee73 · January 10, 2017, 2:01pm

Looks all good (except the exception ). 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.

kvaster · January 10, 2017, 2:30pm

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

<node>
  <deviceClass>
    <basicDeviceClass>ROUTING_SLAVE</basicDeviceClass>
    <genericDeviceClass>THERMOSTAT</genericDeviceClass>
    <specificDeviceClass>SETPOINT_THERMOSTAT</specificDeviceClass>
  </deviceClass>
  <homeId>0xcc2c1cdd</homeId>
  <nodeId>4</nodeId>
  <version>4</version>
  <manufacturer>0x2</manufacturer>
  <deviceId>0x4</deviceId>
  <deviceType>0x5</deviceType>
  <listening>false</listening>
  <frequentlyListening>false</frequentlyListening>
  <routing>true</routing>
  <security>false</security>
  <beaming>true</beaming>
  <maxBaudRate>40000</maxBaudRate>
  <nodeInformationFrame>
    <commandClass>BATTERY</commandClass>
    <commandClass>CLIMATE_CONTROL_SCHEDULE</commandClass>
    <commandClass>CLOCK</commandClass>
    <commandClass>MANUFACTURER_SPECIFIC</commandClass>
    <commandClass>MULTI_CMD</commandClass>
    <commandClass>PROTECTION</commandClass>
    <commandClass>THERMOSTAT_SETPOINT</commandClass>
    <commandClass>VERSION</commandClass>
    <commandClass>WAKE_UP</commandClass>
  </nodeInformationFrame>

And one which is not working:

<node>
  <deviceClass>
    <basicDeviceClass>ROUTING_SLAVE</basicDeviceClass>
    <genericDeviceClass>THERMOSTAT</genericDeviceClass>
    <specificDeviceClass>SETPOINT_THERMOSTAT</specificDeviceClass>
  </deviceClass>
  <homeId>0xf433600f</homeId>
  <nodeId>2</nodeId>
  <version>2</version>
  <manufacturer>0x2</manufacturer>
  <deviceId>0x2</deviceId>
  <deviceType>0x8005</deviceType>
  <listening>false</listening>
  <frequentlyListening>false</frequentlyListening>
  <routing>true</routing>
  <security>false</security>
  <beaming>false</beaming>
  <maxBaudRate>40000</maxBaudRate>
  <nodeInformationFrame>
    <commandClass>MANUFACTURER_PROPRIETARY</commandClass>
    <commandClass>MANUFACTURER_SPECIFIC</commandClass>
  </nodeInformationFrame>
  <supportedCommandClasses>

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

kvaster · January 10, 2017, 2:39pm

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.

jaydee73 · January 10, 2017, 2:47pm

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.

kvaster · January 10, 2017, 2:56pm

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.

kvaster · January 11, 2017, 12:20pm

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

jaydee73 · January 11, 2017, 2:50pm

Maybe the device itself has a malfunction?

kvaster · January 11, 2017, 6:16pm

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…

kvaster · January 12, 2017, 7:40am

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!

jaydee73 · January 12, 2017, 8:06am

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

Thanks!

kvaster · January 12, 2017, 8:16am

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.

HomeBoss · January 12, 2017, 8:58pm

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

jaydee73 · January 12, 2017, 9:08pm

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.

kvaster · January 13, 2017, 8:49am

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.