Introduction

This guide is applicable to the following device / devices:

TMU CM4

CAN-FD Pro

CAN-FD Pro +IP67 casing

---

This guide provides a comprehensive reference for the services running on your AutoPi device. Understand how services are structured and configured, learn how workers and workflows process data, configure reactors to automate responses to device events, and extend functionality using custom hooks for specialized processing.

Key features:

• Modular service architecture with configurable settings.
• Worker threads with customizable timing and execution parameters.
• Two workflow types (Simple and Extended) for different processing needs.
• Workflow steps with defined responsibilities (handler, converter, trigger, filter, enricher, returner).
• Reactor system for event-driven automation.
• Custom hook support for extensible data processing.
• Cloud-based service management and configuration.

note

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

---

Settings

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

Workers

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

Workflows

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

Reactors

Reactors in AutoPi are components that listen for specific events and execute predefined actions in response (how device handle the different events). They are integral to automating behaviors based on real-time data from the device.

Managing Reactors

Reactors can be managed using the reactor.manage command, which provides runtime control over the reactor service.

Supported Commands:

reactor.manage reactor list
reactor.manage reactor show <name>

Example Usage:

reactor.manage reactor list
reactor.manage reactor show enable_obd_on_motion_shaking

• These commands allow you to list all available reactors and view detailed information about a specific reactor.

Example: Automatic OBD Logger Pausing

An illustrative use case involves the automatic pausing of the OBD logger based on vehicle motion:

1. Enable Motion Events: Ensure that motion events are enabled in the device settings.
2. Configure Reactors: Navigate to Services > event_reactor > Reactors in the AutoPi Cloud interface.
3. Enable Specific Reactors: Activate the following reactors:
   • enable_obd_on_motion_shaking
   • disable_obd_on_motion_steady_or_trip_end
     • These reactors respond to motion events, enabling or disabling the OBD logger accordingly.

Hooks

Hooks are custom functions that can be integrated into the AutoPi workflow to process data at various stages. They provide flexibility in handling data by allowing custom processing logic to be executed. Hooks are the core of how your AutoPi.io device works and we only recommend that you change these if you are sure of what you are doing.

Creating Custom Hooks

Steps to create a custom hook:

• Create a Custom Module: navigate to Device > Custom Code in the AutoPi Cloud interface and create a new module of type Execution.
• Define the Hook Function.
• Register the Hook by going to the relevant service's Hooks section (e.g., Services > obd_manager > Hooks) and register the new hook.

4. Integrate into workflow: edit the desired worker's workflow to include the custom hook in the appropriate step (e.g., as a filter or returner).

Hook Behavior

• Hooks receive the output from the previous step in the workflow and return a modified result.
• If a hook returns a falsy value (e.g., None, False), the workflow is halted at that point.
• Hooks are ideal for data validation, transformation, or conditional processing within the workflow.