Hi All, The OpenBeken firmware is an awesome project. I have been able to use it to cut the cloud and enable local control of many devices. I am having trouble with a Treatlife 3-way switch. The main switch in the 3-way setup works fine when using the button or via HA. However, when using the...

No problem, so the solution is very simple. Just set the same channel for LED and dInput. Please try and tell me if it works. You could also setup your HA yaml to listen for the channel publish of dInput channel and use it to display light state in HA.

Hello, how your current Yaml looks like? I think you need to use channel 2 (dInput_n) to track the state of the light...

Hello, I would need some more information about the device because I am not yet sure what exactly is the issue. Is your device a stairs switch, the switch where one bulb is connect basically to two switches and it's not possible to simply tell whether the bulb is on by checking the single relay state? And you are using it indeed in the 3-way switch configuration?

Yes, the device and wiring are as in the stair switch picture you posted. The main / smart switch is switch 1 in the picture and the dumb switch is switch 2 in the picture. The relay state does not change on the device when the light bulb is actuated by the dumb switch. The sensor in HA that tracks dInput_n on PIN 26 does show the actual state of the light bulb. This seems to be the same issue in the previous posts but I did not find a resolution to these posts.

Ah, I remember that issue. I am not sure if it was resolved. What about doing a work around? SOLUTION 1 - link switches by GET packet On switch A, change Relay role to AlwaysLow On switch A, add following code in autoexec.bat: Code: text Expand Select all Copy to clipboard // send POWER ON to second switch alias send_on SendGet // send POWER OFF to second switch alias send_off SendGet // do certain action when channel changes addChangeHandler Channel1 == 0 send_off addChangeHandler Channel1 == 1 send_on change IP to be the IP of switch B. Then, switch A relay is always off, but when toggled it sends data to switch B and switch B really operates relay... EDIT: maybe this could be done even better. Instead of sending On/Off, just send Toggle in both cases, this will avoid a little 'desync' issue when you first tap switch A, and then switch B... just change ON and OFF in SendGET to Toggle.. If you don't like solution, here is alternative. SOLUTION 2 - link switches by device group On switch A, change Relay role to AlwaysLow On both switches, setup two-way DGR: DGR should be a bit better, because first solution may not sync-back the state of second switch in the current state of my script. What do you think about those solutions, do they fit your use case? If not, we can think about one more way to solve the problem.

Switch B is a dumb switch so there is no way for switch A to signal it. I was wondering if there is a way to control the LED on switch A. If so, automation in HA or on the switch could set the state of the LED by tracking dInput_n from pin 26.

In case of DGR solution the LED (channel 1 state) is synced in both ways on both switches. The HTTP GET solution could also sync LED on dummy switch with some callback trickery. Added after 1 [minutes]: This will also work, as long as dInput_n provides a valid 1 or 0 output. Just set dInput_n channel to the same channel that has LED, for example, use channel 2 or something.

Switch B is not a smart switch. It's just a plain old mechanical 3-way switch from the home improvement store. The building previously used a Kasa smart switch with this same wiring and it worked as expected. It also worked with the stock 3-way Treatlife firmware. Once I cut the cloud by flashing OpenBeken, I ran into this issue.

Ah ok, now I understand what you mean. I was under impression that you was referring as dumb in a way that it just sends data and has no control, but you mean not a smart switch. I was confused because I saw people buying Treatlife 3-way switches that are sold in pairs.... Ok, so we are now forced to use dInput solution. Tell me, does having that dInput on channel, let's say, channel 2, gives you a reliable reading showing whether light is ON or OFF? Does it really always yields 1 for ON and 0 for Off, etc? (or dInput_n, if you want negation). If that's working , then we can easily use that value futher. Added after 2 [minutes]: Now that I consider your post again, with understanding that you meant that one of your switches is not smart, then: Solution is simple - if you have dInput on channel 4, set LED channel to 4 as well. And that's all.

Sorry for the confusion. I may not have explained well. Yes, dInput_n seems to accurately reflect the state of the light bulb. I actuated both the smart switch and the dumb switch about 50 times each and dInput_n always had the correct state of the light bulb.

