Using Actions
ChipChop actions allow you to create simple IF » THEN type of rules that can send commands between devices or trigger routines in Alexa.
The terminology I use here is simple:
When we combine this simple concept with anIF » THEN » WHEN pattern it creates...well...logic!
Actions are checked (and executed if all conditions are matched) either:
As with anything you should apply common sense to avoid potentially unpleasant results. Read the following paragraph carefully.
An important thing to understand is that ChipChop is not intended to replace programming logic on your device with code that executes on-line.
Although some simple devices (mostly simple ON/OFF things) can be almost completely "programmed" by using Actions and just having a piece of code in the device that sets a certain pin to HIGH or LOW but for anything more complex you should be implementing the logic on the device itself.
Although some simple devices (mostly simple ON/OFF things) can be almost completely "programmed" by using Actions and just having a piece of code in the device that sets a certain pin to HIGH or LOW but for anything more complex you should be implementing the logic on the device itself.
The terminology I use here is simple:
Trigger This is the device that we are monitoring for the change of the status of one of its components and when that happens it "triggers" the ActionTarget This is the device (the entire device or just one of its components) that the action is "tragetting" by changing its status to something else
When we combine this simple concept with an
Actions are checked (and executed if all conditions are matched) either:
- On receiving a status trough the regular device heartbeat
- Sending a triggerevent from a device
- Clicking some control button in the Web App
- Receiving a command through Alexa
As with anything you should apply common sense to avoid potentially unpleasant results. Read the following paragraph carefully.
The Dev Console has a simple set of checks that will try to predict and warn you on some obvious logical problems with your Action's flow but it is computationaly not feasible to even try and check every possibility. For that reason the ChipChop engine doesn't check jack shit what you send to it, its only concern is to protect itself and the availability of its resources so everybody can enjoy an uninterupted, fast and stable service.
So...if you create circular logical loops with your Actions that will start unreasonably overloading ChipChop's processes it will simply and without warning disable whatever it thinks is causing the issue; that can be blocking the communication channel with one or all of your devices for a time period, turning off one or all of your Actions or suspending the entire account (it will do the same thing if you start sending heartbeats or triggering events at an unreasonable rate).
If you account get's suspended you will have to contact me to have it unblocked and I can't guarantee how quickly that will happen.
Please quadruple check your Actions logic before enabling them to avoid unnecessary problems
So...if you create circular logical loops with your Actions that will start unreasonably overloading ChipChop's processes it will simply and without warning disable whatever it thinks is causing the issue; that can be blocking the communication channel with one or all of your devices for a time period, turning off one or all of your Actions or suspending the entire account (it will do the same thing if you start sending heartbeats or triggering events at an unreasonable rate).
If you account get's suspended you will have to contact me to have it unblocked and I can't guarantee how quickly that will happen.
Please quadruple check your Actions logic before enabling them to avoid unnecessary problems
IF - statement
Action Name
Has to be unique
Trigger Device
Device that can trigger this action
Trigger Component
The device component that you are observing for it's status change
Value is
The logical condition that the component status has to match for the Action to get executed
- For text strings values you can only compare the value as "equals" or "not equal"
- For numeric values you can compare the values as "equals", "not equal", "greater than", "less than"
- For text strings values you can only compare the value as "equals" or "not equal"
- For numeric values you can compare the values as "equals", "not equal", "greater than", "less than"
THEN - statement
When all the conditions are matched in the IF and WHEN statements then the THEN logic can be executed
Add Target
You can change statuses or send commands to multiple devices at the same time and the commands sent don't have to be same.
This allows you to create reasonably complex logic, consider it as a pattern:if » then » then » then
This allows you to create reasonably complex logic, consider it as a pattern:
Target Device or Group
You are choosing here if your are sending a command to a single device component or an entire group.
Target Component
- If you've chosen a specific device as a target you can choose which component you are sending a command to or you can choose ENTIRE DEVICE (see end of this page for the list of Command Options)
- If you choose to target a Group then the only available option isENTIRE DEVICE
(more explanation in the Using Groups pages)
- If you choose to target a Group then the only available option is
(more explanation in the Using Groups pages)
Set Value To
Choose to what status you are changing this device/component to.
This value will be sent as a command directly to the device and also will be sent to Alexa if enabled.
ChipChop will only trigger the status change on the target if its current status is different
What that means is that the logical pattern is more like this
IF something THEN execute ONLY if new status is DIFFERENT from current status
So, if you have a motion sensor you can't accidentally keep firing an Action on the DETECTED status (when the sensor detects motion, which can be gazillion times a second) unless you have reset the status to NOT_DETECTED (when the sensor stops detecting motion).
This value will be sent as a command directly to the device and also will be sent to Alexa if enabled.
What that means is that the logical pattern is more like this
So, if you have a motion sensor you can't accidentally keep firing an Action on the DETECTED status (when the sensor detects motion, which can be gazillion times a second) unless you have reset the status to NOT_DETECTED (when the sensor stops detecting motion).
WHEN - statement
Although this is the last option in the Dev Console and I consider it from usage perspective the least important it is the first thing that is checked before the system can proceed checking the IF & THEN logic
In the WHEN statement you define the time & days when this action can run. It is important that you correctly set the Timezone(s) for your devices so you don't get things happening at the wrong time.
If you would like to find out more how ChipChop handles the timezones and provides you with a Real Time clock, post a question in the Forum. It's a fascinating topic that has caused me enormous amount of pain and most likely left me with a permanent brain damage.
Time is
You can specify if you want this action to be only active between certain hours.
On Days
You can specify on which days this Action can run
Command Options (for 'ENTIRE DEVICE' as a target)
Important: A command sent to the entire device will have the target set as any not a specific component.
So, if you have a simple device with just one component, let say a single led light then any command received is meant for that led light. But, if you have a device with many parts if that device receives let's say a command ON and no target component specified it will be unclear which component should react.
For that reason, you may want to use custom
Text Command
Send a text string up to 1000 bytes
Numeric Command
Send a number - integer or float (max integer value 9007199254740991)
ON/OFF
Send ON or OFF (as string)
DETECTED/NOT_DETECTED
Send DETECTED or NOT_DETECTED (as string)
Send copy of trigger status
This is a special system command that sends the entire status of one device (trigger device) to another (target device)
It's a powerful feature enbling you to create complex multi-device setups or even a type of Virtual Mesh networking concept but over the Internet!
It's a powerful feature enbling you to create complex multi-device setups or even a type of Virtual Mesh networking concept but over the Internet!