Represent humidifiers by humidifier entity instead of fan entity

[kongo09]

Currently, all devices are represented as fan entities in HA. However, there is also a humidifier entity that could be used for the humidifier devices. Right now, the candidates are:

• HU5710
• AC2729
• AC3737
• AC3421
• AC3829

[kongo09]

Following the description here: https://developers.home-assistant.io/docs/core/entity/humidifier it appears that a humidifier lacks many properties of a fan, like speeds, etc... The Philips devices are 2-in-1 so the question is:

• should those air purifiers that also have controllable fans be better represented as humidifiers?
• or should we leave them as fans?
• or should such devices get two entities, one for the fan mode and one for the humidifier mode?

[kongo09]

First humidifier beta release as v0.25.0-beta.1

[GSzabados]

I think that the current implementation is accurate, as there is a select entity for selecting which function the unit uses, purification or purification and humidification.

The idea of introducing these separate categories for everything is making things more complicated and forces developer to put devices into their seperate categories, meanwhile some devices had functions from multiple categories. And of course these overlaps are not covered. (One of the reasons why the official SmartThings integration is a dumpster fire due to the attitude and thinking of the person who developed it and abandoned it during this year.)

If you would like to have a complete solution with a single entity and multiple preset controls, like the climate_ip integration. That could be a way, but it keeps people seeing what is actually on or off.

[GSzabados]

Following the description here

I've looked at that article and the imagination of some of the official HA developer is daunting.

MODE_BOOST - Device turn all valve full up

They are literally reaching as low as SmartThings' developers (and this is a live capability for years!)

wrinklePrevent - The dishwasher machine is in "wrinklePrevent" mode
airwash - The dishwasher machine is in "airwash" mode
spin - The dishwasher machine is in "spin" mode

https://developer.smartthings.com/docs/devices/capabilities/capabilities-reference

[kongo09]

Ah, interesting, you're suggesting to converge everything on https://developers.home-assistant.io/docs/core/entity/climate/

From a quick check, the only thing that seems to be missing are speed settings for the fan?

[merquel]

This is a really nice addition. The humidifier entity definitely improves user friendliness. The 5% button increments work very well too.

I know I'm in the minority (maybe the only one) who has a single purpose humidifier, HU5710. Since there's no option to set a custom speed it doesn't need anything the fan entity provides. In that case it would make sense to only have the humidifier entity exposed and the power and modes being set from there. It seems like no humidifier support custom fan speeds with the exception of AC3420/AC3421.

I've looked at the manuals for the 2-in-1 devices and as far as I understand the only difference is that they have a toggle between 2-in-1 mode and purification only? Maybe setting humidity to 0 or a separate switch could be an option but that's more for the owners of these devices to weigh in on whether two entities are preferable.

[GSzabados]

This is how on the 2-in-1:

And I meant that climate entity as an example. If the fan entity supports multiple preset options.

[kongo09]

Function and target as shown above are now removed and part of the new humidifier entity.

I could double the presets into the humidifier entity if it exists and also make power true power while for the 2-in-1 devices the state would go to idle if the humidifying function is off.

You could then ignore or hide the fan entity.

Alternatively, we could stick everything into a climate entity and get rid of both, fan and humidifier. There is not a single device with arbitrary speed setting, it's always in steps like a preset.

[GSzabados]

The issue with the climate is the focus on temperature control... As I told, trying to push devices into these categories is just an overkill. The previous selector were perfectly good.

[kongo09]

Are you fine with the double solution of fan plus humidifier?

[merquel]

I could double the presets into the humidifier entity if it exists and also make power true power while for the 2-in-1 devices the state would go to idle if the humidifying function is off.

You could then ignore or hide the fan entity.

For single purpose humidifiers this solution would be ideal.

[kongo09]

I've now played quite a bit with this but a truly good solution requires quite some rework. I've now at least changed the humidifier entity to control the power. It's thus redundant to the power setting of the fan entity as both do the same thing.

Internally, I've also refactored a little bit to pull the fan modes into the humidifier class. However, pulling this all the way to the frontend created some confusion for 2-in-1 devices as the fan modes are independent from the humidification function and the humidifier mode setting is needed to select between humidifying or not. In consequence, you still need the fan entity to control the fan speed of your humidifier.

But maybe we now have a compromise that can work for everyone?

[kongo09]

I've merged this in now and did a release. Let's reopen if this isn't practical.

[kongo09]

Ok, the current implementation is annoying. Having a 2-in-1 device I now have a redundant power setting, which is confusing. Users who only have a humidifier find the fan entity confusing. New plan is the following:

• for 2-in-1 devices with a function switch there are modes to change from purification to humidification. Power switches the complete device, so this stays redundant to the fan
• for 2-in-1 devices where the water container is the actual switch there is no mode. Action is determined by the water tank. Power switches the complete device.
• for humidifiers, power still switches the complete device. However, mode here picks up the modes that are otherwise in the fan. I might hide the fan entity.

[kongo09]

I've done a new beta with the plan from above: v0.29.0-beta.1

Please give feedback, especially if you have one of the HU.... devices. You should not get a fan entity anymore.

[merquel]

Nice work, for a single purpose humidifier this is the best solution in my opinion.

Feedback:

• The async_turn_off method sets self._device_status[self._power_key] to FanAttributes.ON instead of FanAttributes.OFF.
• For pure humidifiers self._attr_available_modes isn't returning a list.

I don't know if there is a way to set the icons for the modes though? Only solution I could find is remapping the unsupported modes to the most appropriate from the built in ones:

elif self._function_key == self._power_key:
    self._attr_supported_features = HumidifierEntityFeature.MODES
    
    key_replacements = {
        'high': 'boost',
        'medium': 'normal',
    }

    self._available_preset_modes = {
        key_replacements.get(key, key): value
        for key, value in available_preset_modes.items()
    }
    self._attr_available_modes = list(self._available_preset_modes.keys())

Not an ideal approach in any way so it probably shouldn't be used, but it solved it for me temporarily.

[kongo09]

Interesting. I wasn't even aware that there are icons in the drop-down. Very inconsistent to the preset modes of the fan.

I'll take a look at the rest.

[kongo09]

I guess I need to start working on icon translations to get this right: https://developers.home-assistant.io/blog/2024/01/19/icon-translations/

Let's take that to a separate issue: #211

[kongo09]

@merquel : please check if new beta v0.29.0-beta.2 works or if you (or anyone else) spots more bugs. If not, I'll do a proper release and close this issue.

[merquel]

philips-airpurifier-coap/custom_components/philips_airpurifier_coap/humidifier.py

Line 121 in b84b689

self._attr_available_modes = self._available_preset_modes

It's being assigned a dict, just the modes as a list str is expected. Suggested fix:

self._attr_available_modes = list(self._available_preset_modes.keys())

[merquel]

Have ran it for a couple of days now and everything's been solid.

[merquel]

Just a heads up that in it's current state it will map the sleep and auto modes to the built in modes, while the rest will show up without icons. Currently there's probably not many people using single humidifiers so it might be fine to release anyways, awaiting how to deal with this on an integration level. But worth mentioning in case someone brings it up.

I saw that #142 is the correct way to resolve this. Could be sensible to add translation strings too, if used in combination with the built in modes.

As I have multiple users in my HA instance, I decided just to stick to the built in ones for now. I find them a little bit more self explanatory than the Philips ones and they have translation strings built in.

Edit: Just saw that there's a separate issue on this, will continue there.

[kongo09]

I hope you guys like the humidifier improvement. I've released this now properly. If you want to support my work, you can buy me a coffee.. Feel free to reopen or create a new issue if there is something else.