Add rule trigger of Color#State

[gooman-uk]

Have you look for this feature in other issues and in the wiki?
Yes
Is your feature request related to a problem? Please describe.
No

Describe the solution you'd like
Rule Triggers include Power and Dimmer, but for multi-color devices it is missing the inclusion of Color as a trigger. There seems to be no way to trigger a rule on Color change.

Describe alternatives you've considered
None

Additional context
None

(Please, remember to close the issue when the problem has been addressed)

[gemu2015]

have a look at this thread =>#5689

its easy with a script

[Jason2866]

Please close this issue Script support is now in Tasmota #5816.
With script you can do.

[ascillato2]

Closing this issue as there is now a workaround using scripting. Please, check the documentation for an example for doing this. Thanks.

[DavinKD]

Any chance we can reopen this request? While it can be done with scripts, I would think Rule1 on color#state do.... would be much easier for most.

[qualar]

I agree it would be very useful to have in rules.

[GaryMilne]

I too would have found this very useful.

[ascillato]

I too would have found this very useful.

Hi, this is a very old issue. This has been implemented as Color#Data for triggering a rule, and as %color% as a variable for rules.

Please, take a look at #14556

Thanks.

[GaryMilne]

Hey Adrian, thanks for responding, I really wasn't expecting it but I'm glad you did. I initially assumed that it wasn't working for me because I was on an older version of Tasmota (8.1). I upgraded to version 11 but get the same result. See my log traces. First one works for the dimmer. Second, almost identical, doesn't work for Color //Clear out the old rules 14:49:35.807 CMD: rule1 "" 14:49:35.813 RSL: RESULT = {"Rule1":{"State":"ON","Once":"OFF","StopOnError":"OFF","Length":0,"Free":511,"Rules":""}} 14:49:40.578 CMD: rule2 "" 14:49:40.585 RSL: RESULT = {"Rule2":{"State":"ON","Once":"OFF","StopOnError":"OFF","Length":0,"Free":511,"Rules":""}} 14:49:43.817 CMD: rule3 14:49:43.823 RSL: RESULT = {"Rule3":{"State":"ON","Once":"OFF","StopOnError":"OFF","Length":0,"Free":511,"Rules":""}} 14:49:47.493 CMD: rule4 14:49:47.499 RSL: RESULT = {"Command":"Error"} //Add a Rule2 to do a websend when the dimmer changes 14:50:01.573 CMD: Rule2 ON Dimmer#state do WebSend [192.168.0.200]/apps/api/1902/devices/1899/off?access_token=9ab8ebf8-be31-45b5-af55-0cfa43f099cb ENDON 14:50:01.581 RUL: Stored uncompressed, would compress from 129 to 107 (-17%) 14:50:01.585 RSL: RESULT = {"Rule2":{"State":"ON","Once":"OFF","StopOnError":"OFF","Length":129,"Free":382,"Rules":"ON Dimmer#state do WebSend [192.168.0.200]/apps/api/1902/devices/1899/off?access_token=9ab8ebf8-be31-45b5-af55-0cfa43f099cb ENDON"}} 14:50:26.539 CMD: dimmer 43 14:50:26.547 RSL: RESULT = {"POWER":"ON","Dimmer":43,"Color":"6E6E6E0000","HSBColor":"253,0,43","White":0,"CT":153,"Channel":[43,43,43,0,0]} 14:50:26.631 RUL: *DIMMER#STATE performs "WebSend [192.168.0.200]/apps/api/1902/devices/1899/off?access_token=9ab8ebf8-be31-45b5-af55-0cfa43f099cb"* 14:50:27.056 RSL: RESULT = {"WebSend":"Done"} //Works as expected. //Replace the old rule2 with the exact same content by switching the word "Color" for the word "Dimmer" 14:53:38.320 CMD: Rule2 ON Color#state do WebSend [192.168.0.200]/apps/api/1902/devices/1899/off?access_token=9ab8ebf8-be31-45b5-af55-0cfa43f099cb ENDON 14:53:38.328 RUL: Stored uncompressed, would compress from 128 to 106 (-17%) 14:53:38.332 RSL: RESULT = {"Rule2":{"State":"ON","Once":"OFF","StopOnError":"OFF","Length":128,"Free":383,"Rules":"ON Color#state do WebSend [192.168.0.200]/apps/api/1902/devices/1899/off?access_token=9ab8ebf8-be31-45b5-af55-0cfa43f099cb ENDON"}} //Change color via the console 14:53:51.694 CMD: color 222222 14:53:51.702 RSL: RESULT = {"POWER":"ON","Dimmer":13,"Color":"2222220000","HSBColor":"0,0,13","White":0,"CT":153,"Channel":[13,13,13,0,0]} //Color changes but rule does not run, presumably because the trigger event failed. I also tried CT which I'm also interested in but that does not appear to work either. Do I need a custom compilation for this to work? Thanks for any insight you can offer.

