Can’t wait to see your results on reversing serial protocol.
I can help on the esp32 firmware code part.
Thanks for your elaboration.
I have reached the same by configuring Pihole to redirect all domains that my Duux device was requesting DNS for to a machine that listened to ports 443 and 80.
However, are you sure it’s MQTT protocol (which defaults to 1883 (plain) or 8883 (tls) since in my Unifi USG I only see port 443 to be used from the Duux device?
I’m curious about your thoughts/experiences.
It’s definitely MQTT, I’m certain of that.
Unfortunately, I’m now out of the race.
While capturing the UART I shorted something and blew up my laptop, my logic analyser and the heater.
Game over for me I’m afraid.
oof, that’s sad to here. I’ll play around futher in the hopes of capturing more info and will share it here.
Update:
Ok, I seem to have figured it out:
The Duux device seems to publish its state every few seconds to collector3.cloudgarden.nl. It uses MQTT over port 443, no very common setup, but using this port makes sure you don’t face firewall issues etc, and TLS is used.
The device publishes a telemetry message to topic “sensor/< device mac-address>/in” with this format:
{
"sub": {
"Tune": [
{
"uid": "<some identifying string>",
"id": 1,
"power": 1,
"sp": 28,
"temp": 16,
"mode": 2,
"status": 0,
"err": 0
}
]
}
}
It also publishes messages to topics “sensor/< device mac-address>/online”
{"online":true,"connectionType":"mqtt"}
and “sensor/< device mac-address>/update”
{"pid":"<that same identifier>","tune":"Threesixty 2023"}
but I haven’t figured out their purpose yet.
I’ve been able to get to this by setting up a local Mosquitto server configured with self signed TLS certificates, and by adding custom DNS entries in my Pi hole instance for the domains the device was doing DNS requests for. I made these DNS entries to point to the machine running the Mosquitto instance.
Next thing to do is figuring out how to send commands to the device…
Hi there,
I wrote a node-red module for my duux gen 2 humidifier (Beam 2) and intercepted the mqtt traffic. It also uses a esp32.
Try sending these plain-text commands to “sensor/< device mac-address>/command”.
The command is executed on the esp32 console. The tune command forwards the command to the controller.
tune set power 0
tune set power 1
tune set sp 30
tune set mode 1
and so on…
Hope this helps 
Jon
2 Likes
ha, thanks for these pointers. I’ll try to test this out hopefully tomorrow.
While capturing the UART I shorted something and blew up my laptop, my logic analyser and the heater.
Game over for me I’m afraid.
Oh no! I’m sorry to hear that. I hope the laptop can be repaired. Annoying as it is to lose a Threesixty, it’s not as valuable as a laptop!
To the Cloudgarden connector or to the Duux?
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.