Controllerx: Support for 'virtual' Tasmota sw switch (Switchmode 11)

[htvekov]

Hi' Xavi.

I'm currently in the proces of 'Tasmotizing' all my in wall/ceiling outlets with Shelly's flashed with Tasmota.

With latest Tasmota release, Switchmode 11 has been introduced. This gives me the opportunity to refit all my wall switches with a spring, so they'll act like a one button switch.

Switchmode 11 gives the user ability to toggle and dim the lights with only one button 👍 Lights to be dimmed, of course needs to be smart bulbs 😉
Reference to pull request: https://github.com/arendst/Tasmota/pull/7603

I've already set up one switch and are using ControllerX for controlling toggle and dimming.
But with a hijacked 'pseudo' virtual Aqara switch, I can't eg. control 'HOLD FROM OFF' function. As there's only one button and nothing to be mapped :-) I would like to have SYNC function called instead of SMOOTH POWER ON on the wall switches. Also the implementation of the dimming in Tasmota sends continuous HOLD commands until RELEASE is send. This issue needs to be dealt with in some way as well (filtered out).

For now I've one MQTT sensor in HA that's get's all the switch commands from Tasmota and acts directly as 'virtual' controller in the ControllerX app 😎
All MQTT calls could be done directly from the Tasmota rules. But with my current setup I'm using HA automations as well to 'filter out' the continuous HOLD commands.

New Device Support

Tasmota sw switch with dimming capability

Device Information

Tasmota switch - Push button mode with Switchmode 11
Tasmota v8.2.0
MQTT commands from Tasmota to HA sensor are all easily handled in Tasmota RULES.
RULES can also automatically handle if MQTT server is unavailable and then switch light via relay instead.

Integration: [ HA State and/or MQTT]

Actions

Four states in total are send from Tasmota (read as direct MQTT commands or state from HA sensor)
States are not 'cleared' as with normal Zigbee switches after first MQTT call.
ControllerX don't seem to mind this. Except with the continuous HOLD calls)

Switchstate=2 = toggle (Normal TOGGLE function. One single pres)
Switchstate=4 = inc-dec (HOLD function. But HOLD is sent continuously until RELEASE is send !)
Switchstate=5 = inv (INVERSE dim direction fuction. Not needed in ControllerX, as
ControllerX handles this internally)
Switchstate=6 = clear (Normal RELEASE function. Send when button is released)

I can provide current set-up if needed and I'll make the documentation to explain how to implement 😉 This way people can make they 'dumb' switches smart and experience extremely easy setup via ControllerX 😎🚀🚀

[htvekov]

Have thought somewhat about this new-devise issue. Perhaps its not really in scope with ControllerX development strategy ? Mainly because there's actually no default proprietory integration behaviour to mimic/emultate.

Have read up somewhat on Tasmota rules and found that all described issues actually CAN be dealt with within the rules. So no need for your to waste your coding time on this, Xavi. I've managed to emulate an WXKG11LM Aquara switch (no double click though) 😃 Only a 'virtual' MQTT remote sensor in HA is needed now.

But I would still very much like to somehow be able to control what function to be called from HOLD FROM OFF 😉 For now I'm running with the SMOOTH POWER ON set (to stop brightness stepper) and have set an HA automation to emulate the SYNC function.

Ciao !

[xaviml]

Hi @htvekov,

First of all, thank you for opening this issue and second, sorry for not getting to it until now. I was thinking that I could add TasmotaSwitchMode11Controller that will be used with the state integration. I understand that the states it can take are: toggle, inc-dec, inv and clear. As you said inv can be ignored since toggle directions already handle this, so I can give support to the other ones.

Regarding HOLD FROM OFF, what you want is to be able to hold when smooth_power_on is activated and we hold the brightness up button? Since right now the smooth_power_on with a hold function, it will not keep holding, it will just turn on to minimum brightness.

Regards,
Xavi M.

[htvekov]

No worries, Xavi ! 😎

A dedicated Tasmota controller would be nice and somewhat less confusing for non experienced users ! State integration would be just fine. A HA sensor for ControllerX is needed anyway.

As I wrote earlier, the ControllerX Tasmota controller is not needed to have any special coding, as I've managed to filter out the repeated HOLD calls send from Tasmota. As well as the missing clear/blank payloads. So with my updated Tasmota rules, the sensor now acts just as a 'real' physical sensor 😃

I don't know if you're familiar with Tasmota rules, but here they are (quite straight forward):

