New switchmodes to control a dimmer with one switch

[RemiDing]

Description:

New switchmodes for Tasmota
With Switchmode 11 and 12 you can control a dimmer with one switch.

SwitchMode 11

Set push-button with dimmer mode

Tasmota will send a TOGGLE command (switch2#state=2) when the button is pressed for a short time and is then released. When pressing the button (closing the circuit) for a long time (set in SetOption32) Tasmota sends repeated INC_DEC (increment or decrement the dimmer) commands (switch2#state=4) as long as the button is pressed. Releasing the button starts a internal timer, the time is set in SetOption32. When released for the time set in SetOption32 Tasmota sends a CLEAR command (switch2#state=6). If the button is pressed again before the time set in SetOption32 is up Tasmota sends a INV command (switch#state=5). The INV command is for the controlling sortware (home assistant) to switch between incrementing and decrementing the dimmer.

SwitchMode 12

Set inverted push-button with dimmer mode.
The same as Switchmode 11 with inverted Input

Additional Rules and a automation are needed to control a dimmer.

Rule Example:

Rule1
on switch2#state=2 do publish stat/DVES_B95200/power2 toggle endon
on switch2#state=4 do publish stat/DVES_B95200/power2 inc_dec endon
on switch2#state=5 do publish stat/DVES_B95200/power2 inv endon
on switch2#state=6 do publish stat/DVES_B95200/power2 clear endon

switch#state=2: normal toggle function
switch#state=4: switch will repeat this state when the switch is pressed for a longer time
switch#state=5: the switch is pressed for a second time
switch#state=6: timeout

A short press of the switch sends a message to toggle the dimmer. A long press sends repeated messages to increment the dimmer. If a second press of the switch follows the first press a message is sent to invert the function from increment to decrement and repeatet messages are sent to decrement the dimmer. After releasing the switch a timeout message resets the automation.

Automation example for Home Assistant can be found here:

https://github.com/RemiDing/home-assistant-dimmer-with-shelly-RGBW

Related issue (if applicable): fixes #

Checklist:

• The pull request is done against the latest dev branch
• Only relevant files were touched
• Only one feature/fix was added per PR.
• The code change is tested and works on core 2.6.1
• The code change pass travis tests. Your PR cannot be merged unless tests pass
• I accept the CLA.

[ascillato]

Hi, thanks for sharing your ideas but this PR is backwards incompatible and can't be merged as it is.
switch#state=3 was already defined as HOLD. This PR breaks this behavior and the setup of some users. Can you modify your approach so as to leave the actual behaviors intact? Thanks.

[RemiDing]

I will change the code so that switch#state=3 is not used.
Then I will do more tests before before I commit again

[RemiDing]

switch#state=3 is not used anymore. The update should leave the actual behaviors intact.
Updated despription and Automation example

[patrickdk77]

I really didn't want to use HA inbetween so I adjusted the rule to not need homeassistant at all and directly control a bulb or group of bulbs.
The system#boot is only needed if someone uses a longpress right after bootup, as a anything else would also init mem1 var, but longpress the first time wouldn't work without it (likely a rare edge case)

on system#boot mem1 + endon
on switch1#state=2 do publish dinninglight/cmnd/POWER TOGGLE endon
on switch1#state=4 do publish dinninglight/cmnd/DIMMER %mem1% endon
on switch1#state=5 do mem1 - endon
on switch1#state=6 do mem1 + endon

[gadget78]

been using/playing with these new implementations today for my Dimming needs (Tasmota 8.3.1.2)
added to the fallback steps, to still have dimming work, if MQTT/HA drops out etc ...
using the the slower method of websend but still least in a fallback situation dimming will work :)
of course you will need to adjust it to suit, IP wise, and the switch number you are using !!
plus this implimentation is for MQTT only, but you get the gist :)
Thankyou for this switchmode 11 option !! and continued improvements !

and i hope this if found by some who needs it and gets some use from it :)..
this has elements from @xaviml @patrickdk77 and @htvekov picking bits up from #8386 and #8450

