Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
linkTuyaMCUOutputToChannel [dpId] [varType] [channelID] [obkFlags] [mult] [inv] [delta]
p.kaczmarek2 wrote:Do you know C?
p.kaczmarek2 wrote:Can you check?
p.kaczmarek2 wrote:Is it even acceptable for us to ignore that read? I am not sure, could it break other things?
p.kaczmarek2 wrote:do you know how to download binary from PR
// device: Moyes MS-105
// because standard S1 functionality does not allow to revert the dimming direction at any time
// we replace S1 by a push button connected between P6 of the WiFi module and ground
// new functionality:
// short press now switches on/off
// long press is dimming either up or down
// double press toggles dim direction up/down
startdriver tuyamcu
tuyaMcu_defWiFiState 4
SetButtonTimes 10 3 1 // works with bDPCache==2 only (see below)
SetFlag 43 1 // Flag 43 - [TuyaMCU] Use queue
SetFlag 10 0 // Flag 10 - [MQTT] Broadcast self state on MQTT connect DONT CLUTTER LOG
// P6 connected to the push button
SetPinChannel 6 35
SetPinRole 6 Btn
SetChannel 34 4 // define dim stepsize
addEventHandler OnClick 6 toggleChannel 1
addEventHandler OnHold 6 addChannel 2 $CH34 0 100 0
addEventHandler OnDblClick 6 setChannel 34 -$CH34 // reverse direction on double click
// Power On/Off dpID 1 - Channel 1
setChannelType 1 toggle
setChannelLabel 1 "CH1 On/Off"
linkTuyaMCUOutputToChannel 1 bool 1
// Brightness dpID 2 - Channel 2
setChannelType 2 Dimmer
tuyaMcu_setDimmerRange 100 1000
// as of: https://www.elektroda.com/rtvforum/viewtopic.php?p=21707931#21707931
// linkTuyaMCUOutputToChannel dpId verType tgChannel [ bDPCache ]
linkTuyaMCUOutputToChannel 2 val 2 2 // new "bDPCache" "flags" arg: 2 means "do not read"
PowerSave 1
// device: Avatto DMS16-W1
// because standard S1 functionality allows only switching but not dimming
// we replace S1 by a push button connected between P28 of the WiFi module and ground
// new functionality:
// short press now switches on/off
// long press is dimming either up or down
// double press toggles dim direction up/down
startdriver tuyamcu
tuyaMcu_defWiFiState 4
tuyaMcu_setBaudRate 115200
SetButtonTimes 10 3 1 // works with bDPCache==2 only (see below)
SetFlag 43 1 // Flag 43 - [TuyaMCU] Use queue
SetFlag 10 0 // Flag 10 - [MQTT] Broadcast self state on MQTT connect DONT CLUTTER LOG
// P28 connected to the push button
SetPinChannel 28 35
SetPinRole 28 Btn
SetChannel 34 4 // define dim stepsize
addEventHandler OnClick 28 toggleChannel 1
addEventHandler OnHold 28 addChannel 2 $CH34 0 100 0
addEventHandler OnDblClick 28 setChannel 34 -$CH34 // reverse direction on double click
// Power On/Off dpID 1 - Channel 1
setChannelType 1 toggle
setChannelLabel 1 "CH1 On/Off"
linkTuyaMCUOutputToChannel 1 bool 1
// Brightness dpID 2 - Channel 2
setChannelType 2 Dimmer
tuyaMcu_setDimmerRange 90 600 //Set hardware dimmer range (is mapped to 0, 100 in GUI)
// as of: https://www.elektroda.com/rtvforum/viewtopic.php?p=21707931#21707931
// linkTuyaMCUOutputToChannel dpId verType tgChannel [ bDPCache ]
linkTuyaMCUOutputToChannel 2 val 2 2 // new "bDPCache" "flags" arg: 2 means "do not read"
startDriver httpButtons
//Switch Type dpId=6 Enum V=<seconds>
setChannelType 6 Textfield
setChannelLabel 6 "toggle power after given time in seconds. Set 0 to cancel."
linkTuyaMCUOutputToChannel 6 val 6
// Power-On State dpID 14 - Channel 14
setChannelType 14 OffOnRemember
setChannelLabel 14 "power-on behavior"
linkTuyaMCUOutputToChannel 14 enum 14
PowerSave 1
p.kaczmarek2 wrote:So... are you saying that everything works okay now? Including ping pong?
// device: Moyes MS-105
// because standard S1 functionality does not allow to revert the dimming direction at any time
// we replace S1 by a push button connected between P6 of the WiFi module and ground
// new functionality:
// short press: now switches on/off
// long press: is dimming either up or down
// double press: toggles dim direction up/down
// ping pong: if brightness reaches the upper or lower bound: reverse dim direction
startdriver tuyamcu
tuyaMcu_defWiFiState 4
SetButtonTimes 10 3 1 // works with bDPCache==2 only (see below)
SetFlag 43 1 // Flag 43 - [TuyaMCU] Use queue
SetFlag 10 0 // Flag 10 - [MQTT] Broadcast self state on MQTT connect DONT CLUTTER LOG
// P6 connected to the push button
SetPinChannel 6 35
SetPinRole 6 Btn
SetChannel 34 4 // define dim stepsize
alias reverse_dim_dir setChannel 34 -$CH34
alias check_bounds if $CH2==100||$CH2==0 then reverse_dim_dir
addEventHandler OnClick 6 toggleChannel 1
addEventHandler OnHold 6 addChannel 2 $CH34 0 100 0
addEventHandler OnDblClick 6 reverse_dim_dir
addEventHandler OnChannelChange 2 check_bounds
// Power On/Off dpID 1 - Channel 1
setChannelType 1 toggle
setChannelLabel 1 "CH1 On/Off"
linkTuyaMCUOutputToChannel 1 bool 1
// Brightness dpID 2 - Channel 2
setChannelType 2 Dimmer
tuyaMcu_setDimmerRange 100 1000
// as of: https://www.elektroda.com/rtvforum/viewtopic.php?p=21707931#21707931
// linkTuyaMCUOutputToChannel dpId verType tgChannel [ bDPCache ]
linkTuyaMCUOutputToChannel 2 val 2 2 // new "bDPCache" "flags" arg: 2 means "do not read"
PowerSave 1
p.kaczmarek2 wrote:everything works okay now
p.kaczmarek2 wrote:Or is there a feature that you'd like to add?
p.kaczmarek2 wrote:working correctly with flags set to 0, I mean, in mapping DP?
p.kaczmarek2 wrote:Can I merge this change into the main release, so other users can benefit from it as well?
p.kaczmarek2 wrote:We'll change argument "use wrap instead of clamp", use value 2
// device: Moyes MS-105
// because standard S1 functionality does not allow to revert the dimming direction at any time
// we replace S1 by a push button connected between P6 of the WiFi module and ground
// new functionality:
// short press: switches on/off
// long press if device is on: dim either up or down
// long press if device is off: turn on at brightness zero, continue from there with dim
// double press: toggles dim direction up/down
// ping pong: if brightness reaches the upper or lower bound: reverse dim direction
startdriver tuyamcu
tuyaMcu_defWiFiState 4
SetButtonTimes 10 3 1 // works with bDPCache==2 only (see below)
SetFlag 43 1 // Flag 43 - [TuyaMCU] Use queue
SetFlag 10 0 // Flag 10 - [MQTT] Broadcast self state on MQTT connect DONT CLUTTER LOG
// P6 connected to the push button
SetPinChannel 6 35
SetPinRole 6 Btn
SetChannel 34 4 // define dim stepsize
alias reverse_dim_dir setChannel 34 -$CH34
alias check_bounds if $CH2==100||$CH2==0 then reverse_dim_dir
alias turn_on_at_zero backlog SetChannel 1 1; SetChannel 2 1
addEventHandler OnClick 6 toggleChannel 1
// long press if off: switch on in the first place
addEventHandler OnHold 6 if $CH1==0 then turn_on_at_zero else "addChannel 2 $CH34 0 100 0"
addEventHandler OnDblClick 6 reverse_dim_dir
addEventHandler OnChannelChange 2 check_bounds
// Power On/Off dpID 1 - Channel 1
setChannelType 1 toggle
setChannelLabel 1 "CH1 On/Off"
linkTuyaMCUOutputToChannel 1 bool 1
// Brightness dpID 2 - Channel 2
setChannelType 2 Dimmer
tuyaMcu_setDimmerRange 100 1000
// as of: https://www.elektroda.com/rtvforum/viewtopic.php?p=21707931#21707931
// linkTuyaMCUOutputToChannel dpId verType tgChannel [ bDPCache ]
linkTuyaMCUOutputToChannel 2 val 2 2 // new "bDPCache" "flags" arg: 2 means "do not read"
PowerSave 1
addChannel 1 24 0 100 2
p.kaczmarek2 wrote:and tell me whether it's ready to be merged with public release
// device: Moyes MS-105
// because standard S1 functionality does not allow to revert the dimming direction at any time
// we replace S1 by a push button connected between P6 of the WiFi module and ground
// new functionality:
// short press: switches on/off
// long press if device is on: dim either up or down
// long press if device is off: turn on at brightness zero, continue from there with dim
// ping pong: if brightness reaches the upper or lower bound: reverse dim direction
startdriver tuyamcu
tuyaMcu_defWiFiState 4
SetButtonTimes 10 3 1 // works with bDPCache==2 only (see below)
SetFlag 43 1 // Flag 43 - [TuyaMCU] Use queue
SetFlag 10 0 // Flag 10 - [MQTT] Broadcast self state on MQTT connect DONT CLUTTER LOG
// P6 connected to the push button
SetPinChannel 6 35
SetPinRole 6 Btn
SetChannel 34 4 // define dim stepsize
alias turn_on_at_zero backlog SetChannel 1 1; SetChannel 2 1
addEventHandler OnClick 6 toggleChannel 1
// long press if off: switch on in the first place
// test new OBK feature: addChannel ping-pong flag
addEventHandler OnHold 6 if $CH1==0 then turn_on_at_zero else "addChannel 2 $CH34 0 100 2"
// Power On/Off dpID 1 - Channel 1
setChannelType 1 toggle
setChannelLabel 1 "CH1 On/Off"
linkTuyaMCUOutputToChannel 1 bool 1
// Brightness dpID 2 - Channel 2
setChannelType 2 Dimmer
tuyaMcu_setDimmerRange 100 1000
// as of: https://www.elektroda.com/rtvforum/viewtopic.php?p=21707931#21707931
// linkTuyaMCUOutputToChannel dpId verType tgChannel [ bDPCache ]
linkTuyaMCUOutputToChannel 2 val 2 2 // new "bDPCache" "flags" arg: 2 means "do not read"
PowerSave 1
p.kaczmarek2 wrote:So you want a command to reverse ping pong direction
sp4rk1e wrote:So you need some means (e.g double click) to fix that.
Quote:
So the obk command is:addChannel 1 24 0 100 2
The last argument, here "2", means "use ping pong" mode. So, once it reaches max, it will remember to use inverted sign for 24 (delta value).
sp4rk1e wrote:
we need not to wait for 'once it reaches max, or min' . Instead we could invert the sign after each "grouped sequence of calls" (done with a "long press") to 'addChannel' in this mode. Maybe with flag set to '3' instead of '2'
p.kaczmarek2 wrote:we can bind some command to "on release" event
linkTuyaMCUOutputToChannel 2 val 2 0
linkTuyaMCUOutputToChannel 2 val 2 2
// device: Moyes MS-105
//
// features:
// short press: switches on/off
// long press if device is on: dim either up or down
// long press if device is off: turn on at brightness zero, continue from there with dim up
// if brightness reaches the upper or lower bound: reverse dim direction (ping pong)
// after long press: reverse dim direction
startDriver TuyaMCU
tuyaMcu_defWiFiState 4
PowerSave 1
//SetFlag 43 1 // Flag 43 - [TuyaMCU] Use queue
SetFlag 10 0 // Flag 10 - [MQTT] Broadcast self state on MQTT connect DONT CLUTTER LOG
SetButtonTimes 2 3 2 // provides fast response and low lag, works with bDPCache==2 only (see below)
// must use FW Version: OpenBK7231N_noread_d039226dedd6.rbl for that
SetChannel 14 4 // define dim stepsize
// P6 connected to the push button
SetPinChannel 6 10
SetPinRole 6 Btn
alias reverse_dim_dir setChannel 14 -$CH14
alias turn_on_at_zero backlog SetChannel 1 1; SetChannel 2 1
alias dim_step backlog if $CH2==100||$CH2==0 then reverse_dim_dir; addChannel 2 $CH14 0 100 0; SetChannel 15 1
alias reverse_and_clear backlog reverse_dim_dir; SetChannel 15 0
setChannelType 1 toggle
linkTuyaMCUOutputToChannel 1 bool 1
setChannelType 2 dimmer
tuyaMcu_setDimmerRange 0 1000
linkTuyaMCUOutputToChannel 2 val 2 2 // new "bDPCache" "flags" arg: 2 means "do not read"
addEventHandler OnClick 6 toggleChannel 1
addEventHandler OnHold 6 if $CH1==0 then turn_on_at_zero else dim_step
addEventHandler OnRelease 6 if $CH15==1 then reverse_and_clear
p.kaczmarek2 wrote:PR has reused bDPCache argument for flags, and you set it to 2.
https://github.com/openshwprojects/OpenBK7231T_App/pull/1820/files
On old Release, 2 is intepreted as "true" and value is not sent at all because OBK thinks it's for dp cache request.
p.kaczmarek2 wrote:I think you know how to use it,
startDriver TuyaMCU
tuyaMcu_defWiFiState 4
PowerSave 1
SetFlag 10 0 // Flag 10 - [MQTT] Broadcast self state on MQTT connect DONT CLUTTER LOG
SetButtonTimes 2 3 2 // provides fast response and low lag, works with bDPCache==2 only (see below)
// must use Version: noread_e8ef72c891b1 for that
SetChannel 14 4 // define dim stepsize
// P6 connected to the push button
SetPinChannel 6 10
SetPinRole 6 Btn
alias turn_on_at_zero backlog SetChannel 1 1; SetChannel 2 1
alias dim_step backlog addChannel 2 $CH14 0 100 0; SetChannel 15 1
alias reverse_and_clear backlog addChannel 2 $CH14 0 100 3; SetChannel 15 0
setChannelType 1 toggle
linkTuyaMCUOutputToChannel 1 bool 1
setChannelType 2 dimmer
tuyaMcu_setDimmerRange 0 1000
linkTuyaMCUOutputToChannel 2 val 2 2 // new "bDPCache" "flags" arg: 2 means "do not read"
addEventHandler OnClick 6 toggleChannel 1
addEventHandler OnHold 6 if $CH1==0 then turn_on_at_zero else dim_step
addEventHandler OnRelease 6 if $CH15==1 then reverse_and_clear
addChannel 2 10 0 100 2
addChannel 2 0 0 100 3
startDriver TuyaMCU
tuyaMcu_defWiFiState 4
PowerSave 1
SetFlag 10 0 // Flag 10 - [MQTT] Broadcast self state on MQTT connect DONT CLUTTER LOG
SetButtonTimes 2 3 2 // provides fast response and low lag, works with bDPCache==2 only (see below)
// must use Version: noread_e8ef72c891b1 for that
SetChannel 14 4 // define dim stepsize
// P6 connected to the push button
SetPinChannel 6 10
SetPinRole 6 Btn
alias turn_on_at_zero backlog SetChannel 1 1; SetChannel 2 1
alias dim_step backlog addChannel 2 $CH14 0 100 2; SetChannel 15 1
alias reverse_and_clear backlog addChannel 2 $CH14 0 100 3; SetChannel 15 0
setChannelType 1 toggle
linkTuyaMCUOutputToChannel 1 bool 1
setChannelType 2 dimmer
tuyaMcu_setDimmerRange 0 1000
linkTuyaMCUOutputToChannel 2 val 2 2 // new "bDPCache" "flags" arg: 2 means "do not read"
addEventHandler OnClick 6 toggleChannel 1
addEventHandler OnHold 6 if $CH1==0 then turn_on_at_zero else dim_step
addEventHandler OnRelease 6 if $CH15==1 then reverse_and_clear
addEventHandler OnClick 6 toggleChannel 1
addEventHandler OnHold 6 addChannel 2 10 0 100 2
addEventHandler OnRelease 6 addChannel 2 0 0 100 3
TL;DR: For OpenBeken users modding Avatto dimmers, the proven path is 115200 baud with a TuyaMCU mapping; as one expert put it, "the ignore flag support is the only change really required" for stable scripted dimming. This FAQ shows how to flash the CBU, map 1CH/2CH dpIDs, and build reliable autoexec dimming with MCU feedback control. [#21711817]
Why it matters: This thread turns a partly working Tuya dimmer conversion into a repeatable OpenBeken setup, including stable dimming, dual-channel mapping, and custom button behavior.
| Wariant | Kanały | Kluczowe dpIDs jasności | Baud TuyaMCU | Stan w wątku |
|---|---|---|---|---|
| Avatto DMS16-W1 | 1 | 2, 3, 5 | 115200 | Działa z autoexec; min/max nadal niestandardowe |
| Avatto DMS16-Y1 | 1 | 2, 3, 6 | 115200 | Potwierdzony timer i test z żarówką tradycyjną |
| Avatto 2CH | 2 | CH1: 2/3/5, CH2: 8/9/11 | 115200 | Działa po mapowaniu dpID 7–12 |
| Moyes MS-105 | 1 | 2 | niewskazany w cytowanym skrypcie | Użyty do porównania zachowania ping-pong |
Key insight: Najlepsze efekty dało przeniesienie przycisku z MCU na GPIO modułu BK7231N/CBU i sterowanie jasnością zdarzeniami OpenBeken. Gdy MCU odsyła opóźnione poziomy dimmera, flaga mapowania
2może ignorować ten odczyt i wygładzić działanie. [#21708368]
tuyaMcu_setBaudRate 115200. [#21164436]SetButtonTimes nawet 2 3 2 lub 10 3 1, ale stabilność zależała od ignorowania sprzężenia zwrotnego dimmera i czasem od kolejki TuyaMCU. [#21711591]115200 on this device. 3. Reinstall the CBU, boot OpenBeken, then use TuyaMCU mapping to talk to the Puya over UART. J-Link access to the Puya failed in the thread even with NRST held low, so the working route was replacing only the CBU firmware. [#21164436]led_type_1 and dpID 13 as work_mode. Specific ranges are given: brightness and min/max are 10–1000, countdown is 0–86400 s, and power-on state supports off, on, and memory. [#21164436]startDriver TuyaMCU, tuyaMcu_setBaudRate 115200, and tuyaMcu_defWiFiState 4. Map dpID 1 as bool to channel 1, dpID 2 as val to channel 2, dpID 6 as a text/countdown field, and dpID 14 as enum for power-on behavior. Set channel 2 as Dimmer and apply a hardware range such as 90 600 or 200 1000. The thread’s working scripts also add httpButtons, SetFlag 43 1, and event handlers when the physical switch is rewired to a GPIO. [#21708368]tuyaMcu_setDimmerRange 200 1000 still displayed a fixed 0-100 slider, while UART traffic proved the module sent correct raw Tuya values to the MCU. Later scripts kept the same pattern with ranges like 90 600 and comments that this hardware range is mapped to 0, 100 in the GUI. [#21164436]115200, matching the W1 workflow. [#21173417]switch_led_2, bright_value_2, brightness_min_2, led_type_2, brightness_max_2, and countdown_2 followed the first channel directly. [#21441155]brightness_min and brightness_max as separate controls, not to mimic Tuya’s custom dual-ended slider. OpenBeken did not have a built-in channel type for that UI, and the firmware author said it would need to handle two dpIDs at once. The suggested fallback was two independent sliders, one for minimum and one for maximum, or a custom REST page if you want a better UI. That matches the thread’s conclusion: the Tuya range widget is custom, while OBK’s core mapping stays simpler. [#21164833]91, but the MCU then reported raw value 554, which OBK mapped back to 90; the same pattern repeated at 93→92 and 95→94. Later testing showed these dimmers change brightness smoothly inside the MCU, so feedback can lag scripted commands. On Avatto DMS16-W1, that lag still caused sporadic flicker even after other fixes, while the compared Moyes MS-105 did not show the same issue. [#21707334]addChannel dimming. The flag was also reported as a GUI/template inconsistency at one point, but it could be set with SetFlag 43 1 in autoexec and was shown correctly in the main flags page. [#21706850]linkTuyaMCUOutputToChannel so 2 means “ignore read” for that mapping. In practice, linkTuyaMCUOutputToChannel 2 val 2 2 lets OBK send brightness to the MCU while discarding the MCU’s delayed dimmer feedback. That mattered because user scripts on rewired buttons expected their own channel values to win. The firmware author changed the older bDPCache argument into a flags field, where 1 keeps DP cache behavior and 2 suppresses incoming readback for that mapped channel. [#21707931]N was already tied to 3.3 V circuit ground. 2. Set that pin as Btn. 3. Bind OnClick to toggle power, OnHold to addChannel dimming, and OnRelease to reverse direction if needed. This gave short-press, long-press, and custom dimming behaviors the factory MCU logic did not provide. [#21706499]addChannel bounce between the minimum and maximum instead of clamping or wrapping. With mode 2, OBK remembers direction and automatically reverses when the channel reaches limits such as 0 or 100; the author’s self-test showed a sequence like 0, 25, 50, 75, 100, 75, 50. With mode 3, OBK does not change brightness; it only flips the stored ping-pong direction in place. That let users dim on hold and reverse direction on release or another event. [#21711805]flip, sync, and button modes. By moving the switch to a BK7231N GPIO, users added short-press toggle, long-press dimming, release-triggered direction changes, and ping-pong dimming. One thread expert summarized the benefit clearly: rewiring to the Wi-Fi module “allows interesting new features the original device is lacking.” [#21708368]5 s. What is clear is that both devices dim smoothly inside the MCU, and the user scripts often turn the light on at a very low level first, for example with SetChannel 2 1, then continue dimming upward on hold. That means power-on in the custom script can be a controlled low-start rather than an instant jump to 100%, but no final benchmark in seconds was posted. [#21773291]