I’m happy to hear that we might have support for the new Z-TRM3 soon.
In the meantime I’m having issues creating a direct association between a Z-Push 8 and a fibaro dimmer 2. During my troubleshooting steps I came across your FAQ from aug’18 regarding the issue.
I followed the steps as described and used the log on https://developer.athom.com/tools/zwave, yet nothing usually happens. I see the clicks registering in the log, but the light does not react. However once it worked randomly while doing the steps. It still works to this day.
My Z-push 8 is ID 13 and my dimmer 2 is ID 2. Here is the information I see when I press the top ‘I’ and ‘O’ for 3 seconds:
Node: Marked as online
Node: Received application update: 0x18015e55989f6c
I’m not skilled enough to debug this just by looking at it, but I noticed that I get COMMAND_CLASS_MULTI_CHANNEL_ASSOCIATION, params 0x0402
while you got COMMAND_CLASS_MULTI_CHANNEL_ASSOCIATION, params 0x0102dd
in your example. Is there something wrong here?
Thanks for great work. I’m currently testing it on one of my Z-TRM3. How would you like feedback about issues? Here, or directly? It’s my first Heatit thermostat, so some of the issues might be general and not specific to the latest version.
Disclaimer: I’ve only connected to Z-TRM3 (two of them now) for less than an hour, and these are the first Heatit thermostats I add to Homey, so there might be beginners-mistakes here.
Some observations (I have already installed the 2.5.0 version) :
I start to add the unit from Homey app in iOS. I do Devices -> + -> Heatit Z-wave -> Z-TRM3 -> Install. The help screen shown is the one explaining how to remove the thermostat from Homey, even if this is the first time I install the thermostat. I select “Con” on the thermostat. The help screen changes to the one explaining how to include the thermostat to Homey, and the “1” step is now a green checkmark. Nothing further happens, so I select “Con” again on the thermostat, and now the unit is added.
Maybe the procedure is correct, although confusing? Maybe the first step is always to remove the thermostat and the second step is to include it, and it is normal that I have to select “Con” two times?
The values listed under “Advanced” in the app are not corresponding to the ones on the physical thermostat. The thermostat has earlier been manually configured to use F mode, but in the app the “Sensor mode” is reported as “A-mode”. The floor min and max temperatures reported in the app are also not corresponding to the ones set on the thermostat, and other values are also off.
For one of the thermostats, I changed “Temperature display” in the app to “Display measured temperature”, and “Displayed temperature” to “Floor sensor”. The value displayed on the thermostat is now showing a different value than the set temperature (as expected), but the value does not match the value shown when pressing the middle button on the thermostat (the normal way to see the sensor value). An example: The set temperature for the thermostat is 18.0, and it’s set to F mode, both on thermostat and in app. The idle value shown on the thermostat is 20.0. The value shown on the thermostat when pressing the middle button is 20.3, and the “floor temperature” reported in the app is 20.2.
@Naitsirk please see my response on your questions:
This is indeed a procedure that Homey uses for all Z-wave devices; first force a removal, than include the device. So yes, you will need to activate CON twice
The values within the app are based on the default settings as described in the manual (with some minor changes); aka the state when the thermostat is taken out of the box.
During inclusion, the settings are not interviewed since in most common cases, the settings will be factory default during inclusion; default approach for all Z-wave devices within Homey.
Interviewing the settings is a quite communication intensive action… if more people experience the same ‘issue’, I might add the logic to the device driver to interview these settings (will require quite some testing).
Best alternative option, is to set the settings within the Homey UI directly after inclusion; so both devices are in sync. And keep using the, more accessible, Homey UI for future updates
“Temperature display” setting is controlling which temperature is shown on the thermostat device itself. So selecting “Display measured temperature” it will show the measured temperature by default (rounded in 0.5 degrees), where pressing the middle button shows the actual measured temperature (there might be a difference here) “Displayed temperature” is controlling which of the temperatures is used to display in the Thermostat UI of Homey (to compared to the setpoint); which is based on the reported (actual = not rounded) temperature (updated based on the reporting interval and thresholds)
I hope this clarifies your questions; if not please let me know.
Thanks for quick replay. I suspected #1 was according to expected behaviour, although not super user friendly. One possible issue with #2 is the max temp for the floor sensor. Heatit sets it to 27 to protect wooden floors when you switch to F mode, as it was on my thermostat, while the app reported it as 40. If people set the sensor mode on the thermostat before they connect it to Homey, then maybe the max value will be incorrect and too high? For #3, the “rounding to 0.5 degree” and update intervals explains the differences I see in my numbers. Thanks.
Please note, that the values shown assume that they have not been changed; the settings are not interviewed and all except the meter reporting interval are not changed during inclusion. So there is no actual risk for your wooden floor, only the displayed value doesn’t match the actual setting of the thermostat.
Roger that. One possible improvement, if there is support in the Homey framework, is to gray out or somehow visually show which values haven’t been changed after the inclusion (and therefore possibly not in sync with the device)? Not a big thing, now that I understand the bigger picture.
Hi. My Homey Pro still randomly flags my Z-TRM2fx devices as Unreachable in my Z-wave network (now using version 2.5.0). I’m using Homey Heating Scheduler to control those devices. This app does not communicate directly to the devices, but tells Homey to i.e change the setpoint values. Looks like Homey skips sending commands to the devices it believes are Unreachable. Can something be done with the driver to let Homey know that all the devices are in fact reachable?
One thing I notice now that the thermostats have been connected to Homey for a few hours: The mode is set to F (floor). On the overview page the Floor Temperature value is updated, but Internal Temperature and External Temperature values are stale since 7 hours when the unit was added to Homey. Are maybe only sensors associated with the selected mode updated? I can understand if that is the case, although it would be useful to be able to monitor the Internal Temperature to see how it behaves (as the one in TRM2 had issues).
Did you change Homey’s ID (1.1) to association group 1 to 1?
The multiChannel format (1.1) ensures that all data is multiChannel encapsulated which the driver is expecting. In addition, it changes the reporting behavior of the thermostat. Without enforcing multiChannel communication, the thermostat will only report the data corresponding to the mode (as described), whereas with multiChannel, it will send the data of all sensors.
I did notice that the comment text of Group 1 still refers to 1 instead of 1.1; will correct that.