Cloud-Free Control for Niveo Smart Tuya Fan Heater Using OpenBeken and Home Assistant

Hi all,

We've recently converted a floor of an only occasionally used building to use an R290 Midea Xtreme Save Blue climate control inverter for heating during winter. This works awesome, but I have no solution for the little bathroom on the floor yet. For that room I need frost protection even if no one is in, and when I'm there I want to be able to bring it at least to 18–20 °C.
Basically, the only thing that makes sense in that case is a small wall-mounted fan-heater in my view.
I want this thing to be smart, to have timer programs available. Essentially two things pop up then: Either unknown Tuya-based stuff or the Dreo fans. I really like the Dreo 517s, but I understand there has not been real cloud-cutting for these yet, which would disqualify them, although I prefer their hardware.

I then found this thing for only 60€, available in Germany:
https://www.airsain.de/atlantis-media/files/niveo-smart-manual-en-rev01.pdf

As far as I can see this uses the completely generic Tuya App. I have extremely extensive experience with Tasmota and some with ESPHome, but I am completely new to OpenBeken.

Or is there maybe already something and I did not find it? The only thing I found was a cloudcutter-profile for a heater called BPT-2000B but without any further documentation.

So I'm now coming here to ask: Do you think this heater is cloud-cuttable while maintaining all functions (including frost protection)? For schedules I obviously will use Home Assistant.
But will, e.g., the remote control still work?

I'm completely comfortable with taking this thing apart and posting stuff here and maybe making this another template/tutorial also for others to use, but I guess I will need some assistance as the ecosystem is completely new to me.
I got lab supplies, logic analyzers, oscilloscope, multimeter, good solder equipment etc., all on hand, so that's not a problem if at all needed.

Thanks for advice/help in advance!
AI: Could you provide the exact brand and model number of the Tuya-based fan heater you’re considering (ideally with a product link or photo of the label)?
https://www.airsain.de/produkt/argoclima-niveo-smart/
AI: If you already have the heater, could you share details or photos of the internal hardware—especially the Wi-Fi module or main control board—so we can check compatibility with OpenBeken and cloudcutter?
I do not have it yet and want to explore whether it is worth getting.

Thank you for posting. We can try to get it working for you, but as you said, we need some information first. Can you make few photos from inside?

I'd suspect that your device is probably using TuyaMCU, so our process will be following this guide:
https://www.elektroda.com/rtvforum/topic4038151.html

markusdd wrote:

The only thing I found was a cloudcutter-profile for a heater called BPT-2000B but without any further documentation.

that cloudcutter profile came from a dump taken from this device https://www.elektroda.com/rtvforum/topic4097185-120.html#21762995

It seems to be the case that heaters/air conditioning/stoves/kettles type of device favour RTL8720CF modules, often WBR3.

I think it'd be mostly down to luck to get a device that can be cloudcut, even then it would probably need a full dump for a new profile to be created. Whatever you do get, you may need to be prepared to take apart and maybe desolder.

Added after 5 [minutes]:

markusdd wrote:

Either unknown Tuya-based stuff or the Dreo fans. I really like the Dreo 517s, but I understand there has not been real cloud-cutting for these yet, which would disqualify them, although I prefer their hardware.

of the two dumps we have for Dreo devices, neither are Tuya, so this would disqualify Dreo for cloudcutter anyway - assuming Dreo is still/all non-Tuya

Thanks, guys, for the replies. Yes, Dreo is 100% confirmed NOT Tuya. (not sure which processors/MCUs they use though)
They maintain an own HA integration and are saying they will support full local control but I will not buy into a non-existing feature.

So I will probably order one of these Niveo Smart heaters and have a peek inside. At €60 it's not the end of the world if it goes wrong.

Soldering, measuring, etc. is not at all an issue, happy (and able) to do all that.
It would be awesome if we can get that working.

I will read the links you provided and get back once I have such a thing on hand.

markusdd wrote:

not sure which processors/MCUs they use though

well, the two Dreo dumps are from Belon BL2028N MCUs, which are just Beken BK7231N, so supported by OpenBK.

>>21849621

Mmm... so you are saying the 517s would be worth a try then?

I guess we would lose some convenience in the process, but generally it would work?

