If you have got it in Google Home, you could use the Google Home SDK integration to send commands from HA to Google Home to control your Duux device.
It’s a workaround and not pure control via HA, but it should work.
EDIT: Looks like you can only turn them on/off via Google Assistant. Can’t set temp
I got the duux working on local tuya somewhat pleasing.
When I check the device in local tuya I see the extra 2 entities that I created by adding a select option when configuring the fan in local tuya integration.
See pic 1:
But when I add it to my dashboard I only see on/off and speed. I don’t know how to include the 2 custom properties that I added in the dashboard card.
It doesn’t sync these properties to Google home either.
Compared to my xiaomi fan that uses an integration where the fan settings are complete from the get go.
Any information how to add Duux Threesixty 2 to local tuya integration?
Hey folks. So I spent a few hours last night reverse engineering the Threesixty 2 protocol.
The Threesixty 2 connects to a cloud service and reports data back roughly every thirty seconds.
The protocol is MQTT over TLS. Because it doesn’t use certificate pinning or CA verification it was fairly straightforward to MitM.
After forcing the traffic through to my own MQTT server the commands to control it are pretty straightforward and I was able to control all of its features with mosquitto_pub.
Given the relative complexity of forwarding its traffic to your own server, I’m not sure there’s much value in trying to publish this for local control integration, it requires some specific network conditions that aren’t trivial to achieve for a normal user.
I’d be tempted to open it up and see how reversible the hardware is. From the traffic I was able to confirm that it’s running an ESP32, so flashing it with ESPHome isna possibility, but the pins would all need to be reversed engineered, and I haven’t looked inside to see how practical this is, I’ve only had the heater just over 24 hours at this point.
Since I’m not interested in cloud connected stuff I’m tempted to just return it as I don’t really want to spend the time with it disassembled in the hopes of being able to fully reverse engineer it, I’m not even sure his feasible it is until I take it apart, and even then, hoe many people will want to strio it down to flash the ESP if it’s possible?
I would be very interested if you could describe how to take it apart without destroying it. I haven’t looked at it yet to see if it would be feasible.
I would do it for the WAF alone. Then this device could also be operated under one surface by the gracious wife.
I have figured out how to create a button to toggle the Duux Threesixty 2 Heater on and off from the dashboard.
This may not be the most elegant way to handle this - but this seems do the trick.
I am not sure if the auth token will be expired but it works so far for a day.
Setup Node Red to create a flow to turn on and off the Duux heater.
Install the NodeRed Companion Component from the HACS
Create the Lovelace UI for the button
How to trigger a flow in node-red from HA lovelace ui? - #4 by Kermit
Hope this helps.
I didn’t take it apart to do my reverse engineering, just a MiTM and my own MQTT server.
I noticed on the bottom that the big sticker appears to have 4 screws under it, so I assume removing them will allow you to take it apart easily.
I’m not intending to do that myself as I have emailed Duux to ask about local API access, or the ability to set our own MQTT broker.
If they are unwilling, I plan to just return it for a refund, and I’ll document my findings publicly for someone else to play with.
EDIT: Just to be clear, I wasn’t doing what @terencekmchan is doing. I didn’t grab the Auth for their API and talk to their cloud, I hijacked their MQTT requests to and from the heater, redirecting them to my own local MQTT server and controlled the heater entirely locally.
The heater itself requires no authentication and it subscribes to a command topic that you can publish the simple commands to on your own MQTT server; the downside is that you have to do some DNAT on your network to make it happen and it’s not ideal for most users, it published all of its state information a couple of times a minute.
Hi,
Did you hear back from Duux at all?
Thanks
Yeah, just got a usual low level support response. “We don’t have plans to support that, bla bla, but I’ll pass it on to the development team”.
If you had any information on how to locate the Local Key for the device that would be amazing. Looks like my HA finds the new device but wants this key before I can get any further.
Thanks!
I’m not sure what Local Key is. Is this the Auth key for accessing their cloud API? How did you get HA to detect it? I can try dig a bit more, but I assume that’s using the cloud API?
It’s part of the configuration for the local Local Tuya integration. @tuffno mentioned getting it set up within that integration but you need the Local Key to add the device and I’m currently stuck at that point in the setup. I believe it’s outside the cloud API as it appears on a page after selecting “don’t configure cloud API”.
I believe we’re taking about different devices. I have the Threesixty 2, which does not appear to support Tuya/Local Tuya as far as I can tell.
That would be great, but as far as I know it’s not possible because of a different chip in the Threesixty 2. The previous model could probably be integrated into LocalTuya.
Could you already share some information about the procedure to get this working on a local MQTT server. What is the address for the MQTT server Duux is using? Can any MQTT server (with TLS?) be used to communicate with the Duux device?
I would also be interested in this information
The method I used involved DNAT to reroute all port 443 from the Duux to your MQTT server. I see no way currently to change the address. If you can get the traffic to your MQTT server then you can treat it like any other device. It may be possible to use a DNS override on your LAN to do it but I didn’t get a chance to try it yet.
I don’t have access to the hardware I did this on for the next week or so, I’ll be happy to publish my findings when I do.
I opened a Three Sixty 2 today and found out that there is indeed an ESP32 (wroom) inside.
Unfortunately, it doesn’t talk directly to the hardware (buttons, fan, heating elements).
Instead, the ESP32 seems to only be responsible for the wifi connection and has a serial connection with the main PCB.
I disconnected the ESP from the main board and tried to connect the ESP directly to my laptop and monitor this serial link, but without the connection to main PCB, it only spits out gibberish (at any baud rate) every 15 seconds.
Next step is to monitor the serial link while it is connected to the main PCB.
Or would anyone have another idea to reverse engineer?
I haven’t opened mine as I was planning to return it, I don’t like to support companies who do things like this (no local API, too much data shared).
If it uses a serial connection to the main board, this is good news, it means we can capture the commands and either reflash the ESP32 or fit a new one.
The best option is to tap the serial connection from start up to look for any initialisation commands, then watch out for data coming back.
I might just open and reverse engineer it for us if you’re not too sure what you’re looking at.
Thanks!
Would be great if you could have a look at it as i’m not quite sure how to decode the serial communication (i just use console in the arduino ide or putty, but the communication doesn’t seem to use ascii characters; i guess you would need to look at the raw hex…)
I will try myself if you decide to return yours as i really want local access and i have a couple of friends with the same device 
Unfortunately, my unit is in use most of the time so i need to find a moment where i could open it again