on switch1#state=2 do backlog publish kontor_loftlys_cstm_mqtt/cmnd single;publish kontor_loftlys_cstm_mqtt/cmnd endon
on switch1#state=6 do backlog rule3 1;publish kontor_loftlys_cstm_mqtt/cmnd release;publish kontor_loftlys_cstm_mqtt/cmnd endon

RULE2
on Mqtt#Disconnected do backlog rule1 0 endon
on Mqtt#Connected do backlog rule1 1 endon

RULE3 5
on switch1#state=4 do backlog publish kontor_loftlys_cstm_mqtt/cmnd hold;publish kontor_loftlys_cstm_mqtt/cmnd;rule3 0 endon

RULE1 sends the MQTT commands for TOGGLE and CLEAR. CLEAR also activates RULE 3
RULE2 disable/enable RULE1 on MQTT disconnect/connect. Rule1 needs to be disabled for direct relay function to work as 'fail safe' mode if there's no MQTT server connected. Important WAF factor ! 😁😉
RULE3 (set as run ONCE rule) handles the HOLD MQTT call and disable itself after one call to prevent more that one HOLD to be send.

RULE1 & RULE3 immediately clears payloads (with blank payloads), as physical controllers also do.

In my rules I've different MQTT payload names to mimic Aquara sensor. Anything can be used. But I would go with Tasmota documentations own description names as you also wrote. I've left out inc_dec payload completely in my rules, as it's not needed and I can't think of a good use case for it. ControllerX already handles this direction shift internally.

That's it, I believe !

Finally to clarify what I would like with the HOLD FROM OFF feature.
AFAIK I can't in any way define what function to call with HOLD FROM OFF.
It would be really nice if all the other functions (if possible), like turn on full brightness, sync etc., could be called instead of (just) turning lights on at min. brightness.
I would specifically, in my use case, like to call SYNC function when button is held from lights off position. And do nothing else until RELEASE/CLEAR is send (just like SMOOTH POWER ON function does today)

It would ALSO be nice if 'personal' default SYNC color_temp/color could be set in app.
The 'standard' white is to 'cool' white for my liking 😁

Ciao, Xavi ! 🙋‍♂️

[xaviml]

Hi @htvekov,

Seeing it needs a very pre-configuration to get SwitchMode11 work with HA with sensors and there is no specific controller behind, I think I would leave this as something that can be done with CustomLightController. However, I would be glad to add an example as you did for SONOS in the example page.

Here is how you could configure it:

controller_switchmode11_on:
    module: controllerx
    class: CustomLightController
    controller: sensor.your_controller_sensor
    integration: state
    light: light.your_light
    mapping:
        toggle: toggle
        inc-dec: hold_brightness_toggle
        clear: release

This should work for the use case you specified.
Then regarding the HOLD FROM OFF, I would prefer to call it call different actions depending on the light state, which is what you might be looking for. This is probably what you want, I will explain below:

controller_switchmode11_on:
    module: controllerx
    class: CustomLightController
    controller: sensor.your_controller_sensor
    integration: state
    light: light.your_light
    constrain_input_boolean: light.your_light,on # This whole configuration will work when the light is on
    mapping:
        toggle: toggle
        inc-dec: hold_brightness_toggle
        clear: release

controller_switchmode11_off:
    module: controllerx
    class: CustomLightController
    controller: sensor.your_controller_sensor
    integration: state
    light: light.your_light
    constrain_input_boolean: light.your_light,off # This whole configuration will work when the light is off
    mapping:
        toggle: toggle
        inc-dec: sync

As you have seen, there is a new attribute constrain_input_boolean and created 2 configurations. This attribute is part of AppDaemon, it allows you to activate/deactivate a configuration depending on the condition specified. As you can imagine this opens a whole world of configuration, since you can define one configuration for when the light is on and another one for when the light is off. So what I did is to have the regular configuration when the light is on and I changed the configuration of inc-dec for when the light is off to call sync action. You can obviously pick any pre-defined action from CustomLightController (check here).

Let me know if this will work for you.

[htvekov]

Hi' Xavi.

Just a quick comment for now. I'll go in more details later (tomorrow I believe) 🙂

I actually searched and looked for mapping types in documentation, but didn't find it ?
Had NO idea that state integration was implemented for customlightcontrollers. It's hard to keep up with all the improvements you make 24/7, Xavi 😉😁🚀🚀🚀

Anyway, it works of course as expected 👍
But I' felt' there was an increased lag using state compared to mqtt.
So I went back to mqtt and checked. Probably lag actually was identical, but I just took notice now as setup was new.