Yes! That worked. Below is the config from the web application. { vendor: Tuya, bDetailed: 0, name: Full Device Name Here, model: enter short model name here, chip: BK7231T, board: TODO, keywords: [ TODO, TODO, TODO ], pins: { 6: Btn;1, 8: LED;2, 24: Rel;1, 26: dInput_n;2 }, image: wiki: }

Haha, I am really sorry for not getting that earlier, but I somehow didn't think you'd ask for a such simple fix. Anyway, now that's working, I think we can close this topic. If you have any other questions, or need a particular feature, feel free to ask, I'll try to help

[Solved] OpenBeken for Treatlife 3-way switch - how to setup stairs switches pair in OBK

chri5k 2382 17

Best answers

How can I make the LED on my OpenBeken Treatlife 3-way switch follow the state reported by the dInput_n sensor from the mechanical 3-way switch?

Set the LED and the dInput_n input to the same channel, and the LED will mirror the light state reported by that input [#20481062] If dInput_n is currently on channel 4, move the LED to channel 4 as well; the working example that solved the issue used `LED;2` and `dInput_n;2` on the same channel [#20481013][#20481159] The same reply also noted that Home Assistant can listen to the dInput channel publish to display the light state [#20481062]

Generated by the language model.

Report a violation of the law

| New topic

#1 20480900 11 Mar 2023 14:03

chri5k chri5k

Level 5

Posts: 22

Rate: 2
Topic author

Post #1
20480900 11 Mar 2023 14:03

Hi All,

The OpenBeken firmware is an awesome project. I have been able to use it to "cut the cloud" and enable local control of many devices.

I am having trouble with a Treatlife 3-way switch. The main switch in the 3-way setup works fine when using the button or via HA. However, when using the remote "dumb switch" the LED on the main switch or the switch depiction in HA do not track the actual status of the lights. When using the button on the main switch, the LED is on when the lights are off. The LED turns off when the button is pressed and the lights turn on. Using the "dumb switch", the lights turn on and off but the LED on the main switch does not change. I found a post on this forum where another user was having the same issue. Per the reply to that post I added a dInput_n to PIN 26 and set it to MQTT channel 4. HA shows a new sensor for this pin and the sensor tracks the state of the lights when they are actuated from either switch. What I can't figure out is how to make the LED on the main switch track this sensor. Below is the configuration of the main switch.

{
"vendor": "Tuya",
"bDetailed": "0",
"name": "Full Device Name Here",
"model": "enter short model name here",
"chip": "BK7231T",
"board": "TODO",
"keywords": [
"TODO",
"TODO",
"TODO"
],
"pins": {
"6": "Btn;1",
"8": "LED;1",
"24": "Rel;1",
"26": "dInput_n;4"
},
"image": "https://obrazki.elektroda.pl/YOUR_IMAGE.jpg",
"wiki": "https://www.elektroda.com/rtvforum/topic_YOUR_TOPIC.html"
}

ADVERTISEMENT
#2 20480930 11 Mar 2023 14:21

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14416

Help: 650

Rate: 12371
Helpful post? (0)

Post #2
20480930 11 Mar 2023 14:21

Hello, I would need some more information about the device because I am not yet sure what exactly is the issue.

Is your device a stairs switch, the switch where one bulb is connect basically to two switches and it's not possible to simply tell whether the bulb is on by checking the single relay state?

And you are using it indeed in the 3-way switch configuration?

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#3 20480959 11 Mar 2023 14:38

chri5k chri5k

Level 5

Posts: 22

Rate: 2
Topic author Helpful post? (0)

Post #3
20480959 11 Mar 2023 14:38

Yes, the device and wiring are as in the stair switch picture you posted. The "main / smart switch" is switch 1 in the picture and the "dumb switch" is switch 2 in the picture. The relay state does not change on the device when the light bulb is actuated by the "dumb switch". The sensor in HA that tracks dInput_n on PIN 26 does show the actual state of the light bulb.

This seems to be the same issue in the previous posts but I did not find a resolution to these posts.
https://www.elektroda.com/rtvforum/topic3866123-390.html#19973258
https://www.elektroda.com/rtvforum/topic3866123-390.html#19973661
#4 20480970 11 Mar 2023 14:46

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14416

Help: 650

Rate: 12371
Helpful post? (0)

Post #4
20480970 11 Mar 2023 14:46

Ah, I remember that issue. I am not sure if it was resolved.

What about doing a work around?

SOLUTION 1 - link switches by GET packet
On switch A, change Relay role to AlwaysLow
On switch A, add following code in autoexec.bat:
Code: text Expand Select all Copy to clipboard
// send POWER ON to second switch alias send_on SendGet http://192.168.0.112/cm?cmnd=Power%20On // send POWER OFF to second switch alias send_off SendGet http://192.168.0.112/cm?cmnd=Power%20Off // do certain action when channel changes addChangeHandler Channel1 == 0 send_off addChangeHandler Channel1 == 1 send_on

change IP to be the IP of switch B.

Then, switch A relay is always off, but when toggled it sends data to switch B and switch B really operates relay...

EDIT: maybe this could be done even better. Instead of sending On/Off, just send Toggle in both cases, this will avoid a little 'desync' issue when you first tap switch A, and then switch B... just change "ON" and "OFF" in SendGET to Toggle..

If you don't like solution, here is alternative.
SOLUTION 2 - link switches by device group
On switch A, change Relay role to AlwaysLow
On both switches, setup two-way DGR:

DGR should be a bit better, because first solution may not sync-back the state of second switch in the current state of my script.

What do you think about those solutions, do they fit your use case? If not, we can think about one more way to solve the problem.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#5 20480985 11 Mar 2023 14:52

chri5k chri5k

Level 5

Posts: 22

Rate: 2
Topic author Helpful post? (0)

Post #5
20480985 11 Mar 2023 14:52

Switch B is a dumb switch so there is no way for switch A to signal it. I was wondering if there is a way to control the LED on switch A. If so, automation in HA or on the switch could set the state of the LED by tracking dInput_n from pin 26.
ADVERTISEMENT
#6 20481013 11 Mar 2023 15:10

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14416

Help: 650

Rate: 12371
Helpful post? (0)

Post #6
20481013 11 Mar 2023 15:10

In case of DGR solution the LED (channel 1 state) is synced in both ways on both switches.

The HTTP GET solution could also sync LED on dummy switch with some callback trickery.

Added after 1 [minutes]:

chri5k wrote:
switch could set the state of the LED by tracking dInput_n from pin 26.

This will also work, as long as dInput_n provides a valid 1 or 0 output. Just set dInput_n channel to the same channel that has LED, for example, use channel 2 or something.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#7 20481022 11 Mar 2023 15:15

chri5k chri5k

Level 5

Posts: 22

Rate: 2
Topic author Helpful post? (0)

Post #7
20481022 11 Mar 2023 15:15

Switch B is not a smart switch. It's just a plain old mechanical 3-way switch from the home improvement store.

The building previously used a Kasa smart switch with this same wiring and it worked as expected. It also worked with the stock 3-way Treatlife firmware. Once I "cut the cloud" by flashing OpenBeken, I ran into this issue.
ADVERTISEMENT
#8 20481036 11 Mar 2023 15:24

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14416

Help: 650

Rate: 12371
Helpful post? (0)

Post #8
20481036 11 Mar 2023 15:24

Ah ok, now I understand what you mean.
I was under impression that you was referring as "dumb" in a way that it just sends data and has no control, but you mean not a smart switch.
I was confused because I saw people buying Treatlife 3-way switches that are sold in pairs....

Ok, so we are now forced to use dInput solution.

Tell me, does having that dInput on channel, let's say, channel 2, gives you a reliable reading showing whether light is ON or OFF? Does it really always yields 1 for ON and 0 for Off, etc?
(or dInput_n, if you want negation).

If that's working , then we can easily use that value futher.

Added after 2 [minutes]:

Now that I consider your post again, with understanding that you meant that one of your switches is not smart, then:

chri5k wrote:
Per the reply to that post I added a dInput_n to PIN 26 and set it to MQTT channel 4. HA shows a new sensor for this pin and the sensor tracks the state of the lights when they are actuated from either switch. What I can't figure out is how to make the LED on the main switch track this sensor.

Solution is simple - if you have dInput on channel 4, set LED channel to 4 as well. And that's all.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#9 20481056 11 Mar 2023 15:29

chri5k chri5k

Level 5

Posts: 22

Rate: 2
Topic author Helpful post? (0)

Post #9
20481056 11 Mar 2023 15:29

Sorry for the confusion. I may not have explained well.

Yes, dInput_n seems to accurately reflect the state of the light bulb. I actuated both the "smart switch" and the "dumb switch" about 50 times each and dInput_n always had the correct state of the light bulb.
Helpful post

#10 20481062 11 Mar 2023 15:33

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14416

Help: 650

Rate: 12371
Helpful post? (+1)

Helpful post
Post #10
20481062 11 Mar 2023 15:33

No problem, so the solution is very simple. Just set the same channel for LED and dInput. Please try and tell me if it works.

You could also setup your HA yaml to "listen" for the channel publish of dInput channel and use it to display light state in HA.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#11 20481159 11 Mar 2023 16:37

chri5k chri5k

Level 5

Posts: 22

Rate: 2
Topic author Helpful post? (0)

Post #11
20481159 11 Mar 2023 16:37

Yes! That worked. Below is the config from the web application.

{
"vendor": "Tuya",
"bDetailed": "0",
"name": "Full Device Name Here",
"model": "enter short model name here",
"chip": "BK7231T",
"board": "TODO",
"keywords": [
"TODO",
"TODO",
"TODO"
],
"pins": {
"6": "Btn;1",
"8": "LED;2",
"24": "Rel;1",
"26": "dInput_n;2"
},
"image": "https://obrazki.elektroda.pl/YOUR_IMAGE.jpg",
"wiki": "https://www.elektroda.com/rtvforum/topic_YOUR_TOPIC.html"
}
#12 20481187 11 Mar 2023 16:54

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14416

Help: 650

Rate: 12371
Helpful post? (0)

Post #12
20481187 11 Mar 2023 16:54

Haha, I am really sorry for not getting that earlier, but I somehow didn't think you'd ask for a such simple fix. Anyway, now that's working, I think we can close this topic.

If you have any other questions, or need a particular feature, feel free to ask, I'll try to help

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#13 20481194 11 Mar 2023 16:58

chri5k chri5k

Level 5

Posts: 22

Rate: 2
Topic author Helpful post? (0)

Post #13
20481194 11 Mar 2023 16:58

Yes, please close the topic. Also, you may want to update the configuration on the website where the modules pull configuration when using the web application. That is where I received the initial configuration after flashing to OpenBeken.
#14 20481200 11 Mar 2023 17:01

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14416

Help: 650

Rate: 12371
Helpful post? (0)

Post #14
20481200 11 Mar 2023 17:01

I was not aware about that dInput back then. Template is now updated:
https://github.com/OpenBekenIOT/webapp/commit/5f5f0b304cb113fbda8c73d708dac75079a61ed8

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#15 20541383 15 Apr 2023 22:05

jaymcentire jaymcentire

Level 1

Posts: 1
Helpful post? (0)

Post #15
20541383 15 Apr 2023 22:05

Can you help me with the MQTT code for Home Assistant on this? The existing yaml code doesn't work as intended. When the dumb switch gets used, the switch in HA gets all messed up. Thanks in advance.
Helpful post

#16 20541684 16 Apr 2023 07:47

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14416

Help: 650

Rate: 12371
Helpful post? (+1)

Helpful post
Post #16
20541684 16 Apr 2023 07:47

Hello, how your current Yaml looks like?

I think you need to use channel 2 (dInput_n) to track the state of the light...

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
ADVERTISEMENT
#17 20759455 05 Oct 2023 15:48

Zain00 Zain00

Level 11

Posts: 61

Help: 3

Rate: 20
Helpful post? (0)

Post #17
20759455 05 Oct 2023 15:48

I just got a 3-way switch but came with WR2E
I see an IC on the back of the WIFI module and I was wondering if this chip has something to do with the 3-way function.
Because the switch claim to work with regular mechanical 3-way switch.

the marking in the chip

GD HH2032
25Q16CTIG
AP26305

I still haven't flashed openbeken yet.
#18 20759462 05 Oct 2023 15:53

chri5k chri5k

Level 5

Posts: 22

Rate: 2
Topic author Helpful post? (0)

Post #18
20759462 05 Oct 2023 15:53

Yes! That worked. Below is the config from the web application.

{
"vendor": "Tuya",
"bDetailed": "0",
"name": "Full Device Name Here",
"model": "enter short model name here",
"chip": "BK7231T",
"board": "TODO",
"keywords": [
"TODO",
"TODO",
"TODO"
],
"pins": {
"6": "Btn;1",
"8": "LED;2",
"24": "Rel;1",
"26": "dInput_n;2"
},
"image": "https://obrazki.elektroda.pl/YOUR_IMAGE.jpg",
"wiki": "https://www.elektroda.com/rtvforum/topic_YOUR_TOPIC.html"
}
Create an account, log in here and be active on the forum — ads won't appear. Earn points for registering and replying.

Install Elektroda application

Didn't find an answer? Ask Artificial Intelligence

*I agree to send the question to OpenAI, Anthropic PBC, Perplexity AI, Inc., Kagi Inc., Google LLC - owners of language models in order to prepare the best response. The companies may monitor and log information entered into the form.

*I agree to publicly display my question and answer. The question and answer will be publicly available to everyone. The process may take a few minutes. Upon completion, you will be redirected to the page with the answer.

Wait...(2min)

| New topic

Report a violation of the law

Topic summary

✨ The discussion revolves around configuring the OpenBeken firmware for a Treatlife 3-way switch setup, specifically addressing issues with LED status synchronization when using a "dumb switch" alongside a smart switch. The main switch operates correctly via Home Assistant (HA) and its button, but the LED does not reflect the actual light status when the dumb switch is used. Users suggest utilizing a dInput_n on PIN 26 to track the light's state accurately. A solution is proposed to set the LED channel to the same channel as dInput_n, which successfully resolves the issue. Additional inquiries about MQTT code for HA and the compatibility of a different switch model are also discussed.
Generated by the language model.

FAQ

TL;DR: Map LED and dInput_n to 1 MQTT channel (e.g., channel 2); “Just set the same channel for LED and dInput.” This fixes Treatlife 3‑way state and LED sync with a dumb switch on OpenBeken. [Elektroda, p.kaczmarek2, post #20481062]

Why it matters: It lets OpenBeken users keep HA and the front‑panel LED accurately synced without cloud firmware.

Quick Facts

Working example (BK7231T): GPIO6 Btn;1, GPIO8 LED;2, GPIO24 Rel;1, GPIO26 dInput_n;2. [Elektroda, chri5k, post #20481159]
Fix logic: Set LED and dInput to the same channel so the LED mirrors the load. [Elektroda, p.kaczmarek2, post #20481036]
Reliability check: dInput_n tracked the light correctly across ~50 toggles. [Elektroda, chri5k, post #20481056]
Two‑smart alternative: use two‑way Device Groups (DGR) or HTTP GET with Toggle. [Elektroda, p.kaczmarek2, post #20480970]
Template update: OpenBeken webapp template now includes the dInput mapping. [Elektroda, p.kaczmarek2, post #20481200]

How do I make the Treatlife 3‑way’s LED follow the light when the dumb switch is used?

Assign the sensed line to dInput_n, then set the LED to the same channel. Example: dInput_n → Channel 2 and LED → Channel 2. This makes the LED track the real lamp state, not the relay. “Just set the same channel for LED and dInput.” It also helps Home Assistant reflect the correct state. [Elektroda, p.kaczmarek2, post #20481062]

What exact OpenBeken pin mapping worked for others on Treatlife 3‑way?

A confirmed working setup: GPIO6 Btn;1, GPIO8 LED;2, GPIO24 Rel;1, GPIO26 dInput_n;2. This keeps relay on Channel 1 for control, and uses Channel 2 for the sensed light state and LED. Users reported the LED and HA state finally matched the actual lamp. Copy this layout if your board pins are the same. [Elektroda, chri5k, post #20481159]

How reliable is dInput_n for detecting the lamp state?

One user toggled both switches about 50 times and dInput_n always matched the lamp state. This indicates stable sensing for 3‑way circuits when mapped correctly. If you see inversion, switch to dInput vs dInput_n. Validate readings before linking the LED channel. This quick test prevents false sync. [Elektroda, chri5k, post #20481056]

My second switch is smart; what’s the best way to link two OpenBeken switches?

Use two‑way Device Groups (DGR) to sync state and commands in both directions. As an alternative, send HTTP GET with Toggle on each change. “DGR should be a bit better.” For HTTP, setting the relay to AlwaysLow on one side can help. Both approaches eliminate desync between two smart ends. [Elektroda, p.kaczmarek2, post #20480970]

Why didn’t the LED or HA state update when the dumb switch flipped?

In a 3‑way circuit, the smart relay state may not change when the dumb switch toggles. The device can’t infer the lamp state from the relay alone. Adding dInput_n lets the device sense actual line state. Mapping LED to that channel fixes both the LED and HA state. [Elektroda, chri5k, post #20480959]

Can I solve this in Home Assistant via MQTT without wiring changes?

Yes. Configure HA to track the dInput_n channel as the switch state. Keep the command topic targeting the relay channel. The vendor advises listening to the dInput channel for state publishing. This ensures HA matches the real lamp state, even from the dumb switch. [Elektroda, p.kaczmarek2, post #20481062]

How do I set this up in three steps?

Assign the sensed pin (e.g., GPIO26) to dInput_n and set it to Channel 2.
Set the LED role to Channel 2 so it mirrors the sensor.
In HA, use the dInput channel as state for the light entity. This aligns relay control and real-world state. [Elektroda, p.kaczmarek2, post #20481062]

What if my dInput reads inverted or inconsistent?

Use dInput_n if the logic is inverted, or dInput if it isn’t. Confirm it yields a clean 1 for ON and 0 for OFF. Once verified, map the LED to that channel. If readings aren’t stable, recheck the chosen GPIO and wiring. [Elektroda, p.kaczmarek2, post #20481036]

Does the OpenBeken template now include this dInput mapping fix?

Yes. The project updated the webapp template to include a dInput configuration for this scenario. If you auto-import templates, you should see the corrected mapping. This reduces manual setup and errors. Check the linked commit note for confirmation. [Elektroda, p.kaczmarek2, post #20481200]

In MQTT, which channel should represent the light state for HA?

Use the dInput channel (e.g., Channel 2) as your state topic. Keep the command topic mapped to the relay channel. The maintainer explicitly recommends tracking Channel 2 for state on this 3‑way setup. This keeps HA tiles accurate. [Elektroda, p.kaczmarek2, post #20541684]

Can I keep a relay AlwaysLow and still sync two smart switches’ LEDs?

Yes. Set the relay role to AlwaysLow on one device and link switches via DGR or HTTP GET Toggle. The other device operates the physical load, while both LEDs and states stay synchronized. This pattern avoids relay conflicts. [Elektroda, p.kaczmarek2, post #20480970]

Do I need extra hardware for this, or just a free GPIO?

You only need a free GPIO that can be assigned as dInput or dInput_n. The fix is purely channel mapping. Once the sensor yields a clean digital state, map the LED to the same channel. No auxiliary ICs or add-ons are required. [Elektroda, p.kaczmarek2, post #20481036]

How do I avoid desync when linking two smart switches with HTTP?

Send Toggle for both state changes instead of On/Off. That avoids mismatches when either side is manually toggled. The maintainer calls this out to reduce the classic out‑of‑sync issue. It’s a simple, effective change to the callback logic. [Elektroda, p.kaczmarek2, post #20480970]

Why did Kasa or stock Treatlife firmware not show this issue?

Those firmwares handled 3‑way state tracking internally. After flashing OpenBeken, you must replicate it by sensing the line via dInput and mapping the LED accordingly. Users noted the issue only after moving away from stock. The dInput approach restores expected behavior. [Elektroda, chri5k, post #20481022]

After mapping LED to dInput, does the relay still work from the smart switch?

Yes. Keep the relay on Channel 1 for control and the LED on the dInput channel. A shared working config confirms normal relay operation and proper LED tracking. This preserves manual and HA control without cloud dependency. [Elektroda, chri5k, post #20481159]

Why did a new sensor appear in HA after assigning dInput_n?

OpenBeken publishes the dInput channel, so HA discovers a new sensor entity. Use that entity’s state as your authoritative lamp state. Then map the LED to the same channel for visual feedback. This unifies state across hardware and software. [Elektroda, chri5k, post #20480900]