A flow is the “source code” for your automation, it’s made up of blocks, where each block will perform a single task.
This may be an action like copying a file, assigning a value to a variable
or awaiting a media button press.
A block may also check a condition like is the device unlocked or letting the user make a decision.
There are a lot of blocks to build with, and more will be added in the future.
A block may be connected to other blocks by a path/lane between their “connector” dots.
When a flow is running, a fiber steps through each block along the paths.
The number of dots a block has depends on the type of block, but there are two types of standard blocks:
- An action block is performed as a result of another block, so it must have one or more incoming (IN) connections.
An action can only have one outcome, OK.
- A decision block is performed as a result of another block, so it must have one or more incoming (IN) connections.
A decision can have either an YES or NO outcome.
A fiber is a running instance of a flow. Like a computer program, a flow can be started several times creating multiple fibers which all run simultaneously.
Each fiber run independently, and points to a block in the flow where it’s currently performing the task,
it also contain an independent set of values for the user declared variables.
A fiber is created when a flow is manually started, using the Flow start block,
or by “cloning” an already running fiber using the Fork block.
A fiber stops when the flow is manually stopped, by a Flow stop or Fiber stop block,
it reaches an unconnected dot, or if an error occurs. A flow is considered stopped when all its fibers has stopped.
All fibers run simultaneously, but an individual fiber may pause to await the completion of a block task.
This can often be configured with the Proceed option of a block.
A block can often be configured to perform its action or decision in a certain way.
The configuration, fields in the block editor, are divided into three section:
- Options that can only change at “compile time” by the user when editing the flow, and never at run-time when a fiber is running it.
Many blocks have an option called Proceed which control the basic functionality of the block.
- Input arguments which are evaluated by the fiber at run-time, may include expressions with
variables and operators,
or just a predefined (constant) value. All input arguments are seldom required and can be left unspecified,
then a sensible default will be used instead, read the block instructions.
- Output variables are used by the fiber at run-time to store the result or “output” of a block.
An output variable field can only contain the name of a user-declared variable, not an expression or other value.
The result are assigned to the named variable when the block has completed, the variable can then be used as input argument in the following blocks.
The proceed option
Many blocks have an option called Proceed. This option controls whether the fiber
should pause to await completion of the block, await change of a condition, or if it should just proceed immediately without pause.
For a decision block the Proceed option usually makes the block either instantly check the current condition,
or wait for the condition to change.
For example, the Location at block can check if you’re currently at a location, or wait until you’ve enter/exit a location.
The Wi-Fi connected block can check if a network is currently connected, or wait for a network to connect/disconnect.
Other automation apps differentiate between “event triggers” and “condition/constraint checks”.
Automate combines the same functionally into single block, using different Proceed options.
Automate uses cooperative multitasking, so it doesn’t use a thread for each fiber.
It may do so for blocking operations such as reading from disk or network.
Fibers are saved to the internal storage, so if the device shutdown they’ll continue to run from the last block when the device has restarted,
see the Run on system startup option in settings.