Tasmota: TOGGLE dimmer to 100% optionally; retain dimmer value for dashboard.

[yoh-there]

I would kindly suggest a mode or option where, when a channel is in dimmer mode (pwm pin and Setoption15 ON), POWER ON/OFF/TOGGLE commands behaves as if DIMMER 0 / DIMMER 100 (and a corresponding toggle between the two) were issued, in effect overriding the saved dim value.

Use case: simple pushbutton remote should preferably toggle the dimmable lamp. Dimming could be established with a more complex remote or dashboard.

Alternatives:
1) program it in my Node-RED backend, but that would basically move the state to Node-RED, where I really like the state maintained in tasmota.
2) Add DIMMER ON/OFF/TOGGLE commands, again with an option to force (toggle) ON to 100. Additional advantage is that using DIMMER there will always be a stat/../RESULT message.
3) Add POWER [PWM%] command, again with an option to force (toggle) ON to 100%. Additional advantage is that using POWER there will always be a stat/.../POWER message which can actually be retained.

Only 3) solves the small problem, which is the dimmer value is not MQTT retained, messing up mobile phone based dashboards. Rereading I would suggest alternative 3 is the best and fixes both the toggle as well as the retain problem.

Edit: the more I think about it alternative 3 is preferred I think, as with in combination with the requested "toggle to full power" option, the behavior would work on button presses too, as I believe they "emulate" a POWER TOGGLE command.

Thank you for considering. Great job @arendst

[ascillato]

Hi. Have you tried to send command: scheme 0 or scheme 1, instead of power on?

[ascillato]

May be that meet your expectations

[yoh-there]

Thank you for putting effort in this.

I thought SCHEME was specifically for LED strips? My use case is a PMW COB LED. And reading the documentation I think it only fixes single color, not full on/toggle and not the retain. Correct me please if I misread of course.

[ascillato]

simple pushbutton remote should preferably toggle the dimmable lamp

Your remote pushbutton can send by MQTT the commands:

cmnd/sonoff/XXXX

where XXXX can be:

scheme 0 is like a power on with dimmer 100
scheme 1 is like a power on with dimmer 100 but with a fade effect.
color 255,255,255 is like a power on with dimmer 100 with the color you want.

and for power off use power off

[yoh-there]

I appreciate the effort to help :-)

But no for several reasons:
1) scheme only works with LED strips, not with a PMW out pin
2) Still no retention of dimmer setting for mobile dashboard
3) Still no toggle to full for a one-button remote

I hope Theo will consider alternative 3 :-) //Jeroen

[ascillato]

Hi,

I think I understand what you want to do, but I'm trying to understand your setup, because there are several options to work on for what you want to do.

Your desired behaviour is by a remote button to dimmer 0 and dimmer 100 a sonoff, and by a dashboard to dimmer from 0 to 100, right?

When you say a remote button, are you saying another sonoff device? Because if that the case, in that other device you can send the command cmnd/sonoff/dimmer 100 and dimmer 0 to power on and off the first sonoff.

If by remote button you meant a physical switch attached by wires to only one sonoff, you can use rules to override dimmer command. Also with rules you can store the actual dimmer value for your dashboard.

Your dashboard is sending mqtt commands to tasmota? if that is the case using event and rulesyou can set your desired behaviour.

Please, could you clarify your setup?

[yoh-there]

I think you understand wel. Use case is:

• lamp is NOT a LED strip, but PMW controlled (PWM generated by Tasmota)
• Tasmota has a button (toggle*) on the lamp fixture itself)
• Through rfbridge I want to toggle*) it using one button
• on the phone I have a neat MQTT dash dashboard. It shows the feedback and sends commands.

*) Toggle and ON, I would optionally like to toggle/ON to full on instead of last store dimmed value, I think a setting would be appropriate

The dash can send dimmer commands

The dash would preferably show (so retained message) the actual dimmer value. Of course following if ie the remote changes it's status.

