Rule Machine Rule Only Triggers when I open and Save the Rule

I've been dealing with some major hub speed issues where it slows to a crawl after a day and one thing I'm testing is migrating to Rule Machine. I have a rule that I use to manage a virtual thermostat so that my family can use a UI to control a space heater in a finished attic.

The problem is that the rule doesn't always evaluate properly as states change. I often need to open the rule and close it for it to re-evaluate the rule and come up with the right conditions.

Any ideas on whether it's an issue with my rule?

I don't know what your rule is supposed to be, but that one looks messed up to me. Just write it out as a Boolean expression here:

e.g. ( Idle AND Heat Setpoint >= sensor) OR ( .... etc

Then you can see if you've entered it right or not.

It works perfectly for me. The only thing I have to do is open and close it. The rule itself isn't the problem, it's the failure of the rule to evaluate when the conditions change. I can fix by simply opening and closing the rule and it does what I want. The conditions show proper evaluation but the "Define Rule" section shows incorrect evaluation.

It's essentially

  • IF the Thermostat is NOT OFF AND EITHER
  • The thermostat mode is idle and the current temperature is less than 1 degree less than setpoint
  • OR The thermostat mode is NOT idle (heating) and current temperature is less than 1 degree more than the setpoint (to allow the heat to get to temperature)

IF TRUE - turn on the radiator switch and set the thermostat as heating
IF FALSE - turn off the radiator switch and set the thermostat to idle

The reason for the backwards checks is that that Rule Machine doesn't seem to allow you to compare a temperature attribute to a setpoint attribute unless you reverse them.

Suggest, as a test, you change it to this:

In other words, include "IF the Thermostat is NOT OFF" in both your tests


Is that different from what I have already?

Here's a quick write up of what I have.

((idle and temp < setpoint - 1) OR (not idle and temp < setpoint +1)) AND NOT OFF

I don't have a thermostat, so can't play... My suggestion:

((NOT OFF & idle and temp < setpoint - 1) OR (NOT OFF & not idle and temp < setpoint +1))

Will it make a difference? Dunno. But in a world where your rule isn't working test it & see!


I had the same issue as the sensor being on the right was not sending events in rule machine. I don’t know if that got fixed. My work around is to use the set temp in the virtual thermostat instead of the set points.

I'll try it, but the rule works fine when I first create it. And if I open and click "done" it also reacts appropriately. So the logic doesn't seem to be the problem.

Ahh, now this makes sense, thank you.

So you are using the "temperature" attribute of the thermostat as a replacement for setpoint to get around the fact that Rule machine doesn't let you compare different attributes.

That allows you to put the sensor device on the left hand side of the evaluation logic to account for the fact that rule machine only evaluates based on changes to the left of the equation not the right.

The downside is this workaround on top of a work around breaks the integration with things like Google Home or Alexa, since they use the setpoint method.

It's a start though, thank you very much.

I bet you could make a rule in rule machine to have on change of setpoint change the thermostat temperature

I love the idea, but does Rule Machine support that kind of logic? I'm coming from WebCORE where that's easy to do, but Rule Machine doesn't seem to do well with dynamic parameters in command calls or passing the value of an event to another action.

The only example I know of where Rule Machine can do that is Dimmers, but that only works for dimmers.

Yeah, I don't see a way to do it. I was hoping a custom command could do it. But I don't think we can pass in a variable to it.

There is another cheating way to do this and that is to add an and on the end (and Attic Multisensor >-33) that way everytime your multisensor reports the temperature, the rule gets updated.

Use a Virtual Dimmer as a repository for your variable.

That's a great idea, thank you! You ROCK!

I'm going to abandon going down any more workarounds and just use that one, since it should make it so that the rule works as is and it works with voice automation today.

Credit goes to @bravenel.

Absolutely right. Not my original idea.. I parrot pretty well though. :slight_smile:

I'm really confused why you have Thermostat setpint(TSP) > Temp +1 and TSP > Temp -1. Shouldn't one of those be
"<"? Or at least negated? If the SP is 60 and the temp is 55, both statements are true at the same time. So, why do you need them both?

Also, you can set "ThermostatOperatingState" on your thermostat? I have an Ecobee and that is not a configurable parameter. Its only reported back as to what the thermostat is currently doing. It reports back "heating", "cooling", "idle". But it cannot be set. ThermostatMode is what is typically used to set between heat, cool, and off, isn't it? It is in at least the three thermostats I've worked with.

1 Like

I've almost posted this example every day for the past week....thanks for the inspiration :slight_smile:

@Ryan780 the difference is that one applies when the thermostat is heating and the other when it's idle. I won't turn the heat on if the temperature is close enough to the target (around .5 degrees below it). This is because the radiator stays warm and turning on the heat would end up over shooting the setpoint by a bit.

If the heat is on, I'll run it till it's about .25 over the target temperature, since that will give a bit of a buffer so the room can stay at temp for a bit without turning the heat on and off a bunch

The piece I was missing before was using the motion sensor as a source of events by checking that it's over 0 degrees.

This means that if the temperature, set point or mode of the thermostat change, the rule gets evaluated.

You misunderstand me. You're turning the heat on using both temperature evaluations. Why?

Also, what about the commands? The thermostat operating state? Is this a virtual thermostat?