…

On Fri, Apr 8, 2022 at 10:08 PM Adrian Scillato ***@***.***> wrote: I too would have found this very useful. Hi, this is a very old issue. This has been implemented as Color#Data for triggering a rule, and as %color% as a variable for rules. Please, take a look at #14556 <#14556> Thanks. — Reply to this email directly, view it on GitHub <#5614 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD4ZMVLY2BSUTHKC45JSNCTVEDYDDANCNFSM4HE6YUCA> . You are receiving this because you commented.Message ID: ***@***.***>

-- Gary Milne E-Mail: ***@***.***

[ascillato]

Please, re read my comment. Color#state is not a valid trigger. That won't work. The trigger that is executed when you change the color is color#data. Besides, you have a variable for the color that is %color%. Please, also take a look to the linked discussion that have examples of how to use it.

[GaryMilne]

Thanks for your help Adrian, I was able to achieve what I had set out to do. I was going to submit an enhancement request on this following issue but I could not see a way to do that, only problem tickets. With respect to lighting there are four main properties: power, color, dimmer and CT. The first three all support #State but CT does not. Instead I have to do this. ON CT DO Mem15 %value% ENDON and then use Mem15 for the trigger. This seems like an inconsistency that is detrimental to the overall usability. Gary.

…

On Sat, Apr 9, 2022 at 5:54 PM Adrian Scillato ***@***.***> wrote: Please, re read my comment. Color#state is not a valid trigger. It is color#data. Please, also take a look to the linked discussion that have examples of how to use it. — Reply to this email directly, view it on GitHub <#5614 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD4ZMVLQACUP4M37BVWREU3VEIDCJANCNFSM4HE6YUCA> . You are receiving this because you commented.Message ID: ***@***.***>

-- Gary Milne E-Mail: ***@***.***

[sfromis]

You do not need to go via Mem15, you could just do whatever directly, including having %value%, instead of using Mem15. And if you had to do it indirectly, better use a Var instead of a Mem, as the latter causes flash writes, subtracting from the finite lifetime.

[GaryMilne]

sfromis, thanks for responding. This is one variant of my rule. Basically if it sees changes in any of the tracked items it sends the new status to Hubitat. ON Power1#state=0 DO backlog0 Mem10 OFF ; RuleTimer1 2 ENDON ON Power1#state=1 DO backlog0 Mem10 ON ; RuleTimer1 2 ENDON ON Color#State$!%Mem11% DO backlog0 Mem11 %value% ; RuleTimer1 2 ENDON ON Dimmer#State$!%Mem12% DO backlog0 Mem12 %value% ; RuleTimer1 2 ENDON ON CT DO backlog0 ; Mem13 %value% ; Mem11 %Color% ; RuleTimer1 2 ENDON ON Mem13$!%Mem14 DO backlog Mem14 %Mem13% ; RuleTimer1 2 ENDON ON Fade#data DO backlog Mem8 %value% ; RuleTimer1 2 ENDON ON Speed#data DO backlog0 Mem9 %value% ; RuleTimer1 2 ENDON ON Rules#Timer=1 DO Mem15 %Mem10%,%Mem11%,%Mem12%,%Mem13%,%Mem8%,%Mem9% ENDON ON Mem15#State$!%Mem16% DO backlog ; Mem16 %Mem15% ; webquery http://192.168.0.200:39501 POST {'TasmotaSync':'True','Power':'%Mem10%','Color':'%Mem11%','Dimmer':'%Mem12%','CT':'%Mem13%','Fade':'%Mem8%','Speed':'%Mem9%'} ENDON I did not understand your answer "You do not need to go via Mem15, you could just do whatever directly, including having %value%. Are you saying that instead of #1 that something like #2 is possible? #1 {'TasmotaSync':'True','Power':'%Mem10%','Color':'%Mem11%','Dimmer':'%Mem12%','CT':'%Mem13%','Fade':'%Mem8%','Speed':'%Mem9%'} #2 {'TasmotaSync':'True','Power':'%power%','Color':'%color%','Dimmer':'%dimmer%','CT':'%ct%','Fade':'%fade%','Speed':'%speed%'} Your comment on using Var instead of Mem was appreciated, I had not considered that and it would be good to cut down on the Mem usage if at all possible. If I understand the Var lifetime correctly I don't think it would work in this case as it is currently structured. Thanks.

