Why not use a template fan component to organize what those buttons do in modalities that the fan can have? You can then hide the original fan you base your template on, so it’s not bothering you on the interface.
Ok, that’s a little interesting - the nice part is that it seems your special fan speeds are from 7-11 and 255, meaning your other speeds (I assume 0-6) are to control actual speed.
You may need a bunch of little things in HA to get this working, but it sounds doable without too much work.
What I would recommend is creating a numeric input helper with min 0 and max 6 (I think the step is auto set at 1 and not configurable via UI?). That could then be your fan control - an automation listening to that input changing values could be created to send the input to your fan controller. Then, for the other modes, toggles or some kind of boolean switch that would each be for one of those special modes, and again an event that would watch those and send each value.
I think that custom integration I gave you may be perfect for creating custom buttons directly on the card itself, but you may still need some automations or scripts created to actually change the fan settings.
All that being said however, and I think the ESPHome config could be tweaked so that those special settings would be exposed as buttons - that’s where I’d focus my attention if you’re at all inclined.
Yeah each of that fan work in that way. I am trying to get them as “real” as possible to the real device on ESPHome side so It can be also used standalone for someone without HA.
I am working with the integration you pointed me out to and I am ALMOST there I think, It has an slider that I can customize to what I want to send.
I would check that value is correct. Change the action to do a notification and pass in {{ value | string }} and see what you get. If it’s not the value of the slider, then that’s a question for the developer of that integration.
I found out the problem. I opened an github issue with it. The fan set percentage action just takes numbers with decimals, but numbers as strings without decimals.
Took a look at the fan integration code briefly - where they’re using “percents”, the values are coerced to integers. It seems they want whole numbers for percents only. They may not fix your bug report, as I’m assuming that although internally HA is “accepting” floats, it’s being converted to an int silently, whereas the template is expecting an int.
I’m confused by your float values being used, since the ESPHome thing seems to indicate that your valid values are 0-6 (your extremely precise step is quite interesting). However, I think you could just use {{ value / 100 * 6 | int }} (assuming that value is an integer out of 100 for the percentage).
The device has 11 positions, from there 0 is off (which is not allow by ESPHome as speed ), 1 to 6 are regular speeds and 7 to 11 “special” speeds (also controlled by the presets thing).
Ok, I would definitely see if you can contact the developer for that ESPHome module - those preset_modes look like they’re the special fan settings… so does that mean if you pick those, it sets the correct setting? Then the percentage set - at 90 that’s going to be in the “special” range… so does that mean it’s actually already limiting the speed in the 1-6 range? Many unknowns here. That step is just whack - no idea why it’s like that… but I think that might be coming from the module itself, not Home Assistant.
Regarding the esphome component, I can help with that, since I am the developer doing that in parallel . It is my first attempt to write an custom component.
The component mostly traduces the way the hardware device works, in the UART communication, the speed command is what put the 0 to 6 “normal” speeds, but also the same control code sets the special modes. So if I give it a speed of 6, it puts that speed, if I give it a speed of 7 it goes into an special mode.
It is a device that me and my neighbors have, but, they do not use HA, so I tried to replicate the behavior as close as I could, taking into consideration that the hardware fan device is always the source of truth.
I tried separating the speed from the “special” states, but then, on ESPHome side, I need to keep track of the select separately, since Select components are independent of fans and then I would need to build a middle controller. Also ESPHome Webserver doesn’t have support for presets, so those can not be controlled in ESPHome Webserver side. A single slider was the easier and faster way.
For now at least it is working as I wanted for “Version 1” if I have the time on the future I will probably try to manage separate the presets from the speed.
It beats the gateway the company sells for 200 Euro and NEEDS internet access
Ahh, so the ESPHome webserver is limiting what you can do - was gonna say that presets and using the on_speed and on_preset events would likely get what you need, but hey - whatever works to save $200