Rules - Math issue I can't get my head around

habitat · April 11, 2021, 5:47pm

Anyone got some ideas?

I set the rule to Wait until The Tool Charger was drawing less than 7w

The Rule is showing that the Tool Charger condition is TRUE - it I using less than 7w so power off.

Trouble is it is pulling more than 7w

And shutting off the charger immediately - regardless of how much power is actually being used.

Every time the power goes on the Rule declares the Power below 7w and shuts it down even when power is an order of magnitude higher than 7w.

Can anyone spot why the Rule believes that every number is below 7?

Thanks

I am using this for the Car Battery Charger and the Electrical Yard tools

habitat · April 11, 2021, 5:51pm

Looks like the key issue here is that the Rule Engine is NOT reading Power level of the Device at all.

Power level is working fine in Graphs etc but fails in Rules

@bertabcd1234 How do I get Rules to read and use the Power value in the zwave device?

bertabcd1234 · April 11, 2021, 6:01pm

What driver are you using for this device? Is it built-in or custom? If I had to guess, it's one of two things:

Rule Machine is not showing you the current device state, just what it was in the recent past; the "Refresh Action List" button will fetch them again (this affects only the display--not execution)
the driver is reporting the value as a string (text) instead of a number/decimal, so a numeric comparison in Rule Machine does not work as expected

habitat · April 11, 2021, 6:10pm

I don't think there is a built driver for the GreenWave ZWave sockets is there, I am using a 3rd party driver.

I suspect you are right about the Driver reporting in string for power.

On checking graphing works for the energy but not for power too.

I'll go beg a bug fix

Thanks

bertabcd1234 · April 11, 2021, 6:25pm

I wouldn't 100% blame it on the driver without seeing it. But since it's a community driver, you should be able to look at the code yourself--or post a link here for someone to examine. However, if it's problematic for any app you use, that's probably a good guess!

SmartHomePrimer · April 11, 2021, 6:48pm

Since you can see the power level is working in your driver, I wouldn't use the power level for the condition in the rule if it's not working with this driver. Use a custom attribute and select the attribute power and the comparison to <= 7.

Also, I would remove the delay before the wait. There's no need to have a delay before a wait condition. If you want the notification to be delayed for some reason, then the delay should be on the Notify action.

thomas.c.howard · April 11, 2021, 7:10pm

Hate to agree about the string type being the issue; but my custom drivers do not show units on the device page unless it is a string….

bertabcd1234 · April 11, 2021, 7:19pm

I didn't catch that, but that is, of course, true--and not just your drivers; it's how Hubitat's "Current States" display works. If you are using the standard Power capability, the power attribute (part of that) is supposed to be a numeric type per the spec: https://docs.hubitat.com/index.php?title=Driver_Capability_List#PowerMeter. If you wanted to follow that, my suggestion would be to send the units as part of the event (if you aren't already)--which won't display them on the device page but will in history--or create a custom attribute that includes the value plus units (if you're trying to make it easy for someone to, say, display these on a Dashboard tile with less effort needed on their part; though there otherwise probably isn't a good reason to do this).

But, of course: your driver, your choice. If the OP wants a workaround that would make this work in RM--and this isn't how you want your driver to work--they could modify the driver (if that is allowed by your license terms) to send a decimal value for this event instead of a string, assuming that all reported values are otherwise valid numbers.

woodsy · April 11, 2021, 8:28pm

Change the wait for condition to wait for event. Perhaps that line is executing before the power level is reporting. As opposed to Waiting for it to be triggered as an event.

habitat · April 11, 2021, 9:25pm

I have a delay before to give time for everything to power up.

The battery chargers seem to take a short while to decide whether to start charging or not.

habitat · April 11, 2021, 9:28pm

The issue is that Hubitat sees the Power value as a string and in the rule shows “nul” hence the failure.

habitat · April 11, 2021, 9:31pm

@bertabcd1234what is the Hubitat recommended method for Rules that are triggered on power usage by a device?

I would like to mirror the model envisioned by product architects than build something that may break later.

Thanks

bertabcd1234 · April 11, 2021, 10:32pm

I don't know that they've told us any recommendations for power metering devices in particular. But if you want my take, I'd start with the device and first make sure it reports only at the frequency or amount of change you need (I'm not sure what this device is, but some have options for time- and/or wattage-based changes that are necessary to send a new report). In a rule, if you can then trigger on being above or below a specific level instead of just "changed," you're likely to squeeze a bit better performance out of things since you can use the trigger for something valuable instead of having to check things later in your actions.

As a concrete example, for motion sensors, staff now generally recommend something like this:

Trigger: Sensor active

Actions:

On: Switch
Wait for events: sensor inactive
Wait for events: elapsed time --> 0:05:00
Off: Switch

As opposed to the "old" paradigm,

Trigger: Sensor *changed*

Actions:

IF (Sensor active) THEN
  Cancel Delayed Actions
  On: Switch
ELSE
  Delay 0:05:00 (cancelable)
  Off: Switch
END-IF

