OpenBeken - can GPIO switch state be separate entity from relay in MQTT/Home Assistant?

I am using OpenBeken firmware version 1.18.289 on a BK7238/T1 (Tuya) board, sold by Aziot as Smart Switch 4 Node.

The input GPIOs are P1, P8, P22 and P26 with corresponding channels 1-4, driven by 3.3 V, therefore need an internal PULL DOWN workaround that "TglChanOnTgl_pd" role provides.
The relays are connected as "Rel" role to P6, P9, P23 and P24 with corresponding channels 1-4.

Is it possible for OpenBeken to expose the state of a switch or button connected to a GPIO as a separate MQTT/Home Assistant entity, independent of the associated relay state?

My use case is that the physical switch position carries useful information beyond simply controlling the relay. For example:

* Physical Switch 1 ON -> Relay 1 ON
* Home Assistant detects that Physical Switch 1 is ON and triggers an automation (for example, turning off the kitchen lights)

I would like Home Assistant to be able to read the actual state of the physical switch, even though the switch itself cannot be controlled remotely.

Having separate entities for:

* Relay state
* Physical switch/button state

would make it easier to:

* Create automations based on the physical switch position rather than the relay state
* Synchronize relay and switch states when they become out of sync
* Decouple switches/buttons from relays entirely, for example:

* Switch 1 on Module A is turned ON
* Home Assistant detects the switch state and turns ON Relay 2 on Module B

Is this currently possible, or could it be added as a feature?

I think dInput pins are already exposed and can be used in HA to trigger automations. You can also manually script stuff on OBK itself with click events (addEventHandler).

Try assigning dInput role to pin and run HA Discovery.

p.kaczmarek2 wrote:

Try assigning dInput role to pin and run HA Discovery.

When I assigned the

dInput

role to a GPIO connected to one of the wall switches, it did not work because the GPIO defaults to HIGH, and the optocoupler output on my module also drives the GPIO HIGH. As a result, there is no detectable state change.

To test this properly, I would need a

dInput_pd

role (or equivalent) that enables an internal pull-down resistor.

I did find a workaround, but it requires one additional channel per relay, custom

addEventHandler

rules, and extra Home Assistant configuration.

My current setup works like this:

* The physical switch is connected to

TglChanOnTgl_pd

.
*

TglChanOnTgl_pd

controls a "virtual" relay on Channel 1.
* The actual relay is assigned to Channel 2.
* An

addEventHandler

keeps Channel 2 synchronized with Channel 1 by copying the state from Channel 1 whenever it changes.

This achieves the behavior I need:

* Switch ON -> Channel 1 becomes ON.
* If Channel 2 is OFF, it is turned ON.
* If Channel 2 is already ON (for example because Home Assistant or an automation turned it on), nothing changes.

As a result:

* Channel 1 acts as a "switch state" entity.
* Channel 2 is the actual relay controlling the load.

In Home Assistant I expose both entities:

* Channel 1 = Physical switch state (informational only, never controlled directly).
* Channel 2 = Actual device being controlled (light, fan, TV, LED strip, etc.).

This works, but it becomes difficult to maintain at scale.

For a single relay module, the extra entities and event handlers are manageable. However, with 4-channel or 8-channel modules, and multiple modules throughout a house, the number of additional channels, entities, event handlers, and Home Assistant configuration grows significantly.

A built-in solution that exposes switch state independently from relay state, and/or provides pull-down-capable switch input roles, would greatly simplify the configuration and make these modules much easier to use in larger installations.

I'm not reporting a bug - just looking for a cleaner and more scalable way to achieve this behavior.