logo elektroda
logo elektroda
X
logo elektroda

Avatto DMS16-W1 CBU Dimmer + Puya PY32F002A MCU: OpenBeken Flashing and Autoexec Setup

divadiow 2904 61
ADVERTISEMENT
📢 Listen (AI):
  • #31 21707545
    p.kaczmarek2
    Moderator Smart Home
    No, just replacing addChannel with setChannel in script won't help us much. I was rather thinking, that since you suspect that some odd/even values might not work, that maybe you can try to reproduce slowly the scenario from log with setChannel from command line (obk web app log) and see if the problem repeats.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #32 21707738
    sp4rk1e
    Level 9  
    ok, I will try.

    I got another idea though. I recently bought this one: the successor of OpenBeken and TuyaMCU dimmer - configuration guide/tutorial . It is the Moyes MS-105 (1 channel version). I will setup the same configuration there and then I can compare the two systems. Same software on different hardware. That makes it much easier to find flaws I hope...

    Added after 3 [hours] 3 [minutes]:

    I now setup the moyes the same way. There also exists the problem that hardware dimmer values reported back to the WIFi chip lag behind software dimmer values previously issued to the MCU. It's now clear why :-)

    Because both DMS16-W1 and Moyes MS-105 always change dimming very smootly in MCU. No matter if you use the standard button or WiFi Chip to change the dim value.
  • #33 21707931
    p.kaczmarek2
    Moderator Smart Home
    Do you know C?
    I changed "bDPCache" argument to "flags", 1 means dpCache, 2 means "do not read"
    
    linkTuyaMCUOutputToChannel [dpId] [varType] [channelID] [obkFlags] [mult] [inv] [delta]
    

    If you use obkFlags value 2 for your mapping, it will ignore read. Can you check? Is it even acceptable for us to ignore that read? I am not sure, could it break other things?

    get binary here
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1820
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #34 21707948
    sp4rk1e
    Level 9  
    p.kaczmarek2 wrote:
    Do you know C?

    no problem

    p.kaczmarek2 wrote:
    Can you check?

    thanks! if binary is available I will check

    p.kaczmarek2 wrote:
    Is it even acceptable for us to ignore that read? I am not sure, could it break other things?

    I don't know. I'm completely new to Tasmota and/or OpenBK
  • #35 21708000
    p.kaczmarek2
    Moderator Smart Home
    Build has finished, do you know how to download binary from PR?

    Here is explanation how to download it: https://www.elektroda.com/rtvforum/topic4033833.html
    Helpful post? Buy me a coffee.
  • #36 21708021
    sp4rk1e
    Level 9  
    p.kaczmarek2 wrote:
    do you know how to download binary from PR

    sorry, never dealt with this. Some hourglasses are still rotating in github. Really ready? I'll try to find out

    Added after 30 [minutes]:

    looking at the huge masses of 'Artifacts' of 'ttuyamcu noread flag #7229' how do I know which one is suitable for OTA? I'm used to look for .rbl suffix but none of them got that :-(
  • #37 21708313
    p.kaczmarek2
    Moderator Smart Home
    There is 93MB file which contains all binaries. Alternatively, you can download OpenBK7231T_App_1820_merge_fb5f7b416567_OpenBK7231N, which is pure OpenBK7231N, this should match CBU from the topic.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #38 21708368
    sp4rk1e
    Level 9  
    your fix works very well, thank you. I tested with Moyes MS-105 and Avatto DMS16-W1.

    observations:
    - ignoring the dim level reported by the MCU allows a quite smooth dim effect with exactly the dim step size we specify
    - for both models we now can safely lower 'SetButtonTimes' from standard [10 3 5] to [10 3 1] giving a quite responsive dim effect
    - unfortunately the sporadic flicker of 'DMS16-W1' is still there. This appears to be device specific. The 'MS-105' has no such issues at all

    conclusion:
    - the idea replacing the standard S1 terminals of a dimmer by a custom port of the WiFi module allows interesting new features the original device is lacking. e.g:
    - ping-pong dim direction (instead wrapping brightness) when reaching range limits
    - custom behavior on long press, double press...

    both autoexecs:
    
    // 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
    
  • #39 21708475
    p.kaczmarek2
    Moderator Smart Home
    So... are you saying that everything works okay now? Including ping pong? Or is there a feature that you'd like to add?

    Is the OBK also working correctly with flags set to 0, I mean, in mapping DP? I didn't break anything, right? Can I merge this change into the main release, so other users can benefit from it as well?
    Helpful post? Buy me a coffee.
  • #40 21708719
    sp4rk1e
    Level 9  
    p.kaczmarek2 wrote:
    So... are you saying that everything works okay now? Including ping pong?

    ping pong must be implemented in autoexec.bat.
    Is there some documentation (besides the examples) what maths can be done in autoexec,bat?
    My first (working) attempt (for Moyes MS-105). I don't know if that can be done more efficiently:
    
    // 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

    as said the Avatto DMS16-W1 sporadically flickers, when brightness is changed per 'addChannel'. I don't know how to debug this.

    p.kaczmarek2 wrote:
    Or is there a feature that you'd like to add?

    ATM no other wishes :-)

    p.kaczmarek2 wrote:
    working correctly with flags set to 0, I mean, in mapping DP?

    I haven't seen any issues. But as said I'm absolute beginner in terms of OpenBK. Don't know all test cases
    p.kaczmarek2 wrote:
    Can I merge this change into the main release, so other users can benefit from it as well?

    that would be fine
  • #41 21708759
    p.kaczmarek2
    Moderator Smart Home
    Oh, I see! There is no ping pong yet. Well, how about this - let me add it for you. I have some idea how to do it in OBK firmware itself. We'll change argument "use wrap instead of clamp", use value 2 to set ping pong mode. Would that solve issue better, without autoexec.bat?
    Helpful post? Buy me a coffee.
  • #42 21708830
    sp4rk1e
    Level 9  
    p.kaczmarek2 wrote:
    We'll change argument "use wrap instead of clamp", use value 2

    ok, but the problem is who will change the sign of the added dim step constant?
    What would the code snippet in autoexec.bat for changing the dim brightness look like if the ping pong is implemented in OBK firmware ?

    Added after 8 [minutes]:

    current implementation with ping pong. I don't know how we could port some things thereof to firmware:
    
    // 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
    
  • #43 21708837
    p.kaczmarek2
    Moderator Smart Home
    I've implemented a ping pong by remembering sign of the value. Here's a self test code I used in the Simulator:
    Code: C / C++
    Log in, to see the code

    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).

    The logic is designed in such a way, that it always stops at min and max, so you can relatively easily hit max and min value....
    All tests passed, no conflicts when merging noread branch into main.

    No futher configuration is needed, can you update and retry, and tell me whether it's ready to be merged with public release?
    Helpful post? Buy me a coffee.
  • #44 21708859
    sp4rk1e
    Level 9  
    p.kaczmarek2 wrote:
    and tell me whether it's ready to be merged with public release

    thanks, works like a charm with following autoexec.bat on Moyes MS-105

    compared to my previous autoexec one feature is now missing:

    if we use the new OBK feature:
    we no longer can reverse the dim direction on double press (as in my example before). Except we could make the current dim direction chosen by the firmware visible to the autoexec variables.

    
    // 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
    
  • #45 21708863
    p.kaczmarek2
    Moderator Smart Home
    So you want a command to reverse ping pong direction? Just that? Or what do you mean by visible?
    Helpful post? Buy me a coffee.
  • #46 21708864
    sp4rk1e
    Level 9  
    p.kaczmarek2 wrote:
    So you want a command to reverse ping pong direction

    exactly that.

    But I don't know if it would complicate things unnecessarily if all ping ponging is now done in firmware?
    Because at least all these flags newly added are not so obvious compared to a self contained script. At least for somebody who did not read this thread :-)
  • #47 21709027
    p.kaczmarek2
    Moderator Smart Home
    But.... is it really needed, from a user point of view? Wouldn't it be better to have:
    - single click - toggle on and off
    - hold - ping pong dimmer
    - double click - 100% brightness?
    Helpful post? Buy me a coffee.
  • #48 21709140
    sp4rk1e
    Level 9  
    if you want to dim down but dimmer currently dims up it's annoying to wait for the ping pong and to further wait until it passes the brightness you target,
    So you need some means (e.g double click) to fix that. But it's easily implemented in autoexec,bat

    The ignore flag support is the only change really required in firmware. Because you can't handle that in user space.

    Added after 11 [hours] 47 [minutes]:

    sp4rk1e wrote:
    So you need some means (e.g double click) to fix that.

    most commercial dimmers reverse the dim direction after each dimming step (i.e. after a long press). This IMHO is a good approach to speed up the dimming process.
    It allows for some kind of successive approximation of the targeted dim level :-)

    maybe that could (optionally) be supported directly in firmware? This could be done with a small modification to your existing solution:

    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).


    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'
  • #49 21709514
    p.kaczmarek2
    Moderator Smart Home
    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'

    We don't have a reliable way to detect it in the addChannel, but maybe we can bind some command to "on release" event of the button? When button stops being pressed?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #50 21709522
    sp4rk1e
    Level 9  
    p.kaczmarek2 wrote:
    we can bind some command to "on release" event

    right. We actually just need *any* command that allows the user to switch the dim direction at any time. If it's bound to a release or something else is up the the user
  • #51 21711591
    sp4rk1e
    Level 9  
    just rechecked with current OpenBK7231N_1.18.188.rbl
    something is going wrong. Even though the log appears to be ok, the dimming values do not reach the hardware. Switching on/off works. But brightness stays always on the same level. If I then issue
    
    linkTuyaMCUOutputToChannel 2 val 2 0
    

    on console dimming starts to work as expected. I then can even reactivate the new flag:
    
    linkTuyaMCUOutputToChannel 2 val 2 2    
    

    and it still works properly. Is it an initialization thing?

    I then rechecked with 'OpenBK7231N_noread_d039226dedd6.rbl': there are no such issues
    My test autoexec:
    
    // 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
    
  • #52 21711681
    p.kaczmarek2
    Moderator Smart Home
    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.

    Ok, I added "switch direction" hack for you.
    https://github.com/openshwprojects/OpenBK7231...mits/9bfeae5706a35498f5c7b7ed4b00c5acdbe4a570
    It is fairly simple - if you use mode 3 instead of 2, then max/min/delta values are ignored, and just direction is inverted. I think you know how to use it, right?
    Helpful post? Buy me a coffee.
  • #53 21711738
    sp4rk1e
    Level 9  
    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.

    thank you.
    with 'OpenBK7231N_1820_merge_db247b9d377d.rbl' it works again.

    p.kaczmarek2 wrote:
    I think you know how to use it,

    unfortunately no. How do you decide when to invert the direction? In our last discussion we came to the conclusion the user must do something in 'ButtonRelease'.

    But as you can see from my last script to ease things maybe we don't really need support for this feature directly in firmware? Even in autoexec the direction switch on 'release' is easily managed...
  • #54 21711755
    p.kaczmarek2
    Moderator Smart Home
    Ok, so you know the OnHold event, right? So there is also... OnRelease event, which gets called, when button is released. Do you think it could be suitable?
    Helpful post? Buy me a coffee.
  • #55 21711781
    sp4rk1e
    Level 9  
    I assume you meant the use of the new flag this way?

    
    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
    
  • #56 21711805
    p.kaczmarek2
    Moderator Smart Home
    No. I was referring to automatic ping-pong.
    This will add value to 10 to channel 2 in range 0 100 with mode 2 (automatic ping pong)
    
    addChannel 2 10 0 100 2
    

    This will toggle automatic ping pong direction in place for channel 2 (mode 3 means 'revert'):
    
    addChannel 2 0 0 100 3
    
    Helpful post? Buy me a coffee.
  • #57 21711810
    sp4rk1e
    Level 9  
    ok thank you, modified the script - works 👍‍

    
    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
    
  • #58 21711811
    p.kaczmarek2
    Moderator Smart Home
    Thanks for testing, what do we next? Or can I merge this PR into release?
    Helpful post? Buy me a coffee.
  • #59 21711817
    sp4rk1e
    Level 9  
    from my point of perspective all works.

    The mandatory fix IMHO is the ignore flag in 'linkTuyaMCUOutputToChannel'. Otherwise you can't safely migrate buttons from MCU to the WiFi chip. Because responses of the MCU (if not ignored) possibly interfere with values expected by the user script.

    After all the support of 'toggle automatic ping pong direction' in firmware is questionable. Because some effort to handle the situation is still necessary in the user script. If you compare my 2 scripts the benefit of a firmware support there is not that particularly significant.
  • #60 21711851
    p.kaczmarek2
    Moderator Smart Home
    Why do you have conditionals? Wouldn't this be enough:
    
    addEventHandler OnClick    6 toggleChannel 1
    addEventHandler OnHold     6 addChannel 2 10 0 100 2
    addEventHandler OnRelease  6 addChannel 2 0 0 100 3
    

    On hold add 10 with ping pong (mode 2), on release just add 0 (no change) with direction swap (mode 3).
    Helpful post? Buy me a coffee.
📢 Listen (AI):

Topic summary

The discussion focuses on the Avatto DMS16-W1 1-channel dimmer smart switch featuring a CBU module communicating with a Puya PY32F002A MCU (TSSOP-20). Users explore flashing the device with OpenBeken firmware, identifying and mapping Tuya dpIDs for channel control, and configuring autoexec.bat scripts for proper operation. Key findings include dpID assignments for power on/off, brightness control, brightness range, switch type, power-on status, and timer functions, with variations noted in similar models like the Avatto DMS16-Y1 and 2-channel versions. Contributors share firmware dumps, flashing experiences, and configuration examples, including setting dimmer ranges, linking TuyaMCU outputs to channels, and enabling HTTP button drivers. The conversation also references tools and resources for sniffing dpIDs, restoring original firmware, and improving UI via REST pages. Overall, the thread provides practical insights into customizing and controlling Avatto dimmer switches using OpenBeken firmware and Puya MCU integration.
Summary generated by the language model.
ADVERTISEMENT