EDIT: Just noticed one of the dumps is actually a 517s. Did anything ever come out of those?

OK, here we go. The device is here.
WBR3 module inside. From looking at the PCB, I would say it's very clearly a TuyaMCU setup. There's only two data wires going to the MCU below it. Seems like a GigaDevice thing or similar.

So how do we go about this now?

EDIT: Also connected UART adapter to the A16 UART log pin and logged the startup. I attached the log as a txt. Keep in mind this was just with the MCU board on my desk, where I fed it 5V and GND at the input that normally comes from the motor/power supply board.

So @divadiow and @p.kaczmarek2, I have unsoldered the module and wanted a firmware dump.

Using a serial terminal I see this:

So that should be fine. Using the GUI Flash tool, after I closed the serial terminal, I tried to do a dump only without writing a new firmware yet.
But nothing happens; it is stuck in that state:




What to do? UART adapter is a WCHLink (company that makes the CH340), so that should be more than good for the job.

Hi. I've been working on a revised rtl2 branch of Easy Flasher that I hope will resolve issues relating to failed links, reads, writes etc. it'd be great, if you have the time and want, to get your feedback on it.

https://github.com/divadiow/BK7231GUIFlashTool/actions/runs/22612943136

If you do, please give backup a go at different bauds up to 3000000

[postid:d94ad299b7]21853503 [/postid:d94ad299b7]
  

woohoo! 115200 is failing but 230400 seems to succeed already.

Added after 8 [minutes]:


Ok I'm running through all of them now but Baud rates seem to work north of 115200.

And it is confirmed: TuyaMCU



So what next?

----

EDIT: Based on stuff I found here I tried to use the dev platform and I got the following codes extracted:

thank for trying it out. I do get more retries at lower bauds, but no hard fails. Maybe your cables are long? I'll continue to fiddle.

regarding the TuyaMCU config, you should get the Query Things Data Model json and get Ai to make it pretty. This contains the dpIDs and their values. eg:

>>21853603

I used my SublimeText skills to make it pretty, here we go:



EDIT: Let Grok translate the chinese stuff:



EDIT: Also have attached the firmware dump

EDIT:
Mmh. I now used the Gui Flasher to finally flash the device, but it seems to be bootlooping:
DISREGARD. It was ne UART adapter now running out of power with Wifi on, with lab supply it starts.

I will now resolder the module and then we get to play with the config.

I have now used Grok to write an autoexec.bat for me out of the JSON.
Comparing this to the examples it looks somewhat sane to me but clearly it is not fully correct.

E.g. the power toggle works, but it immidiately turns off again. Temperature is displayed as 0.



Here I need a bit of help now.

Not bad, you figured a lot already. AI also helped a bit, but it also introduced some issues.

For a start, I don't think we parse # comments, so they are parsed as futher link arguments.
So this:

Is matched to this:

So... # is parsed as obk flags (0), Temp is parsed as mult (0), and Calibration as inv (0)

Lol. It really was just the comments. And the order for the fanspeed enum was wrong.




As far as I can see, this is working:



That being said: This would work great. My only gripe is that this thing is actually much louder than I anticipated. Which is a shame.

So my question would be: Do you think we would have a shot at getting the Dreo working?
We know we can flash it with OpenBeken, question is if we can figure out the UART comms.

markusdd wrote:

question is if we can figure out the UART comms.

yes. I'd say this is the unknown.

device list add https://github.com/OpenBekenIOT/webapp/pull/273

>>21853895

Thanks for adding it to the db so quickly! I think this will be very useful for many people as there is a lot of these 1000 W/2000 W wall heaters out there with all different cases but very similar specs. My suspicion is that they are basically the same under the hood. So whatever is here should be readily adaptable.

And thanks so much for the help.

As for the Dreo: I got a proper logic analyzer, and we have the previous dreo-cloudcutter work on GitHub available. I do not believe things will be massively different.
Sure, will be a bit of work, but if we get it running, this will a) make me very happy and b) probably hundreds to thousands of others as well.

So if you are willing to assist as well, I'd start another thread.

I keep the Argo anyway because I can use it elsewhere if need be (and it was cheap). I was able to order the Dreo 517s with a coupon and on discount, so I got one coming on Friday.

