New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Q: rules - trigger on changed values? #4372
Comments
Please, see the wiki at rules examples. There is an specific example on how to send values every delta |
Oh thanks, that example helped. I didn't read it before as it was labeled and implemented quite specific:
Perhaps it would be helpful for others to add a more generic example to the Wiki: Reacting on a sensor value only on changed values:
Note: %var1% should be initialized or it will initially be compared to an undefined value, ie: |
That answered one of my three questions, I still don't know how to initialize a variable at boot time with a sensor value. A GREAT feature would be the ability to use sensor values like variables, ie with %current%, %power%, ... |
To initialize variables at boot time use the trigger On system#boot do var1 value endon That is also explained in the wiki at rules |
How is value defined in your example? I would need access to the current Power, Voltage and Current values of the Energy sensor. RULES will be THE KILLER FEATURE of Tasmota, that's for sure, I am extremely happy to see what's happening here! Thanks! |
Value can be any number. What do you want to do? The example provided in rules works without the need to initialize anything at boot time |
Please, try this. Hope this solves your requirements. Teleperiod 60 |
Your solution has two weaknesses:
A way to initialize variables with Energy sensor values like Current at boot time, so guaranteed to be there before any other regular rule triggers, still doesn't seem to be possible, am I right? |
Your first statement is right. Can be solved with the following example. And the triggers of the rules are being evaluated in the same order they were written. So, no issue there. Example: Teleperiod 60 |
Please, try this and let us know if works fine for you. Thanks |
Hey, that one works, thanks a lot! Your time and support efforts much appreciated!!! |
Using Tasmota 6.3.0.
I want to send Current, Voltage and Power every minute from a Sonoff POW to an external system using the WEBSEND command using rules.
From my understanding:
[that would be a GREAT feature by the way, to be able to use sensor values like variables, ie "%Power%"]
So far, this works well - see my rule code below.
QUESTION 1: a trigger like "Energy#Power" is triggered every around 2 seconds on my device. My code therefore would permanently update three variables every two seconds. This MIGHT be a performance problem for our small gadget, so I would need some trigger functionality like "one-shot value change". Like one-shot which only fires if there is a trigger change, but in my case "fire if the trigger fires AND the value is different than the one before".
I know I can solve my original problem using the "tele-" trigger, but my question is really about a value-change trigger which is fired immediately with no delay, but only once for each value, not using sensor values inbetween by skipping time/delaying.
QUESTION 2: I wand to once define the variables at boot time using the sensor values. While this worked well for a power state using "on Power1#Boot do var1 %value% endon", I can't find such a possibility for the Sonoff POW. I'd need something like "on Energy#PowerBoot do var1 %value% endon" to get access to the "Power" sensor of "Energy" at boot time. Is there a way to achieve this?
My code:
rule1
on System#Boot do ruletimer1 60 endon
on Rules#Timer=1 do backlog ruletimer1 60; websend [] /uri/<%var1%,%var2%,%var3% endon
on Energy#Voltage do var1 %value% endon
on Energy#Power do var2 %value% endon
on Energy#Current do var3 %value% endon
If there are no solutions in Tasmota that I missed, these would be my feature requests:
Any help appreciated. Great system, thanks a lot to the author(s) and contributors!
The text was updated successfully, but these errors were encountered: