Local variable assignment not working in rule

📐 Rule Machine®
#1

This morning the heated floor in my room was not on when it should have been. I check the rule and it shows that I am assigning the set point value to a local variable and then testing if the variable is above or below the current temp.

It shows the set point at 72, then assigning this to a local variable, and then the local variable showing 68.

When I manually clicked on run rule actions it updated correctly and all was fine.

This is the first time it has happened and has run correctly up until now AFAIK. Any way to diagnose this? Thanks.

image
image2312×974 284 KB

#2

Do you happen to have logging enabled?

#3

I didn't - but I do now. Of course it won't happen again now that I am looking.

As a learning exercise - when viewing a rule does it actually run the actions to update the variables? In other words - should Conservatory Heat Setpoint show the actual temp if the rule were run now or does it show the last value it was assigned the last time the rules was run.

I am assuming it is the former, and not the latter, and therefore the situation in the screen shot in theory should not be possible.

Thanks.

#4

It's the latter. The actions are only run if the rule is triggered or if you click the "run actions" button.

Given that your trigger is "changed" though, I would expect that they match.

#5

Thanks - that is helpful. So for debugging you really can't rely on this view unless you cause it to trigger or run actions.

Next question related to this - if I click Run actions I assume it bypasses the trigger requirement and just runs the actions. The documentation is not clear on this but that seems to be what is happening. Thanks

#6

Correct.

#7

Got it - thanks. So now I need to figure out why this rule didn't run. Looking at the log on the trigger temp it changed, and changed below the level of the comparison in the actions. So will keep an eye out for it happening again and check the logs.

#8

Perhaps it is by design but one IF is for > and the second is for <, so the rule does nothing if it is equal?

#9

Rereading a little closer, this could just be a result from the temp of the thermostat not changing even though the setpoint did. That would result in the rule running without the variable updating.

#10

Good catch. Not by design. I do want it to turn off the heat if it reaches the setpoint so changed that to a >=.

Not the cause of my question here however, as the heat would have been on, not off. Thanks,

#11

I checked the history on the setpoint. It did not change. It is a virtual thermostat so no one can play with it physically.

It is an interesting setup. Heat comes from a heated floor and cool comes from an air conditioning unit. Both have separate thermostats that are connected into Hubitat. So I created the virtual thermostat to manage both and provide one universal thermostat for the room. A true example of Hubitat to the rescue.

#12

A few thoughts...

If the rule runs correctly when using the Run Actions button, it seems likely that your trigger is the root cause. Logs should confirm this.

If your two IF statements cover every possible evaluation of the conditions, you really only need one IF statement followed by an ELSE (and the obligatory END-IF).

This seems like a good candidate for a WAIT FOR CONDITIONS action. Once temp is over setpoint, set mode to OFF. Could even set a timeout value as a failsafe.

Have you looked at using a virtual thermostat app for this? nclark's Advanced Virtual Thermostat will create a virtual device that actually "reads" a temperature sensor. It can also control any real or virtual switch based on that temperature sensor...

Then you could let the app/virtual devices handle the temperate evaluation but you would still need a rule for setting the modes of the real thermostats (heat/cool/off) to match the new virtual device. Maybe this is an improvement, maybe not. That's your call.

Screenshot_20230516_233357_Chrome
Screenshot_20230516_233357_Chrome1080×1565 132 KB

#13

I have to see if the issue happens again and will look for the trigger logs. I don't know why I set this up as a double IF - probably because I set up each section at different times. But there are only two options so can definitely move it to an ELSE.

I did look at the vThermostat but if I understand it correctly it switches devices on and off. In my case I am actually controlling two other thermostats - one for cool and one for heat - and I am combining them into one. But I will take another look to see if there is a way to streamline it further. Thanks for all of the help.

#14

Yeah... that's how it works. If you do end up going that route, you'll need a complimentary rule. Something like...

Trigger: operatingState of vStat *changed*
Actions: 
IF operatingState of vStat is heating THEN
Set mode of realStat1 to heating, setpoint 85
Set mode of realStat2 to OFF
ELSE-IF operatingState of vStat is cooling THEN 
Set mode of realStat2 to cooling, setpoint 65
Set mode of realStat1 to OFF
ELSE set mode of realStat1, realstat2 OFF
END-IF

Virtual stat would need to be in AUTO mode with appropriate setpoints. You would not need to select any switches/outlets during the setup of the virtual device.

Of course, the easiest would be to figure out why the original rule isn't triggering. Any luck on that front?

#15

That actually looks like about the same amount of work as the approach I have implemented with the standard virtual thermostat and my rules. I do have a setup in my office where the heater is controlled by a zwave module so I am going to try the vThermostat there.

The trigger hasn't caused an issue since. So perhaps an anomaly. Waiting and watching.

1 Like

Download the Hubitat app