Seems we got a fun weekend ahead. Meanwhile I will look into integrating the Argo in Home Assistant to see how well it plays there.

Added after 1 [hours] 29 [minutes]:




Ok, I still might require some more info on HA integration.
I followed the standard mqtt discovery step and things do show up.
When I do change something on the openbeken page, it also updates in HA. But all controls I try do not work via MQTT. And most importantly: The set temperature control is completely missing. So I cannot even set the temp form HA right now.

Also, it of course would be nice to have the most iimportant controls as a Thermostat. Any hints?

So @divadiow or @p.kaczmarek2, I need some assistance here. I have set flags now so that the status shows up in Home Assistant and is retained, but all controls do not work.
The temperature control is completely missing when I use dimmer, I have to use TextField (which is not as nice when using the device web UI).

Is there any way to configure it so MQTT works as easily as Tasmota does? Or is there now another config that needs to be written so MQTT controls actually work from HA?

In the logs I see this when I press the power button:



So there is a set on channel 1 with payload 1 received. So what is the issue? Why is it not applied?

hmm. not sure I am knowledgeable enough about how the MQTT/HA stuff ties in. @DeDaMrAz and other will know more

I haven't yet played with TuyaMCU based device of that kind but I do have one similar on the bench. It is not easy for me to do any of the work remotely, I need to have a device in hand but will try to look into the issue.

>>21855859

My guess is it's just a relatively basic config issue.
I have flags 2, 10, 19, 21, 30, 35, and 45 set.

I used Home Assistant discovery.

I see all elements in HA now, and status is reported properly. I just need to find out why MQTT commands do not get executed; everything else is working nicely.

markusdd wrote:

my guess is it is just a relatively basic config issue.

It's not, to get the climate/boiler type controls in HA we need to implement that for OBK and TUyaMCU devices

>>21855865

As long as we have switches, etc., you can also build a climate entity in HA out of other basic entities.
But even the basic entities, like the power on/off toggle, don't work via MQTT, I think that is the problem.

Exporting a full climate entity to HA would, of course, be super convenient, but it's not a blocker as such for now.

@DeDaMrAz, would you be able to provide more guidance how to debug this? I am aware we are not publishing a complete climate entity yet, but still selecting the modes by enums or even just a simple power on/off should work via MQTT.
The value updates in HA are clearly working with the flags provided and I can also see the controls. But I guess there is some mismatch in what OBK expects and what HA is sending.
Based on the MQTT log in OBK, I felt it's receiving the correct stuff, but it's not acting on it.

Any idea how to proceed? It would be a shame to get that thing that far and then have MQTT not working.

It's probably all fine on HA side but the TuyaMCU driver for OBK side is not built to deal with that kind of a payload where all dpID's are bunched up as a single command/string (similar to AC units).

@p.kaczmarek2 has way more experience with TuyaMCU devices than I do and may be able to provide more assistance, unfortunately without the device on the bench I can not.

>>21857172

I see. What I do not get, though: It works when we push the button in web interface, meaning the TuyaMCU driver is generating the right command packet.
I would've thought via MQTT cmd we just essentially command OBK to 'push that button'.
And I mean here with the Argo, compared to the Dreo, this is complete standard TuyaMCU right?

Oh, so I got those two mixed up then Dreo is the one where those captures came from.

Can you monitor the OBK log in webapp and provide some info what is going on when you press the buttons Vs when you trigger them in HA (or even on the device)?

>>21857189

Haha indeed, yeah the Dreo needs its own driver flavor; this is a bigger construction site if OBK wants to support it.

At least here I gave a log with the power button with the Argo from this thread here. https://www.elektroda.com/rtvforum/topic4166319.html#21855527

So there is a set command on channel 1 received.

Here is another try. First red arrow is what pops up when I do it in HA. There is clearly a set command being received, but nothing happens.

The second arrow pops up when I press the web UI power button. It recognizes it is now on and pushes that state to MQTT as well. I can then see in HA that the toggle moves to on.

So is there a parameter missing on the set command or something? This must be something stupid simple.

It looks like you have empty device name, how is this possible? What do you have in Configure Names?

>>21857239

I have this.



But I guess this could be a problem? I thought it just takes the short name when left empty?


This is the MQTT info from HA. This indeed looks a bit weird.