[ascillato]

Ok, so

your setup is a wifi lamp like Sonoff B1?

and you want to dimmer 0 and dimmer 100 using a RF Button that communicate to a sonoff-bridge?

and also a MQTT Dashboard on a phone.

It is that your setup?

[ascillato]

If it is that your setup, you only need to set rules on the Sonoff-Bridge to publish to mqtt the commands cmnd/sonoff/dimmer 0 and cmnd/sonoff/dimmer 100 when a predefined RFKey arrives.

All that information is on the wiki

[yoh-there]

You are right about the setup. The light is a Power LED on a MOSFET on a PWM configured pin of the tasmota device.

But your solution is not correct IMHO.
First of all the the bridge cannot toggle between two commands as far as I know.
Second, the RESULT message from Tasmota (to the dashboard) is not retained, making the dash unreliable at startup.
Last (but this is minor) there would be randomness between with pushes as in your solution only the RF bridge knows he state (if it COULD toggle).

[ascillato]

the the bridge cannot toggle between two commands as far as I know.

Using rules you can. Besides, there is no need for that. On the RFBridge just call to a rule event to your lamp. Your lamp can toggle when receives the event trigger.

RESULT message from Tasmota (to the dashboard) is not retained, making the dash unreliable at startup.

When Tasmota Starts, It suscribe to several MQTT Topics, so, it will inform its status there. On your MQTT Server.

there would be randomness between with pushes as in your solution only the RF bridge knows he state (if it COULD toggle).

The actual states it can be configured to be managed only by your lamp.
with rules you can do a lo of things. everything is on the wiki

[yoh-there]

Thank you for your help. With utmost respect, I will keep the request open as I think the solution you propose is too tricky, requires too much tinkering on both the bridge and the lamp, and does not solve the retain issue. Thanks again.

[ascillato]

Ok, no problem. I leave here one possible solution as example for anyone interested. You can try it also.

• For the sonoff bridge

on the console:

turn on rules: rule 1

rule:
rule on RfReceived#RfKey=1 do publish cmnd/sonofflamp/event mytoggle endon

• For the wifi lamp

on the console:

turn on rules: rule 1

rule:
rule on event#mytoggle do event toggling1=%var1% endon on event#toggling1<1 do backlog var1 1; dimmer 100 endon on event#toggling1>0 do backlog var1 0; dimmer 0 endon

The status of the lamp will be all the time in the lamp. The status of the MQTT Dashboard will depends in which topics it is subscribed.

[yoh-there]

That is actually a neat idea, defining ones own command. Thank you!

The random action of the toggle is still an issue (I don't think the rules can use the current dimmer value), but it is minor.

The only problem I see is that the only feedback is in the RESULT message, which cannot be set to retained. But that could in theory be solved by re-emmiting a retained message by Node-RED.

And this is my issue a bit: tinkering in multiple devices for an _almost_ ideal solution. BUT....... this could cover 90% of the way if Theo doesn't like my idea ;-)

[ascillato]

I don't think the rules can use the current dimmer value

Please see rules on the wiki. There are examples for that

The only problem I see is that the only feedback is in the RESULT message

Rules allows you to publish by MQTT whatever you want. Take that into account. So you CAN tell at any time to your mqtt dashboard all the data you want. You can subscribe your mqtt dashboard to stat/sonofflamp/powerstatus for example, and with rules you can publish to that powerstatus

Hope this clarify a little that a complex inter-device arrangement can be solved by rules. Also now there is a new command to direct communication between devices WebSendand also the KNX protocol. And of course, also the use of a dedicated home automation software like HomeAssitant, OpenHab, Domoticz, etc.

[yoh-there]

But publish has no retain flag. Yes, I know we're getting into nitpicking territory. I can solve that on Node-RED (which I prefer over above products, but that's me :-) )

Nifty solution, thank you again, and for your determination :-)