I found that there's an (in my opion) complete obvious error in the Switchmode11 command implementation in Tasmota. As the RELEASE command is delayed with same amount of time (via Setoption32 command) as set to distinguish HOLD from TOGGLE. It doesn't make ANY sense to me ? Why in the world would anyone want to wait (1 second in my use case) for a RELEASE command to be send after button has been released ? When button is releleased I want command to be send immediately.

Anyway, I sorted this via rules in Tasmota. I now toggle between two different delays, depending on what command (HOLD or RELEASE) has been 'fired' latest). This works perfectly and has reduced lag, so user experience is the same now as with a physical button.

Also found that Tasmota has a 200ms default delay inbetween backlog commands.
200ms - that's an eternity... ???
I've reduced to 50ms and haven't experienced any problems with backlog command que.

So I'll revert to test state integration via customlightcontroller again tomorrow.
Everything works - but I'll check for any lag issues using state compared to mqtt.
I don't expect to actually be able to tell the difference 😁

Night, Xavi 🙋‍♂️😌😴😴

[xaviml]

Hi Henning :)

I think we are not in the same page. ControllerX has (as of now) 4 type of integrations: z2m, deconz, zha and state. The latter is an integration that reads the state of the entity you pass on the "controller" attribute. So your workflow is to get the data from MQTT to a sensor and use the state integration to read the state changes of that sensor entity. I hope this clarifies things for you.

In a future, I might add a MQTT integration to directly read data from MQTT and there will be no need of creating an mqtt sensor.

What do you mean by "mapping types" when you said: "I actually searched and looked for mapping types in documentation, but didn't find it ?" Maybe I am missing some documentation.

I will try to create a diagram showing how different components of ControllerX are connected, so you will have a more general idea of how it works. Integrations (like state) are responsible of reading from "controller" attribute, so they can be used with any type of controller (CustomLightController, any LightController, any MediaPlayerController, etc). All controller configurations must implement the integration to know how to read the state changes of the controllers.

Let me know if this clarifies things to you and if the previous configuration work out well for you :)

[htvekov]

Hi' Xavi

We're on the same page - don't worry ! 😉
No need to explain further. I'm completely up to speed now 🚀🚀

Have only used z2m integration so far and could not really see in custom component documentation, that state could be used and that mapping key was the HA sensor state. And there was no custom component state example, that perhaps could have 'jump started' my brain ⚡😝

Obvious and easy when you know it. But last night my brain was not fully in gear 🤪 And I simply didn't think of the obvious, straightforward solution, that state integration mapping of course was done like that 🙂

I've reverted back to full ControllerX setup with no automations.
Can't see any notisable difference in performance from mqtt to state. Perhaps if measured, there's a few milliseconds quicker performance, if the wait for state change was cut out.

I'm using this setup on two wall switches now. And performance is now quite finetuned and close to perfect 😎

I'll make a complete setup example for the ControllerX documentation ASAP.
It's not really that complicated. And if users are just a little familiar with the Tasmota menu and console, it will take less than 5 min. to punch in the three rules, a few extra commands and make the HA mqtt sensor in config.

Would still like to be able to 'personalize' the default color/color_temp used for sync, though ! 😝😉

Ciao !

[xaviml]

Hi @htvekov,

I would love to add this to the documentation. It will help people that want to reproduce what you did.

Would still like to be able to 'personalize' the default color/color_temp used for sync, though ! stuck_out_tongue_closed_eyeswink

Sorry, I did not come back to you on this. Instead of adding a new parameter for this, I will see if I can see a way of adding parameters to pre-defined actions, this will allow you to do this and many more things. I will create an issue explaining this further.

[xaviml]

I created #78 to address the sync functionality. Let me know if this will work for you. This might require some work, but with this, we will be able to add more configuration to pre-defined actions.

This issue will remain open to adding the documentation to the example pages. Otherwise, we can close this issue.

Again, thank you for everything @htvekov :)

[htvekov]

Hi' Xavi

I believe issue#78 describes a neat solution to my specific problem and most likely also future requests from other user that have specific wishes to 'tweak' ControllerX default settings.

Here we go with the Tasmota Switchmode11 wall switch documentation 😁
Please reformat the Tasmota commands and rules section in documentation below, Xavi. I can't really use tab and format correctly here...

I believe I've remembered all the essential settings needed for this project.

Ciao ! 🙋‍♂️

TASMOTA SWITCHMODE 11 WALL SWITCH IMPLEMENTATION TO HOME ASSISTANT / CONTROLLERX

