Please look at the first few lines in the screen shot.
Something is not adding up.
Thanks.
And what do you believe is incorrect? Looks correct to me. Understand that the parenthesized numbers are the current values, not the values at the time the action was executed. You might see what you expect if you used separate variables for each intermediate value, rather than re-using the same variables.
Or, you could turn on logging.
1 Like
39+45.6=351.6?
Every value is 0, except for two values.
The rule starts out setting end value to 0.
In both cases.
It worked right up to 2.3.1.130
Fresh from restart on upgrade.
May be missing something.
Have entered the rule and hit done!
Enable action logging (and I'd also recommend event logging, in part because we can't see your triggers and that would provide some clues), as suggested above. Then, provide logs during or after execution of the actions, and it should become clear what is happening.
As also mentioned above, the display in parentheses on the rule page is from the values at the time the page was loaded or refreshed. So, unfortunately, they are not useful for demonstrating whatever the issue may be if you believe it happens at runtime. That's where logs (plus leaving "Display current values checked," like you have it now) will help.
1 Like
A quick reply.
Primary triggers are local end point from volume control for tv, or changes in fan switches state.
One full iteneration of the rule.
The fans are not pulling 169906.8 watts!
It's a 30 amp 115 circuit!
Stumped here, seems just a pile of variable math to calculate the load of the fans, so that the Vizio volume changes with the increased noise level.
Worked great for the longest time.
And now I cannot clone it...
Error: Cannot get property 'device' on null object
Something looks a little off now; between the third and fourth or so log entries (counting from the bottom first), it's not apparent that Temp.Power.Fan or Temp.Power.Total ever got set to 0, which at that time appears to be the value of the device attribute you are using to set it. However, this entire set of actions executed in less than 1/3 of a second, which (a fraction of which between each action) is possibly not enough for the value of the variable to be fully committed before the next action, if I had to guess. Inserting a small pause ("Wait for event: elapsed time" is what I'd use) between each action might help.
That being said, the entire rule seems a bit odd, perhaps because its purpose was never stated. All of these actions are happening right after each other, very nearly at the same time. Setting one variable to something else based on simple multiplication would be practically the same result in most circumstances, given that the readings you're looking at are unlikely to change that much in a single execution of these actions (again, less than a fraction of a second in your screenshot above). But, again it's not clear what the actions' goals are here. Perhaps if you were to state that, someone could find a different, more certain way to accomplish the same goal.
Attempting to calculate the sum total power of my "HVAC" in a screen room with a TV.
If it is hot, alot, it is not, not a lot.( Of wind noise )
TV vol is automated to go up/down with temp/noise.
Uno... HA, not interaction!
OK, I see what I'm missing now: that "temp" variable is (as its name suggests, I guess....oops) getting assigned a new value between each step. I'm less confused now. 
I think a slight pause between, as I mentioned above, may still help if this is, indeed, the issue. This is simply a guess based on the fact that the logs do not suggest the value updated most of these times. You might also want to try just re-creating the rule in case something got corrupted in this one that could be causing both this problem and the other one (you can't clone, but you may still be able to copy and paste actions and import the clipboard into the other rule, but total re-creation still might be the safest bet).
EDIT: Staff have mentioned that there should be no lag with the variable thing, contrary to my guess above, so I suppose don't consider that option.
Even the third from last action should have set the temp variable to 0.
It should have shown across the board as 0, if variables are end values.
Lots of hub mesh in here.
I have rewritten this rule...
Doing it again is nothing.
If anything, enjoyable.
No legacy here.
Reintered rule, acts the same, only less,not climbing in to the 600000 watt range.
Have a couple of "variable math" heavy rules failing.
Going back to the last firmware and backups.
2.3.0.124
Please turn on Action logging, so you can see what fails. Post here what you find.
What you posted above showed Temp Power Total starting out at 169556. Are you sure you aren't failing to initialize that to 0?
First two actions set the 2 variables to specific values.
Then add them together.
Then set one (the temp.power.fan) to another fans power.
Then add it to the cumulative (temp.power.total)
If the power of the fans power meter is 0, it doesn't get set to 0. (temp.power.fan)
And just keeps accumulating more wattage, ie. The last power reported>0.
Worked great.now not functional.
Been watching the logs, this is the conclusion I have come to.
OK, but I need your help to figure out what's wrong. Can you possibly show me some screenshots from a desktop or laptop, instead of mobile? I need to see the Settings from the App Status page for the rule in question. I need to see the first action where it appears to go off the rails, and with respect to that action the specifics (what device, its device page, etc.). Where is it getting the bad value? You have context that I don't have, and it's not easy to do this from afar.
Sorry, went back to .124
Here is an execution of the rule under .124
This takes 0+0 and ends up with 0.
In the latest firmware, it does not accept/change on a 0 power meter sensor report.
I don't know what this means, please explain. Could you show the specific action you are talking about? Setting a variable with variable math? I don't have a clue.
Local variable "Temp.Power.Fan" is being set to a sensor value on a power meter device.
Power meter devices are:
on a zooz power strip, hub meshed to the stock driver.
a generic ZigBee outlet stock driver, hub meshed.
Aeotec smart switch 6, using hub meshed stock driver.
Attempting to set the power level on a hub meshed virtual Omni sensor.
As I type this on my tablet (all I got), I am truly amazed that it ever worked.
RM rules!
I don't know if there is a bug or not, and if there is what it has to do with. I need specifics as requested above.
