This object is in archive!
Power meter (current_consumption) not triggering rule
Under Consideration
I have a very simple rule that will not run. As far as I know, it should be possible for a meter to trigger a WHEN clause?
I am using a Fibaru wall plug to sense when my light is switched on. The light reports 130-140 watts in the zipabox event viewer.
I have also tried to use the power plugs WHEN ANY with a IF current_consumption > 50 inside it. It will not work either.
I can see the events in the event viewer.
Attached is my current rule. My other rules seems to work.
Files:
bodlys.png
I like this idea 
Access denied
No connection
Real-time notifications may not work
With the same device I use:
WHEN CURRENT_CONSUMPTION != 0
IF CURRENT_CONSUMPTION > 10
and it works.
With the same device I use:
WHEN CURRENT_CONSUMPTION != 0
IF CURRENT_CONSUMPTION > 10
and it works.
Thanks Carlo, I will check if I can use the same logic.
Since the device plugged into the wall plug is continously using a little more that 1W, I reckon a flood of events will be dispatched in the system, which may not be optimal..?
Do anybody else get this to work without a workaround?
Thanks Carlo, I will check if I can use the same logic.
Since the device plugged into the wall plug is continously using a little more that 1W, I reckon a flood of events will be dispatched in the system, which may not be optimal..?
Do anybody else get this to work without a workaround?
I tried the != 0 trick, and it works., thank you Carlo :)
I tried the != 0 trick, and it works., thank you Carlo :)
Try to use JOIN, otherwise your rule is executed continiously and takes system resources.
Try to use JOIN, otherwise your rule is executed continiously and takes system resources.
Sander, that is also my consern.
If I use JOIN I will have to make some logic that prevents sending the pushover message more than once per a defined period. I could do that, but I like to keep my rules as 'clean' as possible :)
By using JOIN, my lamp makes the Fibaro wall plug execute the pushover-call multiple times , because even when the lamp looks to be stably on, it actually differs 3-4 times in watt-consumption within each minute. The zipabox pushed a message for each change in consumption when JOIN was on.
My sollution now is not using JOIN, but instead use WAIT 300. In this way, I get a push message every five minutes if the lamp is switched on again, or changes its consumption while on. The lamp has a built-in timer so that it switches itself off after 300s/5mins.
Sander, that is also my consern.
If I use JOIN I will have to make some logic that prevents sending the pushover message more than once per a defined period. I could do that, but I like to keep my rules as 'clean' as possible :)
By using JOIN, my lamp makes the Fibaro wall plug execute the pushover-call multiple times , because even when the lamp looks to be stably on, it actually differs 3-4 times in watt-consumption within each minute. The zipabox pushed a message for each change in consumption when JOIN was on.
My sollution now is not using JOIN, but instead use WAIT 300. In this way, I get a push message every five minutes if the lamp is switched on again, or changes its consumption while on. The lamp has a built-in timer so that it switches itself off after 300s/5mins.
thats a good solution, only when you change the timer in the lamp you have to remember to change the wait in the rule also.
You can also try to make optimize it with the BETWEEN operator puzzle an choose a good range of the power fluctuation in our IF statement.
On the other hand, it keeps strange that the WHEN is not triggerd on the Power meter values when they change and create an event.
thats a good solution, only when you change the timer in the lamp you have to remember to change the wait in the rule also.
You can also try to make optimize it with the BETWEEN operator puzzle an choose a good range of the power fluctuation in our IF statement.
On the other hand, it keeps strange that the WHEN is not triggerd on the Power meter values when they change and create an event.
Replies have been locked on this page!