The power section consists of two SLD8N65SV MOSFETs (650V, 7A@25°C, 1.1Ω) and two rectifying bridges built with S3M diodes (1000V, 3A).
MS-105B is a trailing edge dimmer. Below are the voltage waveforms for 1%, 30%, 50%, and 100% settings in the Tuya application (77W halogen light bulb used as the load):
My device uses Tuya firmware version 1.0.2, so it should be OTA flashable.
Thanks for another teardown. It's important to keep our list growing.
The following device is TuyaMCU-based. I don't know why Tuya always uses external MCU for dimming, but it really does.
It will be flashable via OTA only if there is a matching profile, and there is only a matching profile if someone already has read 2MB flash of the matching firmware build and provided it for tuya-cloudcutter team.
You can flash it by wires, but you will most likely need to temporarily sever the connection to the MCU, because it occupies the same UART port that is used for flashing.
I've managed to flash it OTA using the laptop running Ubuntu Linux. I don't use Windows at all. If you are Windows user the simplest way will be probably to use a Raspberry Pi with an AP capable WiFi interface.
The biggest problem was to found a way to put this device in the AP mode (slow beeping, fast blinking).
Flashing procedure.
1. This procedure requires to check the firmware version installed on the device. It requires to connect the device to the Tuya cloud and is described here. In my case the firmware version was 1.0.2.
Sometimes Tuya / Smart Life app doesn't display the firmware version and asks you to upgrade your device. In such case do not upgrade it because this probably will close a way to OTA flashing! It's better to try different BK7231N versions without knowing the right one.
$ cd tuya-cloudcutter
$ sudo ./tuya-cloudcutter.sh
4. Power on the dimmer. If the device fast beeps, go to step 5. If not, remove it from the Tuya cloud. It should start beeping fast.
5. Connect S1 to L for 10 times (not so slow, not so fast, e.g. once for 2 seconds) to enter the "slow beeping" AP mode. You can connect any descent isolated push button to the S1 and L to make this task easier. I simply used piece of wire and touched the S1 and L screws.
6. While running the tuya-cloudcutter asks you a few questions. Choose the answers as below:
[?] How do you want to choose the device?:
By manufacturer/device name
> By firmware version and name
From device-profiles (i.e. custom profile)
Select the firmware version you obtained from Tuya app. You must be sure that the selected chip type match the chip used in your device. Probably all MS-105B dimmers use the BK7231N SOC but you can never be sure until you open your device (it's quiet easy).
In my case, I chose the names one by one until I found the first one that works: bk7231n_common_user_config_ty.
Select the OpenBeken firmware included in the tuya-cloudcutter or provide it the latest one. I've used the one included and next OTA upgraded to the latest.
================================================================================
Place your device in AP (slow blink) mode. This can usually be accomplished by
Power cycling off/on - 3 times and wait for the device to fast-blink, then repea
Long press the power/reset button on the device until it starts fast-blinking, t
See https://support.tuya.com/en/help/_detail/K9hut3w10nby8 for more information.
================================================================================
Next you will be asked to power cycle your device and enter the slow beep mode again. In my case after powering off and on the device automatically enters this mode.
Bellow is the full log of the rest of the flashing process.
Scanning for open Tuya SmartLife AP
.
Found access point name: "SmartLife-3715", trying to connect...
Device 'wlo1' successfully activated with 'dcf54998-8a2e-4015-9847-d6c89aa88a8b'
Connected to access point.
Waiting 1 sec to allow device to set itself up...
Running initial exploit toolchain...
Exploit run, saved device config too!
output=/work/configured-devices/DkIOuLcT0kyp.deviceconfig
Saved device config in /work/configured-devices/DkIOuLcT0kyp.deviceconfig
================================================================================
Power cycle and place your device in AP (slow blink) mode again. This can usual
Power cycling off/on - 3 times and wait for the device to fast-blink, then repea
Long press the power/reset button on the device until it starts fast-blinking, t
See https://support.tuya.com/en/help/_detail/K9hut3w10nby8 for more information.
================================================================================
Scanning for open Tuya SmartLife AP
..
Found access point name: "A-3715", trying to connect...
Device 'wlo1' successfully activated with '93b806ad-cbb1-4979-a6c7-9b9d483475fd'
Connected to access point.
Configured device to connect to 'cloudcutterflash'
Device is connecting to 'cloudcutterflash' access point. Passphrase for the AP i
Flashing custom firmware...
================================================================================
Wait for up to 10-120 seconds for the device to connect to 'cloudcutterflash'. T
================================================================================
Using WLAN adapter: wlo1
Configuration file: /dev/stdin
Using interface wlo1 with hwaddr 60:67:xx:xx:xx:xx and ssid "cloudcutterflash"
wlo1: interface state UNINITIALIZED->ENABLED
wlo1: AP-ENABLED
Using PSK v1 - Received PSK ID version 01
Processing endpoint /v2/url_config
Processing endpoint tuya.device.active
Processing endpoint tuya.device.dynamic.config.get
Processing endpoint tuya.device.upgrade.get
Processing endpoint tuya.device.upgrade.status.update
Processing endpoint /files/OpenBeken-v1.17.262_bk7231n.ug.bin
Firmware update progress: 11%
Processing endpoint tuya.device.uuid.pskkey.get
Firmware update progress: 30%
Firmware update progress: 60%
Firmware update progress: 87%
[Firmware Upload] /files/OpenBeken-v1.17.262_bk7231n.ug.bin send complete, reque
Firmware update progress: 98%
Firmware file has been sent and MQTT reported a progress of nearly complete. Wa
Flashing should be complete. It takes about 15 seconds for the device to reboot
Please wait about 30 seconds then look for signs of activity from the firmware y
Device MAC address: 38:1f:xx:xx:xx:xx
Dodano po 40 [minuty]:
After flashing both LEDs are blinking fast. The LEDs are controlled by the Holtek chip (TuyaMCU).
After starting the TuyaMCU driver the device starts beeping fast in sync with the onboard LEDs.
Below the TuyaMCU logs after starting the driver. The last entry more or less corresponds to the time when the device starts beeping.
Info:TuyaMCU:TUYAMCU received: 55 AA 00 00 00 01 00 00
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 0 (Hearbeat) with 8 bytes
Info:TuyaMCU:TUYAMCU received: 55 AA 00 01 00 15 6B 71 6D 30 6D 71 7A 62 35 7A 61 7A 65 77 73 62 32 2E 30 2E 32 73
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 1 (QueryProductInformation) with 28 bytes
Info:TuyaMCU:TuyaMCU_ParseQueryProductInformation: received kqm0mqzb5zazewsb2.0.2
Info:TuyaMCU:TUYAMCU received: 55 AA 00 02 00 00 01
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 2 (MCUconf) with 7 bytes
Info:TuyaMCU:TuyaMCU_ProcessIncoming: TUYA_CMD_MCU_CONF, TODO!
Info:TuyaMCU:TUYAMCU received: 55 AA 00 07 00 08 06 02 00 04 00 00 00 00 1A
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 6, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 07 00 08 0C 02 00 04 00 00 00 00 20
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 12, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 07 00 05 01 01 00 01 00 0E
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 7 (State) with 12 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 1, dataType 1-DP_TYPE_BOOL and 1 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte: 0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 07 00 05 07 01 00 01 00 14
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 7 (State) with 12 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 7, dataType 1-DP_TYPE_BOOL and 1 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 1 byte: 0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 07 00 08 02 02 00 04 00 00 01 10 27
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 2, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 272
Info:TuyaMCU:TUYAMCU received: 55 AA 00 07 00 08 08 02 00 04 00 00 00 C6 E2
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 7 (State) with 15 bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 8, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: raw data 4 int: 198
Info:TuyaMCU:TUYAMCU received: 55 AA 00 00 00 01 01 01
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 0 (Hearbeat) with 8 bytes
Info:TuyaMCU:TUYAMCU received: 55 AA 00 03 00 00 02
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 3 (WiFiState) with 7 bytes
Dodano po 19 [minuty]:
p.kaczmarek2 wrote:
The following device is TuyaMCU-based. I don't know why Tuya always uses external MCU for dimming, but it really does.
They probably use it to do some real-time stuff such as detecting the zero crossing point and control the MOSFETs on time.
The whole dimming algorithm and the manual control of the dimming channels by S1 and S2 lines seems to run autonomously on the TuyaMCU. It all probably may be implemented on the Beken SOC but it may be simpler to have such functions implemented outside of the main firmware, probably developed by different team, etc. In case of the STM32 MCUs the whole dimming algorithm with the zero crossing detection, etc. can be probably implemented in hardware, using timers (hard realtime guaranteed). I don't know if the Beken chips do provide such functionality in hardware. Maybe Holteks do it...
Following command must be entered in the autoexec.bat and then you must reboot the device (along with MCU). It has been tested several times by users on this forum, if the default WiFi state 0x04 does not help for you, then you are the first one...
Is the setChannelType configuration stored in some kind of EEPROM or in the Flash? It's more about whether it store something in Flash or somewhere during every execution of autoexec.bat if set there?
Dodano po 2 [minuty]:
p.kaczmarek2 wrote:
Is this a typo, or why are you linking both dpID 3 and 4 to channel 2?
No. I tried these both commands but not at the same time.
Dodano po 6 [minuty]:
p.kaczmarek2 wrote:
Can you try to run this command from the Web App (at realtime) and catch the output?
TuyaMCU dpIDs mapping is not stored between reboots, that's why we use autoexec.bat.
[[edit]] setChannelType settings are stored in flash. You can edit them in the Web App.
I can see some more dpIDs in your log output. Now you should be able to tell which dpID is second power state (boolean) and which is second dimmer state (value). There seems to be more of them than two pairs, but at least it will help you narrow it down
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 6, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 12, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 6, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_ParseStateMessage: processing dpId 12, dataType 2-DP_TYPE_VALUE and 4 data bytes
This may be the minimal brightness setting, maybe it's a separate value for each dimmer. You can try if you feel brave
leśny_ziutek wrote:
So leaving them in autoexec.bat isn't recommended because of increased Flash wearing.
Flash writes are optimized, flash is written only if there is a change, and futhermore we try to save many changes with one write:
your script will not cause any flash wear
The dpID 6 and 12 have a function to toggle the output state after the given number of seconds. That is, tuyaMcu_sendState 6 2 0 does nothing, tuyaMcu_sendState 6 2 1 toggles the L1 after 1 second, tuyaMcu_sendState 6 2 30 toggles the L1 after 30 seconds.
Dodano po 17 [minuty]:
It can be useful in some scenarios. Something like ToggleAfter channel type would be handy.
It's usually easier for me, when a user already copy-pastes the OBK JSON from the Web App, can you do that in that topic?
(for the record, I will leave this discussion here, because it is related to all teardown topics. Copying/filling the fields in OBK JSON from the Web App always helps)
In the Home Assistant Configuration, the CMD window is empty. When I started the HA discovery, there were 4 switches detected (two switch icons and two light bulb icons) and an RSSI sensor. There isn't any dimming control, only on and off.
There are 5 retained configuration messages in my MQTT broker:
Code: JSON
Log in, to see the code
Dodano po 2 [godziny] 14 [minuty]:
***
Feature request
Per channel tuyaMcu_setDimmerRange command would be useful.
I have two different dimmable LED bulbs (Philips, Osram). With one global mapping command, there is no way to make them work similarly.
>>20827829 Thanks for the instructions on how to flash OpenBeken using Cloudcutter. I have tried this before and gave up. The instructions you posted solved the issue for me.
One question: is there a way to connect a rocker switch to the dimmer and make the rocker switch turn on and off the light? I don't want to dim using the wall switch, just turn on and off. I will handle the dimming using automations and voice commands.
Note: I mean by rocker switch a switch that has an on and off state only, it's not the momentary or reset switch that is usually used with dimmers.
@mcheibani what kind of dimmer you have? It should be possible, in worst case with a little help of a script.
Set TglChannelOnToggle role for given GPIO, assign channel like CH 10, and add a "on change" event that calls light toggle.
The S1 and S2 lines are handled by TuyaMCU completely autonomously. It has its advantages, e.g. the dimmer keeps working even if the Open Beken have rebooted into the safe mode.
I put pieces of elastic rubber under the buttons of the regular switch so it now works like momentary one.
It took a few days to get used to the momentary switches, but now it's unnoticeable to all users.
A script may not solve this problem because if the switch is closed TuyaMCU autonomously keeps dimming and undimming (what is the right English word?) the light.
Apologies for the delayed response. I was offline for the past week. The model I have is the MOES 3 gang dimmer switch MS-105B. It looks exactly like the one shown in this teardown thread. Even though the brand name is slightly different (MOES GO vs MOES), but I think it's the same company.
I am a beginner in the Tasmota and OpenBeken world, can you elaborate more on how to set the GPIO to TglChannelOnToggle. I am using autoexec.bat file with the following content which is currently working with reset switch but not with a rocker switch
This is TuyaMCU device, but you can make a work around. If you connect a wire to, for example, P26, which is not used yet, and add a rocker switch between P26 and GND, you can later set P26 pin role to TglChannelOnToggle (or to a Button, if you want to click) and us it to toggle, for example, channel 1:
✨ The MoesGo Two Channel Smart Dimmer Module MS-105B features a CB2S Tuya Module based on the BK7231N microcontroller and a Holtek HT66F3195 MCU for dimming control. The power stage uses two SLD8N65SV MOSFETs (650V, 7A) and rectifying bridges with S3M diodes (1000V, 3A). It operates as a trailing edge dimmer with voltage waveform characteristics demonstrated at various dimming levels. The device employs a TuyaMCU architecture requiring external MCU communication, flashable OTA only with matching firmware profiles, and UART port management for flashing. Configuration and control are managed via OpenBeken firmware using autoexec.bat scripts to set channel types, link TuyaMCU dpIDs to channels, and define dimmer ranges. The dimmer supports toggling and dimming channels with dpIDs mapped for boolean and value types, including additional dpIDs for toggle-after timing functions. Flash memory wear is minimized by optimized write operations. Integration with Home Assistant via MQTT is possible, though initial issues with dimming control were resolved by correcting JSON configurations. Workarounds for using rocker switches involve assigning unused GPIO pins with TglChannelOnToggle roles due to TuyaMCU's autonomous handling of physical buttons. The Martin Jerry MJ-SD01 dimmer differs by using PWM control without an external MCU, unlike TuyaMCU-based dimmers. Adjusting minimal brightness levels depends on the bulb type and can be tuned via the tuyaMcu_setDimmerRange command. The community provides detailed flashing instructions, configuration examples, and troubleshooting for OTA flashing, dpID mapping, and device integration. Generated by the language model.
TL;DR: This 2-channel MoesGo MS-105B dimmer uses a CB2S BK7231N and a Holtek HT66F3195; “the third one” was the first working Cloudcutter profile on firmware 1.0.2. This FAQ helps OpenBeken users flash it OTA, enter AP mode, map TuyaMCU dpIDs, stop post-flash beeping, and restore proper Home Assistant dimming control. [#20827936]
Why it matters: The thread turns a hard-to-flash Tuya dimmer into a repeatable OpenBeken setup with verified channel mapping, OTA steps, and Home Assistant fixes.
Variant
Observed low-end dimming result
Working range example
Philips WarmGlow
Can dim very deeply
0–100%
Osram Glow Dim
Minimum stays visibly bright
~30–100%
Key insight: The MS-105B is not a simple BK7231N dimmer. OpenBeken works well only after you treat it as a TuyaMCU device, set Wi-Fi state 0x04, and map each bool/value dpID pair to the right channels. [#21351383]
Quick Facts
The teardown identified a CB2S Tuya module with BK7231N, plus a Holtek HT66F3195 MCU that handles dimming-side logic. [#20827148]
The power stage uses 2× SLD8N65SV MOSFETs rated 650 V, 7 A at 25°C, 1.1 Ω, and two rectifier bridges built from S3M diodes rated 1000 V and 3 A. [#20827148]
Scope captures showed this is a trailing-edge dimmer, tested with a 77 W halogen bulb at 1%, 30%, 50%, and 100% app settings. [#20827148]
A proven OpenBeken mapping is: L1 = dpID 1 bool + dpID 2 value, L2 = dpID 7 bool + dpID 8 value; dpID 6 and 12 act as delayed toggle timers. [#20830306]
Home Assistant discovery was corrected after upgrading from OpenBeken 1.17.308 to 1.17.326, which removed the extra switch entities and left two light entities plus RSSI. [#20838746]
1. What is a trailing edge dimmer, and how is it different from other AC dimming methods?
A trailing edge dimmer cuts the end of each AC half-cycle, not the beginning. The MS-105B was verified as trailing edge from captured waveforms at 1%, 30%, 50%, and 100% using a 77 W halogen load. "Trailing edge dimmer" is an AC phase-cut dimmer that reduces power by switching off late in each mains half-cycle, with the key characteristic that conduction starts normally and ends early.[#20827148]
2. How can I flash a MoesGo MS-105B dimmer with a CB2S BK7231N module using tuya-cloudcutter and OpenBeken OTA?
You can flash it OTA with tuya-cloudcutter if the installed Tuya firmware has a matching profile. 1. Check the device firmware in the Tuya or Smart Life app; the reported version here was 1.0.2. 2. Run sudo ./tuya-cloudcutter.sh, choose third-party firmware, then select the firmware-version method and a BK7231N profile. 3. Put the dimmer into slow-beep AP mode, let Cloudcutter connect twice, then flash an OpenBeken .ug.bin image. Avoid upgrading Tuya firmware first, because that can block OTA flashing. [#20827829]
3. Which firmware profile works for the MoesGo Two Channel Smart Dimmer MS-105B on Tuya firmware 1.0.2, and how do I find the right one?
The first confirmed working profile on Tuya firmware 1.0.2 was bk7231n_common_user_config_ty. The user tried profiles in sequence and reported that “the third one” worked first. To find the right one, select the exact Tuya firmware version, confirm the chip is BK7231N by opening the device, and test candidate 1.0.2 profiles one by one until Cloudcutter succeeds. [#20827936]
4. What sequence puts the MoesGo MS-105B into Tuya AP mode when it only beeps or blinks?
The working sequence is to remove the device from Tuya cloud, power it on, then connect S1 to L ten times. The thread reports a rhythm of about once every 2 seconds, using either an isolated pushbutton or a short piece of wire. Fast beeping indicates one state, while slow beeping is the AP mode Cloudcutter needs. After a power cycle, this device often re-entered the required mode automatically. [#20827829]
5. Why does the MS-105B start beeping after OpenBeken flashing, and how does tuyaMcu_defWiFiState 4 stop it?
It beeps because the Holtek-based TuyaMCU still drives the buzzer and LEDs after flashing, and it expects a different Wi-Fi status from the BK7231N side. Adding tuyaMcu_defWiFiState 4 to autoexec.bat and rebooting both the main chip and MCU stopped the buzzer, although it took some time to mute fully. The same post confirmed the command worked after earlier testing suggested otherwise. [#20828080]
6. What is TuyaMCU in devices like the MoesGo MS-105B, and why does Tuya use an external Holtek HT66F3195 MCU for dimming?
TuyaMCU is the external controller that handles dimming logic and exposes states through dpIDs. "TuyaMCU" is a secondary microcontroller subsystem that manages device-side functions such as dimming and switch inputs, with the key characteristic that the Wi-Fi SoC talks to it through a command protocol instead of driving the load directly. In this thread, the external MCU was a Holtek HT66F3195, and the likely reason was reliable real-time tasks such as zero-cross detection and MOSFET timing. [#20827829]
7. How do I map the correct TuyaMCU dpIDs for both channels of the MS-105B in OpenBeken?
Map the two channels as bool/value pairs: L1 uses dpID 1 to channel 1 and dpID 2 to channel 3, while L2 uses dpID 7 to channel 2 and dpID 8 to channel 4. The working commands were linkTuyaMCUOutputToChannel 1 bool 1, 2 val 3, 7 bool 2, and 8 val 4. This mapping was confirmed after querying states and testing both wall inputs. [#20830306]
8. Where are OpenBeken setChannelType settings stored, and does leaving them in autoexec.bat cause flash wear?
setChannelType settings are stored in flash, but leaving them in autoexec.bat does not create harmful flash wear. The maintainer explained that writes are optimized, flash is written only when a value changes, and multiple changes are grouped into one write when possible. TuyaMCU dpID mappings are different: those are not stored between reboots, which is why autoexec.bat remains necessary for the link commands. [#20828152]
9. How can I use tuyaMcu_sendQueryState and tuyaMcu_sendState to inspect or control TuyaMCU value and boolean dpIDs?
Use tuyaMcu_sendQueryState to dump all current dpIDs, then use tuyaMcu_sendState [dpID] [dpType] [dpValue] to write one back. In the captured log, tuyaMcu_sendQueryState exposed bool dpIDs 1 and 7 and value dpIDs 2, 6, 8, and 12. tuyaMcu_sendState then let the user test what hidden value-type dpIDs actually did, instead of guessing from the logs alone. [#20828278]
10. What do dpID 6 and dpID 12 do on the MoesGo MS-105B, and how can they be used for delayed toggle-after-seconds control?
dpID 6 and dpID 12 act as delayed toggle timers, one per channel. The thread verified that tuyaMcu_sendState 6 2 0 does nothing, 6 2 1 toggles L1 after 1 second, and 6 2 30 toggles L1 after 30 seconds; dpID 12 behaves the same way for L2. A practical setup linked them to text fields named toggle_L1_after and toggle_L2_after, which made the timer values editable from the interface. [#20828527]
11. Why does Home Assistant discover extra switch entities instead of proper dimmer controls for an OpenBeken dual dimmer, and which build fixes it?
It happened because OpenBeken published extra MQTT discovery entities incorrectly for this dual TuyaMCU dimmer. The user first saw four entities, including two extra switches, on build 1.17.308. After the maintainer fixed the bug and recommended build 1.17.326, Home Assistant showed the correct result: two light entities with brightness topics and one RSSI sensor. [#20838746]
12. How should I configure Home Assistant MQTT discovery for a two-channel OpenBeken TuyaMCU dimmer so brightness control appears correctly?
Publish each channel as a light entity, not as a separate switch, and bind brightness topics to the dimmer channels. In the working discovery JSON, L1 used stat_t ~/1/get, cmd_t ~/1/set, bri_stat_t ~/3/get, and bri_cmd_t ~/3/set, while L2 used channels 2 and 4 the same way, with bri_scl set to 100. After upgrading to 1.17.326, the user confirmed Home Assistant showed two light controls and brightness worked correctly. [#20838746]
13. What is a Tuya dpID, and how does it relate to channels, dimmer values, and TuyaMCU integration in OpenBeken?
A Tuya dpID is the numbered data point that the external MCU uses to report or accept states. "dpID" is a Tuya data-point identifier that labels one function in the TuyaMCU protocol, with the key characteristic that each identifier also carries a type such as boolean or value. On this dimmer, dpIDs 1 and 7 were booleans for on/off, dpIDs 2 and 8 were dimmer values, and OpenBeken linked each one to a local channel. [#20828101]
14. How does a TuyaMCU phase-cut dimmer compare with the Martin Jerry PWM dimmer approach for OpenBeken support?
A TuyaMCU phase-cut dimmer relies on an external MCU for mains timing, while the Martin Jerry design uses a PWM dimmer path that OpenBeken can drive differently. The maintainer said direct support for other phase-cut dimmers would require OpenBeken itself to detect the optocoupler phase point and switch the load quickly at the right sine-wave position. That makes the TuyaMCU design more dependent on protocol mapping, while the PWM design depends on a different control method entirely. [#20901151]
15. What is the best way to improve minimum brightness on the MS-105B with different dimmable bulbs like Philips WarmGlow and Osram Glow Dim using tuyaMcu_setDimmerRange?
Adjust the minimum and maximum with tuyaMcu_setDimmerRange min max, then tune for each bulb type. In the later working example, tuyaMcu_setDimmerRange 100 900 improved behavior, while an earlier setup used 1 1000. Real bulbs differed sharply: Philips WarmGlow could dim from 0–100%, but Osram Glow Dim behaved more like 30–100%, so the best low-end result came from range tuning plus choosing bulbs with a deeper native dimming curve. [#21351383]
