Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HomeKit temperature adjustments apply until schedule, ignoring active override #149

Open
PuzzledUser opened this issue Mar 22, 2023 · 6 comments

Comments

@PuzzledUser
Copy link

PuzzledUser commented Mar 22, 2023

My system was set (EDIT: had an override active) to 19°C until 20:30. At 16:01, I used Apple Watch to increase the temperature to 20°C. However, the clever algorithm changed the validity time until the next scheduled target change (which is 17°C @ 18:00).

Why change the until figure when setting the temperature? When using the Honeywell round thermostat to adjust the temperature it applies to any existing schedule or override.

Is it not possible just to send temp info to the server and leave the existing until figure unchanged? If I hadn't spotted what was going on I'd have found it chilly later.

@SeaneyC
Copy link

SeaneyC commented Mar 22, 2023 via email

@PuzzledUser
Copy link
Author

Yes, that's right @SeaneyC. To my mind, desired behaviour is that homebridge-evohome should respect your override time, not set a fresh override until the next scheduled target change time.

If you re-test in your scenario and use home bridge-evohome to change to 16°. You will find it sets that temperature until the next scheduled target change, not until your override time of 5pm.

The cure would be to not set a new override time, just set the desired target temperature.

@PuzzledUser
Copy link
Author

PuzzledUser commented Mar 22, 2023

I just tried hacking line 820:

//            .setHeatSetpoint(that.device.zoneID, value, nextScheduleTime)
            .setHeatSetpoint(that.device.zoneID, value, null) // try to stop override time

I passed null as the last parameter (which is done in all other places setHeatSetpoint is called). However, I discovered that this sets a permanent override. Not what I want.

I recall reading previously that it is tricky to just set a new target temp. Hence the workaround of setting until the next scheduled time. However, it must be possible to do this as Honeywell gear does it ok. So it's just figuring out what the API call is... Peesy. 😉

EDIT: I thought I could use the function setTargetTemperature documented at line 892, It seems to just set the target temp. But I don't see/understand the syntax to call that...

@luc-ass
Copy link
Owner

luc-ass commented Mar 23, 2023

From what I can see even the Honeywell gear can not set a temperature without choosing either a specific time frame or permanent. Where did you find that?

@PuzzledUser
Copy link
Author

I tested this using my Honeywell Round Thermostat: https://www.tradingdepot.co.uk/y87rf2024-honeywell-single-zone-wireless-round-thermostat

I can't easily test on a full EvoHome with rad valves, as that home doesn't have a homebridge setup. But I can check later to confirm that it respects any override time when manually adjusting a rad valve.

@PuzzledUser
Copy link
Author

PuzzledUser commented Mar 24, 2023

The behaviour is different for Honeywell Home and an adjustment of a rad valve in a Zone. For me a manual target adjustment is never propagated to the Evohome central unit, never reaches the server and hence never gets to HomeKit via homebridge-evohome.

However, adjustments to a Honeywell Round thermostat quickly propagates its new target to the server (without changing the next scheduled switch time or any override time) and hence to HomeKit via home bridge-evohome.

Bottom line

There is definitely an API to update just the target temp on the Honeywell online system at tccna.honeywell.com/WebAPI/

If we can find the call, we can solve my problem and simply the existing code that calculates the next scheduled switch point (and cocks up across midnight).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants