Rules/Automation

Get it on Google Play

Why aren't my rules running?

On android the AM Server widget must be on one of your home pages (see below for instructions) and the rule engine must be enabled in the AM Manager menu.

Is there a "long press" trigger like belkin supports for their lightswitches?

Unfortunately not, Belkin has chosen to not expose the long button press event locally.  The "WhenClicked" trigger below will allow you to take action on a double click of any wemo.  You could also use a belkin long press rule to trigger another wemo device and use that wemo device state change to trigger a AM Server rule, and now you can use IFTTT to handle the event.

Some rule actions or restores were not completed after I closed the rule editor, what happened?

When you exit the rule editor the rule engine is restarted, cancelling any pending operations.  A "rule engine restarted" message will appear in the log.  Use the "Rule Status" viewer to check your rules without restarting the rule engine. 

Can I use Belkin's or TP Links' "onboard" rules as well as AM Server rules?

Yes.  Those rules run on the device itself.  Their rule engine implementation is too messy for me to integrate with, but there's no problem with using vendor app defined rules along with AM Server rules.

What can I do with rules (see below for some more examples)?  Rules are triggered by events to take some action:

Remember, on android the rules only run if the AM Server WIDGET has been added to one of your home pages or if you've enabled "widgetless rules"!

AutomationManager/AM Server "Rules"

Rules are what you use to tell AutomationManager how to automate your devices.  You create rules that react to external events called "triggers" when "conditions" are met to perform given "actions".

Triggers are events caused by your automation devices reporting changes (e.g. a motion sensor or a light switch) or externally via a web page, through WemoRemote, or using your own automation tools like Tasker or other applications.  Think of triggers as "OR" events - when any of the trigger events occur the rule actions will be executed.

WAIT - a delay between when the event occurs (the trigger is triggered) and when the rule actions are dispatched.  The delay can be marked random to simulate occupation.

restartable - if a rule is re-triggered the rule is cancelled and restarted.  Any wait time is restarted, any restore actions are cancelled.

interruptable - any STATE event NOT in a trigger will cancel the rule. Of course only state events for the devices in that trigger are monitored.

Cancel - cancelling a rule using a cancel action, a restart, or an interrupt stops any WAIT timer and cancels any restore action.  If restarted the rule is re-triggered.

A second trigger on a rule that is already active (the WAIT timer is counting down or a restore action is pending) has no effect unless that trigger is restartable or interruptible.  If the rule is not active it will be triggered.

Conditions are decisions to be made when a trigger is fired or rule is ready to execute (after a non-zero WAIT time). 

All of the conditions must be true for a rule's actions to be scheduled.  Conditions are "AND" decisions.  When a trigger event occurs AND all of the conditions are true AND the WAIT time reaches zero the rule actions are executed.  A condition can be time based, check the state of your automation devices (e.g. if it's night, or if a switch is already on), or test flags that you can set or reset with other actions.  Use multiple devices/states in a single condition for an OR check.

Actions are executed when a rule is fired (when triggered any WAIT).  If the action is marked for a restore the action is "undone" after the restore period.  For example if a light is turned on when a rule fires, it's turned off when the restore period is up.  Not all actions can be restored. A restore has no effect if the target device is already in the restore state (unless it's a toggle action).  Restores are cancelled if the rule is cancelled.

Devices

Devices generate events (triggers), for example when a device like a sensor or switch changes from off to on, or a value like power use changes.  Devices can also be used in conditions in the same way.  Finally, devices are things that can be acted on - switches can be turned on or off, etc.

Flags are pseudo devices that can be used for logical operations just like real devices.  The can be used in triggers and conditions, and turned on or off in actions or manually.  When the rules engine is started (the engine is restarted if a rule is changed or when AM starts fresh) flags are cleared to the off state unless the "persist" property is set.  Flags are created as custom devices under the search menu.

Events are pseudo devices representing OnEvents.  They can be used in triggers and will fire when the event is received by the rules engine (AutomationServer).  Events are typically triggered externally (from AutomationRemote or an incoming REST call, Tasker, etc) but can also be caused by using SetOn rule, the buttons from the AutomationManager UI, or a DeviceWidget against the Event device (the Event device will return to off state immediately after firing).  Events can be added as custom devices under the search menu.

Triggers

Conditions

Actions

Actions can be ordered (do earlier/later) and there is a Pause action.

Keyword Substitutions 

For SendGMAIL, SendSMS, SendHTTP, BroadcastIntent, PushBullet, PostData, FileData, and WriteLog actions.  Values are taken from the event firing the trigger and will be substituted for &keyword; in the text sections of these actions.  Keywords:

Custom Devices

Custom devices can be used on an AM Server to increase the capabilities of your home automation.  Some devices have a "persist" setting in the submenu to preserve state across engine restarts.

Use the "Find/Search" menu in your AM Manager server to add custom devices:

When running on android these devices can be used in the defined rules (use "Add Phone Management"):

And custom IFTTT devices.  Use these to integrate IFTTT events and to monitor or control IoT devices that are integrated via IFTTT from AM (note there will typically be a 2-3 second delay for actions/events).  IFTTT setup instructions are available in the editor for each device.


How do I add the WemoServer widget to enable the rules?

WemoServer engine must be running before rules will execute (other than as tests).

For a conventional AM Server, configure AM on your server device:

Add the WemoServer widget to one of your home pages to enable the engine.

Any of the WemoServer widgets will do, the small one (no devices displayed) is usually the best choice.  It will look like this, the enabled services should be green:

Touch the widget to open WemoManager, you'll find the WemoServer configuration in the settings menu.  Confirm the WemoServer rules in the WemoManager menu are enabled.

Activate "always on while charging" in android settings "Developer Options".  If "Developer Options" is not available, go to "settings>About>Software Information>Build Number" (sometimes it's under "more").  Tap "Build Number" seven times to enable it.

Check your advanced wifi settings to confirm wifi will not be turned off to save power.  If you have a task killer on your device add the WemoServer (and WemoOnDrive if you're using it) to the list of exceptions.

On some android devices you may need to set the screen to stay on at all times.