Those commands listed are from the Aeon Labs Multifunction Siren device handler, not the home energy monitor.
If you’re using that DH for the aeon siren, or my other device handlers for the Aeon Labs Doorbell or GoControl Siren, instead of having to specify the parameters individually, it’s a lot easier if you just select the device as a music player and use the Speak Text command.
Setting up custom commands in Rule Machine was a pain and SHM along with most other SmartApps don’t support them so I built this workaround into all my sound related device handlers.
For the aeon labs siren, if you enter delayedAlarm 4, 2, 60, 30 into the speak text field, when the siren gets activated it will wait 30 seconds and then play sound 4 for 60 seconds at volume level 2.
The full list of the aeon siren commands that can be entered this way is located here.
Having trouble with some logic and was hoping the community can help. My goal is to have my garage door close after 15min of being left opened. For some reason nothing seems to happen with this rule. I;m attaching the screenshot of my Piston.
The “stays” triggers are not yet functional. Use “is open” and add a Wait 15 minutes before the Close task. Also enable cancel on piston state change for your action.
IF garage door is open
THEN using garage door wait 15 minutes, send notification, close (cancel on piston state change)
OK, but where’s “cancel on piston state change”? All I see in the UI is “execute on piston status change only”.
Edit: To be clear, the “execute on piston state change only” option appears in the “BUT IF” clause of the piston. And, I found the “cancel on piston state change”. It’s in the “Advanced Options” for the Action. Way down at the bottom under “Task Cancellation Policy”.
OK, so that mystery is solved. But, when I change that option to “cancel…” there is no indication that is selected when you go to the “top level” page for the piston. Perhaps @ady624, that’s an enhancement to be made?
The only need for the cancel on piston state change here is to prevent the push notification from being sent. The piston will evaluate the main IF statement. Since this is a simple piston, the state of the piston is determined by (and equal to) the evaluation of that main IF statement. When the condition is true, the THEN statement is executed. The Wait delays every task following it by 15 minutes. To do so, the piston will internally schedule two “command” tasks (as a side note, there are currently two kinds of tasks: event and command - event tasks are generated by the Date & Time capability to wake the piston up at a certain time). So you now have three “pending” tasks. An “event” task for time in 15 minutes, one “command” task for garage closing, in 15 minutes, and a third “command” task to send a push notification, also in 15 minutes. The first occuring event task is used to schedule a job run in 15 minutes. 15 minutes from now, the ST job runs and the piston identifies the event task and uses that as the source event. It will then look for any pending “command” tasks that are now “passed” - they were scheduled for the time when the ST job happened, so they should now be in the past. The push is sent, the garage is closed, all three tasks removed, piston goes idle waiting for a “device” event. Now, should something happen to the garage door within those 15 minutes, the piston is again evaluated. The most natural event that can happen is the garage door going into the “closing” state. At this point, the piston would again evaluate the IF statement and find it false (garage is NOT open, it is closing). This would cause the piston to switch to false. Now, if you enabled “cancel on piston state change” option, those three tasks I mentioned above would be marked with a flag for cancellation on piston state change (namely data.c for those tasks would be true). Every time the piston state flips, a method cancelTasks is executed which finds all these marked tasks and simply removes them. They won’t get the chance to run when the original 15 minute wait ends, hence no notification. It would be very confusing if you opened the garage door, closed it, and then 15 min later you’d get a notification saying your garage door is being closed.
I would change the off sequence with this:
Using garage door >>>
Wait 5 minutes
Send Push Notification "hey buddy, you left the garage door open… Unless you’re having an open house event, I think you should close it…"
Wait 10 minutes
Send Push Notification "hey, I am closing the garage door for you. You are welcome"
Close
UPDATE: it could also happen (without the cancel) that you open the garage door, close it, then 14 minutes later you open the garage only to find out your obstacle sensors that came with your garage door no longer work (who tests them regularly, anyway?!) and the garage door suddenly decides to close in on the roof of your brand new Platinum Escalade. Okay, I am exagerating a bit here… but it COULD happen… LOL
@ady624 once the “stays” triggers become functional will it change the way we right these sort of rules where we want an action to occur after X minutes? Would we still then need to use “(cancel on piston state change)”?
The “stays” trigger would include the “cancel” logic in it. It would only execute if the door stayed open. If the door state changed, it would automatically “cancel”. More like, won’t happen.
This is more of lipstick but I was wondering if when this goes beta if we could have the ability to see pistons that are paused. That is when you go into the app you can see the piston paused without having to go into each one.
You mentioned that I was using the energy monitor, but what I posted was the pic of the Aeon Labs Multifunction Siren device handler’s custom commands.
Hahaha…thanks for that catch. I don’t know what I was thinking.