Want to make your 'dumb' wall switches smart and at the same time improve smart lighting WAF ? Then the solution could be to 'Tasmotize' your wall switches, and use Home Asssistant with ControllerX app to control the smart light connected to that switch. With this setup, you'll be able to toggle and dim your lights directly from your wall switch. Today, many switches are so small, that they can fit behind wall outlets/switches or in ceiling outlets. Personally I've used Shelly One devices (https://shop.shelly.cloud/shelly-1-wifi-smart-home-automation#50) and Itead Sonoff Mini's (https://www.itead.cc/sonoff-mini.html). Both are easy to flash with Tasmota using either USB-to-UART adapter or directly OTA. No soldering is actually needed these days. The flash part and build instructions are to comprehensive to elaborate on further in this documentation. Instructions are 'out there' - Google it ! 😊

One final warning: Using Shelly/Sonoff devices behind wall switches/outlets involves fiddling with HIGH VOLTAGE that could potentially INJURE OR KILL YOU, if not handled/installed correctly !! Furthermore, local building code might prohibit use of such devices in wall outlets and unauthorized installation will most likely be illegal in most countries.
If you don't know EXACTLY what you're doing - then DON'T proceed with this project !!
Now you've been warned !!

Following example is with a Shelly One device, placed in the wall socket behind the switch, to control an Ikea WS bulb in the ceiling outlet. The bulb is connected to Home Assistant via Zigbee2mqtt. I've refitted my wall switch with a spring, so it'll act like a push button.

The Switchmode11 option in Tasmota gives the user four different switch commands to be used for automation. With ControllerX only three commands are needed, as ControllerX internally controls changes in dimming direction. These commands are via MQTT send to a HA sensor, which is directly used in ControllerX as a 'virtual' switch.

Switchmode11 Tasmota output commands are:

Switchstate=2 = toggle (Normal TOGGLE function. One single pres)
Switchstate=4 = inc-dec (HOLD function. Send after delay defined with Setoption32)
Switchstate=5 = inv (INVERSE dim direction function. Not needed in ControllerX, as
ControllerX handles this internally)
Switchstate=6 = clear (Normal RELEASE function. Send when button is released after delay defined with Setoption32. This delay is here 'bypassed' and set to lowest possible 0,1 sec. delay )

Setup MQTT sensor in HA's configuration.yaml:

sensor:
  - platform: mqtt
      name: "tasmota"
      state_topic: "tasmota_topic"

Setup ControllerX app:

This setup is with two separate controllers. This will also handle HOLD FROM LIGHTS OFF situation. Which, when lights are off, will SYNC light/lights when button is held for 1 sec.

ControllerX apps.yaml example no. 1:

controller_switchmode11_on:
    module: controllerx
    class: CustomLightController
    controller: sensor.tasmota
    integration: state
    light: light.0xec1bbdfffed45c3b_light # define your own light entity
    constrain_input_boolean: light.0xec1bbdfffed45c3b_light,on # This whole configuration will work when the light is on
    mapping:
        toggle: toggle
        inc-dec: hold_brightness_toggle
        clear: release

controller_switchmode11_off:
    module: controllerx
    class: CustomLightController
    controller: sensor.tasmota
    integration: state
    light: light.0xec1bbdfffed45c3b_light # define your own light entity
    constrain_input_boolean: light.0xec1bbdfffed45c3b_light,off # This whole configuration will work when the light is off
    mapping:
        toggle: toggle
        inc-dec: sync

This is a more simple setup, where SMOOTH POWER ON is enabled instead, when button is held from lights off position.

ControllerX apps.yaml example no. 2:

tasmota_switchmode11:
  module: controllerx
  class: CustomLightController
  controller: sensor.tasmota
  integration: state
  smooth_power_on: true # enable 'smooth power on' feature when button is held from lights off
  delay: 250 # change delay if you want faster/slower dimming response (default: 350 ms.)
  light: light.0xec1bbdfffed45c3b_light # define your own light entity
  mapping:
        toggle: toggle
        inc-dec: hold_brightness_toggle
        clear: release

Setup needed commands and rules in Tasmota software via console:

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 10      Delay for HOLD button (in 0,1 sec.). I use 10 = 1 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

RULE1                             on switch1#state=2 do backlog publish tasmota_topic toggle;publish tasmota_topic endon
                                   on switch1#state=6 do backlog publish tasmota_topic clear;setoption32 10;rule3 1;publish tasmota_topic endon    

RULE2
            on Mqtt#Disconnected do backlog rule1 0 endon
            on Mqtt#Connected do backlog rule1 1 endon

RULE3 5
            on switch1#state=4 do backlog publish tasmota_topic inc-dec;setoption32 1;publish tasmota_topic;rule3 0 endon      

NB: Note the extra decimal '5' in RULE3 !!

RULE1 sends the TOGGLE command and afterwards immediately clears the sensor state with an empty payload (just like a physical button does). It also handles the CLEAR command when button is released, resets HOLD delay to 1 sec., enable RULE3 and finally clears payload

RULE2 handles the 'fall back' to direct switch control if MQTT server is unavailable. Nice WAF feature, if HA/MQTT server is down 😉 Then lights can still be toggled on/off using the wall switch.

RULE3 sends the HOLD command, set wait delay to lowest possible minimum 0,1 sec. (for next release button event), disables itselves (to ensure only one HOLD command is send) and finally clears payload.
RULE3 is set as 'run once' in Tasmota (with the decimal 5 after the rule number) to prevent some extra HOLD commands gets send before rule is disabled.

That's it ! 😎🚀

[htvekov]

Revised a bit and added an extra ControllerX app example.

I think documentation is done for now 😎 🙋‍♂️

[htvekov]

God damn it !!
Forgot the most important Tasmota setting - set Switchmode 11 🤪😁
Added now...

[xaviml]

This is great @htvekov! Thank you very much for this :) I have added it into the example page as we did with the SONOS example. It will be visible when I shipped the next release since the example is still in the dev branch.

