Here is the piston that will make her happy:
IF any motion sensors change to ACTIVE,
Then
With Webcore
DELETE
LOL
Use certain Alexa to turn on items in that room
WCmore
#43
I have seen this time and time againâŠ
When I program for others, most of the time, I end up working with the husband⊠But when the missus speaks up, she gets my full undivided attention.
You know the old clichĂ©âŠ
If momma ainât happy, then ainât nobody happyâŠ
lflorack
#44
I agree with this. I will say that my wife is extremely tolerant of my hobby and even enjoys certain parts of it. However, sheâs really happy about having control over actions (pistons) that affect her.
As an example, I have a âGloomy Lightsâ piston that turns lights on/off in the living room and den during pre-set timeframes - based on external LUX levels, our presence and override switches. It works very well. However, although my wife liked it overall, when she was reading a book in the living room, she did not enjoy having the lights turn off when the LUX level increased. To me, it made perfect sense to turn the lights off when the LUX levels were sufficiently bright. Why would you need lights when itâs bright? To her though, she felt that it was a disruption when trying to read. Upon further discussion, she said that it felt like she couldnât control the situation.
So, I gave her back control by adding additional logic to the piston for each affected room. If the lights in a particular room are turned on and set to 100% - normally via Alexa verbal command, the lights will remain unaffected (both on and off) by the changing LUX levels. Now, she feels like she has complete control of the lights when she wants it and loves the automation.
As you said, the ability to have control is the key.
WCmore
#46
Excellent example @lflorack⊠Thanks for sharing!
Most of my best pistons have âover-rideâ methods to occasionally disable ânormalâ automations.
Terminal
#47
So I have been playing with this a bit more lately, and I was trying to find a way to minimize the wait time. Below is what I came up with. I originally just had a straight 20 second wait. I have done some testing and this will execute about 5 seconds faster than just the 20 second wait. Someday if the system were able to react quicker it could save more, I think.
The problem I had though is when the global LastSpokenTo is already set to the echo you are speaking to. Then LastSpokenTo never changes so it waits the full 20 seconds. When the last echo is different it will toggle the ceiling fan in about 18 seconds, if echo is already correct it takes 25.
There is a 5 second wait in the âCurrent Echoâ piston. It waits 5 seconds before it does the get activity. That seems to be about the minimum to wait before that gets updated. I originally had the wait in this piston at 15 seconds to allow the global to update, that worked most of the time but not always. So I had to bump it up to 20.
The Piston âClear Last Echoâ then sets the LastSpokenTo variable to a echo out in my garage that is hardly ever used. That way when I run one of these routine it is going to update. Not the cleanest method but the only one I could come up with. If I change the global in the routine that doesnât work.
If anyone has any suggestions, please let me know.
Mebejedi
#49
The trick is to send a âgetdeviceactivityâ command, which updates the
âlastSpokenToâ data and drops the reaction time down to around 5+ seconds.
Terminal
#50
The get device activity is not the cause of the longest delay. I have a âgetdeviceactivityâ and I have a 5 second delay in the piston that determines activity. The longest delay is waiting for the global to be updated between pistons.
Mebejedi
#51
Why are you using a global? Globals donât get updated until the end of the piston, regardless of where you put them in the piston.
Also, I just realized I posted the wrong piston. In this piston, when I give the âTurn on/off Fanâ command, it executes the getdeviceactivity, determines which echo received the command, and controls the fan assigned to that Echo. Very quick.
Terminal
#52
Because I use the same routine among several pistons. I could make it faster by combining everything into one, but I prefer smaller pistons and the extra time is not a big deal to me.