Support for a smart tower fan

[frank-f]

I have a "smart" tower fan (Princess 350000, so Google can find this thread better) and it has a built-in ESP-WROOM-02 module. Unfortunately the fan permanently keeps a connection open to the manufacturer and every command (regardless if via touch controls or via the app) goes through their servers. Just what I had in mind, when I bought the thing... not.

So today I opened the fan to check if this shortcoming can be fixed. The fan has an unmarked control IC that takes care of everything regarding switching things on and off, touch controls, timer, displaying the current state (I guess they also make a version without App support). The control IC and the ESP are connected via UART.

I pulled out my logic analyser and recorded a bunch of commands. Now I have a long list and my ideal goal would be to integrate the fan controls into Tasmota. The protocol seems to be fairly simple. It has a two byte start sequence (aa a0) and then two bytes containing the actual command in a bitmasked fashion.

Sounds rather easy, but probably too complex to integrate into Tasmota without a custom driver? I don't know any C. I have recently read about Berry support, but haven't looked into that at all yet. Could my goal be achieved with Berry? At first glance it looks somewhat like Python, which I am familiar with. Otherwise, a hint in a direction of a driver that works in a similar way would be nice. I'd then try to modify that for my needs.

If anyone is interested I could share my notes about the protocol. I also dumped the software off of the ESP and flashed it onto another one. It does seem to work there as well, so it's probably not dongled to the chip id. Could be useful for debugging.

[barbudor]

You will need some kind of driver
But as it is an ESP32, it may be easier to design a driver in Berry scripting language (Python like) than a native C driver

Have a look at https://tasmota.github.io/docs/Berry/ and we can support you

[frank-f]

Ah, I'm sorry for the confusion. I did not realize, that Berry is not included in ESP8266 builds. ESP-WROOM-02 is an ESP8285 based module. So I guess I would need to figure out how to write a driver in C then... Any ideas which existing driver has similar functionality that I can use as a starting point?

[barbudor]

No need to be sorry, it's me who read too fast ESP32 where it was not written

I see a few drivers that are using the TasmotaSerial class that could be suitable:

• xdrv_44_miel_hvac
• xdrv_45_shelly_dmmer

These are quite large drivers but you should see

• how they are initialized and can handle POWER and DIMMER commands
• how they handle serial comm

There are many other drivers that use TasmotaSerial but mainly those are sensors or energy monitoring chip/devices so not really the best representative case.

[JojoS62]

@frank-f have you made progress controlling this device? I have the same fan and was also looking for same hackes. Have you reverse engineered the hardware for the fan an the touch buttons?

[frank-f]

I had analyzed the commands the ESP sends to the fan controller board to switch states, but I have zero experience in C and never found the time (and motivation, probably) to teach myself how to put this into code.

[JojoS62]

sounds interesting. I'm using Tasmota and I have some experience in C/C++ coding. Haven't written custom modules for Tasmota, but I think that will be not too difficult. Can you share the list of serial commands that you have discovered already?

[frank-f]

I couldn't find my notes from last year anymore, but I remembered that the protocol is pretty simple, so I just sniffed it all again.

Communication protocol is UART, 9600 baud, 8n1. The protocol is exactly identical in both directions.
Whenever any setting changes (no matter if via touch controls or phone App), the fan reports a full datagram to the ESP.

I tried to write down which bits need to be changed to achieve which state. I hope this makes any sense to you. If you have questions or need me to test something on my fan, just let me know. It'll leave it disassembled for now.

Datagram length    4 byte
Start sequence     Static (Hex AA A0)
Byte 3, Bits 1-6   Timer
Byte 3, Bit 7      Swing (1/0 = on/off)
Byte 3, Bit 8      ? (always 0)
Byte 4, Bits 1-3   Fan speed (1 = 110, 2 = 101, 3 = 111)
Byte 4, Bit 4      Mode natural (1/0 = on/off)
Byte 4, Bit 5      Mode sleep (1/0 = on/off)
Byte 4, Bit 6      ? (always 0)
Byte 4, Bits 7,8   Timer


Description   Hex            Binary

Switch off    AA A0 00 02    01010101 00000101 00000000 01000000

Fan speed 1   AA A0 00 03    01010101 00000101 xxxxxxxx 110xxxxx
Fan speed 2   AA A0 00 05                      xxxxxxxx 101xxxxx
Fan speed 3   AA A0 00 07                      xxxxxxxx 111xxxxx

Swing on      AA A0 40 03                      xxxxxx1x xxxxxxxx
Swing off     AA A0 00 03                      xxxxxx0x xxxxxxxx

Mode natural  AA A0 00 0B                      xxxxxxxx xxx10xxx
Mode sleep    AA A0 00 13                      xxxxxxxx xxx01xxx

