logo elektroda
logo elektroda
X
logo elektroda

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

io2345 6915 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
  • #91 21423127
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14416
    Help: 650
    Rate: 12371
    Just 23W? So... you have to be extra careful and you can't just connect plain old classic 60W bulb?

    That's certainly something to keep in mind, especially for other family members.

    So, how much power did it take with all 8 channels on and how much power it takes now?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #92 21423166
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    >>21423127 I connect floor heating actuators (those thermal ones with melting wax inside). They are around 2 watts each.
    I don't remember how much power the relays consumed - but I remember that my first attempt with a 5V/0,5A power supply failed with all 8 relays powered. Had to use a 1A type. Consider, that during winter the floor heating is switched on almost all the time, for several weeks. That's a lot of power, and next you might have a temperature problem in a closed box, that I want to use.
    Now you need only the power for the internal LEDs that need to lit. Almost nothing. Maybe 10mA for all 6 MOSFET-relays?
  • #93 21434832
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    I could use one more hint, please. Remember, that I activated input detection here: Link
    Now, how can I read the actual value of the input, not the switched value? Because currently, when I have a signal on - let's say - input 2 (which is P22 on the chip), the device switches output 2 to "active" and the state indicator "get" changes accordingly to "1". But if I switch the channel 2 now to "off" in the webpage (which is the same as setting the "set" value to "0"), the "set" and "get" value will both be set to "0", and I cannot detect the real value for input 2 (which is still "1") any longer. Maybe, the mentioned "get" value isn't the input value at all, but the value for the output state (?). But how to get the value for the input, then?
    Is there a way to get that done?
  • ADVERTISEMENT
  • #94 21435820
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14416
    Help: 650
    Rate: 12371
    I'm not sure if I understand?
    - if you are using dInput, then you can use dInput_n to invert logic
    - if you are using ToggleChannelOnToggle, then it should just work - it works with bistable switch, it will toggle target channel on switch toggle
    - if you have just a touch button or a classic button, then you can use Button, with optional immediate button reaction flag
    What are you exactly trying to do?

    You could try using dInput along with change callback to simulate yourself ToggleChannelOnToggle behaviour but still read dInput value, but why...
    Helpful post? Buy me a coffee.
  • #95 21436563
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    >>21435820 Let's make an example: For heating, a "1" (thermo switch is on) on input X will set output to "1", valve will open, room is heating up. Thermo switch then changes to "0", accordingly valve will close.
    Now for cooling purpose, I have to invert logic: When thermo switch is "0", cooling has to start. So I have to set the output to "1", using the "SET" variable. But now the "GET" variable will change to "1" as well. Room is cooling down, thermo switch changes to "1" - but nothing happens now, cooling will run eternally unless input changes to "0" again. But that only happens on manual interaction, like turning the knob on the thermo switch.
  • #96 21437902
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    >>21436563 If I think longer about it, probably both "GET" and "SET" values belong to the output side, right?
  • #97 21438177
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14416
    Help: 650
    Rate: 12371
    I've been reading your post for like 10x already at various times of the day and I am still not sure if I understand....

    Would you be able to draw a schematic, what is exactly on your inputs and outputs, and how you want to script them?

    If you want to give HIGH signal to show the temperature is too low, then you can use dInput with Relay on the same channel. It will set relay to HIGH as long as temperature is too low - this will be a very simple heating.

    If you want to inverse logic, you can either change dInput to dInput_n or Relay to Relay_n.

    Of course, temperature control is usually more tricky than that, and you may want to have some kind of deadtime, so maybe it would be better to have temperature as a variable (channel) and use change handlers or a loop in OBK script to enable/disable heating within a certain margin.

    Or do you mean that you want to use a single channel for both cooling and heating?

    PS: You can't use SET when you have dInput, because dInput will SET given channel to value that is read from pin. So it makes no sense to use SET at the same time. It creates a race condition when two methods of setting channel fight each other.

    SET can be used where you have a Relay and want to set it externally, via HA, etc
    Helpful post? Buy me a coffee.
  • #98 21439204
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    Thank you for your patience and effort. I made a schematic picture. It shows the original setup, the one with the relay only, and the final one with relay and input. Don't get confused about "dInput_n" and "dInput", it's just that there is an optocoupler inbetween, who inverts logic on the input side...

    Diagram comparing three electronic configurations for a thermostatic switch and actuator.

    It also shows the OBK configuration and what I see in ioBroker.

    Basic Version: If the thermo switch is on, the actuator is activ. Simple.

    Relais only: If you switch the button on the OBK page to ON, the GET variable is "1" and the relais will activate the actuator. Same, if you or a script does set the SET variable to "1" - this will also change the state of the button on the OBK page. (This doesn't work the other way round - the SET variable will always stay on the value that you or the script did set).

    Relais with input: Same as above, just that the thermo switch can activate the actuator again. Working fine for heating: Thermo switch goes on in cold room, Input is activ, output activates actuator. Later, the thermo switch goes off, Input is inactive, output is inactive. Excellent.
    For cooling, you would have to reconfigure the Input from "dInput_n" to "dInput", which is probably not possible via script (is it?). Otherwise you will get into this situation: Thermo switch is off, because room is hot. To activate cooling, a script has to activate the output when the cooling machine starts to run, which means that it has to change the "SET" variable to "1". After a while the room is cold, thermo switch will go on - but that doesn't change anything, as output is already on, so cooling will not stop.
  • ADVERTISEMENT
  • #99 21445066
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    With "TglChanOnTgl" I can get around somehow (of course) - but that's far from being perfect. When device restarts and has no information about the current signal on input, you have a 50:50 chance that you will end up with inverted logic.
  • #100 21447792
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    @p.kaczmarek2 Still no idea how to transmit the input value via MQTT?
  • #101 21448054
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14416
    Help: 650
    Rate: 12371
    I'm still having problems understanding what are you exactly trying to achieve. You have one thermo switch and you want to use it for both cooling and heating?

    Can you give a list of separate sensors and outputs you have? Do you have one thermo switch - or two? Do you have a separate cooler and heater? Or by "cooling" you mean turn off the heater...

    io2345 wrote:

    For cooling, you would have to reconfigure the Input from "dInput_n" to "dInput", which is probably not possible via script (is it?).

    It is possible:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/commands.md
    but it doesn't seem like a good solution.

    io2345 wrote:

    (This doesn't work the other way round - the SET variable will always stay on the value that you or the script did set).

    What do you mean? You can set any channel to either 0 or 1. No problem.

    io2345 wrote:

    Otherwise you will get into this situation: Thermo switch is off, because room is hot. To activate cooling, a script has to activate the output when the cooling machine starts to run, which means that it has to change the "SET" variable to "1". After a while the room is cold, thermo switch will go on - but that doesn't change anything, as output is already on, so cooling will not stop.

    What kind of script sets "SET" variable? You mean OBK script or what?
    If you do in OBK script:
    
    again:
    delay_s 1
    setChannel 5 $CH4
    goto again
    

    it sets channel 5 to value of channel 4 easily in every second. You can do negation:
    
    again:
    delay_s 1
    setChannel 5 0==$CH4
    goto again
    

    or even (If I remember correctly)
    
    again:
    delay_s 1
    setChannel 5 !$CH4
    goto again
    

    Then you can introduce extra channel that describes mode of operation:
    
    again:
    delay_s 1
    // mode 1
    if $CH6==0  then  setChannel 5 !$CH4
    // mode 2 - sample
    if $CH6==1 then  setChannel 5 $CH4
    // mode 3 - always on
    if $CH6==2 then setChannel 5 1
    // mode 4 - always off
    if $CH6==3 then setChannel 5 0
    goto again
    

    So many options, depending on what you want to do

    io2345 wrote:

    Still no idea how to transmit the input value via MQTT?

    This is incorrect approach, please consider doing it totally other way around. Input just reads digital pin value, nothing else. It's not supposed to be sent via MQTT.


    I still don't even know if you have separate cooler and heater or just a single heater or what, but if I were to implement it, I'd so something like:
    - one channel to hold mode - Automatic, Force On, Force Off ?
    - gui for mode change
    - dInput for thermo switch to know if room is hold
    - Relay to enable heater
    - manually in script, in a loop, check if mode is automatic, then setChannel of relay to value from dInput (you can use ! if you want negation), else if mode is forced, then set forced state
    I could also add a "timer" mode.

    I would love to make such script for you, but I would need to know more exactly which inputs and outputs you have. Which requirements.
    Please fill a list, and forget about "SET" variable:
    1. Inputs:
    - thermo switch (gives 1 when room is cold)
    - ......
    - ......
    2. Ouputs
    - heater (when enables, heats up the room)
    - ......
    - ......
    3. Control requirements
    - I want to be able to either run automatic heating, or force it off, or force it on via OBK main panel
    - ......
    - ......
    Helpful post? Buy me a coffee.
  • #102 21448265
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    >>21448054 Thank you for your fast response. To be honest, I didn't think about the vast possiblities that could be present - probably, because the situation on my side is the most simple setup that could be: There is just one thermo switch (the one for the room) on the input side and one valve (the one for the floor heating/cooling) on the output side of the relay. There is hot water running through the floor heating circle on cold days. And cold water is circling in the same circle, when the cooling equipment is running.
    The status of the cooling equipment (on or off) is transmitted to a home automation software, which is ioBroker in my case.

    Input (for the relay) is 0 when room is cold and 1 when hot. (I already said that the logic on the relais' input is inverted, due to the opto coupler that I have to use between thermo switch and relay input)

    Output is always the valve. 0 when closed, 1 to open the floor heating/cooling circle.

    Control requirements: Everything should work without human interaction - and that's the point: Currently (without relay, just the basic setup in the schematic, so we have only switch and valve), you have to open the valve manually in cooling condition by setting the thermo switch to maximum temperature, as the logic for the valve to open is inverted: valve now has to be open when room is hot (unlike for heating condition, when valve has to close when the room is hot).
    We can use scripts in ioBroker or on the OBK-device, but probably ioBroker is better, because there is already the information about the status of the cooling device as well as the output status of the relay.

    What I still didn't understand so far: Is it possible to change the OBK-configuration at runtime (and which command should that be - I didn't find anything promising in the command list)? Because it would be easiest to change the input configuration from dInput_n to dInput for cooling condition as it is exactly what's happening: Inverted logic on the input side when it comes to cooling condition. But this information (cooling yes or no) can only be provided by ioBroker, so the script to reconfigure OBK-Input has to be initiated there.
  • #103 21449536
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    >>21448054 In case that the reconfiguration of the input has to be done on the OBK-device itself, and an OBK-script needs information about the status of the cooling device: Is it possible to use a virtual channel to store the information? The relais uses eight channels for hardware. If it is possible to add a ninth channel in software, where ioBroker could set a "1" as long as the cooling device is running, would that be of any help? We could have then a local OBK-script running on the device, that checks periodically (like once a minute) for this information on the ninth channel, and if the value changes, it inverts the input-values on the eight hardware channels.
  • #104 21462528
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    @p.kaczmarek2
    One source of the misunderstandings is probably, that I know too little about OBK and you know too much ;-)
    So if you try to explain something to me, it might be similar like telling a stone age man how ETFs work...

    For me, a "channel" in OBK was a set of input and output. But it turned out, that a channel isn't necessarily that. It also can be only input or only output.
    Until now, I had configured the eight inputs on the same channel as the outputs. Now, I configured them to channels 9-16 and also introduced an additional channel #20 to display the status of the cooling device (this channel is set by a ioBroker-script to "1" when cooling is running) with the role "Rel" - just to be displayed on the devices page.

    So now I have separate variables for input and output in ioBroker and could do everything from there with the help of some scripts.
    But as you already suggested to create some script for OBK, it might be better in terms of system stability (home automation software or other infrastructure could fail) to script behaviour in OBK itself. Could you do that?:

    If channel 20 has a value of "0" (which is the default): Map input channel # 9 to relais channel 1, input 10 to output 2, input 11 to output 3 and so on, until all eight input/output-combinations are set. When dInput_n on input-channels is "1", let output be "1"
    If channel 20 has a value of "1": Invert output logic: When dInput_n is "1", let output be "0"

    It is sufficient to check for changes on status-channel 20 only once a minute. System behaviour of floor heating is very slow anyway.

    Autoexec.bat:
    startDriver TuyaMCU
    tuyaMcu_setBaudRate 9600
    tuyaMcu_defWiFiState 4
    
    setChannelType 1 Toggle
    SetChannelLabel 1 "KA"
    setChannelType 2 Toggle
    SetChannelLabel 2 "Badboden"
    setChannelType 3 Toggle
    SetChannelLabel 3 "Bad HT"
    setChannelType 4 Toggle
    SetChannelLabel 4 "Schlaf"
    setChannelType 5 Toggle
    SetChannelLabel 5 "Küche"
    setChannelType 6 Toggle
    SetChannelLabel 6 "Wohn"
    setChannelType 7 Toggle
    SetChannelLabel 7 "KI"
    setChannelType 8 Toggle
    SetChannelLabel 8 "Flur"
    setChannelType 20 Toggle
    SetChannelLabel 20 "Kühlung"
    
    
    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


    Graphical interface showing dropdown lists and values assigned to various ports.
  • #105 21473799
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    io2345 wrote:
    as you already suggested to create some script for OBK, it might be better in terms of system stability (home automation software or other infrastructure could fail) to script behaviour in OBK itself. Could you do that?


    @p.kaczmarek2
    Please be so kind and let me know, if you will try to provide an approriate script or not. No problem, if you don't want to, or have no spare time. I will try to find a different solution, then. But at least I wouldn't wait in vain.
  • Helpful post
    #106 21473811
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14416
    Help: 650
    Rate: 12371
    If you want to:
    Quote:


    If channel 20 has a value of "0" (which is the default): Map input channel # 9 to relais channel 1, input 10 to output 2, input 11 to output 3 and so on, until all eight input/output-combinations are set. When dInput_n on input-channels is "1", let output be "1"
    If channel 20 has a value of "1": Invert output logic: When dInput_n is "1", let output be "0"

    Then you can do a loop with conditionals, the simplest approach would be:
    
    again:
    if $CH20==0 then SetPinChannel 9 1
    if $CH20==0 then SetPinChannel 10 2
    if $CH20==1 then SetPinChannel 9 11
    if $CH20==1 then SetPinChannel 10 12
    delay_s 1
    goto again
    

    adjust pin indexes accordingly to your requirements. You can also change pin roles.

    Alternative, you can just copy channels:
    
    again:
    if $CH20==0 then SetChannel 1 $CH9
    if $CH20==0 then SetChannel 2 $CH10
    // invert value if 1, ! is negation
    if $CH20==1 then SetChannel 1 !$CH9
    if $CH20==1 then SetChannel 2 !$CH10
    delay_s 1
    goto again
    
    Helpful post? Buy me a coffee.
  • #107 21473841
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    >>21473811
    That was fast! Thank you so much. "delay_s" is in seconds (?)
    I have to put the script at the end of autoexec.bat, right?

    For all Noobs like me, the full script would then be:

    again:
    if $CH20==0 then SetChannel 1 $CH9
    if $CH20==0 then SetChannel 2 $CH10
    if $CH20==0 then SetChannel 3 $CH11
    if $CH20==0 then SetChannel 4 $CH12
    if $CH20==0 then SetChannel 5 $CH13
    if $CH20==0 then SetChannel 6 $CH14
    if $CH20==0 then SetChannel 7 $CH15
    if $CH20==0 then SetChannel 8 $CH16
    // invert value if 1, ! is negation
    if $CH20==1 then SetChannel 1 !$CH9
    if $CH20==1 then SetChannel 2 !$CH10
    if $CH20==1 then SetChannel 3 !$CH11
    if $CH20==1 then SetChannel 4 !$CH12
    if $CH20==1 then SetChannel 5 !$CH13
    if $CH20==1 then SetChannel 6 !$CH14
    if $CH20==1 then SetChannel 7 !$CH15
    if $CH20==1 then SetChannel 8 !$CH16
    delay_s 20
    goto again
  • #108 21473845
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14416
    Help: 650
    Rate: 12371
    Hmm something like this, but please check and let me know if it works, I didn't test it myself yet. Delay is in seconds.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #109 21473876
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    >>21473845 Works instantly as expected. Perfect!
    (and script does go into autoexec.bat - in case that anyone would wonder)
  • #110 21473878
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14416
    Help: 650
    Rate: 12371
    So is this what you required or do you need any futher changes?
    Helpful post? Buy me a coffee.
  • #111 21473880
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    >>21473878 Currently fully satisfied - but wait, until something else comes to my mind :-)
  • #112 21475695
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    As currently this model is hard to find, I decided to try a different one, which is CBU based as well
    Link: Link to Aliexpress
    If it is technically more or less the same than this board, I will just add a few lines. If it turns out to be something different, I will open another thread. Item should arrive by end of next week.

    Device is here. I opened a new thread for this model: Link
  • #113 21539284
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    If anyone wonders, how this went finally:
    Here is the mounted device in the floor heating box

    Electronic controller and junction box in insulation with connected cables.

    And the final result in the closed case with the optocoupler-board mounted ontop:

    A circuit board and a junction box with wires surrounded by mineral wool insulation.
  • #114 21540490
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14416
    Help: 650
    Rate: 12371
    I see, that's certainly an interesting setup. Did you document it with a final schematic? Also, that board on top, is it a custom-made board or can it be bought somewhere?
    Helpful post? Buy me a coffee.
  • #115 21540560
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    >>21540490 All documentation is in this thread. As this board version has an MCU that I don't even use, it would be better to use the board mentioned in #112 and here: Link
    The optocoupler is a cheap version that can be found in various Ali-Shops. Mine is from here: Link . The advantage is, that you can easily cut one until four elements on the sides, if space is a matter, so make - let's say - a five-channel version out of the 8-channel board.
  • #116 21721986
    io2345
    Level 9  
    Posts: 244
    Help: 1
    Rate: 6
    I have to add this: When using it the way I do - with floor heating actuators (those thermal ones with melting wax inside) - please observe this: While they consume around 2 to 3 watts when powered, they have a significant higher inrush current. I had some channels on my board with two heating actuators connected to one electronic relay, which let the relay die from time to time due to overcurrent.
    If you plan to connect a single relay (of the same type that I use) to more than one actuator, use a relay with higher max. current or add a NTC thermistor connected in series with the actuators. I ordered a thermistor model MF72 400D-9 (400 ohms at 25°C) now and will report, if that solves the problem reliable.
    EDIT: The 400 ohms model wasn't available. I bought now some 1000 ohms ones. After replacing the defect relay, it seems to work without problems now.

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.

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