Which ‘Duux App’ do you use? They have two - at this moment - and the ‘Gen1’ version is NOT compatible with ‘Gen2’ products, although they seem to label 'em with the same product name.
Recently I encountered the Duux customer service with this joke regarding their “new” app. And they are serious on it… sadly it seems their website is happy on it (The new Duux app | Duux | Designed for better air.).
Although I haven´t found out a way to configure ‘Gen1’-products with Tuya, it seems that ‘Gen2’ is a whole different kind of cookie…
Gen2 as that is required for my Threesixty 2 heater. I also have a (Gen1) Whisper Flex fan, and that was easy to pair using the Tuya Smart app.
From a user perspective there’s not much magic about the new app. It includes some scheduling and “insights” which are currently next to useless. That doesn’t matter to me as I am hoping to be leveraging HA for that. It looks like I might need to bring Google Home into the loop though.
i also have a DUUX 360, the control is now via a template (calculating nett solar power excess, a helper and automation) so ALEXA gets the boolean that my powerexcess is sufficient to switch on the DUUX 360.
Will see once the sun comes up.
If I understand you correctly, HA tells Alexa about your power, and Alexa tells the Duux when to switch on and off? Duux have just enabled the proper Google Assistant and Alexa integrations (here in NL anyway) so that is definitely an angle to investigate!
Yes, a template calculates the excesspower, a helper converts the type and toggles a boolean which is read by alexa. A routine in alexa switches the DUUX on/off. At least that is the intent, now waiting for the sun to provide the 1000W excess so i can see whether is really works.
Whether the on/off switching is triggered correctly is still unclear.
I have a DUUX Threesixty 2 which has the new chip and doesn’t support the old methods of adding it to Tuya. My workaround is similar to @acjtaal : use IFTTT Webhooks + Alexa to trigger commands and helpers + automation on the Home Assistant side.
How to:
In the DUUX App (Gen 2), set up the Alexa integration
In IFTTT, set up Alexa Actions by mkZense integrations. The free account allows you to set up 3 actions, you will need 2 of them. Make sure to not name them Heater since that can conflict with voice commands. I named them Virtual-Switch-On and -Off.
For powering on, you can also set the desired temperature. What I noticed is that if you set the temperatue, it will turn on in Mode III (high = 1800W). If you don’t set the temperature it uses the lowest Mode I = 800W in my case. I haven’t found a way to power it on in Mode II (~1200W).
In IFTTT: Create applets to turn the heater on and off. I use a webhook request with a specific event turn_duux_heater_on, which triggers the corresponding Alexa routine through mkzense (e.g. Virtual-Switch-On)
That should make the helper switch work (on/off). I’ve added 2 more bonus things:
Sometimes the Alexa routine doesn’t execute properly / needs a retry. I have a power plug meter, so for example I wrapped the turn_duux_heater_off in a Repeat/Until the power meter draw is < 1W, where I repeat + sleep 30 seconds until it’s off.
I have a separate temperature sensor in the room, which allows you to use Generic Thermostat - Home Assistant and have a nicer UX. It uses the helper switch to turn things on and off. This is what I added to my configuration.yaml.
I solved it by creating a helper: input_boolean.duux_on which is toggled by an automation (triggered each 5 mins). The automation checks whether the excess power provided by the solar panels is more than 800watts and if so, sets the boolean to ON.
There is a condition based on the actual room temperature which is provided by the thermostat of the central heating system so it stops at 20 degrees C.
The excess power calculation is a template in which i take the numeric values of the entities provided by the smart meter and calculate current_consumption - current_solar_production.
In ALEXA, a routine monitors the opening of the state of the boolean (i use nabu casa for the connection). And if the “latch opens” as ALEXA calls it, it switches the DUUX on. ALEXA-DUUX is via a skill in ALEXA. Vice versa when the excess power is too low (eg the dishwasher switches on).
Can you explain how you did that? How did you capture the tokens? I tried with a packet capture app on an Android phone using SSL MITM but that didn’t work - I assume it is checking the certificates. Do you have any docs on the cloudgarden API?
Curious to see if anyone is willing to set this up.
Perhaps you could open a feature request in the Home Assistant GitHub repo and provide the info you’ve discovered so far? See if somebody is willing to take this further?
Hi, we have a DUUX Threesixty 2. Since we don’t have anything from Alexa, I guess the above instructions are out of the question. I have the heater in Google Home but do not get it in the Home Assistant. I would also prefer a direct connection heater-Home Assistant.
Maybe there is a simple tutorial on how to do this.
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.
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 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.