RULE1 
on Mqtt#Disconnected do backlog rule2 0; rule3 1 endon
on Mqtt#Connected do backlog rule2 1; rule3 0 endon

RULE2 
on switch2#state=2 do publish cmnd/MagicH/POWER TOGGLE endon 
on switch2#state=4 do publish cmnd/MagicH/DIMMER %mem1% endon 
on switch2#state=5 do mem1 - endon on switch2#state=6 do mem1 + endon

RULE3
on switch2#state=2 do websend [192.168.178.58] power toggle endon 
on switch2#state=4 DO websend [192.168.178.58] dimmer %mem1% endon 
on switch2#state=5 do mem1 - endon on switch2#state=6 do mem1 + endon

[mgiggs]

Love these new switchmodes and their ability to align remot single switch dimming to local single switch dimming, thanks for your work.

One thing I'm trying to do and do not know whether it is possible with the code as is or requires changes is still allow and process multipress on the same switch. I would like to be able to go to max brightness with a double press as this is how my hardwired tasmota (single button) dimmers work but I have not been able to get a multi press action using these switchmodes. Additional multipress options (3/4/5) would be an added bonus as these could be used to perform other functions on the remote lights other than dimming.

Thanks.

[htvekov]

Hi' @mgiggs

Switchmode 11/12 don't support multipress.
Switchmode 8/9 (10) support multipress but not dimming (hold/release) function.

Main issue against implementing multipress features on single button units, is the need to wait typical 0,5 to 0,8 seconds for additional presses before firing single/double/triple etc. commands.
In my usecase with Tasmota units behind wall switches, i rely on INSTANT toggle commands to turn on/off lights without delay.

In your usecase though, an extra double press command could be fired AFTER initial toggle command, without compromising instant toggle commands. You could try and raise a feature request for this 🙂

There's also the possibility to 'play' with the INV command (hold button followed by a single quick press) and length of SetOption32 period and see if this feature can be used as an alternative to the double press function ?

Ciao !

[htvekov]

Hi' @mgiggs

Just did a quick test and found that INV command does not rely on initial HOLD command.
INV command will also be issued after single press, if button is pressed again within SetOption32 time period (see log)

11:20:14 RUL: SWITCH1#STATE=2 performs "backlog publish zigbee2mqtt/office_cmnd toggle;publish zigbee2mqtt/office_cmnd"
11:20:14 MQT: kontor_loftlys/stat/SWITCH1T = {"TRIG":"ON"}
11:20:14 MQT: zigbee2mqtt/office_cmnd = toggle
11:20:14 MQT: zigbee2mqtt/office_cmnd = 
11:20:14 RUL: SWITCH1#STATE=5 performs "backlog publish zigbee2mqtt/office_cmnd inv;publish zigbee2mqtt/office_cmnd"
11:20:14 MQT: kontor_loftlys/stat/SWITCH1T = {"TRIG":"ON"}
11:20:14 MQT: zigbee2mqtt/office_cmnd = inv
11:20:14 MQT: zigbee2mqtt/office_cmnd = 
11:20:14 RUL: SWITCH1#STATE=2 performs "backlog publish zigbee2mqtt/office_cmnd toggle;publish zigbee2mqtt/office_cmnd"
11:20:14 MQT: kontor_loftlys/stat/SWITCH1T = {"TRIG":"ON"}
11:20:14 MQT: zigbee2mqtt/office_cmnd = toggle
11:20:14 MQT: zigbee2mqtt/office_cmnd = 

You'll have to deal with the consequitive TOGGLE command which will be fired as well, though.
Perhaps it's possible to use a rule to clear command buffer after the INV command is send ? If not you'll have to deal with the extra TOGGLE command in your automation code. Or use a rule with variable to capture second TOGGLE command.

Ciao !

[RemiDing]

