Homey Community Forum

Heatit Z-wave app (v2.7.0)

I’ve received the Z-TRM3 last week and will spend time this week to add support for the Z-TRM3 to the Heatit app.

Are the Z-TRM2fx devices added secure or unsecure?

No, unfortunately Homey does not support OTA firmware updates.

@Lennert, can you send me a diagnostics report through the app?

2 Likes

All my Z-TRM2fx devices have been added unsecure and they all seem to work pretty well except that Homey believes that they are unreachable.

Hi @TedTolboom

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:

2020-05-18T19:50:43.834Z Node[13]: Marked as online
2020-05-18T19:50:43.834Z Node[13]: Received application update: 0x18015e55989f6c
2020-05-18T19:50:47.334Z Node[13]: [COMMAND_CLASS_WAKE_UP] [WAKE_UP_NO_MORE_INFORMATION] {“type”:“Buffer”,“data”:}
2020-05-18T19:50:47.334Z Node[13]: sendData to COMMAND_CLASS_WAKE_UP, params 0x08
2020-05-18T19:50:47.334Z Node[13]: [COMMAND_CLASS_SECURITY] [SECURITY_NONCE_GET] {“type”:“Buffer”,“data”:}
2020-05-18T19:50:49.220Z Node[13]: sendData to COMMAND_CLASS_MULTI_CHANNEL_ASSOCIATION, params 0x0402
2020-05-18T19:50:49.220Z Node[13]: [COMMAND_CLASS_SECURITY] [SECURITY_NONCE_GET] {“type”:“Buffer”,“data”:}
2020-05-18T19:50:53.836Z Node[13]: Marked as offline

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?

@TedTolboom Have you already built in the module? :slight_smile:

Yes, working on it and expecting to finalize the Z-TRM3 driver by end of this week.

4 Likes

You are the best. For me it’s OK when he is ready in October :wink: Now it’s 25c. :rofl: Thanks for al the good support.

#Homey4Life

ok thanks, too bad.
Now I sent it to Intuitech. They offer firmware updates for 6€, sounds fair. (https://shop.intuitech.de/smart-home-systeme/881-fibaro-module-firmwareupdate-service.html)
Thanks anyway!

Well, I’ve almost made it… still counting since it is a long and hot weekend.

Version 2.5.0 will provide support for the Z-TRM3

Anyone who would like to support in testing this update?
You can install the update through the following link: https://homey.app/a/no.thermofloor/test/

Once approved and based on positive (as always) feedback, I will release the update to the general app store…

Enjoy testing your heating system in a hot summer :sunglasses:

1 Like

@TedTolboom Thanks a lot. I will try to test it :slight_smile:

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.

You’re welcome to share your feedback here.

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) :

  1. 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?

  1. 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.

  2. 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?

Thanks…

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.

The value is 1.1 from what I can see:

I do see that data like power consumption isn’t updating, as the thermostat is heating but shows idle value.
image