…

On Mon, Apr 18, 2022 at 6:36 PM sfromis ***@***.***> wrote: You do not need to go via Mem15, you could just do whatever directly, including having %value%, instead of using Mem15. And if you had to do it indirectly, better use a Var instead of a Mem, as the latter causes flash writes, subtracting from the finite lifetime. — Reply to this email directly, view it on GitHub <#5614 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD4ZMVNNVU2OAC7FMNCQP7TVFXWXZANCNFSM4HE6YUCA> . You are receiving this because you commented.Message ID: ***@***.***>

-- Gary Milne E-Mail: ***@***.***

[sfromis]

To me, your rules looks like you only need a very short lifetime, not what Mem gives you which is lifetime across boots. Other than that, you get the same with Var, just without wearing down flash.

What I meant with using trigger %value% directly, based on your previous comment, is that simple usage of triggers can be done without staging the value in a Var/Mem, but that does indeed not cover the use case of it being part of a further trigger expression. This has nothing to do with your #2.

However, since recently, %color% is now available as a rule variable, but that's not some sort of general replacement for using triggers to pick up values.

[GaryMilne]

Yes, you are correct in your assessment of the variable usage. I tried to submit a feature request to support this capability but it was rejected saying that template was missing. This was what I submitted below. Do you know if there is a separate mechanism for feature requests vs an issue? Hi, Tasmota currently allows storage in either var or mem types. My request is to have some form of variable that persists across rules but does not require writing to NVRAM. What is a use case? Consider these two rules. Version #1 <#1> *ON Tele-Energy#Current DO var13 %value% ENDONON Tele-Energy#Power DO var14 %value% ENDON "ON Tele-Energy#Voltage DO backlog ; webquery http://192.168.0.200:39501 <http://192.168.0.200:39501/> POST {'TSync':'True','Current':'%var13%','Watts':'%var14%','Voltage':'%value%'} ENDON* Basically sends some JSON to the host at whatever the TELEPERIOD is, whether the data has changed or not i.e. all zero's. Not ideal from a POV of network usage and host activity and logging. Version #2 <#2> *ON Tele-Energy#Current DO backlog0 Mem11 %value% ; RuleTimer1 1 ENDONON Tele-Energy#Voltage DO backlog0 Mem12 %value% ; RuleTimer1 1 ENDONON Tele-Energy#Power DO backlog0 Mem13 %value% ; RuleTimer1 1 ENDONON Rules#Timer=1 DO Mem15 %Mem10%,%Mem11%,%Mem12%,%Mem13% ENDONON Mem15#State$!%Mem16% DO backlog ; Mem16 %Mem15% ; webquery http://192.168.0.200:39501 <http://192.168.0.200:39501/> POST {'TasmotaSync':'True','%Mem10%','Current':'%Mem11%','Voltage':'%Mem12%','Watts':'%Mem13%'} ENDON* In this case the net result is that Tasmota only sends changes to the host whenever one of the three values has changed since the last period. Slightly more processing but greatly advantageous in terms of reducing network traffic and events at the host because only changes are sent. However, the considerable downside is that with a TelePeriod of 60 seconds you would have 60 (events) x 24 (hours) x 5 (mem variables) = 7,200 mem writes per day. That would start killing off memory cells within a few days and obviously a non-starter. The availability of a couple of semi-persistent in memory registers %pvar% would greatly enhance what is capable of achieving with rules within the stock compilation. Thanks for listening.

…

