Got it - I deleted the thing and readded it, and saw the new channel called ‘Thermostat state’. But it is linked to switch_binary, which apparently is the functionality for turning the thermostat entirely off, or on (which also can be accomplished with the channel ‘Thermostat Mode’).
It is the message sent to association group 2 I would like to capture in a channel, which tells me whether there is power being drawn at the moment. Maybe it is difficult to get into a channel?
Did you ever get a hold of the the message sent to ass group 2?
No, it does not work yet (I am still using a Python parser on the z-wave DEBUG statements to capture the state)
To be clear, the binding doesn’t know anything about association groups - only the commands it receives. When the device sends a command, there is no way to know why it sent the command - eg which association group might have caused it. Association groups are what the device uses to provide functionality only…
So, with that said, we did add a channel called “Thermostat State” a few months back - if this doesn’t work, then I would need to see logs to see what the binding is actually sending as this channel was linked to the basic command class as requested in the original request.
Looking at the database, and the exported XML, this is definately not the case -:
It’s clearly linked to the basic class.
I am not able to state how it should be accomplished in the Z-wave database (or if it is even possible). But my log-file-parser looks for DEBUG statements like this:
2018-03-17 00:00:47.060 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 5: Basic Set sent to the controller will be processed as Basic Report
2018-03-17 00:00:47.067 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 5: Basic report, value = 0x00
where the “Basic Set” is the crucial point, and the value 0x00 is then picked up and interpreted as the thermostat being turned off.
In addition I get a lot of events like this:
2018-03-17 08:24:38.061 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 23: Incoming command class BASIC
2018-03-17 08:24:38.064 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 23: Received Basic Request
2018-03-17 08:24:38.067 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 23: Basic report, value = 0xFF
which I should ignore, the 0xFF here does not mean that the thermostat just turned on.
Python-code doing this parsing is available at https://pastebin.com/yaTtsS1R
From this it sounds like the thermostat reports when it is turned OFF (stops heating), but not when it is turned ON (heating starts)?
I am interested in this because I want to know the energy consumption on my non-energy-reporting thermostats. One solution might be to set up a recurring check that uses what we know (temperature, setpoint, hysteris), something along the lines of (pseudo code):
var powerConsumptionDiningRoom = 0.60 * 50 // watts * square meters for floor heating
var isOn = (heating_setpoint-temperature+hysteresis)>0
var currentConsumption = isOn*powerConsumptionDiningRoom
But I’m not sure if I want to have a lot of recurring rules running very often…
The thermostat is reporting both ON and OFF correctly (with Basic Set), the log excerpt is just an example.
In my case half of my thermostats do not have a floor sensor, and then there is no readout of measured temperature from the thermostat (it measures air internally, but refuses to send it over Z-wave as it is affected by internal heating inside the unit), and such a recurring check would not work at all. For the others, the check could work, but most likely with quite a bit of uncertainty.
Hi Berland,
Did you also delete the XML-file after deleting the Thing?
I upgraded to the latest snapshot and deleted and readded the termostat, but cannot find a new channel.
As you can see, the channel is configured to use the BASIC command class, so it should work as far as I can see. Please provide a log showing this data being received so I can see what is happening.
I upgraded from 2.3 release to openHAB 2.4.0 Build #1326 on openhabianpi using the “upgrade to latest snapshot tool” in the console.
I then deleted the thermostat and added it again and added the stick to association group 2. But I don’t see a new channel.
Does the version of the binding follow the version of the openHAB version, or do I have to upgrade the z-wave binding too?
Yes, if you are using the snapshot version of OH (ie 2.4) then when you install the binding, it will use the latest snapshot.
And if it is already installed, I will have to delete and then add the z-wave binding? Will I then have to re-add all z-wave things?
I think if you are doing a complete upgrade, then it should also be updated, but you might need to clear the cache to ensure that old bindings are removed.
No - they will still be there. However, if the thing definition changes, then you will need to delete the thing, and add it back - otherwise the channels will be the same.
Alright, deleting cache, deleting thing, adding thing didn’t work. But that’s probably because it is a TF016 Multireg thermostat and not a HeatIt one… 
So that’s all on me. However, I believe it is (pretty much) the same thermostat as the heatit-one. Which might mean that the Multireg-thing can be ugraded in the same way as the HeatIt one. Is that correct?
We can add the channel, if the device sends the same data - the question is if it does this or not? Have you observed this in the debug logs?
It looks like the behavior is the same (and I do believe the two thermostats are the same except for the name).
Log when I set to lower heating setpoint so heating stopped:
2018-08-12 15:17:20.154 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 8: Application Command Request (ALIVE:DONE)
2018-08-12 15:17:20.158 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 8: Starting initialisation from DONE
2018-08-12 15:17:20.166 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 8: Incoming command class BASIC
2018-08-12 15:17:20.170 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 8: Received Basic Request
2018-08-12 15:17:20.173 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 8: Basic Set sent to the controller will be processed as Basic Report
2018-08-12 15:17:20.177 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 8: Basic report, value = 0x00
2018-08-12 15:17:20.184 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2018-08-12 15:17:20.188 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got a value event from Z-Wave network, endpoint = 0, command class = BASIC, value = 0
And on:
2018-08-12 15:19:13.510 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 08 03 20 01 FF 27
2018-08-12 15:19:13.514 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2018-08-12 15:19:13.516 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 04 00 08 03 20 01 FF 27
2018-08-12 15:19:13.518 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 04 00 08 03 20 01 FF 27
2018-08-12 15:19:13.521 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 08 03 20 01 FF
2018-08-12 15:19:13.523 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 8: Application Command Request (ALIVE:DONE)
2018-08-12 15:19:13.524 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 8: Starting initialisation from DONE
2018-08-12 15:19:13.526 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@1a27a58 already registered
2018-08-12 15:19:13.529 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 8: Incoming command class BASIC
2018-08-12 15:19:13.530 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 8: Received Basic Request
2018-08-12 15:19:13.532 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 8: Basic Set sent to the controller will be processed as Basic Report
2018-08-12 15:19:13.534 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 8: Basic report, value = 0xFF
2018-08-12 15:19:13.536 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2018-08-12 15:19:13.538 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2018-08-12 15:19:13.540 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got a value event from Z-Wave network, endpoint = 0, command class = BASIC, value = 255
2018-08-12 15:19:13.542 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 28: Transaction not completed: node address inconsistent. lastSent=28, incoming=255
There are two versions of this device - my guess is you have the one that has not been configured with this channel? Can you advise the version please?
Multireg 16A 3600W
I want to confirm the software version running in your device so we can be sure that this is the problem.