[ascillato]

To simplify:

We can MADE by rules this command that you want

You want a command that dimmer to 100% and also that publish a POWER by MQTT

so, if you type at the console:

dimmer 100
power1 on

your will have your desired ON status right? because it will publish at

18:20:21 MQT: stat/sonoff/RESULT = {"POWER1":"OFF"}
18:20:21 MQT: stat/sonoff/POWER1 = OFF

and if you type:

power1 off

your will have your desired OFF status right? because it will publish at

18:20:21 MQT: stat/sonoff/RESULT = {"POWER1":"OFF"}
18:20:21 MQT: stat/sonoff/POWER1 = OFF

It this correct?

[ascillato]

so if that is the case, you should change the first example to:

rule on event#mytoggle do event toggling1=%var1% endon on event#toggling1<1 do backlog var1 1; dimmer 100; power1 on endon on event#toggling1>0 do backlog var1 0; power1 off endon

[yoh-there]

I'd still not have the retained dimmer value, but if i would implement an alternative dimmer command through a rule, I could save it in a var. However, the MQTT flag is still a (solvable) issue. I opened another request to be able to publish with a retain flag. #2861

[yoh-there]

For those having the same issue: I eventually decided to implement everything in the automation hub (Node-RED). I did try extensively using rules, but for a reason unknown to me, any var x (where x is a value, i.e. 1) command resulted in a "Unknown command". So (sorry ascillato), while I am sure it's me, I gave up on rules for now. Tried 5.13 and 5.14 both pre-compiled releases BTW.

The solution was remarkably simple.

1. Subscribe to stat/+/RESULT and parse the JSON
2. If the JSON contains a dimmer value, re-emit a retained message fdbk/.../DIMMER with the dimmer value. This is used for the dashboard. Then abort.
3. Else (there is no dimmer value), if the JSON does not contain a POWER value, abort
4. Else (so there IS a POWER, but no DIMMER value and note that this will happen as a result from any POWER command.) .....
   3a. If the POWER is "ON", emit unretained cmd/.../DIMMER 100 and abort. This will ensure the dimmer goes to 100. Also, a new RESULT will be sent by tasmota, so 2. will be trigered again for feedback purposes
   3b. Else (so if the POWER is OFF), just emit a retained fdbk/./DIMMER 0. As the light is already off, no need to send anything to Tasmota.

The only downside is that:

• fdbk messages will be created for all devices (not just dimmer enabled ones);
• non-dimmer enabled devices will receive DIMMER 100 commands, which they will ignore.
  I can live with that.

Thanks again for all your help.

I think my original request is valid, but I understand if it is dismissed.

[ascillato]

Hi,

Happy to know that it is now working for you. :+1:

Thanks a lot for sharing your solution. It is very appreciated.

any var x (where x is a value, i.e. 1) command resulted in a "Unknown command"

Yes, you are right. Won't work in v5.13.0 nor v5.14.0. The commands VAR and MEM were added in the v5.14.0a. If you want, you can try v5.14.0b compiled firmwares at https://github.com/ascillato/Sonoff-Tasmota_KNX/releases. Those are the same Tasmota v5.14.0b but with KNX enabled. I made those for testing KNX features. Also there are the ones from Reloxx at https://github.com/reloxx13/Sonoff-Tasmota-Modified/releases/latest

I think my original request is valid

Me too, That's why I'm helping you.

[yoh-there]

Ah got it. I assumed (!) as it was documented it was in the latest release. D'uh. Anyway, I will try again in a few releases. :-)

For now, here a snippet of my for-the-time-being Node-RED solution. https://gitlab.com/snippets/1720998

I have enhanced it to avoid said two disadvantages. The only price to pay for that is that the MQTT topic needs to start with "dimm". FOr me that was a no brainer, as my topics alsways start with 4 letters "what is it", i.e. "lamp", "vent", etc.