Support for dmaker.fan.p18 and dmaker.fan.p33 #19
Comments
|
Spend a night shift and I have good news: I was both able to do a backup of the original firmware, flash ESPHome and then I tried one test control in the config (power on/off) and the device does react to it 👍 This is the original firmware: mi-smart-standing-fan-2-pro--dmaker.fan.p33-orignal-firmware.zip The ESPHome log for this device shows many commands sent from the MCU to the ESP8266/ESP-WROOM-02D which should be additionally helpful to further complete the config with all possible controls. This is the working ESPHome config with the first working controls (most essential controls already included): |
|
I just bought the non-pro version based on this post and looking to flash the ESP. Did you end up soldering pig-tails to the chip to flash via USB-to-serial adapter? If this works, this will be the only full-local smart tower fan that I'm aware of, and I have had nearly 7 of them. So far they all require cloud API integrations. |
|
Sure is a shame that these pins cannot be used :/
|
|
I wired up to io13 and 15 on the back per your previous post, and I'm hoping that I can piggyback on the VDD5 and GND front the other controller in my above photo. I just need to dig out my serial to USB adapter and fiddle with it. Any tips? Would be so cool to build a full guide on this. |
|
I built up a little mount to hold pins/wires up against the ESP, and when I set my USB-to-Serial adapter to 3.3v and plug in, my port disappears immediately from my Windows PC, and the fan board just keeps chirping, about once every second. My next test will be with the 12v plugged into the board. I was hoping to avoid this, just in case it could shoot it into my serial adapter.... somehow
|
|
@scrampker you should try it only using UART USB device connection, incl power coming from UART. This worked well for me. I used FTDI Chip based UART like this one https://amzn.eu/d/2w40Qh4 . Experience with it was much more stable than other noname chip UART that I used before. I'm traveling until the end of the week, I thought I had already posted the instructions how I successfully put the ESP into bootloader mode but it doesn't seem to be the case. I'll post it later. I think I kept notes about it. |
|
Oh that would be really cool. I'm using https://www.amazon.com/dp/B09F3196FB?psc=1&ref=ppx_yo2ov_dt_b_product_details which looks to be using a proper FTDI chipset. I tested a loopback to make sure it's working properly. When I connect everything WITH the 12v base attached, the serial adapter does not crash. I believe what is happening is that the 3.3v line is pulling too much power for my serial adapter -- due to all the extra components being powered off that rail. That being said, I tried using the UART0 TXD/RXD pins, and also the IO13/15 pins you reference in the yaml, but nothing seems to stick. It's been 3+ years since I've programmed an ESP device from a serial header, so I could be screwing up any number of things. Your notes would be amazing, exactly which pins you used for each step. I'm trying to ground IO0 like it says to flash firmware, but no dice. Could even be that I'm not making sufficient contact with the pads. Did you solder directly to the chip, or were the underside contacts enough for everything? Thanks so much! |
|
I finally got it connected. Here's what seemed to work, but I'm not 100% sure if I had a bad connection for other attempts or not.
Looking good so far. Time to re-assemble. |
|
Congrats! Glad you got it to work. My yaml is work in progress as you probably noted already, it's not on top of my priority list at the moment since there are some other projects I want to complete before, but I will definitely continue on it in the later course of this year. Of course I'm happy if others join the yaml configuration work. |
|
Because you asked how I flashed the chip. I bought PCBite from Sensepeek some time ago. I'm not capable of soldering and using this amazing equipment I was able to flash more than 10 devices, some of them had ESP pins which were extremely difficult to reach due to the PCB design. PCBite saved me. It's such a well designed toolset. |
|
Dang, that's pretty cool. Never seen it before, which is why I 3D printed my own pin-holder. I also was not confident in soldering such small pads without damaging the connection to the traces. Word of warning to anyone else doing this.. the nut that attaches the motor housing to the base which allows it to tilt, (the tensioner,) is made out of extremely soft metal and stripped instantly. I have to find a suitable replacement at the hardware store. My guess is it was made out of aluminum. |
|
I do have to say, this build quality and features of this fan are pretty weak when you look at the sale price of $159. It's actually horrendous, and unforgiveable. I have several of these $139 Dreo Pedestal fans that oscillate left/right and up/down, with temperature, and better algorithms for natural-feeling airflow. The only reason I don't have 20 of them in my house is because I have to rely on the cloud to control them. https://www.amazon.com/dp/B0BSH7YKHT?psc=1&ref=ppx_yo2ov_dt_b_product_details All that being said, I'm very pleased to have flashed this ESP and have 100% local control. Not relying on the internet, or some greedy company that wants to charge for their API access. |
|
@helgek by chance do you know if the miot module can define an actual fan component, versus 'select'? The reason being is that certain automations and especially my hubitat integration have a hard time controlling the speed. It's not seen as a legit fan. More of a jumble of various entities. |
|
@scrampker I think I can answer that. esphome-miot doesn't (yet) have a It's as barebones as it can be and there's no state feedback support (i.e. register state change when pressing physical buttons) but may be workable via the On State trigger and friends. fan:
- platform: template
name: "Virtual Fan"
on_state:
- lambda: |-
// id(my_miot_speed_select).set_index(x->speed) or something?
on_speed_set: # etcI've ordered a non-pro standing fan 2 too and it seems fun to try my hand at a miot fan component, but don't hold your breath. I'd love to hear it if you manage something workable with the above 😃 |
|
Thanks! I was tinkering with something along these lines, but I'm not too familiar with the way this all pieces together. I assume I'd need to add some code to the miot base for fan. My quick attempts to build outputs and whatever haven't worked yet. Hopefully I'll figure out something. |
|
@scrampker would you mind sharing the 3D Print STL files for the Dupont holder? |
|
@w-marco You can search the Thingiverse and other sharing platforms for "ESP8266 programming jig", I see there are several options. I've also received my (change the Edit: logger:
level: DEBUG
# Important: Disable UART1 logging to avoid hardware errors on main UART0
baud_rate: 0 |
|
I can send you mine a bit later if you really want. I did search a bit but I must suck at it and didn't find an easy print. Otherwise I wouldn't have made mine. If you know of a good one please let us know. |
|
Mine definitely isn't perfect. It could hold the pins in tension better if the holes were angled some. |
|
Yeah, I also couldn’t find one where I am certain it will fit, so adding yours here is probably a good idea! |
|
@scrampker I managed to get the fan component working via The fan component can control the device, and device updates by button press / entity changes are updated in the fan too. Also, I've shoehorned the "Natural / Direct" breeze modes as presets. To make this work, I've had to keep updating the template_fan preset_mode state, as the normal esphome fan behavior is to clear the preset whenever a manual speed/oscillation change is made :/ You can check out the full working yaml here for Hopefully, in the future the Template Fan component will get new powers so we can maybe say which number/select/switch entities control which part of the fan instead of this spaghetti, like: # My daydream
fan:
- platform: template
entities:
power: my_miot_power_switch
speed: my_miot_power_number
preset: my_miot_mode_select
oscillation: my_miot_oscillation_switchSeeing how often devices break the xiaomi specifications (integer 0/1 instead of booleans, one write-only property for left/right instead of two actions, etc) I'm not sure how a If you have any ideas or successes I'd be happy to hear them! And, last but not least, some eye candy:
|
Unfortunately none of the prints from Thingiverse seem to fit the orientation this ESP Chip is placed in the p18, but once I have the 3D Print files from @scrampker I will happily try out your config for the fan and report back! |
|
Here's the latest version I had. |
Pretty cool man, I was just able to test this yaml and pretty smooth sailing. Does anyone know if we can use the original repo yet? |
|
I'll have to be keep playing with that yaml because it seems to turn the fan right back on every time I power it off. Great step in the right direction though. The fan component is working as expected.
…-------- Original Message --------
On 7/21/24 9:21 AM, w-marco wrote:
> ***@***.***(https://github.com/w-marco) You can search the Thingiverse and other sharing platforms for "ESP8266 programming jig", I see there are several options.
>
> I've also received my dmaker.fan.p18 yesterday and managed to get a good config working, hopefully this will cut some of your work :)
Unfortunately none of the prints from Thingiverse seem to fit the orientation this ESP Chip is placed in the p18, but once I have the 3D Print files from ***@***.***(https://github.com/scrampker) I will happily try out your config for the fan and report back!
—
Reply to this email directly, [view it on GitHub](#19 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ADS37XAXKEWZMT5Y3ZMAIFLZNOYXLAVCNFSM6AAAAABGFAY2MSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBRGYYDSNRSGQ).
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
On that branch I have another commit simplifying things a bit after I've discovered you can just If after you power off the fan it tries to set the speed anyway, the automation there starts with - platform: "miot"
id: "speed_level"
miot_siid: 2
miot_piid: 10
name: "Fan Speed"
icon: "mdi:speedometer"
min_value: 1
max_value: 100
step: 1
unit_of_measurement: "%"
on_value:
- lambda: |-
- auto call = id(template_fan).turn_on();
+ auto call = id(template_fan).make_call();
call.set_speed(x);
call.set_preset_mode(id(mode).state.c_str());
call.perform(); |
|
I'm a dummy -- totally glossed over the fact that you were using the d18 and I have the d33 'pro' version and in testing I copied your yaml entirely. After throwing back some of the code I had previously, AND making the patch you pasted, it seems to work great. Doesn't appear to be turning back on right away. Awesome! I really need to dig deeper into these yaml configurations, and the baseline code. Just getting started with truly customizing HA or ESPHome stuffs. I also have a bunch of 8266 units I was using some hacked code to operate linear actuators to open windows, and should get those over on ESPHome as well. |
|
Yay, the notification sound disabling actually sticks now. That's been obnoxious. Seems to work exactly as I'd expect. The added bonus of the left/right control is actually interesting. I wasn't aware that it was even capable of that. I knew it had a little servo from the tear-down, but that's really cool. Wild thought... is the servo index/left-right position known or controllable? Would be so cool to use occupancy data to tell the fan where to position itself and then set the oscillation angle range. |
|
Awesome, glad to hear it! When you're happy with the config for the p33 you could add a PR for it so we can close this issue :) Last I heard from the maintainer, he was swamped with other things, but he'll take a look when he has time, and in the meantime people can still benefit from the config in the PR. As for the left-right position, I can only speak for the p18, but the MCU knows and doesn't expose that in the miot-spec, bummer. I've tried wild poking of a few random SIID/PIIDs (Calling Off-topicWhen first plugged in, the fan goes full-tilt to the right for a couple of seconds to zero the angle (e.g. even if it started full left it should be back in a known position) and then back to center. To hack it, you could delete the oscillation switch from the config, tape over the button, and emulate the same behavior in the ESP. Make a note of how many steps you have for a full swing, then at startup spam enough (You could even do the same thing for the "natural breeze" algorithm. Add a template number input for the speed control for the intensity, and each 1-5s calculate a speed based on a pseudo-random math function of your choosing.) |
|
Steps are probably better than timing, but that's likely something I'd play with using another tool. Was just thinking it would be cool if somehow we could get that angle. |
|
@dhewg I was just opening ESPHome when you tagged me 😄 fan:
- platform: "miot"
name: "Fan"
state:
miot_siid: 2
miot_piid: 1
speed:
miot_siid: 9
miot_piid: 2
min_value: 450
max_value: 2000
step: 1
preset_modes:
miot_siid: 2
miot_piid: 4
options:
0: "Auto"
1: "Sleep"
2: "Favorite"
3: "Manual"I'll also test with the smart standing fan 2 soonish |
|
Of course its' |
|
@dhewg also,
There's the action: fan.set_preset_mode
target:
entity_id: fan.standing_fan_smart_standing_fan_2
data: {}
# -- and --
action: fan.set_percentage
data: {}
target:
entity_id: fan.standing_fan_smart_standing_fan_2And yes, it would be very nice if we could keep the individual sensors/entities and have the fan as an addition, with their states synchronizing automatically. Or is this already the case in your branch? |
|
I don't see those two actions, so that's fine, an upgrade would solve it for my setup. But no, the fan component is supposed to replace the single components. It kinda sucks w.r.t. automation backwards compatibility, but I'd argue that's the nature of HA, I had to redo my automations lots of times over the years... |
|
Updated HA, and indeed, the actions are there now. While talking about backwards compatibility, the |
|
In case you didn't notice: I pushed some minor fixes to the "fan" branch
(which I'll squash eventually).
With that I think it shouldn't be rather trivial to use for all the
purifiers we support.
But what about the standing fan? Does that work out? From a quick glance
it should be rather easy to replace the template fan with the fan
component without losing any features?
|
|
@dhewg I'm still receiving the Cleaned build files and fetched fresh: # https://home.miot-spec.com/spec/dmaker.fan.p18
external_components:
source: github://dhewg/esphome-miot@fan
refresh: 0s
# .. snip
fan:
- platform: "miot"
name: "Fan"
state:
miot_siid: 2
miot_piid: 1
speed:
miot_siid: 2
miot_piid: 10
min_value: 1
max_value: 100
step: 1
preset_modes:
miot_siid: 2
miot_piid: 3
options:
0: "Normal"
1: "Nature"
oscillating:
miot_siid: 2
miot_piid: 4 |
|
Huh, how about now?
I mean the error is kinda obvious, but I really wonder why I don't run
into it...
…On 17/02/2025 5:24 pm, Cristian Chelu wrote:
@dhewg <https://github.com/dhewg> I'm still receiving the |direction| error.
Cleaned build files and fetched fresh:
|In file included from src/esphome/components/miot/fan/miot_fan.cpp:1:
src/esphome/components/miot/fan/miot_fan.cpp: In lambda function: src/
esphome/components/miot/fan/miot_fan.cpp:38:144: error: could not
convert 'this-
>esphome::miot::MiotFan::<anonymous>.esphome::fan::Fan::direction' from
'esphome::fan::FanDirection' to 'bool' 38 | ESP_LOGV(TAG, "MCU reported
reverse direction %" PRIu32 ":%" PRIu32 " is: %s", this-
>direction_siid_, this->direction_piid_, ONOFF(this->direction)); src/
esphome/core/log.h:86:91: note: in definition of macro 'esph_log_v' 86 |
esp_log_printf_(ESPHOME_LOG_LEVEL_VERBOSE, tag, __LINE__,
ESPHOME_LOG_FORMAT(format), ##__VA_ARGS__) | ^~~~~~~~~~~ src/esphome/
components/miot/fan/miot_fan.cpp:38:7: note: in expansion of macro
'ESP_LOGV' 38 | ESP_LOGV(TAG, "MCU reported reverse direction %" PRIu32
":%" PRIu32 " is: %s", this->direction_siid_, this->direction_piid_,
ONOFF(this->direction)); | ^~~~~~~~ src/esphome/components/miot/fan/
miot_fan.cpp:38:132: note: in expansion of macro 'ONOFF' 38 |
ESP_LOGV(TAG, "MCU reported reverse direction %" PRIu32 ":%" PRIu32 "
is: %s", this->direction_siid_, this->direction_piid_, ONOFF(this-
>direction)); | ^~~~~ Compiling .pioenvs/standing-fan/src/esphome/
components/number/number_traits.cpp.o *** [.pioenvs/standing-fan/src/
esphome/components/miot/fan/miot_fan.cpp.o] Error 1
========================= [FAILED] Took 10.75 seconds
========================= |
# https://home.miot-spec.com/spec/dmaker.fan.p18
external_components:
***@***.***
refresh:0s
# .. snip
fan:
-platform:"miot"
name:"Fan"
state:
miot_siid:2
miot_piid:1
speed:
miot_siid:2
miot_piid:10
min_value:1
max_value:100
step:1
preset_modes:
miot_siid:2
miot_piid:3
options:
0:"Normal"
1:"Nature"
oscillating:
miot_siid:2
miot_piid:4
—
Reply to this email directly, view it on GitHub <https://github.com/
dhewg/esphome-miot#19#issuecomment-2663582075>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/
AAET23BOTC4O6MTXOXZBTML2QIENRAVCNFSM6AAAAABGFAY2MSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRTGU4DEMBXGU>.
You are receiving this because you were mentioned.Message ID: <dhewg/
***@***.***>
cristianchelu*cristianchelu* left a comment (dhewg/esphome-miot#19)
<#19 (comment)>
@dhewg <https://github.com/dhewg> I'm still receiving the |direction| error.
Cleaned build files and fetched fresh:
|In file included from src/esphome/components/miot/fan/miot_fan.cpp:1:
src/esphome/components/miot/fan/miot_fan.cpp: In lambda function: src/
esphome/components/miot/fan/miot_fan.cpp:38:144: error: could not
convert 'this-
>esphome::miot::MiotFan::<anonymous>.esphome::fan::Fan::direction' from
'esphome::fan::FanDirection' to 'bool' 38 | ESP_LOGV(TAG, "MCU reported
reverse direction %" PRIu32 ":%" PRIu32 " is: %s", this-
>direction_siid_, this->direction_piid_, ONOFF(this->direction)); src/
esphome/core/log.h:86:91: note: in definition of macro 'esph_log_v' 86 |
esp_log_printf_(ESPHOME_LOG_LEVEL_VERBOSE, tag, __LINE__,
ESPHOME_LOG_FORMAT(format), ##__VA_ARGS__) | ^~~~~~~~~~~ src/esphome/
components/miot/fan/miot_fan.cpp:38:7: note: in expansion of macro
'ESP_LOGV' 38 | ESP_LOGV(TAG, "MCU reported reverse direction %" PRIu32
":%" PRIu32 " is: %s", this->direction_siid_, this->direction_piid_,
ONOFF(this->direction)); | ^~~~~~~~ src/esphome/components/miot/fan/
miot_fan.cpp:38:132: note: in expansion of macro 'ONOFF' 38 |
ESP_LOGV(TAG, "MCU reported reverse direction %" PRIu32 ":%" PRIu32 "
is: %s", this->direction_siid_, this->direction_piid_, ONOFF(this-
>direction)); | ^~~~~ Compiling .pioenvs/standing-fan/src/esphome/
components/number/number_traits.cpp.o *** [.pioenvs/standing-fan/src/
esphome/components/miot/fan/miot_fan.cpp.o] Error 1
========================= [FAILED] Took 10.75 seconds
========================= |
# https://home.miot-spec.com/spec/dmaker.fan.p18
external_components:
***@***.***
refresh:0s
# .. snip
fan:
-platform:"miot"
name:"Fan"
state:
miot_siid:2
miot_piid:1
speed:
miot_siid:2
miot_piid:10
min_value:1
max_value:100
step:1
preset_modes:
miot_siid:2
miot_piid:3
options:
0:"Normal"
1:"Nature"
oscillating:
miot_siid:2
miot_piid:4
—
Reply to this email directly, view it on GitHub <https://github.com/
dhewg/esphome-miot#19#issuecomment-2663582075>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/
AAET23BOTC4O6MTXOXZBTML2QIENRAVCNFSM6AAAAABGFAY2MSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRTGU4DEMBXGU>.
You are receiving this because you were mentioned.Message ID: <dhewg/
***@***.***>
|
|
@dhewg Compiles now. The only small issue I see is an error with unknown preset OFF -> ON ON -> OFF Preset Nature -> Preset Normal: Set speed: Oscillation ON -> OFF: |
|
@dhewg The purifier also works, and the 1% to 100% speeds correctly set 450-2k rpm. however... I'm not sure how to best add the config. fan:
- platform: "miot"
name: "Fan"
state:
miot_siid: 2
miot_piid: 1
speed:
miot_siid: 9
miot_piid: 2 # Favourite speed
min_value: 450
max_value: 2000
step: 1
preset_modes:
miot_siid: 2
miot_piid: 4
options:
0: "Auto"
1: "Sleep"
2: "Favorite"
3: "Manual"There is a target So I can set the target fan speed to 69%, set the preset mode to "Favourite" and all is good. For "Auto" and "Sleep" the speed should basically be read-only, but I'm not sure we can do that in HA UI. For good UX, I would say set the mode to favourite when a user changes the speed (that old automation branch would come in handy). Or we could just leave it as is... Thoughts? |
|
Yeah, I noticed that too.
I think all we can do atm is to work around it. A cleaner solution would
be if the fan component could handle such dependencies.
Maybe that's planned for the future, I didn't look into it. Right now I
tend to leave it as-is and adapt to future changes to the fan component
to hopefully handle that more gracefully.
With that you'll basically have to choose if the speed slider uses
"manual" or "favorite" then.
The 3rd, the speed sensor, is different though. At least for my purifier
that's the fan's real rpm, so that's an additional sensor, independent
of the fan's inputs. And my speed settings are 0-14, so it's another
unit altogether. Yours are 450-2000 though, does that map closely to the
rpm?
|
Gotcha. In the meantime, I realized I can fix my issue today, we have actions for fans: fan:
- platform: "miot"
# ...
preset_modes:
miot_siid: 2
miot_piid: 4
options:
0: "Auto"
1: "Sleep"
2: "Favorite"
3: "Manual"
on_speed_set:
then:
select.set:
id: preset_mode
option: Favorite
select:
- platform: "miot"
miot_siid: 2
miot_piid: 4
id: preset_mode
name: "Mode"
options:
0: "Auto"
1: "Sleep"
2: "Favorite"
3: "Manual"aand... while writing this I realized there might be another bug, or I'm misunderstanding expected behavior. I forgot to delete the old components when I added the fan, but I have no compile error, and I can't spot any runtime errors either. Maybe because I'm missing the very first logs due to the OTA logger. The components are visible in HA, controllable from HA, but their state is always unknown. I guess I could always use
Correct, exactly the same for me.
Yes, it does map. With the normal spin-up transition delay and small fluctuations, it's within a couple rpm to any target I set (when Favorite/Manual are separate The very latest commits also work, BTW, no more missing preset errors on changing states. |
|
HA seems to cache old entities, I've had some issues there too. In the
past, I could just delete those, but last week that was grayed out. I
had to delete them from the HA config files...
But does that config even work? I think you should get an error when a
second id 2:4 registers a listener. Do you even have to use a second
component, can't you use the fan itself to set the preset mode?
|
That's what is surprising to me too. It's not newly unavailable entities still living in cache, they're still live, interactive, actually-device-controlling :) Their current state is just never updated, presumably because the Edit: Fair point, I could just use the fan itself; it didn't cross my mind. Thanks! Favorite speed and Mode in the below screenshots are affected:
|
|
This sounds sensible:
https://developers.home-assistant.io/docs/core/entity/fan/#preset-modes
It seems like neither HA nor esphome enforce "Manually setting a speed
must disable any set preset mode" though, but our fan component could do
that.
|
|
Hmm...
By this reasoning, the smart fans in this issue should not have a preset mode. There's no other "eco"/"smart"/autopilot option available. And for the purifiers, this would mean that the only true presets would be "Auto" and "Sleep"(minimum). Otherwise, we could keep "Favourite" and "Manual" as presets but not have speed control in the fan entity? Leave them as separate inputs? I'm more confused now. But, to get back on track, I think the |
|
I tried to make the fan component act as described on the HA site.
So no manual preset modes anymore, there's just 'auto' and 'sleep' for
my purifier now.
And with that, setting a speed percentage now wipes the preset mode.
As we need a manual mode for the device ("favorite" for my rmb1), I
chose to use an empty preset mode string to declare it as such. So now
it looks like:
options:
0: "Auto"
1: "Sleep"
2: ""
The last one isn't a usable preset mode, but when you set a speed
percentage, that mode gets activated under the hood. E.g. you set the
speed slider to 50% and the component wipes the preset mode, sends "set
mode to 2" and then "set speed to 50%".
I think that matches the HA site description pretty well and the gui
feels nicer that way.
For your mb5 you'd have to choose manual or favorite for the speed
percentage and just drop the other for the fan component. But as it's
basically two mode for the same thing it kinda makes sense too I'd say.
As for the standing fan, by HA's definition the "natural breeze" should
be a switch not part of the fan component. A fan component without
preset modes is valid and should just work here too.
But neither HA nor esphome seem to enforce that preset/speed behavior,
so you could also keep the breeze a preset, but that may break in the
future if they start enforcing it.
So I'd chose the former, make the breeze mode an distinct switch.
Does that make sense?
|
|
I've had a chance to play around with the latest code, yes it does make sense. I have a few separate comments: Manual presetI've chosen Manual mode for the manual fan preset. Whatever preset I am in, changing the speed correctly sets it back to manual mode and I am in control. Put it back to a preset, the device is in control, nice! However, what I'm missing is precise fan speed reporting in these modes. I know it's complicating things further, but would it be possible to have the speed reporting PIID be separate from the speed setting PIID? Or at least, in the non-manual presets make the speed null, as having an incorrect speed displayed is worse in my view than having none displayed at all. The Manual speed PIID on this device is a bit interesting (read: annoying), there's two cases I've just now understood:
It also doesn't help that the manual speed PIID is only polled once per minute, when the actual motor speed PIID is notified real time by the mcu. So, for any preset, the displayed speed is wildly out of touch with what I can hear the fan do. Re: favourite vs manual being the same,I've left "Favourite" as a selectable fan preset as well, with its corresponding Favourite speed piid as an independent control in the device menu. I guess if we have "auto" and "min/sleep", we could have a user definable "just right" preset, besides the "manual" temporary override. (e.g. "cooking-when-others-are-sleeping" :D ) speed reporting bugThe reported speed should be the raw speed in this device's case. There may be 1-100% mapped to 450-2000rpm in the "set" direction, but in the "report" direction there's no need for the inverse. I'm not sure if this is new or I just didn't spot it in the beginning. The possible device bugMost likely not something we can fix in this project, but I've seen some weird errors from time to time. It seems that if the MCU has some From what I've seen very likely to happen when we queue the 3 |
|
That Manual Speed PIID behavior sounds funky and is different on my device. In my case you have a 0-14 range, and that is exactly what is reported back. If the device is in any other mode it doesn't report back anything different as in your case. If the favorite speed piid acting in the same way? Your device's behavior is even problematic for HA, if you set a value of 3 and it a bit later it reports back 5, that yields all kinds of issues, like never ending automations triggering all the time. So we can't just make it report other values or even units (like the raw value) there for the same reason, but I've had the same idea with just unsetting the speed if the device in not in manual mode. It's just consistent gui wise and a less confusing. Same when the device is off, reporting a speed makes it look like it could be on or in manual mode. So let's just not report the speed in those cases. I've just implemented exactly that, how does that look? |
|
As for the -5001 error/bug, I get that too, but only in verbose mode, not in debug mode. I didn't dig too deep, but it looks like a sdk or even hardware bug, where using one uart affects the other. The more you use one the more likely it affects the other or something. |
|
I'm still using the template fan config tossed together a few months ago. What benefit is there to switch over to a proper fan config? |
|
It's a reusable component so we don't have to spam all that ugly template code into all the configs ;) But it also allows us to fine-tune the behavior, like the template/speed issue discussed on the last few comments. I've refactored the standing fan configs for this new components too, so feel free to jump in, test and report back: |
|
@cristianchelu while refactoring dmaker.fan.p18 I noticed |
Yes, it's very weird, but at least we understand it now. Also keep in mind that this is
It only reports back a 5 if the mode is no longer manual. When you set it to 3 and the fan component also sets the preset to manual, all is stable. Only later when/if something else changes the mode from manual to auto, would the speed reported rightfully change (even if only in coarse values).
Much better, but in an ideal world, I would still expect it to report the speed I know it has access to regardless of the mode. Still in percentages, but mapped from 450-2000 instead of 0-14. Small steps, though...
Good to know, thanks!
The command is
@dhewg just in case you missed this in my comment ^ |
|
If your piid 9:4 and/or 9:2 is too funky you may as well use 9:9 with a range of 1-11 for the fan's manual mode? Sure, it's less granular, but that range should be more than sufficient for a daily driver.
I know what you mean, but I don't think that's how HA's
Nope:
There're two levels of conversions:
We always need to set and get the same unit, why do you think we need to mix units here? |
It's only the logs for the intermediate value that are wrong, you're right, in HA all is good. I saw: 1%(HA) = 450 (MCU) Or from a more complete log: I guess we could live with it or log directly in %, but this is what caused me the initial confusion. |
|
Oh, I see. Well, sorry, my painted picture isn't complete either ;) If you really wanna know, a yaml of: means that our fan components maps that 450-2000 range onto 1-1551 (0=off). Why? Because esphome/HA only has a So that Which doesn't directly map to the motor's real percentage either... One could argue that 2000 is 100% and 450 is 22.5%, but as 1-449 isn't possible the percentage is mapped onto the valid 450-2000 range, so with that 450 is 0.065%. And all of that crap is why I asked for Happy now? :P |
|
In any case, to me the current state looks pretty good. Well, considering what HA's fan component expects. There're different ways we might want it to behave (e.g. the standing's fan breeze mode a preset mode), but it just isn't designed like that. With that in mind, how are your devices 'feeling' with this state? In other words: ready to merge? |
Yeah, I understood the math; I guess I could have explained what I saw was wrong better -- words are hard sometimes, sorry for that. And, functionally, it does work as intended, as I said, as tested by setting the speed in HA to 1%, 50%, and 100% and observing the I'll try to rephrase: Do with that info as you wish :) .
The p18 standing fan without presets LGTM. The purifier with its manual/presets, when the thing is OFF and there is auto/sleep shown selected, if you press the power button (not selecting a percentage speed), it still clears the preset ad turns on to Manual mode in its last selected speed, instead of turning on to the shown preset mode. Your choice if you want to do anything about that. |
|
Don't worry, glad we're on the same page now ;) I get that the values look wrong/confusing. I'll leave the logs as-is, as the used value is useful for debugging too. And the raw/on-wire value is also there ;)
Indeed, didn't notice that. I think that's a esphome bug: esphome/esphome#8277 |
Hi,
I have here a dmaker.fan.p18 and a dmaker.fan.p33 (Mi Smart Standing Fan 2 and Mi Smart Standing Fan 2 Pro). Difference between the two is that one has a battery, otherwise they should be the same. The specs differ slightly though:
https://home.miot-spec.com/s/dmaker.fan.p18
https://home.miot-spec.com/spec?type=urn:miot-spec-v2:device:fan:0000A005:dmaker-p18:1
https://home.miot-spec.com/s/dmaker.fan.p33
https://home.miot-spec.com/spec?type=urn:miot-spec-v2:device:fan:0000A005:dmaker-p33:1
Screenshots of the app show that there are differences regarding accessible controls through the app. The control name for speed adjustment differs:
(dmaker.fan.p18 / Mi Smart Standing Fan 2)
(dmaker.fan.p33 / Mi Smart Standing Fan 2 Pro)
These are pictures of the dmaker.fan.p33 / Mi Smart Standing Fan 2 Pro version (for the other one I haven't done the sull teardown yet but I could see inside that it's an ESP-WROOM-02D for both):
Unlike the Air Purifier devices that are already supported in this project these fans don't seem to have an easily accessible UART port so one probably has to flash directly on the pins of the ESP-WROOM-02D.
I checked plenty of contacts combinations for continuity but for the ESP-WROOM-02D I could only find test points for IO13 and IO15 on the backside of the PCB (marked in the pictures above) + 3.3V and GND. My hope is that IO13 and IO15 would work if I use them in the ESPHome config:
uart:
tx_pin: GPIO15
rx_pin: GPIO13
baud_rate: 115200
For Air Purifier 4 Lite the config looks like this:
uart:
tx_pin: GPIO17
rx_pin: GPIO16
baud_rate: 115200
and the docucmentation (ESP32-WROOM-32D - https://www.espressif.com/sites/default/files/documentation/esp32-wroom-32d_esp32-wroom-32u_datasheet_en.pdf) states this :
This is from the ESP-WROOM-02D documentation ( https://www.espressif.com/sites/default/files/documentation/esp-wroom-02u_esp-wroom-02d_datasheet_en.pdf ):
As a next step I will try backing up the original firmware and flashing the chip with ESPHome, starting with only a basic config and as a next step I would try if e.g. a switch added to the config would work. I'd be happy though if - in the meantime - maybe one of the pros here could share their opinion if these things I've summarized here make sense. Thank you!
The text was updated successfully, but these errors were encountered: