Endpoints should be automatically filled in when I uploaded the XML - this is the main purpose of loading the XML as this information is downloaded directly from the device. You therefore don’t need to worry about editing this.
Sensors don’t “send” an association group. Associations are simply lists of nodes to which the device will send updates when certain things happen. I don’t really understand your point about allocating groups to sensor_temperature - you don’t allocate channels to groups - in fact, you can’t do this… Maybe I’ve misunderstood your point?
I think I have it. It means that if the user associates groups 3, 4 and 5 to the controller, the data will end up in the same channel, meaning that the updates received on the OpenHAB channel will be a mix of internal, air temp and floor temperature sensor. So this is something the user should avoid in order to get sensible results.
It means that it will not be possible to obtain both air temperature and floor temperature at the same time from the same device, but that is then probably impossible to accomplish when the firmware only distuingish these values by which association groups that get them.
If the entry looks fine, I assume it will get into a snapshot in a few days, and I can test it.
I also just updated one of my Heatit thermostats to 1.92 . However, it seems that it does not connect anymore. Do I have to reinclude the device after the update process?
Well, I am having troubles to get any communication with the device at all after the update. So I asked myself if perhaps the update process has performed a hard reset on the device and it lost its Z-Wave network information? That was the reason for my question.
Ok, for that, I don’t know. I guess it’s possible that the firmware update has reset the device, and therefore you will need to re-include it. I have no visibility of that process though so can’t really comment.
I already updated some Aeonlabs devices “over the air” and that works without having to reinclude them very smoothly. But the Heatit devices have been special ever since…
But you haven’t updated the HeatIt device “over the air” have you? I thought it was done using a cable and this is likely to be a different system all-together.
On my first upgrade attempt, I forgot to also update the z-wave firmware, then all communication was lost.
After I followed every step in the upgrade document from Heatit, the node works ok, but I don’t have any sensor reports coming from it (pending the z-wave database update)
(and yes, since I messed it up on first attempt, I can’t answer whether one needs to exclude and reinclude the device)
Yes, I have the cable and did it with the cable (no other option for these devices unfortunately). Compared to the smooth OTA-Update for the Aeon devices the update process for Heatit is real pain in the ass
Thank you very much. The device is recognized correctly with firmware 1.92.
However not all channels are reported to OH.
I receive updates for thermostat_mode, thermostat_setpoint_heating, thermostat_setpoint_heating_econ and config_decimal_param2.
There are unfortunately no updates for the channels sensor_temperature and basic_switch_binary.
I’m not sure what to say - it’s either a device configuration issue if it’s not sending the data, or a binding issue if it is. However, without a log to see what is happening, I’m completely blind as to what it could be.
I have tried the newest snapshots of the 2.4.0 zwave bindings, but the most recent ones do not work on my OpenHAB 2.3. I have one 2.4.0.201809060839 which works on my system, but possibly too early for the changed thermostat settings (it seems), but the later ones I have tried do not work at all.
In habmin all Z-wave devices come up with a question mark, and in the log there are abort messages and alikes. I can provide a debug log if it is interesting, but could it be that there are changes in the z-wave binding that relies on newer OpenHAB features than 2.3.0?
I finally dived in and upgraded to the 2.4.0 snapshot releases, getting the new Z-wave binding with breaking changes. After some initial hiccups, it now seems stable.
For my upgraded Heatit-unit, and the updated z-wave binding, the channel for the relay state in endpoint 1 is working perfectly in reporting the relay state correctly. Very good.
I made some changes to the z-wave database, which probably get in if they are correct and approved:
Renamed the new channels - now the webpage says the channel names are not supported, but from another discussion I found, this might be ok.
Added a channel for the P-setting (power_setting) that should set configuration item 12 to values between 0 and 10.
After studying plots from internal air temperator sensor, I conclude as many others that the unit’s internal software for correcting the air temp sensor for internally generating heating is flawed, and the power-setting is then maybe the way to go for units with no extra temp sensors attached.
FYI, my Z-TRM2 using the internal sensor set to 24degC looked like this the last week, so it looks like they have done something right for the new version: (fw 2.6)
