Can this Kruidvat smart remote be used with OpenBK-flashed devices, or flashed to send MQTT directly?
Not with OpenBK at the moment: the remote uses a WR3 module, and WR3 support is planned but not yet functional [#20823592] The device appears to be a TuyaMCU-style design with an MCU talking to the Wi‑Fi module over UART, and the MCU can also switch the Wi‑Fi module’s power to save battery, so keeping Wi‑Fi always on would drain the batteries quickly [#20823799] To make it work with MQTT, the suggested path is to capture the TuyaMCU UART protocol with TuyaMCUAnalyzer and then configure Tasmota to react to the `TuyaReceived` event and publish MQTT messages for each button press [#20823799][#20825264] The capture may need to be separated per button so you can map each unique hex packet to a rule [#20825082][#20825264]
WR3 support is planned in the near future, but it's not currently functional. Please wait and check Elektroda from time to time, I will post the update when something changes. Still, it's interesting to see a WiFi module being used in a remote.
I've actually tried to replace the module with an ESP8266MOD (ESP-12E I think) with Tasmota flashed on it. The thing is now that the WiFi is not connecting/showing on my network after assembling back. I think I need to do some wiring changes to keep the WiFi module on all the time to be discovered.
P.S: Do you know any other remote controls that I can use with MQTT?
Ok ok, so now, the question is, do you know how this remote works? For me, it looks like a TuyaMCU device. It seems there is an MCU that is connected by UART to WiFi module:
In this particular case TuyaMCU may also control the power of WiFi module.
If you wire the WiFi module to be always on, the batteries will drain in a day or two. This is not the solution.
If you want to get it running, the correct way would be to check which protocol is TuyaMCU using with original Tuya firmware, do the capture with our tool:
https://github.com/openshwprojects/TuyaMCUAnalyzer and then try to configure Tasmota to work with that.
Can you try to do a TuyaMCU capture for that device? I don't know how much skilled you are with hot air and if it would be a problem...
But in general, for a remote control, I'd strongly suggest an IR or RF solution... this topic is actually the first time I see a WiFi remote.
Added after 6 [minutes]:
PS: On your photo, I can clearly see TX1/RX1 traces of UART1 port to the MCU. I can also see the transistor on the power line (with capacitors) that is controlled by TuyaMCU (by the MCU) to turn on and off the power of WiFi module when it's needed.
It'a a power saving method, the MCU is always on, but it's a lower power MCU, and WiFI module gets turned on only when there is a need to send data.
I'd say you need to script Tasmota to do things on TuyaReceived event, create separate rule for each button, just paste HEX and do something when it happens, like, idk, MQTT publish.
I can try to help you with that step by step, but I don't have much experience with Tasmota rules.
As per Blakadder site: Change device to a TuyaMCU module
Disable multipress button options to prevent a device reset or Wi-Fi AP config mode, disable Power Cycle recovery, turn on TuyaReceived publish to MQTT and set switchmode to follow instead of toggle
Rule1 ON TuyaReceived#Data=55AA00050005030400010213 DO publish2 stat/%topic%/button 1 ENDON
You must change hex string 55AA in the above example to the string you saw in the capture.
The following should make Tasmota publish data when this string is received.... in theory.
I am not sure how reliable it will be, maybe for a start, you can temporary route 3.3V permantently to VDD of WiFI module to do the setup, and then try it in the battery-powered mode... I dont know currently how will Tasmota respond to "publish2" command when it's not yet connected to WiFI, and it may happen on this remote very often. We need to experiment
Well, if that's the case, then you need to investigate each pin one by one and find out which is breaking ESP booting.
Is VDD and GND correctly connected?
Is RST correctly connected? Maybe it's somehow kept in RESET state?
How is GPIO0 connected? Maybe this board keeps ESP in uart bootloader mode, because it had non-ESP module earlier?
Do you have a photo showing the traces of the board before you swapped WiFI module to ESP one?
Here is a random "ESP12 minimal circuit" schematic from Google:
Keep in mind that I am showing it here just for reference, I haven't verified it with the datasheet.
Did you find the solution to get it working? I have exactly the same problem. (I want to get it working with Home Assistant) Can I maybe just flash ESPHome on the WR3 chip and configure the GPIO pins for each button?
✨ The discussion revolves around the compatibility of the Kruidvat Smart Remote with OpenBK flashed devices and the potential for MQTT linking. The remote utilizes a WR3 chip, and while support for this chip is planned, it is not yet functional. Users have explored replacing the module with an ESP8266MOD (ESP-12E) flashed with Tasmota, but encountered issues with WiFi connectivity. The remote appears to operate on a TuyaMCU protocol, which may require specific configurations in Tasmota to enable MQTT functionality. Suggestions include capturing the communication protocol and scripting Tasmota to respond to button presses. However, challenges remain regarding the proper wiring and booting of the ESP module. Generated by the language model.
TL;DR: WR3-based Kruidvat remote can drain batteries in 1–2 days if Wi‑Fi stays on; "batteries will drain in a day or two." Use TuyaMCU captures and Tasmota rules instead of OpenBK today. [Elektroda, p.kaczmarek2, post #20823799]
Why it matters: This helps DIYers link Kruidvat WR3 remotes to MQTT/Home Assistant without killing batteries or breaking boot states.
Is the Kruidvat WR3 remote compatible with OpenBK right now?
Not yet. WR3 support was stated as planned but not functional at the time discussed. Monitor updates and revisit when support lands. Meanwhile, consider a TuyaMCU + Tasmota rules approach for MQTT. [Elektroda, p.kaczmarek2, post #20823592]
Can I link this remote to MQTT without OpenBK firmware?
Yes. Treat it as a TuyaMCU-like device and handle its UART bytes with Tasmota rules. Publish MQTT messages on TuyaReceived events per button. This approach avoids relying on unfinished WR3 support. [Elektroda, p.kaczmarek2, post #20825264]
How do I set up Tasmota rules for button presses?
Use TuyaReceived with your captured hex. Example flow:
Set Module 54; run Backlog SetOption1 1; SetOption65 1; SetOption66 1; SwitchMode 1.
Add Rule1 ON TuyaReceived#Data= DO publish2 stat/%topic%/button 1 ENDON.
Why doesn’t my ESP8266 swap broadcast Wi‑Fi after reassembly?
Check power and boot pins. Verify VDD/GND continuity, ensure RST is high, and review GPIO0 state. Incorrect GPIO0/RST wiring can block normal boot. Investigate each pin to find what breaks boot. "Maybe this board keeps ESP in uart bootloader mode." [Elektroda, p.kaczmarek2, post #20825302]
Is it safe to keep the Wi‑Fi module powered constantly during setup?
You can temporarily feed 3.3V to keep it awake for setup, but expect trade-offs. Battery devices are designed to power-gate Wi‑Fi. Tasmota may try to publish before Wi‑Fi connects; test and iterate. Do not leave it permanently powered in production. [Elektroda, p.kaczmarek2, post #20825264]
My UART capture shows only MCUConf frames. What should I do?
That can happen on custom TuyaMCU variants. Don’t parse the full protocol; trigger on the exact byte pattern you captured. Use TuyaReceived#Data rules and publish the needed MQTT payload. Add separate rules for distinct button hex patterns. [Elektroda, p.kaczmarek2, post #20825264]
What actually powers the Wi‑Fi module on this remote?
A transistor, driven by the onboard MCU, gates the Wi‑Fi module’s VDD. The MCU stays awake at low power and enables Wi‑Fi only when needed. The UART1 TX1/RX1 connect the MCU and Wi‑Fi module. This design maximizes battery life. [Elektroda, p.kaczmarek2, post #20823799]
Will an always-on Wi‑Fi remote kill my batteries fast?
Yes. Expect battery drain in 1–2 days if you bypass the power-gating and keep Wi‑Fi on. "Batteries will drain in a day or two." Use the stock gating and event-driven rules instead. [Elektroda, p.kaczmarek2, post #20823799]
Can I flash ESPHome directly on a WR3 module?
Within this thread’s scope, no viable ESPHome path was provided. WR3 support for OpenBK was planned but not functional. Use Tasmota with TuyaReceived rules or wait for WR3 firmware support to mature. [Elektroda, p.kaczmarek2, post #20823592]
How do I capture the button protocol correctly?
Attach to the UART pins between MCU and Wi‑Fi and run TuyaMCUAnalyzer. Press each button and save the resulting hex. Those hex strings become your TuyaReceived rule triggers in Tasmota. Then map them to MQTT messages. [Elektroda, p.kaczmarek2, post #20823799]
Are IR or RF remotes a better choice than Wi‑Fi for MQTT?
Yes, for battery life and simplicity. The author recommends IR or RF remotes with gateways for automation. This Wi‑Fi remote is unusual and power-challenging by design. Consider IR/RF for robust, low-power control. [Elektroda, p.kaczmarek2, post #20823799]
Can I map each Kruidvat button to different MQTT topics?
Yes. Create a rule per button hex and publish distinct topics or payloads. Example: publish2 stat/%topic%/button 1 when a specific hex arrives. Repeat with different topics for other buttons. Test each press and verify broker messages. [Elektroda, p.kaczmarek2, post #20825264]
Where are the UART pins on the PCB, and how do I hook them?
The UART1 TX1/RX1 traces run between the MCU and the Wi‑Fi module. Tap those lines for protocol capture or debugging. Use a suitable USB‑UART adapter and common ground. Avoid loading the lines excessively during capture. [Elektroda, p.kaczmarek2, post #20823799]
What else can block ESP8266 boot on this board?
A button wired to GPIO0 can disrupt boot behavior. The user observed GPIO0 tied to a push button on this remote. Rework that path so GPIO0 is in a valid state at reset. Then retest normal boot. [Elektroda, mihaim1980, post #20825330]
Is there a known capture for this exact Kruidvat remote?
Yes, a capture was posted showing the UART traffic. Use it as a baseline to identify unique button frames. Build TuyaReceived rules from those hex strings. Expand as you discover more patterns. [Elektroda, mihaim1980, post #20825079]
