Hello,
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.
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.
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.
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.
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.
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.
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.
@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.
