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.
Absolutely right. Not my original idea.. I parrot pretty well though. 
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 
@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?
yes, it's a virtual thermostat, made up of a multisensor and plug.
the first one effectively turns on the heat when it's cold. The second one is there so that the statement evaluates to False when it's too hot, so the automation turns off the switch and sets the mode to idle.
It's not about turning the heat "more" on, it's about causing the whole statement to turn false when it's too hot.
Okay. I still don't see it. You have an OR between the two, not an AND. But if it's working for you, great.
I had to rewrite his rule and add a sample scenario to make his rule make sense to me, but I'm not seeing any issues with the logic itself.
Assuming a heating setpoint of 72, I think the rule can be rephrased as follows:
Heat will turn on if:
Thermostat is not off
AND
(Heat is off and attic temp is 71 or less
OR
Heat is on and attic temp is 73 or less)
So as long as the thermostat is turned on, the heat will come on when the attic temp drops below 72 and it will stay on until the attic temp exceeds 73.
@chris do I have this right?
Ah...i think I see it now. I think it's all the Not's and the double Negative's that are really confusing me. "Not off" should just be "On", shouldn't it? It's just a lot more confusing than it needs to be i think because of the virtual Thermostat thing. I understand the reason for it...but if the rule isn't firing the way you want it to, you might try doing it without that.
1 Like
@Ryan780 -
The rule fires fine with the addition of "Attic Temperature greater than 0" so that the rule checks every time the temp changes.
The reason for all the negatives is 2 fold:
- Rule machine allows comparing a setpoint to a temperature, but not a temperature to a setpoint in the case of a thermostat.
- The thermostat has multiple "on" states (auto, heat, cool) but only 1 "off" state, so its simpler for me to say "not off", since I don't think you can do multi-select on conditions
@destructure00 you have it right: the first one turns heat on, second one evaluates true as long as heat should stay on.
So it works if you change your opening line to : "Heat should be on if:"
1 Like
but the thermostat isn't going to be set to cool because you're only controlling a heater. And it's a virtual thermostat. Like I said, the virtual Thermostat could be part of your problem if its not working the way you want it to.
@Ryan780 I can use it to control an AC in the summer without changing anything. Just plug the AC into the smart plug and we're set. As it is, it allows for integrations that might turn the thermostat to heat instead of auto or vice versa to not break the experience.
In any case, it's working fine now thanks to the tip from @napalmcsr and @bravenel.
2 Likes
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
