Then I deleted the thing using habmin, and then rediscovered it, and added it. The new channel “Thermostat type” appeared, and I can confirm that this channel picks up on/off messages from the device.
Important: Group 2 must be associated to ‘OpenHAB controller’.
Sorry, no joy. The channel works in that it picks up offs and ons, but it picks up all the other ‘Basic’ commands being sent from the device, which gives a lot of noise (I have had 50-100 offs and ons on my thermostat during the night hours, none of them real) and renders the channel state useless.
There is only 1 BASIC command. If the device is sending basic command class for different reasons, then it’s not possible to tell them apart. This is why different command classes are normally used and BASIC is normally only used to trigger other devices.
This is not possible in the binding. The binding treats a SET and a REPORT in the same way.
Ok, I guess we have to leave it at that then, I will continue to run zwave in DEBUG mode and pick up ‘Basic Set’ from the logfile.
I think there is a firmware upgrade available (using a specific cable) that supposedly should fix something related to this. It could possibly be the erroneous Basic commands that is being sent from the device that are being removed. If so, the new channel added in the database could just stay there, and it will start working properly for upgraded firmware.
i have the Multireg thermostat and not the HeatIt one, which might explain it. But I’ll look at the data collected in a couple of days and see if they make any sense. I only tried switching (setting heating up/down above/below temperature) a couple of times and confirmed I got correct changes on the channel in the log.
I have now upgraded one of my thermostats to firmware 1.92 (from 1.8).
It seems that the erroneous "Basic Request"s that the old firmware 1.8 sent at random intervals are now gone, the Basic Request’s that I get now in the log are real. Good.
But, currently I do not get any information from the device back into OpenHAB, so the sensor temperature and status switch do not work at all. Maybe something needs to be done in the zwave database following the firmware upgrade? At least there seems to be similar issues reported by other users of other systems (in particular Domoticz).
Changing setpoint from OpenHAB works fine.
I have attached the xml file I got from the device after a fresh inclusion, and parts of the log (grepped on NODE 58).
Z-wave-binding at 2.4.0-snapshot from August 23. OpenHAB running at 2.3.0 release version.
Looking at the XML for the new and the old (and reading other posts in Norwegian) it seems clear that the upgraded firmware reports its data over 5 association groups. “maxGroups” in the new xml is 5 versus 2 in the xml for the 1.8 version.
Will it need a new entry in the Z-wave database for handling this difference in firmware?
It is new for the firmware that all these three temperature sensors are reported, I hope they don’t share the same name so that we can have a channel for each.
Yes - this will need a new database entry as the changes are significant. I will try and create the initial entry later tonight if I can get time and then someone will need to add the associations and parameters etc…
Thanks. I already tried to upload a new XML to the database (entry 247, but with some errors). I will try to fill out details on associations and parameters when ready.
This link is actually up to 1.7. There’s another database entry for 1.8, and now another for 1.92… Before proceeding too far, can you confirm these versions are all different?
Wow, I have always had 1.8 as firmware, and thus have been looking at the wrong entry in the z-wave database all the time(!) I cannot confirm anything between 1.7 and 1.8, but between 1.8 and 1.92 (I have not seen anything in between), there is at least a significant difference. If there is 1.9 out there I would guess it is compatible with 1.8 but not with 1.92.
The ‘changelog’ for 1.92 is available here (in dual language, scroll down) https://www.heatit.com/heating-control/floor-heating-thermostats/heatit-z-wave-thermostat/
and it is an ‘unofficial firmware’, probably explaining why 1.92 is so different from 1.9. The supplier has also confirmed that further updates to 1.92 is unlikely, as there is an upgraded physical device Z-TRM2 available.
I do have 1.7 firmware devices and can confirm that the binding (dev version) works correctly with them. The On/Off changes are reflected in the item bound to the new channel (of course you need to set the association to the controller).
Thank you all very much for this helpful new channel (I just discovered it today because of your discussion here in the forum). I will create some new items now for all my 15 Heatit thermostats
It seems that I spoke too soon…The state of the basic_switch_binary channel is updated every couple of minutes (always changing ON/OFF/ON/OFF) even if there is no change. Since midnight it already changed 250 times (in 8 hours) according to my persistence tables. However this is not true. I am sitting right beside the thermostat and I can hear it clicking when it switches the relay. It did not switch at all in the last 30 minutes but the channel reported more than 15 status changes in this time. So there still seems to be something wrong.
Have you looked at the log? It’s unlikely that the binding is recording activity that is not sent from the device itself, so probably we have this situation where the device is sending many different reports using the BASIC command class that is reported above.
Yes, this was expected, as it is precisely the same behaviour as all firmwares up until 1.92. Fixed in 1.92 it seems.
For pre-1.92 firmware you can do a workaround by having a script analyze your openhab log (with zwave binding in debug mode), see link earlier in the thread.
I have filled out the parameters (copied from 1.8 / id 412) and inputted new association groups according to an educated guess (this is undocumented from the vendor).
I do not fully understand how endpoints should be filled out, and how it would relate to the different sensors (air, external and floor) each sending to their own association group, we can probably only have one of them allocated to the sensor_temperature channel at a time (by forwarding only one association group among 3,4,5 to the controller).
