Temperature changes not sent to thermostats

[JOR200]

I bought Homey Pro in early December and added 4 x Heatit Z-TRM2fx thermostats to it. I installed Homey Heating Scheduler (v1.2.3) and created 2 different plans. I addet my bathroom thermostat to one of the plans and the 3 other thermostats to the other one. I had issues with both plans. Some of the schedules were set on the physical thermostats and some were not. After a while I tried only using the predefined temperatures (Night, Economy, Comfort and Comfort Plus) in my schedules and the temperatures were actually set on my thermostats, at least for Economy and Comfort Plus. For all other temperatures I could see that the virtual thermostat was set to the correct value, but no temperature updates were sent to the physical thermostats. After the Heating Scheduler App was updated to v1.2.4 (late December), everything started working perfectly. No more issues regarding schedules and plans whatever temperatures I had set in my plans. A few days ago I added 3 more Z-TRM2fx thermostats to Homey. I added one of them to a new plan in the Heating Scheduler App and the 2 others were included to the existing plan with the already existing 3 thermostats. Since this my plans including new thermostats are failing the same way as before. The last plan (only the old thermostat) is still working perfectly. It looks like the new thermostats are somehow misbehaving and the old ones are not. Could this be due to some variables not being defined or something else missing for the newly added thermostats?

[mskg]

Some comments:

• The named temperature are just shortcuts for actual values. The thermostats always sends the value. It doesn’t make a difference if you choose a value or enter it manually.
• The temperature you give is adjusted to what your driver reports/supports. E.g. it could only support full degrees, or 1.3 instead of 1.25.
• In 1.2.4, I changed the way how to communicate with Homey internally. As you reported, after some time it just stops working. The reason I (hopefully) deducted (correctly) is, that persistent connections to devices silently stop working (values were always sent, but ignored by Homey). Such, I reestablish them regularly and this (seems to) did the trick.

I can only guess what might go wrong here. Did you ever try to restart the app? Or your Homey? This forces a totally fresh reinitialization of all drivers.

Last guess: Was the device driver updated in the last weeks?

[JOR200]

Hi. Thanks for really quick response and a very nice app. Yes, I believe the Heatit Z-wave App was updated in the last weeks as well, but if I remember correctly, there was no changes in behaviour until the scheduler app was updated.

I find it strange that I only have issues with the plans that includes one or more of the newly added z-wave thermostats.

If I change the virtual thermostat for a failing plan to manually and back to scheduled, the Homey message that temperatues have been set appears in the home screen and the setpoints changes on my thermostats. I also find it strange that my plan for changing temperature to 20.5 at 14.00 works fine and another plan for changing to 18.5 at 14.02 fails (no message on the home screen) and the next plan to change temperature to 21.5 at 14.04 works fine. This is the same behaviour every day. If I remove the newly added device from the 14.02 plan, then that plan works as well. Please advice what to check for or what to do next.

[mskg]

The time is slotted into 5 minute blocks to prevent clock drift problems. If you change (the same thermostat) on 14.02 and 14.04, the change will be aggregated to the setpoint with the highest temperature value at 14.05.

Heating systems are very lazy... changing them in 5 minute cycles is still way too fast :)

[JOR200]

Thanks for the feedback. I totally agree that heating system are lazy. I was not clear about my configurations. The schedules mentioned are in 3 different plans and all my physical thermostats only exists in one plan each. I therefore only try to change temperature one time for each thermostat during this short timeslot. I did some more testing yesterday and found some new information that I have missed earlier on. For those schedules that are failing / skipped, I can see that the virtual thermostat does not get set properly according to the corresponding plan. I’m not sure how the scheduler app works, but I guess it should set the virtual thermostat according to plan. The virtual thermostat will then in turn set the corresponding physical ones, right? I also see that if I have an active plan containing none physical thermostats, the virtual one is not set according to plan. I have no issues setting the physical thermostats by controlling the virtual one manually. All the assigned physical ones always respond to what I set the in the virtual one. One of my plans controls 3 physical thermostats in 3 different rooms. If a schedule fails in that plan, all 3 thermostats are not set. With other words: All thermostats are set correctly or all fails. It’s never just one of them that fails. I have also seen a repeated issue where one of my thermostats changes temperature at 23:00 even if the schedule in the corresponding plan is set for 23:04. I only have a schedule at 23:00 defined in one other plan. That plan controls another thermostat and seems to work correctly most of the time. Could it be an issue where there is a mixup regarding which thermostats belongs to whish plan / virtual thermostat? Does this info give any clue of what goes wrong?