This weekend I will have a look at his request. -- Diese Nachricht wurde von meinem Android Mobiltelefon mit WEB.DE Mail gesendet.Am 15.07.20, 11:54 schrieb Henning Tvekov <notifications@github.com>: Hi' @mgiggs Switchmode 11/12 don't support multipress. Switchmode 8/9 (10) support multipress but not dimming (hold/release) function. Main issue against implementing multipress features on single button units, is the need to wait typical 0,5 to 0,8 seconds for additional presses before firing single/double/triple etc. commands. In my usecase with Tasmota units behind wall switches, i rely on INSTANT toggle commands to turn on/off lights without delay. In your usecase though, an extra double press command could be fired AFTER initial toggle command, without compromising instant toggle commands. You could try and raise a feature request for this 🙂 There's also the possibility to 'play' with the INV command (hold button followed by a single quick press) and length of SetOption32 period and see if this feature can be used as an alternative to the double press function ? Ciao ! —You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.

[RemiDing]

Hi compiled with  #define USE_RULES // Add support for rules (+8k code) #define USE_EXPRESSION // Add support for expression evaluation in rules (+3k2 code, +64 bytes mem) #define SUPPORT_IF_STATEMENT // Add support for IF statement in rules (+4k2 code, -332 bytes mem)   and the setting Switchmode1 11; Switchmode2 11; Switchtopic 0; ButtonTopic 0; SetOption32 10; SetOption68 1   I tried the following rule to detect a double press of a switch   Rule2  on switch1#state=2 do if (var1==2) var1=3 else var1=1 endif endon                   on switch1#state=4 do var1=0 endon                   on switch1#state=5 do if (var1==1) var1=2 endif endon                   on switch1#state=6 do if (var1==3) publish stat/richelly/DVES_B95200/power1 max100 endif endon                   on switch1#state=7 do var1=0 endon   It should detekt the doublepress of a switch. The problem is that the rules are executed to slow. Is there a way to run rules faster? If not I can change the code so that switchmode 12 detects a doublepress of a switch Ciao !             Gesendet: Mittwoch, 15. Juli 2020 um 12:36 Uhr Von: "Henning Tvekov" <notifications@github.com> An: "arendst/Tasmota" <Tasmota@noreply.github.com> Cc: "RemiDing" <richi.glatthaar@web.de>, "Author" <author@noreply.github.com> Betreff: Re: [arendst/Tasmota] New switchmodes to control a dimmer with one switch (#7603)   Hi' @mgiggs Just did a quick test and found that INV command does not rely on initial HOLD command. INV command will also be issued after single press, if button is pressed again within SetOption32 time period (see log) 11:20:14 RUL: SWITCH1#STATE=2 performs "backlog publish zigbee2mqtt/office_cmnd toggle;publish zigbee2mqtt/office_cmnd" 11:20:14 MQT: kontor_loftlys/stat/SWITCH1T = {"TRIG":"ON"} 11:20:14 MQT: zigbee2mqtt/office_cmnd = toggle 11:20:14 MQT: zigbee2mqtt/office_cmnd = 11:20:14 RUL: SWITCH1#STATE=5 performs "backlog publish zigbee2mqtt/office_cmnd inv;publish zigbee2mqtt/office_cmnd" 11:20:14 MQT: kontor_loftlys/stat/SWITCH1T = {"TRIG":"ON"} 11:20:14 MQT: zigbee2mqtt/office_cmnd = inv 11:20:14 MQT: zigbee2mqtt/office_cmnd = 11:20:14 RUL: SWITCH1#STATE=2 performs "backlog publish zigbee2mqtt/office_cmnd toggle;publish zigbee2mqtt/office_cmnd" 11:20:14 MQT: kontor_loftlys/stat/SWITCH1T = {"TRIG":"ON"} 11:20:14 MQT: zigbee2mqtt/office_cmnd = toggle 11:20:14 MQT: zigbee2mqtt/office_cmnd = You'll have to deal with the consequitive toggle command which will be fired as well, though. Perhaps you can use a rule to clear command buffer after the INV command is send. If not you'll have to deal with the extra TOGGLE command in your automation code. Ciao ! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[htvekov]

