@rambo350z Hmmm, can you confirm if the temp was above or below 76 at 6am? The reason I ask is because my route is exactly as yours (I changed it to make sure it was “When all conditions are met”) and I’m still not having success. I think as have been implied, if the temperature is above the target temperature when the routine starts running, it doesn’t pick it up as it is not changing from a value below the target temperature to one above (of that makes sense what I am saying).
I thought that by switching the trigger from Equal to or above to Range and it didn’t seem to make a difference. One of the routines ran, but the other didn’t and the one that did run wasn’t consistent … it was just the one time.
Thank you all for your help with this however! It has been a mass help in trying to trouble shoot!
The temp was below 76 at 6AM and the virtual device was in the off state. The virtual device turned on at 10:34AM when the temp was either equal to or above 76
Did you change your routines since you first posted them? The original routines you posted did not have the Dinning Room AC - Switch as a condition for the trigger. My routines have the expect state of the virtual device as a trigger condition prior to switching virtual device to the new state
Yes, that’s what we’ve all been kind of saying … if the temperature is above the set temperature in the routine before the routine is set to be triggered then when the routine is supposed to be triggered, it won’t because it is not changing to above the temperature in the routine as it’s already passed it. See what we’re saying?
What I wanted and what I thought would happen, is that the routine would run as long as the temperature was above the defined value … not that it would only run if it were below and then changed to a value above the defined value.
My routine runs fine as long as at 7:30 the temperature was below that in the routine. If it were above the temperature in the routine, then it wouldn’t run unless I triggered the switch in the routine and then it would track the changes up and down.
You are correct, the dining room switch was not originally a trigger for the routine, which I changed (see photos), but that didn’t change the out come … the temperature part of the routine is what’s holding it up … if the temperature was already above the defined temperature in the routine, then the routine would not run until the temperature went below what was stated in the routine and then back up above it … which means I had to trigger it.
In the screen shots below, you can see that the temperature was above what was stated in the routine (at the time when the routine should start checking) and that the temperature sensor was tracking the change. However, the routine did not run …. presumably because the temperature was already above what it is tracking.
Remember, there are two parts to Routines; the triggering event and the precondition (bounding conditions/state check). Your Routine is written so that there must be a temperature event where the temperature crosses the threshold and the switch turns off when the state of the bounding conditions is within the specified time range. I think you really want the temperature and AC switch as preconditions as well and then use the virtual counter Edge driver to create a loop that then triggers your Routine every X amount of time. I use a similar method to check if a gate is left open and send a message every 15 mins.
Thanks for the suggestion, I really appreciate it. This is an interesting take … so, this virtual switch would constantly be turning on and off (based solely on the temperature being pulled from the temperature sensor), but my routine would be responsible for the timing and actually triggering the Alexa routine. Is that what your suggesting?
Thanks. Tried implementing this, but it’s not making much sense to me as to how I would get it to work … sorry, I had never used the Edge Counter Utility before.
Just an fyi, it tried rewriting the routine with the AC Switch as a precondition as well (without the counter utility component), this didn’t make a difference.
Thank you all for your help with this … still working on it and seeing if I can make this work the way I want it to work. Both @Terri_Baker and @h0ckeysk8er suggestions seems like they might work (the second, being very similar to what @Johnnybegoode was suggesting). These are all some good jumping off point.
For what it works, it seems like Sharp Tools could actually work! The problem is that it doesn’t seem like I can specify a time period trigger in their rule engine (at least not in the non-paid version). However, I was able to say if the device’s temperature “changes and is greater than” which seems that it would work, because as the temperature changes, as long as it was grater than my specified temperature, it would run … but, I can’t specify a time period as I stated above.
You’ll want to think of your rules based on their Triggers and then any further conditions, restrictions, or actions would be in your Flow.
So if the event that triggers the rule to run (and eventually checks your conditions), is the temperature changing above a certain value, then the trigger would be the temperature change. Then if you only wanted that to run during a certain time period, the first block in your rule would be an IF Condition with the time restriction.
You can also use time as a Trigger when that makes sense, but keep in mind that triggers are an event. Which means you could trigger at a specific time. For a range of time, as alluded to above, if you wanted to restrict something to happen during a particular time window, you would use your actual event as the trigger and use the time range as a condition.
Now if you want to use the timer driver so you can have local Routine execution, you’ll have to use 6 Routines since they don’t support enough complex logic; 2 to turn the timer on/off and 4 for the different states of the temperature and switch state. So with a timer called “Check Temp”, set the on time to 8am and off time to 11pm on the device’s Routines panel. That will create the two Routines to start and stop the temperature checking during the desired time window. In the settings for Check Temp, set the timer resolution and the update frequency.
Next, create the Routines for the four states:
Temp above X deg and AC switch off
Temp above X deg and AC switch on
Temp below X deg and AC switch off
Temp below X deg and AC switch on
If Temp above X (precondition)
AC switch off (precondition)
Check Temp is 15 mins (as an example)
Then
AC switch on
Reset Check Temp
If Temp above X (precondition)
AC switch on (precondition)
Check Temp is 15 mins
Then
Reset Check Temp
I’ll leave the other two Routines for you since they are the inverse of the above
Thank you so much @joshua_lyon for the explanation! I was very silly and didn’t realize that I could change between “before,” “after,” and “between” in the time condition! I had written my rule exactly as yours, but didn’t that it was that easy to change the time conditions! I’m gonna give that a try tomorrow morning and see what happens!
Thanks @h0ckeysk8er I was thinking exactly that (that I would need about 6 separate routines) as I was rethinking how this would work. Like your option as well, for local control!
Man! This is the most difficult “simple” routine that I have ever written! So, now I’m having an issue with the rule running in Sharptools! I’m getting an error from the switch saying “IF condition logic check failed for: Dining Room AC - Switch contact; Forbidden (Check that the device still exists in the source platform),” and an error saying “Error executing rule (RigPr7V6CfJ2U7xcbbrA).” Does this have something to do with this being a Alexa virtual switch which has a contact and switch component.
I removed the switch from the IF section; however, I then ended up with a “ Failed to send device command.”
Any idea what’s going on?
I’m starting to think that this routine is going to defeat me!
The bolded message above is usually the most common cause of the error. If you’ve deleted / recreated / reonboarded devices, you’ll want to make sure you’ve synced over any changes to your SharpTools account by proceeding through the authorization process from your SharpTools User Page → Manage Connections.
I suspect that the device was reonboarded and it has a new device ID, so when you created the rule, the conditions and actions were pointing to the old device ID which is why you are getting those errors. Once you perform a fresh authorization / device sync, I would remove the device from the condition and action and reselect the ‘new’ device.
Thank you!!! That was it exactly! The rules now run as expected! Don’t feel like such a failure anymore! The cloud executions are working beautifully! This seems like it might be the way to go as it’s very stable and doesn’t require a ton of virtual switches or additional routines to complete
Now, just to test out the local routines (just so that I can say that I actually succeeded) and to have as a back up in case I absolutely need this run locally (though I doubt it since this will only run during the summer months and when I am home.
Thanks again for all your help, really appreciate it!
