[BK7238] OpenBeken 1.18.289 - Feature request- add "Switch_pd" roles for latching inputs.

I am using a BK7238-based 4-relay switch board with 4 physical latching wall switches running OpenBeken 1.18.289.

The board is sold as "Aziot Smart Switch 4Node" and uses a BK7238/T1 (Tuya) module. The wall switches are connected to GPIOs P1, P8, P22, and P26.

The hardware drives the switch GPIOs HIGH (3.3 V) when idle, and the physical switches also apply 3.3 V when activated. To make the inputs usable, the GPIOs need to be configured with an internal pull-down resistor so that a switch activation can be detected as a HIGH signal.

I tested the following input roles:

* Btn
* Btn_n
* Btn_pd
* Btn_pd_n

However, none of them appear to enable a pull-down resistor on this BK7238 board. The only role that successfully pulls the GPIO LOW and detects switch activation is:

* TglChanOnTgl_pd

Unfortunately, TglChanOnTgl_pd is intended for toggle-button operation, while my hardware uses latching wall switches that should directly reflect their physical ON/OFF position.

Would it be possible to:

1. Add pull-down support to the standard switch/button roles on BK7238 devices?
2. Add dedicated switch roles with pull-down variants (for example, Switch_pd and Switch_pd_n) that preserve latching switch behavior while enabling the internal pull-down resistor in the same way that TglChanOnTgl_pd does?

This would help support boards that require a pull-down input configuration and do not have external pull-down resistors fitted.

TglChanOnTgl is intended for latching wall switches, because it allows you to control it also remotely. If you follow 1:1 state of latching switch, then you won't be able to control the relay from the firmware (WiFi).

If you really want to 1:1 reflect the state of input, you can use dInput role. We can add pulldown there, if it's missing.

This, however, looks still strange in general. I've looked at Aziot Smart Switch 4Node device and it looks like something that could either use Btn role (momentar button) or TglChanOnTgl (twostate switch), I can't imagine any possible scenario where you'd want dInput.... dInput is for door sensors, water sensors, etc...

but also, maybe your experiences with button_pd/n is because of this?

https://github.com/openshwprojects/OpenBK7231...ain...divadiow:OpenBK7231T_App:missingbuttons

re

divadiow wrote:

I was just trying to get the button working on the GD32 (active high) with role Btn_pd_n but it didn't seem to be effective at all. dInput_pd_n was registering button changes though. Seems Btn_pd/n is missing here? https://github.com/openshwprojects/OpenBK7231T_App/pull/2118/changes

Oh great spotting! In future, we could also introduce #define IS_BUTTON_ROLE.... is see your PR is already merged, so it shall be in release already.

Still, it doesn't explain the confusion from the first post. We need a clarification. Maybe a photo of used switches or a description of end use case?

Or maybe we really just need dInput_pd:
https://github.com/search?q=repo%3Aopenshwpro...2FOpenBK7231T_App%20dInput_pd&type=issues
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/ioRoles.md

p.kaczmarek2 wrote:

Still, it doesn't explain the confusion from the first post. We need a clarification.

Thanks for the response. Let me clarify how this Aziot module is intended to work.

The module is designed to be retrofitted into an existing home electrical installation to add smart-home functionality. It is powered directly from the 220 V mains supply. The electrical load (lights, outlets, etc.) is connected to the relay outputs, while the existing wall switches are connected to dedicated switch inputs on the module.

Instead of directly switching power to the load, the wall switches provide a 220 V signal to the module. The module uses optocouplers and resistor networks to safely detect the presence of 220 V and translate it into a GPIO signal.

The PCB is designed so that the optocoupler output drives the GPIO HIGH (3.3 V) when the wall switch is ON. Therefore, the GPIO must be held LOW by a pull-down resistor in order for the ON state to be detected correctly.

The only role I have found that enables a working pull-down on this BK7238 device is

TglChanOnTgl_pd

. However, a toggle input is not suitable for a latching wall switch.

With a toggle input, the following happens:

1. Physical switch ON - relay turns ON.
2. Physical switch OFF - relay turns OFF.

This works correctly until the relay state is changed externally.

For example:

1. Physical switch is ON.
2. Relay is ON.
3. Home Assistant, a schedule, or an automation turns the relay OFF.
4. Physical switch remains ON.
5. When I move the physical switch to OFF, the toggle input generates another toggle event and turns the relay ON again.

At this point, the relay state and the physical switch position become inverted and no longer represent each other.

What I need instead is true latching switch behavior:

* Physical switch OFF - relay OFF.
* Physical switch ON - relay ON.

If Home Assistant or an automation changes the relay state, that is fine. The next physical switch movement should simply force the relay to match the switch position rather than generating a toggle event.

In other words, I need a switch role with pull-down support, not a toggle role with pull-down support.

I hope this better explains the use case and why a pull-down-enabled switch role would be useful on this type of hardware.

If you are getting a "Failed to get bus" error while trying to flash the Aziot 4-Node Smart Switch, it is likely caused by hardware lines interfering with the serial communication. After some troubleshooting on the T1-3S module, I found a working solution:

1) Disconnect the onboard LED pin: I first isolated the onboard LED pin connected to the TX line, but this alone did not resolve the error.
2) Cut the RX-to-Optocoupler Track: I then cut the PCB trace routing from the RX pin to the PC817 optocoupler.

Cutting this specific RX track instantly resolved the bus error and allowed the module to flash successfully. Not sure if the first one is required, as it didn't fix the issue for me. You may directly try the second option and check in your case.

Hopefully, this saves time for anyone else modifying the same hardware!