On Fri, Apr 29, 2022 at 3:06 AM sfromis ***@***.***> wrote: To me, your rules looks like you only need a very short lifetime, not what Mem gives you which is lifetime across boots. Other than that, you get the same with Var, just without wearing down flash. What I meant with using trigger %value% directly, based on your previous comment, is that simple usage of triggers can be done without staging the value in a Var/Mem, but that does indeed not cover the use case of it being part of a further trigger expression. This has nothing to do with your #2. However, since recently, %color% is now available as a rule variable <https://tasmota.github.io/docs/Rules/#rule-variables>, but that's not some sort of general replacement for using triggers to pick up values. — Reply to this email directly, view it on GitHub <#5614 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD4ZMVIIDEIML2UKSS2I64TVHOJ7HANCNFSM4HE6YUCA> . You are receiving this because you commented.Message ID: ***@***.***>

-- Gary Milne E-Mail: ***@***.***

[GaryMilne]

Never mind. I found it and submitted it here: #15498 Thanks for your help. Hopefully it will garner some interest but even if it does not I think I have a workable solution.

…

On Sat, Apr 30, 2022 at 2:01 PM Gary Milne ***@***.***> wrote: Yes, you are correct in your assessment of the variable usage. I tried to submit a feature request to support this capability but it was rejected saying that template was missing. This was what I submitted below. Do you know if there is a separate mechanism for feature requests vs an issue? Hi, Tasmota currently allows storage in either var or mem types. My request is to have some form of variable that persists across rules but does not require writing to NVRAM. What is a use case? Consider these two rules. Version #1 <#1> *ON Tele-Energy#Current DO var13 %value% ENDONON Tele-Energy#Power DO var14 %value% ENDON "ON Tele-Energy#Voltage DO backlog ; webquery http://192.168.0.200:39501 <http://192.168.0.200:39501/> POST {'TSync':'True','Current':'%var13%','Watts':'%var14%','Voltage':'%value%'} ENDON* Basically sends some JSON to the host at whatever the TELEPERIOD is, whether the data has changed or not i.e. all zero's. Not ideal from a POV of network usage and host activity and logging. Version #2 <#2> *ON Tele-Energy#Current DO backlog0 Mem11 %value% ; RuleTimer1 1 ENDONON Tele-Energy#Voltage DO backlog0 Mem12 %value% ; RuleTimer1 1 ENDONON Tele-Energy#Power DO backlog0 Mem13 %value% ; RuleTimer1 1 ENDONON Rules#Timer=1 DO Mem15 %Mem10%,%Mem11%,%Mem12%,%Mem13% ENDONON Mem15#State$!%Mem16% DO backlog ; Mem16 %Mem15% ; webquery http://192.168.0.200:39501 <http://192.168.0.200:39501/> POST {'TasmotaSync':'True','%Mem10%','Current':'%Mem11%','Voltage':'%Mem12%','Watts':'%Mem13%'} ENDON* In this case the net result is that Tasmota only sends changes to the host whenever one of the three values has changed since the last period. Slightly more processing but greatly advantageous in terms of reducing network traffic and events at the host because only changes are sent. However, the considerable downside is that with a TelePeriod of 60 seconds you would have 60 (events) x 24 (hours) x 5 (mem variables) = 7,200 mem writes per day. That would start killing off memory cells within a few days and obviously a non-starter. The availability of a couple of semi-persistent in memory registers %pvar% would greatly enhance what is capable of achieving with rules within the stock compilation. Thanks for listening. On Fri, Apr 29, 2022 at 3:06 AM sfromis ***@***.***> wrote: > To me, your rules looks like you only need a very short lifetime, not > what Mem gives you which is lifetime across boots. Other than that, you get > the same with Var, just without wearing down flash. > > What I meant with using trigger %value% directly, based on your previous > comment, is that simple usage of triggers can be done without staging the > value in a Var/Mem, but that does indeed not cover the use case of it being > part of a further trigger expression. This has nothing to do with your #2 > . > > However, since recently, %color% is now available as a rule variable > <https://tasmota.github.io/docs/Rules/#rule-variables>, but that's not > some sort of general replacement for using triggers to pick up values. > > — > Reply to this email directly, view it on GitHub > <#5614 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AD4ZMVIIDEIML2UKSS2I64TVHOJ7HANCNFSM4HE6YUCA> > . > You are receiving this because you commented.Message ID: > ***@***.***> > -- Gary Milne E-Mail: ***@***.***

-- Gary Milne E-Mail: ***@***.***