A variety of services are running on the device, each having its own specific area of responsibility. Most services are built around the same structure and using the same concepts which are described below.

Services can be setup and configured from the AutoPi Cloud. When logged in go to: Advanced -> Services


At startup, a service is initialized with the given settings. They vary between different services but usually contains connection strings, timeout threshold etc.


Within a service multiple worker threads can run. Each worker is setup to process one or more workflows sequentially for a limited period of time or indefinitely.

Available options for a worker instance:

Field Type Description Default Value
name Text System name to identify the given worker. -
delay Decimal Initial delay in seconds before starting the worker. No delay if left empty. -
interval Decimal Pause in seconds between each run. Enter 0 if no pause. 1
loop Integer How many runs should the worker do? Enter -1 if infinite. -1
suppress_exceptions Boolean Suppress errors/exceptions so that they do not kill the worker thread? True
kill_upon_success Boolean Kill the worker thread after the first successful run? Successful means that no errors/exceptions occurred. False
transactional Boolean Ensure that consecutive workflows are processed in an uninterrupted sequence and not potentially mixed with others from other workers? False


A worker can process one or more workflows in a sequence. A worflow consists of a number of steps. The primary step of a workflow is called handler and is always required. Then more steps may occur both before and/or after, and are not normally required. At present, there are two built-in workflows. Below is an overview of the steps in the first workflow called simple:

handler trigger filter returner

And secondly the extended workflow:

validator handler converter trigger filter enricher returner

Each step in a workflow has a defined area of responsibility:

Step Description Example
validator Validates the request and decide whether or not to proceed to the handler. -
handler Produces a result typically by interacting with an external device or system. See
converter Converts the result returned from the handler into a more usable format. See
trigger Decides whether to trigger an event based on the result. See
filter Filters out result if insignificant. See
enricher Enriches result with additional information. Could for example be calculations. See
returner Returns the final result to an external system or service. See


Coming soon…


Coming soon…