search

thoukydides / homebridge-homeconnect

Home Connect home appliances plugin for Homebridge
https://www.thouky.co.uk
ISC License
134 stars 14 forks source link

It's not possible to set fan to "auto" mode #289

Closed joeybaker closed 1 week ago

joeybaker commented 1 month ago

Description of Issue

Setting a hood fan to "auto" doesn't actually set the fan to "auto" even though HomeKit thinks it has done so.

Expected Behaviour

The hood to show that it's in "auto" mode.

Steps to Reproduce

  1. In the Home app, set the fan mode to "auto"
  2. the hood will not indicate it is in "auto" mode.

Plugin Version

0.42.4

Environment

Home Connect Appliance(s)

No response

HomeKit App(s)

No response

Diagnostic Checks

Log File

n/a

Configuration

n/a

Additional Information

This is just a small logic error. The fix is here: https://github.com/thoukydides/homebridge-homeconnect/compare/master...joeybaker:homebridge-homeconnect:patch-1?expand=1

thoukydides commented 1 month ago

I think this comes down to how this HomeKit state should be treated:

The plugin currently treats the Active characteristic as being more important - the ultimate fan power switch. The AUTO state is remembered within the plugin, but only takes effect when Active is subsequently set to ACTIVE (e.g. by selecting a non-zero fan speed in the Home app). Personally, I think this makes sense.

Your suggested logic change reverses the priority between these two characteristics, so that when AUTO is selected the fan is always on. I don't think that's necessarily any better or worse; just different.

I don't have a Hood appliance that supports Home Connect, so I can only test this with my own mock appliance. Neither do I have any other fans with native HomeKit support. This makes it difficult to determine what the correct behaviour should be. The Apple HAP Specification doesn't appear to provide any clarity on this issue.

Given how long the plugin has implemented the Hood fan control in this way without anyone else commenting, I am reluctant to change the behaviour now.

joeybaker commented 1 month ago

What you're saying makes sense, but unfortunately it doesn't map to the way my Thermador hood works.

If, in HoneKit, I set the hood fan to "auto" nothing actually happens on the hood. I believe this is because the hood needs to be active before it can be in auto mode.

Put another way: when I press the "auto" button on the hood itself, the Home Connect API sends back events to set the fan to active and the program mode to auto.

With the current logic, I know for sure that it is impossible to set my Thermador hood to "auto" mode. HomeKit thinks it has succeeded, but it hasn't.

thoukydides commented 1 month ago

What happens if you either: i) Switch on AUTO in HomeKit while the fan is already running? ii) Switch on AUTO in Homekit while the fan is off, and then switch on the fan in HomeKit?

I would expect both of those to start the fan in AUTO mode. If they don't then please provide Homebridge log files with debug enabled so that I can understand what is going on. Like I said, my scope for reproducing it here is limited to mocking up a fake appliance.

joeybaker commented 1 month ago

i) Switch on AUTO in HomeKit while the fan is already running?

HomeKit shows "no response" from the fan, doesn't update the fan speed to what the fan is actually running at, but the hood does actually switch to auto mode.

ii) Switch on AUTO in Homekit while the fan is off, and then switch on the fan in HomeKit?

The fan moves to auto mode, but HomeKit still thinks the fan is running at a previous speed.

So, yes these both set "auto" as you're expecting, but have other incorrect behaviors. FWIW, I found a few other small bugs with the current implementation resulting from similar edge cases: https://github.com/thoukydides/homebridge-homeconnect/compare/master...joeybaker:homebridge-homeconnect:master?expand=1

As I say, I actually do have a hood so I'm happy to tell you real-life behaviors are!

thoukydides commented 1 month ago

From a quick look at your new suggested changes, one is to the eslint configuration, and the other only makes sense if I adopt your control approach.

I think the issue is that you are looking at forcing the appliance behaviour onto HomeKit - where AUTO means that the Cooking.Common.Program.Hood.Automatic program is active - whereas I think the HomeKit intention is that AUTO is a set-and-forget setting that takes effect if the fan is switched on by other means. This plugin has implemented it this way for 4 years.

As far as I am aware, Home Connect does not provide any indication of fan speed in Automatic mode, so there is no information that the plugin could use to reflect the actual fan speed back to HomeKit. I suppose it could just indicate that it is at 100%, but I don't think that's any better than just leaving it, and it could introduce more problems due to the way that the Home app combines Active and RotationSpeed into a single slider.

It took a lot of test builds and log files exchanged over many months to reach the current point. Much of that was due to different Hood appliances behaving differently, so the current code is a rather delicate balance between the quirks of different models.

I will take a look again once you have provided debug log files. If HomeKit is indicating that the accessory is in a "no response" state then that may be something that needs fixing. However, I am not convinced about other changes at this stage.

joeybaker commented 1 month ago

I appreciate the effort you've put in! FWIW, my hood does show different fan speeds in auto mode, that's why I've got things set that way.

I completely understand the feeling of years of built up effort and can empathize with the frustration of trying to create mocks from logs. All I can say is, I've been testing against my physical hood and these changes fix things.

Let me know if I can be of further help!

(P.s. the Eslint change was to update the config for what I assume the desired behavior was. Without this change, eslint --fix stripped all semicolons.)

github-actions[bot] commented 2 weeks ago

This issue is stale because it has been open for 30 days without activity. This issue will be closed in 5 days unless the stale label is removed or a comment added.

github-actions[bot] commented 1 week ago

This issue was closed because it has been stalled for 7 days with no activity.