The commands are sent to the add-on controllerboard (as seen in the images above) from the esp32.
So 100% local, no cloud included. I have successfully set it up without any internet connection at all, it does not seem to stop even if the “call-home” and “OTA check” functions are blocked.
Ah, you bypassed the ESP32, so your suggestion is to try and send the commands over the UART cable to the controller board right?
That would be interesting indeed. If it works, we can add our own ESP32 board with ESPHome’s UART bus (and leave the Duux one alone so it can be restored).
Thanks guys, I also succeed to force to a local mqtt using pihole local dns.
Next step will be to replace the esp32 too but for now it works already really good using mqtt.
Cheers
Thank you for all the informations here.
I am able to control a duux heater threesixty 2 with mqtt base on @runnane informations:
tune set power 0
tune set power 1
tune set sp 30 → target temp
tune set mode 0 → high power mode
tune set mode 1 → medium power mode
tune set mode 2 → low power mode
Can you share how you achieved this? I would like to send mqtt commands from HA to control my Threesixty 2 as well
You need to have your own local DNS server. Your DHCP server has to set this DNS to clients.
Then add a DNS entry ( here I use piHole ) for collector3.cloudgarden.nl pointing to your Mosquito server.
Mosquito should be configured to listen on port 443 with TLS. You need to setup a self signed certificate for this domain.
If everything is ok, you should see the Duux device connected to your mqtt instance.
Then use the mqtt topics described below to control your device.
Hey folks, so I got a new heater and fixed my laptop (full mainboard replacement; ouch).
I had wanted to replace esp32 entirely but having had lots of time to think about it, its probably best not to for most people (including myself); there is some safety functionality built in such as the tilt switch (for if it falls over) as well as the 30-second cool-down timer; though I’m confident I can program these features, I wouldn’t like to take responsibility for anyone else using it.
What I did find before I blew everything up is that the main board with all the high-voltage stuff is required in a setup-handshake of some sort; capturing the outputs of the esp board alone doesnt provide anything useful.
I have thought some more about how i managed to blow up my laptop and the heater, it was all wired correctly; my guess at this point is that because I used a C to C cable to connect my LA, which might not have negotiated power properly, my laptop may have sinked several amps though the LA and connected equipment or vice versa.
I don’t really want to make a second attempt at this point so I think the DNS solution is the best option.
With the weather being pretty decent in the UK at the moment, the heater isn’t in use so I probably won’t give it any more attention until later in the year.
Hi,
I bought a Whisper flex smart fan and was also wondering if it is possible to replace the wifi module. I took the base apart and found the same exact board as previously pictured. I immediatly bought a usb to tty adapter and hooked it up to the wifi daugther board and saw some interesting output.
54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 55 AA 20 20 20 20 FF
This leads me to believe the protocol they use is just basically the Tuya serial protocol. Im now looking at options to capture the communication between the MCU and the wifi daughter board.
I found a way to capture the uart traffic and this is what i found:
off: 55 aa 00 06 00 05 01 01 00 01 00 0d
on: 55 aa 00 06 00 05 01 01 00 01 01 0e
set speed: 55 aa 00 06 00 05 03 04 00 01 <speed in hex 1-26> 19
mode natural: 55 aa 00 06 00 05 02 04 00 01 01 12
mode normal: 55 aa 00 06 00 05 02 04 00 01 00 11
mode night: 55 aa 00 06 00 05 02 04 00 01 00 11
horizontal oscillation off: 55 aa 00 06 00 05 04 04 00 01 00 13
horizontal oscillation on: 55 aa 00 06 00 05 04 04 00 01 01 14
vertical oscillation on: 55 aa 00 06 00 05 05 04 00 01 01 15
vertical oscillation off: 55 aa 00 06 00 05 05 04 00 01 00 14
1 Like
Was looking at getting a Duux fan, saw they hard a smart variant and stumbled upon this topic while checking for HA support for that. The above seems to confirm what I found elsewhere: it probably makes use of a Tuya MCU.
Both Tasmota and ESPHome pages for this device seem to match up as well (though tbf, one could’ve just been copied over to the other).
Checking the datapoints in the configrations on those pages, these seem to correspond with the bytes shown in the post by @Wolfo-Gaming
This suggests the main board is really only responsible for connectivity and the question then becomes; is this (still?) and ESP board or did they replace it with something else.
If it still is, replacing the stock firmware with ESPHome configured to talk to the Tuya MCU should keep all functions operating but provide direct/native/local HA support shouldn’t it?
Hi,
I successfully replaced the wifi module with an esp8266, however its not optimal since there still seems to be some issues in the communication. It seems to work sometimes but not all the time (maybe because of the weird uart situation on the esp8266). The error im getting on the esphome logs is Initialization failed at init_state 3
I can confirm the main board still uses a ESP module (i dont remember exactly but i think it was a esp32) and the wifi board is the esp32-d0wd-v3.
I dont have access to the fan right now, but im certainly going to look more into why the communication doesnt work sometimes (and maybe make a pcb that you can just plug and screw in). If someone is interested in maybe replacing the firmware on the original wifi board im going to need some help figuring out what pins do what on the debug port (that 10 pin connector)
Replacing the firmware on the wifi board with ESPHome and leaving the Tuya MCU as-is seemed like the easiest way to go about things if you don’t care about returning to the original/vendor firmware. You would keep the device’s functionality working and untouched (buttons, remotes, etc) whilst replacing the ‘smart’ part that locks you into a vendor specific system. We would indeed need to figure out the pins to be able to flash it.
I don’t have a fan in my possession at the moment but I’m thinking of just getting the smart variant regardless of whether this can work in the end or not. Worst case it’ll just end up being used like the dumb/standard variant.
Im currently not in the possesion of a multimeter (mine died unfortunately) however im going to buy a new one so when that arrives im going to look into the pins situation for flashing esphome
1 Like
Fan arrived today, a quick measurement gives me the following information (transposed onto the photo that was made earlier in this topic):
I do not have a logic analyser so I have not been able to figure out which is the 3.3V and which is the Tx out of those two, nor which of the three 0V ones would be the Rx or reset pin and such.
EDIT: Looks like I may have drawn some lines onto the wrong pins, will make an update post later with some additional measurements and a table instead.
The connector is a Tag-Comnect (https://www.tag-connect.com/), they connect to a JTAG debugger so it’s entirely possible it has a standard pin-out.
I’ve not had time to look more into this and I still haven’t replaced my logic analyzer as I spent enough replacing my laptop and heater already 
I def. do not have anything for JTAG related stuff to check that sadly. I honestly just assumed the connector is masking a classic TTL UART since it’s an ESP board. I suppose that’s not a guarantee but I can’t line up the multitool measurements with what I can find as a supposed pin-out for JTAG either.
That said, I’ve almost never done this so I’m probably not looking in the right place, measuring incorrectly or JTAG has multiple standards/variants or something.
In the mean time, continuing under the assumption it is just a TTL UART masked under this connector, I took some new/additional measurements with the device connected and powered on (not just continuity testing). For the pins numbered as:
it becomes something along the lines of the following:
| Pin | R → GND | Voltage | Possible Options |
|---|---|---|---|
| 1 | ~1.1k | ~3.28 | 3.3V |
| 2 | - | ~3.26 | 3.3V |
| 3 | - | ~3.55-3.56 | 3.3V |
| 4 | ~3.1M | ~3.25 | 3.3V |
| 5 | 11k | ~3.28 | 3.3V |
| 6 | 3.2M | 0 ↔ ~3.28 | TX |
| 7 | - | ~0.5m | RX, RST |
| 8 | 0.1 | 0 | GND |
| 9 | - | ~0.2m | RX, RST |
| 10 | - | ~1.5m | RX, RST |
It would be great if someone with the right tools and know-how could actually check things out though 
1 Like
My multimeter will arrive tomorrow so i will have a look at the pins.
My plan is using the pinout of the esp package as a source and just figuring out where they go. I think it will be difficult though since i think the pcb is 3 layers (correct me if im wrong)
Also i must mention i ordered a logic analyzer too!
My multimeter arrived and i got straight to work. What i have found now is:
U0TXD = P11
GPIO0 = P13
U0RXD = P10
GND = P3
these refer to the pads on the back, so i think we dont need the 10 pin for flashing(??). Besides that i would also like to dump the current firmware so we can maybe figure out a way for OTA flashing
i have gotten some success on connecting to the pins, and i got some interesting output (i put it in 2 parts, because of the changing baud rate)
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4852
load:0x40078000,len:13688
load:0x40080400,len:3904
entry 0x40080688```
HW_VERSION: 20
FW_VERSION: 14.3.9
Fri Jun9 10:30:24 2023
Mac Address : <mac addr>
====FACTORY TEST MODE ACTIVE!====
{"tune":2,"fw":"14.3.9","id":"<mac addr>","pin":1}
Sending Tuya: CMD=0x00VERSION=0 DATA=[(0)] INIT_STATE=0
Name: DUUX.1.229173
Local time: Thu Jan 1 01:00:03 1970
[E][cg_cloud_device.cpp:693] readAndHandleConfigFile(): No time sync, abort!
[WIFI] start scan
[WIFI] Connecting to <wifi> @ ch11
Sending heartbeat
Sending Tuya: CMD=0x00 VERSION=0 DATA=[(0)] INIT_STATE=0
[WIFI]Connect timeout: 6
[WiFi]Connect Timeout > Failed with status 4
[WIFI] start scan
[WIFI] Connecting to <wifi> @ ch11
[WiFi]connected 192.168.2.18
null
[E][cg_cloud_device.cpp:1072] mqtt_event_handler_cb(): MQTT_EVENT_CONNECTED
[mqtt]connected!
TOPIC=sensor/<mac addr>/command
Running: 'tune set power 1'
Usage: tune device not connected!
[mqtt]No method tune set power 1 found
TOPIC=sensor/<mac addr>/config
Sending heartbeat
Sending Tuya: CMD=0x00 VERSION=0 DATA=[(0)] INIT_STATE=0
null
[E][cg_time.cpp:13] time_sync_notification_cb(): Got NTP sync!
Local time: Wed Jul 24 14:05:26 2024
Local time: Wed Jul 24 14:05:26 2024
Sending heartbeat
Sending Tuya: CMD=0x00 VERSION=0 DATA=[(0)] INIT_STATE=0
Sending heartbeat
Sending Tuya: CMD=0x00 VERSION=0 DATA=[(0)] INIT_STATE=0
{"bt":1721822727}
Sending heartbeat
Sending Tuya: CMD=0x00 VERSION=0 DATA=[(0)] INIT_STATE=0
Sending heartbeat
Sending Tuya: CMD=0x00 VERSION=0 DATA=[(0)] INIT_STATE=0
null
Sending heartbeat
Sending Tuya: CMD=0x00 VERSION=0 DATA=[(0)] INIT_STATE=0
This is funny though, since it seems they left it in factory test mode
EDIT: i got esptool to work and i am now in progress of dumping the firmware
EDIT2: Since i cant reply to the topic, ill just edit this message.
I got ESPhome on the wifi module, however iam having a VERY weird issue. The MCU just keeps logging [I][tuya:156]: MCU restarted however when i open the logs on homeassistant it suddenly start working and im able to control the fan. Does anyone maybe know what this could relate to?
The “mqtt/dns hack” works perfectly well with the Duux Whisper Flex connected fan…
Same topics as above (sensor/mac address/in, /online and /update).
The status info for this fan is
{
"sub": {
"Tune": [
{
"uid": "<some identifier>",
"id": 1,
"power": 1,
"mode": 2,
"speed": 1,
"swing": 1,
"tilt": 0,
"timer": 0
}
]
}
}
The commands are sent to sensors/mac address/command with the same set tune name value commands:
- set tune power 1/0 => turn the fan on or off
- set tune speed 1/26 => select the speed of the fan
- set tilt 0/1 => enable/disable the vertical swing
- set swing 0/1 => enable/disable the horizontal swing
- set mode 0/1/2 => fan mode (0 = normal, 1 = natural wind, 2 = night)
- set timer 0…12 => auto-off (from 0=off to 12 hours)
K.