TargetAirPurifierState when toggling Active

[lilyball]

Side issue forked from #158 regarding this tidbit:

[2/20/2022, 4:17:44 PM] [homebridge-dyson-pure-cool] F3H-US-NFC4805A - set TargetHeatingCoolingState to 0: {"hmod":"OFF"}
[2/20/2022, 4:17:44 PM] [homebridge-dyson-pure-cool] F3H-US-NFC4805A - set TargetAirPurifierState to 1 with delay
[2/20/2022, 4:17:44 PM] [homebridge-dyson-pure-cool] F3H-US-NFC4805A - set Active to 1: setting TargetAirPurifierState cancelled
[2/20/2022, 4:17:44 PM] [homebridge-dyson-pure-cool] F3H-US-NFC4805A - set Active to 1: {"fpwr":"ON","fmod":"FAN"}

Description

I just discovered why it's doing this cancelling. You've got a comment saying that Home always sets TargetAirPurifierState when toggling power on, and you're right, it's absolutely doing that. Unfortunately, this is indistinguishable from a HomeKit scene that sets both Active and Target Air Purifier State. Which means the plugin's attempt to work around Home's behavior causes it to break scenes like this.

My inclination is to say that breaking scenes is worse behavior, and that Home's behavior of always forcing the Target Air Purifier State to Auto should be filed as a bug with Apple and just lived with. If turning on the fan with the Home app always sets it to Auto mode that's honestly not a big deal, but if I cannot set Auto mode when turning on the fan with a scene that is very annoying. This is especially true because the result of the current behavior is that if the fan is on in auto mode, and I toggle power off, then back on, it leaves auto mode (as turning the fan on turns off auto mode automatically)[^1].

Possible workaround

I do wonder how Home behaves if the air purifier accessory exposed a Target Fan State characteristic. This characteristic belongs on Fans, not Air Purifiers, so maybe Home would just ignore it and third-party HomeKit apps could use that as a workaround for scenes (i.e. Home would set TargetAirPurifierState, which the plugin would ignore, but TargetFanState would still work). That would be a little weird and fairly confusing for anyone who doesn't know what's going on here, and maybe Home would show it after all (which would be a dealbreaker).

Even if this does work, I still think the plugin should just stop trying to handle Home's behavior here as it breaks scenes.

[^1]: This bit can be fixed by doing what I suggested in #158 and having the plugin restore auto mode when turning on the power if it was in auto mode prior to turning on the power. Fixing that doesn't justify breaking scenes though.

[lukasroegner]

My inclination is to say that breaking scenes is worse behavior and that Home's behavior of always forcing the Target Air Purifier State to Auto should be filed as a bug with Apple and just lived with.

Even if this does work, I still think the plugin should just stop trying to handle Home's behavior here as it breaks scenes.

That depends on your use case. If you are an active user of the Apple Home app, you rather want to have a UI that behaves the way it should (i.e. don't switch to auto mode when activating the device). Filing a "bug" (as it is an extra step, I would assume that it's a feature) that occurs when using an uncertified HomeKit bridge doesn't make sense imo.

I think the easiest solution would be to add another setting like disableHomeAppBehavior (or maybe you can think of a better name?). If set to true, the whole delay and cancellation logic will just be ignored. Thus, your scenes should work as expected.

[lilyball]

That depends on your use case. If you are an active user of the Apple Home app, you rather want to have a UI that behaves the way it should (i.e. don't switch to auto mode when activating the device). Filing a "bug" (as it is an extra step, I would assume that it's a feature) that occurs when using an uncertified HomeKit bridge doesn't make sense imo.

I am an active user of Apple Home. That's the whole reason I use Homebridge. Speaking as a user of Apple Home, the current behavior is confusing and buggy. I primarily control my dyson fans using scenes, and setting auto mode in the simply doesn't work.

So the question is whether you want to optimize for scenes or for manual control. And I think it's better to make scenes work. If I use manual control, I can always set the fan speed afterward. Perhaps a little annoying, but "turning on the fan with Home sets it to Auto" is predictable behavior. Meanwhile "I set auto mode in my scene and it's not working" is buggy, especially since triggering the scene again does work.

The fact that I had to change my daily automation to being a Shortcut that sets the scene, waits a few seconds, and sets it again, is a problem. The fact that if I trigger a scene with Siri (which I do multiple times per day) and the fan doesn't end up in the correct state is a problem.

I think the easiest solution would be to add another setting like disableHomeAppBehavior (or maybe you can think of a better name?). If set to true, the whole delay and cancellation logic will just be ignored. Thus, your scenes should work as expected.

I would suggest doing the opposite, adding an ignorePowerOnAutoFromHomeKit that enables the current behavior, and defaulting it to off. This way the default behavior is more predictable and scenes work out of the box. It also means that users are opting in to the workaround, which makes the behavior more understandable.

[lukasroegner]

I agree with you that adding the opposite logic (ignorePowerOnAutoFromHomeKit) would be way more logical, and more convenient for new users. However, I also want to consider users that already have the plugin installed. For them, the behavior changes without user interaction/change of the configuration. That may lead to confusion.

[lilyball]

It will be a behavior change, yes, but one that fixes any scenes which might currently be confusingly broken. I don't think it's that awful to say "This version fixes TargetAirPurifierState when set from a HomeKit scene. It does mean that toggling the air purifier on manually now resets the state to Auto, but you can set ignorePowerOnAutoFromHomeKit if you want to retain the old behavior and don't need scenes to work."