Timer 0.5h    AA A0 03 C3                      110000xx xxxxxx11
Timer 1h      AA A0 07 83                      111000xx xxxxxx01
Timer 1.5h    AA A0 0B 43                      110100xx xxxxxx10
Timer 2h      AA A0 0F 03                      111100xx xxxxxx00
Timer 2.5h    AA A0 12 C3                      010010xx xxxxxx11
Timer 3h      AA A0 16 83                      011010xx xxxxxx01
Timer 3.5h    AA A0 1A 43                      010110xx xxxxxx10
Timer 4h      AA A0 1E 03                      011110xx xxxxxx00
Timer 4.5h    AA A0 21 C3                      100001xx xxxxxx11
Timer 5h      AA A0 25 83                      101001xx xxxxxx01
Timer 5.5h    AA A0 29 43                      100101xx xxxxxx10
Timer 6h      AA A0 2D 03                      101101xx xxxxxx00
Timer 6.5h    AA A0 30 C3                      000011xx xxxxxx11
Timer 7h      AA A0 34 83                      001011xx xxxxxx01
Timer 7.5h    AA A0 38 43                      000001xx xxxxxx10
Timer 8h      AA A0 3C 03                      001111xx xxxxxx00

[JojoS62]

thanks a lot, that looks really simple. Also the berry scritpting should be sufficient for this automation.
Are the programming pins for the ESP also accessible?
edit:
ok, its not the ESP32 and so no berry. I will try to setup Tasmota for compiling.

[frank-f]

Also the berry scritpting should be sufficient for this automation.

Unless something changed in the last few months, Berry is not available on ESP8266 or ESP8285 chips.

Are the programming pins for the ESP also accessible?

Pins are available, GPIO2 is not a pin however - you'll need to hold your wire to it during flashing.

[JojoS62]

That looks very hacker friendly :)
Then it will be easier to use an ESP32 and replace the original module, so the original could be changed back again.

The software has to and/or the command bits to the current state. I guess the fan controller is also sending the state cyclic or at least at power on.

[frank-f]

Then it will be easier to use an ESP32 and replace the original module, so the original could be changed back again.

I'd prefer to keep the existing hardware. After all it is a mains powered, moving device and the existing module is securely mounted in the case with three screws.
If one wants to put back the original firmware, they should dump it before flashing Tasmota - as with any other device.

The software has to and/or the command bits to the current state. I guess the fan controller is also sending the state cyclic or at least at power on.

I did not sniff the communication long enough to notice any cyclic message, but it reports the new state of operation after power-on - just like any other state change is reported.

[JojoS62]

the unknown bits are maybe for the coupling mode when power on is pressed for 6 s. I have disassembled my fan also and the next step is to add some opto couplers so that I can sniff the communication also.

[JojoS62]

I have now removed also the fan controller, I can't see any galvanic isolation, its a simple capacitor power supply. So ESP GND can be AC-L

[JojoS62]

I'm still busy to check what is necessary for a tasmota driver. I found that TuyaMCU uses the same concept of device and wifi controller with serial connection, but unfortunately has some different serial protocol.
Then I checked to integrate it into ioBroker sonoff adapter, but there is also a lot of hardcoded stuff and it is hard to analyze what is needed. With Berry I made some more progress, I think the easiest step is to use some control via commands and some states for feedback.

[sfromis]

As long as you are on ESP32 with Berry, that is probably the easiest way of creating a driver for the serial communication, unless possibly if you already are well-versed in C++.

[JojoS62]

@sfromis yes, you helped me already a lot on discord :) The orignal module in the fan is an ESP8285, but I don't have a problem with replacing it by a self designed ESP32 board, its nothing more than a simple breakout board.
Using some Arduino Code for mqtt control with the existing module is also possible, but I would like to use some 'standards' for integration into ioB or other systems. By evaluating, I see that standards are hard to find. To get a better understanding with Tasmota, testing with Berry helps also. That was also my question if its better to use Berry for exotic drivers or to integrate them into Tasmota native. But therefore its necessary to know what is already existing.

[sfromis]

Clear standards are not really done. Tasmota has a reasonably uniform way of reporting sensors and getting commands, which is well-suited to a backend using common parsing schemes.

The most problematic area for finding a standard is if you also want automatic discovery, including a device being able to tell what it is. Tasmota has been supporting Home Assistant "MQTT Discovery" which is a very specific HA structure, including lots of rather internal HA ways of doing certain things.

More recently, HA has gotten an improved Tasmota integration, with another style of discovery message from Tasmota. Somewhat more generalized, but still on the specialized end of the scale.

Of course, a rather important consideration for choosing ways of doing things is what you are comfortable with.

[0neday]

I have yeelight fan (identified id is yeelink.light.fancl5 ), which use UART communicate between esp32 and bp6601 (the hardware driver for fan) .

the yeelight fan stock firmware maybe use some check for comminication with Mijia Sever, so when I flash the stock firmware into a new esp32, that not work very fine.

I flash esphome, and use uart.write to write command, and work fine, do not need write C or python code for realize soft driver.

https://github.com/0neday/yeelight-c900/blob/main/yeelight-c900.yaml#L93