So like this right? One is Ecobee changed to Home and the other is Ecobee is changed to Away.
I don't know since I can't see the details of the two.
Yup, that looks right. But you really want to have the setting of your Ecobee to Home Indefinite? You don't use the sleep comfort profile in your Ecobee?
Yes, I do have the Sleep profile in Ecobee but I am trying to setup a Good Night Routine to set this to Sleep. I was trying to set it in WC but I am having trouble with it and I would like to have it all in RM. I will start another thread and post the piston to see if I can get some suggestions. I guess what is hard to wrap my head around with RM is having to break things down into smaller "Rules" rather than putting everything into one "piston".
Your original piston is really two automations in one, you have two separate if statements. So in that case it makes sense that it would become two separate rules...er...uh...triggers. The nomenclature for RM is confusing, I tend to call everything rules... Even when they are triggers, but then, are they RULE rules, or trigger rules, or triggered RULE rules 
Maybe we should call them RM apps? I dunno.
Either way, RM can do nearly everything webcore can do, it just has to be broken up into "building blocks" of rules apps.
Yes I vote for calling them “apps”!
when trying to work my way through another piston conversion I noticed “restrictions”. I have used them here instead of conditions. Is this ok?
1 Like
I call the Rules pistons:smile:
1 Like
Restrictions will stop the "app" from doing anything at all. Think as if the app were deleted at that time. If that's what you want, then good. If not, then consider using them as conditions.
Triggers = "changes to" or "happens". A temporary thing.
Conditions = "is", can act as a trigger if no other conditions are present, or can act as a restriction on other triggers or conditions
Restrictions = "stop button" make everything halt, including rule evaluation ad true or false. Use with caution IMO.
I'd be careful setting your thermostat program by your motion sensors. If you get up in the middle of the night to use the bathroom, do you really want your thermostat changing it's program temporarily. You seem to have all of your automations tied to motion sensors. is that what you had in ST? You don't see a lot of false events happening?
Something needs to call a RM "app" to be evaluated.
In a normal rule, without triggers, conditions become triggers and cause the rule to be evaluated. If you have a rule that says if motion is active and mode is home, do x....this rule will be evaluated if motion changes or if mode changes. Meaning if motion changes to active while mode is home or if mode changes to home while motion is active, then do x.
In a trigger or triggered rule, you specify which events cause things to happen. The difference here is that one just causes the actions to run, and the other checks conditions before making the actions run. Trigger: motion active, rule: mode Home means only do the actions if motion changes to active while mode is home.
Restrictions are like pause buttons. If you have an app that says if motions is active with restrictions mode is home, this can get weird. If motion is active, do x, but only when mode is home. So...motion is active, mode is home. Rule evaluates true..actions happen. Mode changes while motion is still active. Restrictions now in effect, rule never has a chance to go false. Now mode changes back to home. Rule is still true because it hadn't re-evaluated yet, even though motion is inactive. Motion becomes active again, nothing happens because rule was true before restrictions and never had a chance to go false, then became true again, so no change and no actions.
This works because it is only some of the motion sensors in certain areas. The point of this app is that once the house detects motion in the morning, the mode changes and the heat comes on. It is like the "Good Morning" Routine in ST. Because of the "restrictions", the mode won't change in the middle of the night if someone gets up.
I see your point here but this wouldn't happen in my case because I have a "Good Night" Routine in ST that am trying to bring to RM, that at night when certain motion sensors are inactive for a certain time then the lights go off and the mode changes to "Night". Although now that I think of it, some of these motion sensors are different in these apps. Might be best to use Conditions. What would be a good case to use Restrictions then?
As a side note, I found something really nifty about Ecobee. If your scheduled program is Home and you issue a setProgram command as (Home, nextTransition), it effectively does a resumeProgram command, rather than the hold command. The thermostat won't be on Hold status anymore, it will be back to schedule. I had a whole bunch of complex commands and conditions in webCoRE on ST to make sure that the thermostat was on it's schedule and not on hold when it didn't have to be (it shows up as a different status when you look at your data from Ecobee). Turns out, I didn't need to do any of that! Who knew? 
I find it easier to set Ecobee with things that are happening instead of using the Ecobee Schedules.
I like the house to be warm BEFORE I get up in the morning. 
1 Like