Hi' @RemiDing

I'll try and test your version ASAP later this week.

Between each backlog rule command the default delay is 200 ms.
So if this same delay applies to 'if/expression' rules, the delay from your first to last command in rule2 will be one full second - an eternity... 🙄
I've succesfully decreased default delay to 50 ms. in my current setup and haven't (yet) experienced any problems.
Have you tested with a lower setting for setoption34 ?

Setoption34 50 Minimize delay between backlog commands to 50 ms. (Default 200 ms.)

Ciao !

[RemiDing]

Hi I tried Setoption34 50 Its better but it is still not fast enough.   Maybe a change in the support_switch.ino code is better. Switch.hold_timer[i] is always smaller than 64  I suggest to use 2 Bits of Switch.hold_timer[i] as a state machine, so there will be not more RAM usage. Ciao     Gesendet: Montag, 20. Juli 2020 um 22:34 Uhr Von: "Henning Tvekov" <notifications@github.com> An: "arendst/Tasmota" <Tasmota@noreply.github.com> Cc: "RemiDing" <richi.glatthaar@web.de>, "Mention" <mention@noreply.github.com> Betreff: Re: [arendst/Tasmota] New switchmodes to control a dimmer with one switch (#7603)   Hi' @RemiDing I'll try and test your version ASAP later this week. Between each backlog rule command the default delay is 200 ms. So if this same delay applies to 'if/expression' rules, the delay from your first to last command in rule2 will be one full second - an eternity... 🙄 I've succesfully decreased default delay to 50 ms. in my current setup and haven't (yet) experienced any problems. Have you tested with a lower setting for setoption34 ? Setoption34 50 Minimize delay between backlog commands to 50 ms. (Default 200 ms.) Ciao ! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[mgiggs]

Very impressed with your efforts, a lot of this is a bit more advanced than I usually manage but happy to help test if I can.

[RemiDing]

under  https://github.com/RemiDing/Tasmota/tree/development/build_output/firmware you will find a firmware.bin to test   you can use rules like this:   on switch1#state=2 do publish stat/DVES_B95200/power1 toggle endon on switch1#state=4 do publish stat/DVES_B95200/power1 hold endon on switch1#state=5 do publish stat/DVES_B95200/power1 inv endon on switch1#state=6 do publish stat/DVES_B95200/power1 clear endon" on switch1#state=8 do publish stat/DVES_B95200/power1 max100 endon"     switch state 8 is a new switch stae that should turn on the LEDs to 100%         Gesendet: Mittwoch, 22. Juli 2020 um 07:45 Uhr Von: "mgiggs" <notifications@github.com> An: "arendst/Tasmota" <Tasmota@noreply.github.com> Cc: "RemiDing" <richi.glatthaar@web.de>, "Mention" <mention@noreply.github.com> Betreff: Re: [arendst/Tasmota] New switchmodes to control a dimmer with one switch (#7603)   Very impressed with your efforts, a lot of this is a bit more advanced than I usually manage but happy to help test if I can. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[htvekov]

Hi' @RemiDing

Cool ! 😎👍

So on top of Tasmota 2.3.1.X dev. you added switchx#state=08 to detect double presses.
Is delay between the double presses defined by SetOption32 or hardcode to xx msec. ?

Any changes to the previous switchstates ?
(Hopefully no delays added to toggle or clear command (waiting to detect second press)

I'll download and test ASAP

Ciao !

[mgiggs]

Gave it a try and it works perfectly for me, thanks so much for your time and effort on this. Obviously the extra feature is convenient but the best element of this is that it aligns the usage of a virtual dimmer with that of a hard wired dimmer so you can mix and match through the house and have a common user experience. So I think this capability will be beneficial in the mainstream code.

For your interest and reference, these are the rules I use:

on system#boot mem1 + endon
on switch1#state=2 do publish cmnd/test_light/power toggle endon
on switch1#state=4 do publish cmnd/test_light/dimmer %mem1% endon
on switch1#state=5 do mem1 - endon
on switch1#state=6 do mem1 + endon
on switch1#state=8 do publish cmnd/test_light/dimmer 100 endon

[RemiDing]

Hi Yes I added switchx#state=08 to detect double presses. Delay is defined by SetOption32 The previous switchstates should not change. but I would be happy if someone tests it, No delays to toggle or clear. Everything is the same as before, exept the added switchx#state=08 to detect double presses.   I have a new version https://github.com/RemiDing/Tasmota/tree/development/build_output/firmware   When you look at the code:  (support_switch_ino) I used Bits [7:6] of Switch.hold_timer[i] as a state machine to detect the double press. SetOption32 musst be smaller than 32 !!!!!!  (this applies only to switchmode 11 and 12) This is not really a problem. I have setoption32 aroud 10 most times   Ciao         Gesendet: Montag, 27. Juli 2020 um 00:00 Uhr Von: "Henning Tvekov" <notifications@github.com> An: "arendst/Tasmota" <Tasmota@noreply.github.com> Cc: "RemiDing" <richi.glatthaar@web.de>, "Mention" <mention@noreply.github.com> Betreff: Re: [arendst/Tasmota] New switchmodes to control a dimmer with one switch (#7603)   Hi' @RemiDing Cool ! 😎👍 So on top of Tasmota 2.3.1.X dev. you added switchx#state=08 to detect double presses. Is delay between the double presses defined by SetOption32 or hardcode to xx msec. ? Any changes to the previous switchstates ? (Hopefully no delays added to toggle or clear command (waiting to detect second press) I'll download and test ASAP Ciao ! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[htvekov]

Hi' @RemiDing

Just dowloaded your latest dev. version with double press feature and tested on a 'behind wall switch' Shelly1 running previous dev. version using Switchmode 11.

Can't seem to find any issues whatsoever regarding already existing switch states I'm using today with both switchmode 11 & 12. Toggle, hold & clear behaves, as far as I can tell, as usual and equally fast. Only 'issue' is that there's a suddenly double press feature as well 😁😉

Tested the double press feature to set office lights on at full brightness using following rules and let Xavi's ControllerX handle remaining part.

What a great addition, RemiDing ! 🎉 So usefull in many ways like in @mgiggs usecase and mine which is completely different. Great job I must say !! 👍😎

I'll keep this version and do some live 24/7 testing and see if any issues should pop up.

Below my current Tasmota settings for ControllerX control of lights:

Office - Tasmota settings
Moduletype: Shelly1 (46)
v8.3.1.7 (RemiDing dev. version)

rule1 on switch1#state=2 do backlog publish zigbee2mqtt/office_cmnd toggle;publish zigbee2mqtt/office_cmnd endon on switch1#state=8 do backlog publish zigbee2mqtt/office_cmnd double;publish zigbee2mqtt/office_cmnd endon on switch1#state=7 do backlog publish zigbee2mqtt/office_cmnd clear;rule3 1;publish zigbee2mqtt/office_cmnd endon

rule2 on mqtt#disconnected do backlog rule1 0 endon on mqtt#connected do backlog rule1 1 endon

rule3 on switch1#state=4 do backlog publish zigbee2mqtt/office_cmnd inc-dec;publish zigbee2mqtt/office_cmnd;rule3 0 endon

Powerretain1 1    Retain Tasmota power settings i HA in event of power outage
Setoption1 1      Allow only single, double and hold press button actions
Setoption32 8     Delay for HOLD button (in 0,1 sec.). I use 8 = 0,8 sec.
Setoption34 50    Minimize delay between backlog commands to 50 ms. (Default 200 ms.)
Switchtopic 0     Disable switchtopic. Needed when using rules in Tasmota.
Switchmode1 11    Set Tasmota to switchmode11

Thanks again and Ciao ! 🙋‍♂️