[JOR200]

Hi. I can see that Homey firmware release 3.2.1 (experimental) solves an issue where zones might become recursive. Can this be the reason for my strange behavior? Have you heard anything from Athom about release date to the public? Rgds.

[JOR200]

Homey firmware release 3.2.1 did not change anything. My schedules still have issues. I also have schedules that do not yet have any devices attached. They all are set to disabled, but I wonder if those schedules containing no devices could somehow screw things up? Rgds.

[JOR200]

It looks like this is the same issue as the closed #114. This still does not work.

[PaulSchryve]

I have the same problem. Every Morning, 2 of my vthermo do not receive the temperature changes. 4 other vthermo receive them correctly. I have created a flow, that control if the change is done, and if not it forces an 'Apply all active heating plans' => the scheduler then works correctly. my config : Homey pro 3.2.1 / French user Tell me if you need more info to debug this.

[JOR200]

Is it possible that this issue can be related to the Homey hardware? My Homey is Homey Pro (Early 2019) / Norwegian user.

I also tested with English language setup and even Dutch. Same behaviour with the different language configs.

[JOR200]

I also have a Fibaro wallplug controlled by vThermo. Sometimes Homey shows this wallplug as turned on even if it is not. I can turn it off and on again in the device pane in Homey, and the wallplug turns on as it should. I suspect this behaviour may be the root cause for why setpoint are not changed for some thermostats.

[mskg]

This is not a perfect system. It consists of Homey itself, the device drives, the devices, and this App. All parts can fail independently.

As you stated: The App is doing the same job every time, but only after a second push the temperature is sent. This is most likely the Homey->Driver part and not App->Homey.

To map it to your switch scenario: Your toggled state is the target temperature for me. Homey tells me it’s set, but it isn’t.

[JOR200]

Looks like there is a bug in the Heatit Z-wave driver wich controles most of my thermostats. The devices are very often seen as unreachable by Homey even if they are not.

I'm not sure how Homey is handeling this situation, but maybe it just skips sending commands to devices that is flagged as unreachable in the z-wave network? I guess the z-wave routes between Homey and the thermostats will not be the best ones if devices flagged as unreachable are skipped.

I have opened an issue for this for Heatit Z-wave driver on Github as well.

[JOR200]

Do you have any ideas about how Homey will handle z-wave devices that are flagged as unreachable?

[mskg]

I already do a lot to workaround the problems.

When applying a temperature (TemperaturePolicies)

1. Check if the temperature is not set already (configurable), because some drivers prevent working in this case
2. Try to set the value with incremental backoff, 5 times

https://github.com/mskg/homey-heating/blob/812471b5fc444358e3f85494ea8492112df354cc/src/app/services/heating-manager/DefaultTemperaturePolicy.ts#L54

When setting the temperature value, I ensure that the temperature is in range of every single device. Also, I never use a cached references to a device, I always send the command directly to Homey itself. https://github.com/mskg/homey-heating/blob/812471b5fc444358e3f85494ea8492112df354cc/src/app/services/device-manager/DeviceManagerService.ts#L124

The main concern: Homey does not report that the command failed, but rather reports the temperature as being correctly set (the capability values changes). This leaves no way for me to detect if the setting really worked.

[mskg]

Do you have any ideas about how Homey will handle z-wave devices that are flagged as unreachable?

Normally it should result in a timeout (30s). But Homey does not always report that the command failed, but rather reports the temperature as being correctly set (the capability values changes).

[JOR200]

Hi. I have not yet given up the Homey Heating Scheduler since this is app has a really great functionality and an eazy to use user interface. I have found a workaround for the issues regarding my virtual thermostats not changing according to assigned plans, but it would be nice if the scheduler could do this correctly without workarounds. It looks like Homey Heating Scheduler is losing track of witch plans are active or not. Using the Homey Heating Scheduler flow card “Apply all active heating plans” does not apply all the active plans correctly, but using the flow card “Apply heating plan” for a given virtual thermostat (that is not in sync) do actually apply the plan correctly. The virtual thermostat is set correctly and then the physical thermostats also change. The workaround is to trigger a flow every 15 minutes that run the flow card “Apply heating plan” for each and all of my virtual thermostats in order. This works every time and forces the virtual thermostats to be set correctly within 15 minutes after they should have been changed by the scheduler app. Only the plans that are actually active according to the user interface are applied. This is exactly how it should work. I wonder why the heating scheduler app does not change all the virtual thermostats by schedule. Does it somehow not see all the plans as active? I really hope you have the time to look into this.

Rgds.