[htvekov]

You're welcome, Xavi 😊

Hopefully someone 'out there' will find it helpful.
It's really easy to implement, now I've done the 'testing and fine tuning part'
I've thought of doing this for many months, but didn't start up the project before now, as I KNEW that the automation part would be painful. With ControllerX and Switchmode11 it's an absolute joy ! 😉😎

By the way (almost forgot). I've noticed one minor thing, that I believe could be ControllerX code related.
Do ControllerX set dimming direction to 'down', when lights are at 100% brightness. Regardless of how lights got at 100% in the first place (just turned on and at random at 100% brightness) ? Or does the 'brighten' to 100% has to be done IN ControllerX, to ensure dimming direction to be down ?

I ask, as I sometimes (50/50%) experience that my Tasmota switch won't dim down with the first hold action. When I look at the commands in HA and the MQTT messages, all seems correct and fine. But light don't dim down. If I release and hold again, light start to dim from 100% brightness.

Ciao ! 🙋‍♂️

[htvekov]

Or more correctly brightness at 100% should be at MAX_BRIGHTNESS.

Same question actually also applies for brightness at MIN_BRIGHTNESS for lights just turned on/toggled on.

[xaviml]

Hi! :)

The combination of Switchmode 11 and ControllerX is a great example for a use case of ControllerX. I hope someone will find it useful too.

Regarding the second issue you are commenting, you are totally right, I took the assumption of changing the directions only if full or min brightness are called. However, what I should do is check the value and compute the direction from it. If it is MIN, then UP. If it is MAX, then down. If it is between MIN and MAX, then the opposite direction that it ran before. I will create an issue for this tomorrow. This will not only work when the brightness (or color temp) is changed from ControllerX, but as well externally.

[htvekov]

I'm SO pleased, Xavi ! 😁🚀🚀🚀

[htvekov]

Hi' Xavi.

Just FYI

Some improvement on the Tasmota 'hold release' delay is in the pipeline.
I'll update the documentation when the Tasmota PR hits the released dev versions.

https://github.com/arendst/Tasmota/issues/8386

Hopefully this will also draw some attention and new users to ControllerX 😁

Ciao !

[xaviml]

Cool! Thanks @htvekov. You can either post in here the changes or you an create a PR modifying this file: https://github.com/xaviml/controllerx/blob/dev/docs/examples/tasmota-switchmode11.md

GitHub allows you to do that from the same website, so no need to use git to download my code or anything.

[htvekov]

Hi' Xavi.

I'll try with the PR, when the new immediate 'clear' command is included in Tasmota.
Have to learn how to do a PR at some point, so I might as well start now 😉

Tasmota 8.3.0 has just been released. So it will probably be some weeks before PR is made and merged.
I'll keep you updated, Xavi 😊

Ciao !

[htvekov]

Hi' Xavi

Just FYI

https://github.com/arendst/Tasmota/pull/8450
PR for the Tasmota sw change has been merged and are in latest dev version now.
All smooth sailing 😎

I'll update the documentation (I'll try to work my way through a PR 😉), when the change hits the next Tasmota release version.

Ciao !