Hey All, the wife was wanting to control the ceiling fans (Hampton Bay controllers) using (Alexa). I saw on this forum that someone mentioned that they made virtual switches to turn on fan controls so I came up with this.
The abbreviations are for 2 different fans family room and kitchen, they are the virtual momentary switches that I created. Trigger is any of these VMS to ON. The actions turn the fans on at different settings. I used the echo skill to link these switches to (Alexa). The rule works as it is, but I was wondering if there was a better way to do this. All Input will be appreciated.
these turn right back off. Momentary switches. Is this what you want to happen? If not then they should just be virtual switches. Not momentary.
I think this will work, but I think there is a more efficient way to do it. [My head is all over on this one]
My first thought is to expose the fan and light to alexa if it's available and do it in scenes?
Every time the switches change, any one of them, the whole rule will evaluate. the way the rule is set up is "the old way" of doing things and has proven in the past to contribute to hub issues when you get a bunch of really complicated rules evaluating all of the time. So, That being said, rules are free. IMHO I'd either run these in the alexa app if possible or set them up in simple automation engine. The positive about that is that each command works independently.
Maybe @bertabcd1234 will chime in. He's really good with creating rules efficiently in rule machine. He'll have some ideas with your current rule.
The thing is, that these triggers will only be evaluated when I ask (Alexa) to turn one of them on. They won't be evaluating all the time because I am not using them with anything else.
See the whole rule will evaluate from start to finish when you speak the command. Get too many of these and that can cause different issues. May I ask how you're asking alexa? Asking for certain switches? Could you give the the whole use case? Looking at the rule, I wonder how complicated the question to alexa has to be? Need to keep the WAF (Wife acceptance factor) at nominal levels. So, I apologize in advance for being so inquisitive.
No problem. I set these up as routines in the Alexa app.
Name of Routine-Family Room Fan High
When Alexa hears "Family Room Fan High"
runs "turns on FRFH" the virtual momentary switch in Hubitat.
which in turns triggers the Rule and turns on the fan.
The reason I went with momentary switches is because I just want these switches to turn ON and not OFF at a later time. Alexa turns them on and that starts the trigger. If I want to turn the fans OFF I just tell Alexa to "Family Room Fan off". I hope that makes sense.
Ok that gives me a better idea of how you're working it.
So you've taken the time to write each routine in Alexa at this point as well? If that's the case then I think that at this point you're way too deep into this automation to do any major changes to it. Is is working for you? Have you tested it?
[EDIT]
I think there IS a way to make the rule itself more efficient, but I'm an old way thinker and that is no longer considered the right way. Which your rule is considered the old way. So even though I might have executed differently, I'm in that boat with you on it because I would have done it this way too after you explain your use case.
Yes, It works just as I thought it would. Can you imagine that, I wrote a Rule that worked the first time. 127th wonder of the World. I don't know the difference between the old way and the new way, but If it works then don't fix it. If someone would enlighten me on the "new" way maybe I can go down that path.
I have one helluva time wrapping my head around the new way, myself. @lairdknox has a good point about the switch, so "on" would be a better choice for a trigger.
I was hoping that @bertabcd1234 or @ogiewon would chime in. They're really good at this. There are a few others, but I'm a blank on naming people at the moment.
Because you have "changed" it will re-evaluate the rule when the virtual switches turn on AND off. Thus causing the potential race condition that is being referred to.
I went ahead and changed the trigger to ON. So we will see what happens. I still donāt see how this can cause a race condition. If trigger is āchangedā it should only run the rule twice, when it turns ON and 500ms later when it turns OFF. Unless Iām missing something.
Well, It's not like it will happen, just a potential. It's also reducing the amount of unnecessary processing that you're asking the hub to do. Part of the new way of doing things. If it's one rule that is this complicated, you'll probably not see many issues, but think forward 6 months when you have 20 or 30 complicated rules, you could see the potential issues with that. Then add on 3rd party apps that may not take everything into consideration and you get a recipe for slow downs and missed executions. This is why they recommend doing as much in simple automation apps instead of creating a whole evaluation. Which, you could very easily do with this rule since it's just switches being triggered. Food for thought.
What you chose is NOT wrong. But just making you aware of things people run into. So you consider these factors when hashing out your next automations. You'll always find way to make things better. And you should. A home automation enthusiast is always tinkering. As you learn more, you'll go back and change things to make them more efficient. It's in the nature.
I don't think the HE Alexa skill gives you that option. All of my fans came through to Alexa as on-off switches. I now have my fans connected thru the Bond skill directly and have the option to set the speed as you described.
A race condition is when you have two asynchronous events that could impact the same thing. Normally one event finishes before the other one but it is possible that the second event could finish first.
Many times it doesnāt matter but sometimes it can cause problems. Say you were designing a gas stove And you turn on the pilot light first and then open the gas flow. Then one time the pilot light is slow for some reason and the gas valve opens first. Then the pilot comes on and you have an explosion.
Not a great sample but hopefully you get the idea. (Also why stoves arenāt designed that way. )
Looking back at your sample it really wouldnāt be an issue because all the ifās are looking for the on state. But say six months from now you decide to include an off condition or two. It probably would work ok but if for some reason the on trigger got delayed the off would happen first and you would be wondering why the rule failed. It is unlikely but a possibility. Race conditions can be difficult to trace because the events shouldnāt be coming in in the wrong order. Add a bunch of nested if statements and debugging can get ugly.
But a better reason to use on instead of changes in this case is as @april.brandt said - no reason to process all the extra off triggers.
)
