logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

Experience with LLXLJY 8-Channel Tuya Switch and OBK Compatibility?

io2345 6918 115
Best answers

Can the LLXLJY 8-channel Tuya switch be used with OBK, and how should it be flashed or configured?

Yes — the LLXLJY box turned out to be a BK7231N TuyaMCU device, so OBK compatibility is realistic; for flashing/backing up, choose BK7231N, and one user found that leaving the 3.3 V line disconnected during readback helped because the board was already powered via RX [#21212778 #21218438 #21218602]. OBK support became workable after newer TuyaMCU handling was added: the device uses relays on DPs 1–6 and 101/102, and with `tuyaMcu_setBaudRate 9600`, `tuyaMcu_defWiFiState 4`, `setChannelType ... Toggle`, and `linkTuyaMCUOutputToChannel ... bool ...` the eight relays could be toggled normally [#21223289 #21246749 #21247143]. The sticking point was TuyaMCU status handling (the 0x22 status-report path); once OBK learned to reply properly, relay control started behaving as expected [#21228786 #21229901 #21240579 #21245009]. If the relays behave linked or inverted, the original Tuya interlock settings are still likely stored, so resetting back to Tuya and clearing those settings fixed it for the user [#21247189 #21247345]. The RF remote is not learned in the app; pairing is done by pressing the onboard button five times quickly, then binding each remote button one by one [#21264721]
Generated by the language model.
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • #61 21246749
    DeDaMrAz
    Level 22  
    Posts: 600
    Help: 34
    Rate: 127
    @io2345

    Update to latest build - 1.17.738 and use the following autoexec and please respond back.

    Code: text Expand Select all Copy to clipboard
    startDriver TuyaMCU
tuyaMcu_setBaudRate 9600
tuyaMcu_defWiFiState 4

setChannelType 1 Toggle
setChannelType 2 Toggle
setChannelType 3 Toggle
setChannelType 4 Toggle
setChannelType 5 Toggle
setChannelType 6 Toggle
setChannelType 7 Toggle
setChannelType 8 Toggle


linkTuyaMCUOutputToChannel 1 bool 1
linkTuyaMCUOutputToChannel 2 bool 2
linkTuyaMCUOutputToChannel 3 bool 3
linkTuyaMCUOutputToChannel 4 bool 4
linkTuyaMCUOutputToChannel 5 bool 5
linkTuyaMCUOutputToChannel 6 bool 6
linkTuyaMCUOutputToChannel 101 bool 7
linkTuyaMCUOutputToChannel 102 bool 8


    Again, this is without reading initial states on reboot or remembereing the states, just toggling the channels!! So whatever you have set up with original FW will still be there!!

    Some pictures of the progress on my end:
    Dashboard of the OpenBK7231N device with eight toggle buttons and system details.

    Electronic setup with multiple cables, wires, and modules on a blue workbench.
  • ADVERTISEMENT
  • #62 21247143
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    DeDaMrAz wrote:
    Update to latest build - 1.17.738 and use the following autoexec and please respond back.

    Looks better. Relays can be switched on and off !!!
    Yet, some strange effects: Switching on relay 1 and after that relay 2, makes relay 1 go off. Switching it on again makes relay 1 go off. Same for 2 and 3 and combinations with relay 1. Same for combinations relay 4, 5 and 6. Relays 7 and 8 seem to not be affected.
    This strange behaviour might as well have somthing to do with the setting I did in the original FW: "Interlocking: participating=5 and number of channels per group=3"
    Will I have to flash back to original FW and reset all items, flash OBK again after that - or just wait, until "reading initial state" is implemented?
  • #63 21247189
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    This sounds like you have interlock enabled. You can either switch back to Tuya and disable it or check out the packets you've captured and determine which packet sets the interlock. Then we can use console commands to manually send the command to disable interlock from OBK.
    Helpful post? Buy me a coffee.
  • #64 21247345
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    Works now. Did flash the Tuya-FW again and then back to OBK.
  • #65 21247351
    DeDaMrAz
    Level 22  
    Posts: 600
    Help: 34
    Rate: 127
    So it works normally with OBK in terms of toggling relays, correct?

    We will look into reading initial state and everything else can be scripted via OBK so I wouldn't waste much time on other dpID's unless time allows.

    Let us know if you have anything else.
  • ADVERTISEMENT
  • #66 21247492
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    >>21247351
    Exactly, switching relays works as expected. Perfect!
    I'm fine with that. Of course it would be nice to set the initial state of the relays, but usually you do that only once. So this can be done in Tuya-FW before flashing OBK
  • #67 21247676
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    Initial state should be very, very easy with TextField channel type, you just need to know the dpIDs....
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/channelTypes.md
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #68 21261909
    DeDaMrAz
    Level 22  
    Posts: 600
    Help: 34
    Rate: 127
    Since this device uses TuyaMCU for saving states and startup flags will not work I have tested the following autoexec in standalone and with HA.

    Code: text Expand Select all Copy to clipboard
    startDriver TuyaMCU
tuyaMcu_setBaudRate 9600
tuyaMcu_defWiFiState 4

//get initial status
tuyaMcu_sendState 191 2 16

//link tuya output to OBK channels 
linkTuyaMCUOutputToChannel 1 bool 1
linkTuyaMCUOutputToChannel 2 bool 2
linkTuyaMCUOutputToChannel 3 bool 3
linkTuyaMCUOutputToChannel 4 bool 4
linkTuyaMCUOutputToChannel 5 bool 5
linkTuyaMCUOutputToChannel 6 bool 6
linkTuyaMCUOutputToChannel 101 bool 7
linkTuyaMCUOutputToChannel 102 bool 8

//set OBK channel types
setChannelType 1 Toggle
setChannelType 2 Toggle
setChannelType 3 Toggle
setChannelType 4 Toggle
setChannelType 5 Toggle
setChannelType 6 Toggle
setChannelType 7 Toggle
setChannelType 8 Toggle

//aliases for state saving in the tuyaMCU
alias SAVE1 backlog tuyaMcu_sendState 191 2 103; tuyaMcu_sendState 192 2 1; tuyaMcu_sendState 193 2 1
alias NOSAVE1 backlog tuyaMcu_sendState 191 2 103; tuyaMcu_sendState 192 2 1; tuyaMcu_sendState 193 2 0
alias SAVE2 backlog tuyaMcu_sendState 191 2 103; tuyaMcu_sendState 192 2 2; tuyaMcu_sendState 193 2 1
alias NOSAVE2 backlog tuyaMcu_sendState 191 2 103; tuyaMcu_sendState 192 2 2; tuyaMcu_sendState 193 2 0
alias SAVE3 backlog tuyaMcu_sendState 191 2 103; tuyaMcu_sendState 192 2 3; tuyaMcu_sendState 193 2 1
alias NOSAVE3 backlog tuyaMcu_sendState 191 2 103; tuyaMcu_sendState 192 2 3; tuyaMcu_sendState 193 2 0
alias SAVE4 backlog tuyaMcu_sendState 191 2 103; tuyaMcu_sendState 192 2 4; tuyaMcu_sendState 193 2 1
alias NOSAVE4 backlog tuyaMcu_sendState 191 2 103; tuyaMcu_sendState 192 2 4; tuyaMcu_sendState 193 2 0
alias SAVE5 backlog tuyaMcu_sendState 191 2 103; tuyaMcu_sendState 192 2 5; tuyaMcu_sendState 193 2 1
alias NOSAVE5 backlog tuyaMcu_sendState 191 2 103; tuyaMcu_sendState 192 2 5; tuyaMcu_sendState 193 2 0
alias SAVE6 backlog tuyaMcu_sendState 191 2 103; tuyaMcu_sendState 192 2 6; tuyaMcu_sendState 193 2 1
alias NOSAVE6 backlog tuyaMcu_sendState 191 2 103; tuyaMcu_sendState 192 2 6; tuyaMcu_sendState 193 2 0
alias SAVE7 backlog tuyaMcu_sendState 191 2 103; tuyaMcu_sendState 192 2 7; tuyaMcu_sendState 193 2 1
alias NOSAVE7 backlog tuyaMcu_sendState 191 2 103; tuyaMcu_sendState 192 2 7; tuyaMcu_sendState 193 2 0
alias SAVE8 backlog tuyaMcu_sendState 191 2 103; tuyaMcu_sendState 192 2 8; tuyaMcu_sendState 193 2 1
alias NOSAVE8 backlog tuyaMcu_sendState 191 2 103; tuyaMcu_sendState 192 2 8; tuyaMcu_sendState 193 2 0

//change handlers on every state change
addChangeHandler Channel1 == 1 SAVE1
addChangeHandler Channel1 == 0 NOSAVE1
addChangeHandler Channel2 == 1 SAVE2
addChangeHandler Channel2 == 0 NOSAVE2
addChangeHandler Channel3 == 1 SAVE3
addChangeHandler Channel3 == 0 NOSAVE3
addChangeHandler Channel4 == 1 SAVE4
addChangeHandler Channel4 == 0 NOSAVE4
addChangeHandler Channel5 == 1 SAVE5
addChangeHandler Channel5 == 0 NOSAVE5
addChangeHandler Channel6 == 1 SAVE6
addChangeHandler Channel6 == 0 NOSAVE6
addChangeHandler Channel7 == 1 SAVE7
addChangeHandler Channel7 == 0 NOSAVE7
addChangeHandler Channel8 == 1 SAVE8
addChangeHandler Channel8 == 0 NOSAVE8


    This will save every change each time it is made and if the device is restarted relay states will be retained. Caveat is that the changes will not be instant (there is a slight lag for transmitting commands) and if the device is unreachable via WiFi it will remember last states and the only way to reset them is the button on the device!!!

    We can probably do this in a different way with the option to chose to save state but reasoning is that if we can change the state it should stay that way.

    Let us know if there is any feedback and also if anybody comes up with a different way or better way.
  • #69 21262326
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    So this sets startup state?
    Code: text Expand Select all Copy to clipboard
    
tuyaMcu_sendState 193 2 0

    If 0 is off, and 1 is on, then maybe 2 is "remember previous"?
    Helpful post? Buy me a coffee.
  • #70 21264721
    DeDaMrAz
    Level 22  
    Posts: 600
    Help: 34
    Rate: 127
    p.kaczmarek2 wrote:
    If 0 is off, and 1 is on, then maybe 2 is "remember previous"?


    No, it didn't work unfortunately. Device is half baked or incomplete on the supporting SW side. Pairing of the RF remote was a painful experience, it can not be done via the app. The only way to pair a remote is to press onboard button 5 times in relatively quick succession, relay 1 will start to blink/click - that is pairing process activated. Then you proceed to click button one on your remote and once paired relay 2 will start to blink/click.. do that for all the channels/buttons. once done power cycle the device and try the remote.
  • ADVERTISEMENT
  • #71 21268070
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    I would need input lines, and thought it might be possible to use the COM Port connectors
    Close-up of a circuit board with visible pins and COM label.
    But connecting Pin-Holes 1 and 9 or connecting Pins to ground doesn't switch anything (using stock firmware).
    Any idea, if these are of any use for input purpose?
  • #72 21270089
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    Where are those pads connected? To MCU or to WiFi module?

    I think you need to connect to WiFi module pads directly. Then you can script them in OBK.
    Helpful post? Buy me a coffee.
  • #73 21271379
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    >>21270089 I Think it is the MCU, see picture. Close-up of a circuit board with an integrated circuit labeled 8H3K64S2.
    If I can connect it to the CBU module, it would be fine for me (just have to find out how to be safe with 230V input - maybe opto-coupler with 230V line detection. Something like that: AliExpress 230V Optocoupler module). Can I use any of the CBU-pins that are not connected to the mainboard? There are 14 pins without visible connection. Those would be:

    Pin 3 - P20, Common GPIO (Pin 20 of the IC)
    Pin 4 - P22, Common GPIO (Pin 18 of the IC)
    Pin 5 - P23, ADC (Pin 17 of the IC)
    Pin 6 - P1, UART RX2 (Pin 28 of the IC)
    Pin 7 - P0, UART TX2 (Pin 29 of the IC)
    Pin 8 - P8, IO with PWM hardware support (Pin 24 of the IC)
    PIN 9 - P7, IO with PWM hardware support (Pin 23 of the IC)
    Pin 10 - P6, IO with PWM hardware support (Pin 22 of the IC)
    Pin 11 - P26, IO with PWM hardware support (Pin 15 of the IC)
    Pin 12 - P24, IO with PWM hardware support (Pin 16 of the IC)
    Pin 17 - P28, Common GPIO (Pin 10 of the IC)
    Pin 19 - P9, Common GPIO (Pin 25 of the IC)
    Pin 20 - P17, Common GPIO, can be reused as SPI_MISO (Pin 14 of the IC)
    Pin 21 - P15, Common GPIO, can be reused as SPI_CS (Pin 13 of the IC)

    The UART Pins are probably not suitable, but the others should be useable.
  • #74 21272301
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    Of course you can use them, but remember, they are 0-3.3V levels, not even 5V, nor bigger. What do you want to do with them?
    Helpful post? Buy me a coffee.
  • #75 21272531
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    >>21272301 The inputs will receive the signal of the room thermostats and (as standard function) switch on the relays whenever the thermostat switches on. Remember, that I want to use this device as control center for floor heating valves? With it's help I should be able to supply functions like negative logic for the thermostats in summer (for cooling purpose) or warm-overload the floor heatings screed concrete by one degree when the sun provides electricity for free for the heat pump. ;-)

    Can you give me an example for one channel how to do the input detection by script? Let's say Input 1 (for control of relay 1) should be on Pin 1 of the CBU (Symbol P14, corresponds to Pin 11 of the IC). Signal HIGH on that Pin should switch relay 1 on.
  • Helpful post
    #76 21273718
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    If you have digital input on, let's say, P15, then you just need to set the P15 role to dInput (this will have internal pull up resistor enabled), and set the target channel to the same channel that your relay is using. Then, automatically, HIGH state on P15 will set Relay to HIGH state, and LOW state on P15 will set relay to LOW state.
    If you want to inverse the logic, then change dInput to dInput_n (negated).
    Helpful post? Buy me a coffee.
  • #77 21273887
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    Thank you. Wish it were that easy every time :-)

    For those who want to achieve the same. This is what you have to do: First, create an autoexec.bat in Web Application and insert the code shown in Thread 61 ("save, reset SVM and run file..."). Set Config as shown here ("Save"):

    Screenshot of a web application interface configuration with pin settings.

    If you connect now these CBU Pins to GND, the appropriate relais will switch on:

    Diagram of an electronic module with pins labeled CBU and GND.
  • #78 21275094
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    As there are no important user controls (other than the reset button on the device - don't use it when connected to 230V): once installed in a safe plastic box, you can as well do the 230V input detection the easy way. The chinese devices use a similar method:

    Diagram showing a circuit for detecting 230 V with components like diodes, resistors, and a transistor.

    You will need the same for every input that you want to do 230V detection for.
    R5, R6, D1, D2 and LED are optional, as LED will only show if S1 is switched on or not. R1 and connection to U+ can be skipped, if the input on the CBU has pullup activated, which is true for the config in Thread #77.

    As always when connection to high voltage is present: Be careful, 230V can kill you. Preferably use the optocoupler module mentioned in Thread #73
  • #79 21275589
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    Are you sure about this circuit? Would it also work correctly in case of a voltage spike on L?
    Helpful post? Buy me a coffee.
  • #81 21275597
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    Maybe a varistor could help. Tuya device manufacturers also sometimes put one, but they also often just leave an empty place on PCB for it.
    Helpful post? Buy me a coffee.
  • #82 21276471
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    >>21275592 Can't test it, don't have the necessary components at hand. But I opened a switch I had lying around, and they do very much the same here, only that they are using a MOSFET instead of a bipolar transistor:

    Close-up of a circuit board with electronic components, including resistors and SMD transistors.

    They have R3, R4 at only 150 kOhm, R2 at 7,5 KOhm. Transistor is a 2300 SMD. The capacitor I can't measure (but according to the above link in #80 it should also be 100nF). Doesn't look like X2 at all. Under normal working conditions there shouldn't be more than 10 Volt at the capacitor anyway.
  • #83 21323836
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    Is PowerSave working for Chipset BK7231N? No matter if I set nothing, or PowerSave 1 or 2, temperature stays at 47 degrees.
  • #84 21329215
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    >>21323836 Or does it have to do something with the communication between CBU and TuyaMCU? Maybe they are talking with each other non-stop? How can I tell?
  • #85 21329223
    DeDaMrAz
    Level 22  
    Posts: 600
    Help: 34
    Rate: 127
    @io2345

    PowerSave feature is 0 for off and 1 for on, it works on N modules well and 47'C temp is not that much, I would even say it is low.
    Also power save has no meaningful impact on the temp on tuyaMCU devices as you noticed, they need to communicate constantly, more impact is noticed on standalone BK7231 devices.
  • #86 21330580
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    TuyaMCU has to exchange Heartbeat packets all the time, but I don't think it affects power usage much. There are other things that affects power save, for example, PowerSave will not work good if you keep your Web App Logs tab open in the browser.
    Helpful post? Buy me a coffee.
  • #87 21330716
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    >>21330580 Of course, Webpage isn't open constantly. Temperature just made me think if it's normal, compared to other devices I have - like a smart plug with LN882H chipset, which is at 31 degrees (with PowerSave 1).
  • #88 21422892
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    Pimped version with MOSFET relays instead of mechanical ones (I use only 6 channels). No significant power usage and noiseless.

    Close-up of an electronic circuit board with components, including MOSFET relays and screw terminals.

    As you can see, I also stripped off the RC-part, as I have no use for that.

    Idea was born here: Link
  • #89 21422925
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    What is the maximum power for each channel now?
    Helpful post? Buy me a coffee.
  • #90 21422968
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    >>21422925 With this version of "relay" (Omron G3VM-601EY) you can switch 23 watts (100 mA).
    Omron G3VM-601CR/FR would allow up to 140 watts.
Reply | New topic
Report a violation of the law

Topic summary

✨ The discussion centers on the LLXLJY 8-channel Tuya smart switch, focusing on its compatibility with OpenBK (OBK) firmware and integration challenges. The device uses a BK7231N chipset with TuyaMCU architecture, communicating via UART at 9600 baud. Initial firmware backup and flashing to OBK were successful, enabling relay toggling through OBK's web interface. However, issues such as relay interlocking behavior and incomplete initial state reading were noted, linked to TuyaMCU's handling of device states and DP (Data Point) IDs. Extensive TuyaMCU packet captures were performed to map DP IDs to functions like relay switching, jog setting, interlocking, delayed open/close, and power-on settings. The community developed OBK autoexec scripts to link TuyaMCU outputs to OBK channels, allowing relay control and partial state management. Input detection via unused GPIO pins on the CBU module was explored for thermostat integration, with digital inputs configured as dInput or dInput_n to control relays based on thermostat signals. Hardware modifications included replacing mechanical relays with low-power MOSFET relays (Omron G3VM-601EY) for silent operation and reduced power consumption. Challenges remain in fully implementing initial state synchronization, interpreting complex DP IDs, and transmitting input states via MQTT. The device's RF remote pairing requires manual onboard button presses, as app-based pairing is unsupported. PowerSave mode on BK7231N shows limited effect due to continuous TuyaMCU communication. Overall, the device is functional with OBK for relay control, with ongoing efforts to enhance full feature support and input state reporting.
Generated by the language model.
Today's popular

FAQ

TL;DR: This 8-channel board uses 8 relays and, as one contributor put it, "it is definitely MCU". For OpenBeken users, the working path is BK7231N + TuyaMCU at 9600 baud, with relays mapped to dpIDs 1-6, 101, and 102; stable eight-relay control was confirmed after OBK 1.17.738. [#21246749]

Why it matters: This FAQ saves time for anyone trying to convert the LLXLJY 8-channel Tuya switch to OpenBeken without breaking backup, UART capture, or relay control.

Option What happened Practical result
BK7231M backup mode "non-standard encryption key" warning and no usable backup Wrong target for this board
BK7231N backup mode 2 MB dump succeeded Correct chip family/mode
Early OBK builds Relays could switch on but not reliably off 0x22 status handling incomplete
OBK 1.17.738 + autoexec All 8 relays toggled correctly Confirmed working setup

Key insight: The hardware is OpenBeken-compatible, but only because it is a TuyaMCU design. You must treat the Wi-Fi module as a UART bridge to the MCU, not as a simple direct-relay controller. [#21247676]

Quick Facts

  • The successful stock-firmware backup produced a 2 MB dump, used BK7231N mode, detected GD25Q16B flash, and found the Tuya config magic at 2023424. [#21218602]
  • The confirmed working TuyaMCU serial speed was 9600 baud; using 115200 in autoexec caused incorrect behavior during early setup. [#21228256]
  • Final relay mapping was dpIDs 1-6, 101, 102 for the eight outputs, with menu/control functions concentrated around dpIDs 170-199. [#21223289]
  • On this TuyaMCU device, PowerSave did not meaningfully lower the reported module temperature; the user still saw about 47°C, and constant MCU communication was cited as the reason. [#21329223]
  • A later solid-state relay mod used Omron G3VM-601EY parts rated for about 23 W / 100 mA per channel, while G3VM-601CR/FR was noted as allowing up to 140 W. [#21422968]

How do I flash OpenBK7231N on the LLXLJY 8-channel Tuya switch and get all eight relays working with TuyaMCU?

Use BK7231N firmware, not BK7231M, then configure TuyaMCU at 9600 baud. 1. Back up the original 2 MB flash. 2. Flash an OpenBK7231N QIO build. 3. In autoexec.bat, start TuyaMCU, set baud to 9600, set channels 1-8 as Toggle, and link dpIDs 1-6, 101, and 102 to channels 1-8. Relay toggling was confirmed working after updating to OBK 1.17.738 with that mapping. [#21246749]

Why does the LLXLJY 8-channel switch backup fail in BK7231M mode with a 'non-standard encryption key' warning, and why does BK7231N mode work instead?

It fails because this board uses a BK7231N-based CBU module, not BK7231M. In BK7231M mode, the tool read an encryption key and showed a "non-standard encryption key" warning, then produced no saved result. In BK7231N mode, the same flash chip, GD25Q16B, was detected and the full 2 MB backup succeeded once the wiring was corrected. That makes the warning a mode mismatch symptom here, not proof that backup is impossible. [#21218602]

What wiring should I use to back up the original firmware from this CBU/BK7231N Tuya board without powering the whole circuit incorrectly?

Use only GND, TX, and RX for backup, and do not connect the 3.3 V line. The successful report said the 3.3 V lead powered the rest of the board and caused read failures. With only ground plus UART lines connected, backup worked and the board was identified as a likely TuyaMCU device. The same post also noted that the required power was present on the RX line during that readback setup. [#21218602]

How can I capture TuyaMCU UART packets on this LLXLJY board to identify dpIDs for relay control and advanced functions?

Capture the Wi-Fi-module-to-MCU line for app actions, and the MCU-to-Wi-Fi line for physical events. 1. Use two USB-UART adapters to record both lines, or one adapter in two separate passes. 2. Save one capture per action, such as toggle_relay1.txt. 3. Change exactly one setting each time, because mixed captures make dpID decoding harder. The thread explicitly recommended separate captures for each relay and each menu function. [#21220533]

What is TuyaMCU, and how does it affect OpenBeken compatibility on Tuya relay boards like the LLXLJY 8-channel switch?

"TuyaMCU" is a secondary microcontroller that handles device logic and exchanges serial dpID packets with the Wi-Fi module, instead of letting the Wi-Fi chip drive relays directly. On this board, that means OpenBeken must speak the Tuya serial protocol over UART, including heartbeat and status packets. The board was identified as definitely MCU-based, and that is why correct TuyaMCU mapping matters more than simple GPIO relay assignment. [#21218700]

What is dpID in the Tuya protocol, and which dpIDs were identified for the eight relay outputs and menu functions on this device?

"dpID" is a Tuya data-point identifier that names one control or status field in the MCU protocol, such as a relay state, timer string, or menu parameter. On this device, relay outputs were identified as dpIDs 1-6, 101, and 102. Menu and parameter areas included 170 for page-like state, 171-175 for string controls such as timers, 182-189 for numeric values, 191 for operation/menu selection, and 192-195 for menu-dependent values. [#21223289]

How do I configure autoexec.bat in OBK for the LLXLJY 8-channel switch so channels 1-8 map correctly to dpIDs 1-6, 101, and 102?

Create autoexec.bat with TuyaMCU started at 9600 baud, then map the eight bool dpIDs to channels 1-8. The confirmed pattern was linkTuyaMCUOutputToChannel 1 bool 1 through 6 bool 6, then 101 bool 7 and 102 bool 8. Set channels 1-8 to Toggle before or after linking. That exact structure was posted as the working eight-relay setup for OBK 1.17.738. [#21246749]

Why did the relays switch on but not off in early OBK builds, and how was command 0x22 status reporting involved?

They failed because the MCU kept sending command 0x22 status reports and OBK did not fully handle them yet. The logs showed repeated cmd 34 messages, which is decimal 34 for hex 0x22, marked as unknown and unhandled. Another contributor pointed out that the MCU waits for an acknowledgment to status reports, so incomplete 0x22 handling could block normal state changes. After OBK added 0x22 reply support and then parsing based on 0x07-like data, relay behavior improved. [#21228786]

Which OBK version finally fixed relay toggling on this TuyaMCU-based 8-channel board, and what autoexec setup was confirmed to work?

OBK 1.17.738 was the version that finally gave confirmed on/off control for all eight relays. The working autoexec used startDriver TuyaMCU, tuyaMcu_setBaudRate 9600, tuyaMcu_defWiFiState 4, set channels 1-8 to Toggle, and linked dpIDs 1-6, 101, and 102 to channels 1-8. After flashing that build, the user reported: all relays switched on and off, with only leftover Tuya settings causing temporary odd behavior. [#21247143]

How can I disable leftover Tuya settings like interlock or jog mode after flashing OBK if the relays behave strangely?

Restore stock Tuya firmware, reset the unwanted MCU-side settings, then flash OBK again. The thread showed that odd relay behavior, such as one relay turning another off, came from old interlock settings still stored in the TuyaMCU. After reflashing Tuya firmware and then returning to OBK, relay toggling worked normally. That is the safest cleanup path when interlock, jog, or power-on rules persist across OBK flashes. [#21247345]

What's the difference between using stock Tuya firmware settings and scripting the same behavior in OpenBeken for jog, delayed open/close, and interlocking?

Stock Tuya firmware stores those features inside the MCU, while OpenBeken can reproduce most of them with scripts and channel logic. The thread identified menu items for jog, power-on setting, interlocking, delayed open, delayed close, and timing, but the user noted these are also easy to implement in home automation. The practical difference is persistence and complexity: Tuya stores MCU-side behavior directly, while OBK gives more flexible logic but may require custom scripting. [#21219836]

How do I use free CBU GPIO pins as digital inputs in OpenBeken to control the LLXLJY relays from room thermostats?

Use unused CBU GPIOs as dInput or dInput_n and assign them to the same target channels as the relays. The thread confirmed that free pins on the CBU can be used because they are normal 0-3.3 V GPIOs. The recommended method was simple: set the chosen pin role to dInput for normal logic or dInput_n for inverted logic, and point it to the relay’s channel. A later test confirmed this worked for thermostat-driven relay control. [#21273718]

How can I script heating and cooling logic in OBK so thermostat inputs control floor-heating valves with normal or inverted logic depending on mode?

Use separate input channels and one mode channel, then copy or invert values in a loop. The confirmed pattern was: thermostat inputs on channels 9-16, relays on 1-8, and a mode flag on channel 20. When channel 20 was 0, the script used SetChannel 1 $CH9 and so on. When channel 20 was 1, it used negation such as SetChannel 1 !$CH9. The user reported that this script worked immediately after being added to autoexec.bat. [#21473876]

What are the safest ways to detect 230V thermostat signals for CBU GPIO inputs, and when should I use an optocoupler instead of a simple transistor circuit?

Use an optocoupler when you need the safest isolation from 230 V thermostat lines. The thread discussed a simpler transistor-based AC detection idea, but it was explicitly questioned for surge tolerance and voltage-spike safety. The user later recommended a separate optocoupler module as the safer choice and used one in the final installation. That is the better approach whenever mains voltage is present near the GPIO input path. [#21275094]

Why doesn't PowerSave reduce temperature much on a BK7231N TuyaMCU device like this one, and what actually affects heat and idle power use?

PowerSave has little effect here because TuyaMCU devices must keep talking over UART. One contributor stated that PowerSave works on BK7231N, but on TuyaMCU boards it does not meaningfully reduce temperature because the module and MCU communicate constantly. Another contributor added that open WebApp logs also hurt PowerSave behavior. In the reported case, the module stayed around 47°C, which was described as not unusually high for this design. [#21330580]
Generated by the language model.
ADVERTISEMENT