Now instead of triggering on an event and needing to check a value later, you're triggering only when the event fires with a certain value, so that work is already done. (The first also exploits a behavior of "Wait" where a wait gets cancelled any time the rule re-triggers, freeing you from needing to explicitly cancel a delay as in the second example, but there's no practical advantage to that particular aspect besides less clicking for the time-based one.)

For power metering, here's a rule I wrote for my washing machine that I believe follows these guidelines:

It's nothing you couldn't also do with a "changed" trigger, but this is pretty easy to write, only creates the specific device/event subscriptions needed for the rule, and--not pictured--I think another important piece is that I have my plug configured, as I mentioned above, to only send power reports with the amount of change I really need to make this work (plus, honestly, probably a bit more; I wasn't trying to be that picky, and power usage varies a bit depending on the type of load I'm washing).

FLGuy · April 11, 2021, 11:22pm

You could change the string value to a number and then do what you want with it.
You need 2 local variable, one a string variable (stringVal) the other a decimal variable (numberVal)

Set the reading from Garage Tool Charger on Heating (I'll use 4 in example) to stringVal. stringVal is now 4 as a string.
Then set numberVal to stringVal by choosing string as the type

Now numberVal is a decimal number
Now you can evaluate for your condition
Wait for condition: numberVal is <=7.0

Original values for both variables was 0 before Run Action

Not sure if this will do what you want.

habitat · April 14, 2021, 3:38pm

OK many thanks for everyone here.

Managed a clunky workaround, I had bought some Neo CoolCam Power Plugs because they are natively supported by Hubitat.

They do report Power as a number so can be used to track power usage.

Just not comfortable hacking Drivers - just not that level of confidence - besides the 30+ Greenwaves work great at switching on off and reporting energy (as a number) so good enough, plus have the added advantage that they ALWAYS turn on after a power cut so are great for Fridges, Freezers that you ALWAYS want on.

For just basic On/Off I also have a pile of INNR and Hue sockets.

Thinking about it, I may copy the Driver and just test a hack on One device. Not an urgent project.

Again thanks you for your help, it just never occurred to me that you could see a power value but can not preform comparisons against

habitat · April 14, 2021, 3:51pm

Ha

A quick sanity Check

and the device itself

From the time the Power dropped below 90w In the Device and in the Rule it took 4 minutes for the Wait Event action to kick in and actually turn off the device.

I'll do some more tests and see if this is consistent behaviour.

Is that to be expected that the Wait for Event takes several minutes to process the change if so I need to look at a workaround.

Looking at the Device Event Log

It looks like it took a while to turn off the device and when it did it really wanted to ensure it was off, not sure what the difference between a physical Off and a Digital Off but the Rule sent two of both to be really sure.

bertabcd1234 · April 14, 2021, 4:10pm

No, a wait creates a "subscription" to that device event and the subsequent actions should happen more or less immediately.

One oddity of your rule: you're triggering on the power level of one device becoming >= 10, then waiting for the power level of (what appears to be) the same device becoming <= 90. Any time the rule re-triggers, any "Wait" actions are cancelled, so that would include any reading between 10 and 90 here. Therefore, what your rule is really doing is watching for power >= 10 followed by something < 10 (and also <= 90, but by no means most values <= 90). That is likely why it seems to be taking so long to turn off. (And also why it's important to share your entire rule, including triggers, which were missing from the screenshot in the original post. Though, of course, there are problems outside this rule that aren't under your direct control in that one.)

I'd re-think the logic for how you want to know when to turn off this outlet. Changing the ">= 10" trigger to a much higher value would be my best guess, but of course this all depends on what the power reports of your device says during this time. See my washing machine rule I shared above as an example. This rule works as expected because the trigger doesn't conflict with the "wait," at least not under the circumstances where I don't want it to.

habitat · April 14, 2021, 4:21pm

@bertabcd1234 Thank you so much for this help.

Wait is a new one to me, am I right that increased/decreased works the same way - with a subscription - and therefore uses fewer cpu cycles?

I was trying to create test -

ie if the power goes above 10w then start the wait

Normally the Tool Chargers are done when it hits 7w, I set it to 90w so I could monitor it but understand that is causing another Trigger event.

Could I just not set a Trigger on DEVICE Turns ON?

bertabcd1234 · April 14, 2021, 4:49pm

Pretty much all triggers create event subscriptions (apps don't spin constantly checking device attribute values, which would be a waste of resources; a device generates an event, which apps--including rules--can "subscribe" to, at which point they'll wake up and do whatever they're supposed to). So, I'm not sure what you mean with "fewer CPU cycles," but yes, "increased" and "decreased" would also create a subscription.

I wouldn't really worry about much beyond this; it's often good to avoid a "changed" trigger if you can (you'll often end up checking a value in your actions anyway, so if you can just trigger on a specific value or range of values, it's usually less work for both you and RM), but your existing rule looks mostly fine to me. The biggest issue is that you can't say "trigger when the power goes above 10 and then wait until it goes below 90" because 10 is already below 90 and it's quite likely you're going to get lots of re-triggers (between those values when the device is in use) that cancel that wait and starts everything over.

If you start with the device off (so turning it on generates an event at the appropriate time), sure. For a smart plug, this would be the on/off switch capability.