If you have pre gen. 3 hardware, that might be the only option if you don’t want to rely on the “cloud” yes, but the local REST API introduced in gen 3 is “good enough” as far as I am concerned. There are a couple of things that don’t work, at least on my devices, and there are multiple shortcomings in the documentation, but all in all it lets you do what you need (the commercial lock for example seems to be broken, it’s supposed to let you program an upper and lower “allowed temperature” that can be set to using the display/buttons).
Sure, it isn’t open-source, and it DOES communicate with Amazon servers even if you turn “cloud communication” off, but it does much less communication with it turned off than when turned on. According to the documentation, the device has no battery backed RTC, so that it will go online to get the correct time after every reboot. If it used NTP, that would be just fine, but I’ve found no trace of NTP traffic in the firewall logs, so it probably fetches the current time from Amazon servers instead - stupidly. But, the device only needs to “know” the time if you want to use the built-in schedules. I haven’t implemented, and don’t intend to, those API calls. I mean, when using it with OH, it’s much better, and more flexible, to let OH do this, to make whatever rules you want for raising/lowering temperatures at different times of the day, in weekends or when you’re away. So, the only thing that actually bothers me is that it never seems to “give up” on trying to contact Amazon to get the time, and keeps doing that every 3 seconds “forever” until I let it through. It must also do something more than fetch the time, as it contacts 3 different Amazon servers after booting. But, I digress, what I’m trying to say is that I think the “local API” gives sufficient control that you don’t need to do a hardware mod like the one described above, even if a few things should ideally be changed to make it “perfect”.
There are downsides to such mods too, if you actually want to replicate what the heater can do today, there will be quite a lot of work to make the software for your replacement controller. Also, they seem to have changed the design for gen 3, I have opened one of my devices up, and the “controller” and the “Wi-Fi chip” are one and the same from what I can tell.
It is not just a “simple” on/off thermostat, it uses PWM to regulate the heating element and runs a software PID controller to control how much heat to apply. Add with things like “open-window” functions and tuning of PID parameters, and there’s really quite a lot to “replicate” in your “replacement software” if you want to make your own that does roughly the same. Not to mention that you also have to implement the control of the display and the buttons, configuration menus etc.
Ideally they would open-source the whole firmware so that we could improve it, but companies are always worried that somebody else will copy their products, so that probably won’t happen. As such, the local API is a good compromise. The problem is that they haven’t responded to any questions on GitHub since 2022, and there has been no updates to the documentation for more recent firmware versions, so I don’t know if their heart is really in the local API. But, that also depends on how much “support” it gets in home automation systems like OH, so making bindings and similar available, so that the local API actually has “real value for customers” might help to convince them not to drop support for it in the future.
The project for the gen 2 device looks very similar to what I am planning for my dehumidifier, except that I’m not so lucky that the controller is connected by wires, so I have to desolder the WBR3 and solder the ESP32 in the same spot. That opens the possibility of breaking the whole thing, of course, and is far from ideal. I’m really happy the fewer such projects I must undertake.
