ACAEngine is a platform for creating digital experiences for physical environments. It connects devices, hardware systems and thir-party software to provide an API for the built environment.

ACA Engine

What is ACAEngine

Software only built on the modern web
Open source continuously improved and backed by a full-time team of developers
Extensible able to run stand-alone, or intergrated into staff, build or third party apps
Vendor agnostic designed to bridge multiple disparate systems
Scale-able from rooms, to buildings, to precincts
Distributed multi-node replication for live backup and fail-over
Secure audit-able interaction with the physical environment and encrypted devices communication
Insightful provides analytics for physical systems

Focusing on devices logic more than low level device communication and connection.

Intergrating tens of thousands of devices and services into unique experiences.

Key Concepts

1. Drivers

Communcication with external system, device and service drivers
coordinate actions across modules and build complex behaviours (logic drivers)
All drives must be instantiated as modules before they can be used

2. Modules

Modules are instances of drivers. These represent a device to be controlled, service integration or piece of logic that controls how a system should behave.

Modules were referred to as ‘Devices’ in older versions of ACAEngine.

State - status info about the device, service or high level logic (e.g. power status)
Behavior - actions whichh they can execute

Once a module is started, ACAEngine will attempt to connect to the associated physical device or service and keep track of its status.
It will disconnect from that device and stop send commands if it is stopped.

Modules must be associated with at least one system. Same instance can be shared across everywhere it is needed.

3. Systems

System is a collection of modules, setting and basic metadata. They provide the main logical building blocks within ACAEngine deployments.
ACAEngine Systems

Systems often represent physical spaces but can also represent standalone items (e.g. digital signage endpoint) or non-physical system with information based inputs and outputs.

4. Zones

Zones are collections of systems. A system can be tagged as a member of any number of zones.

ACAEngine Zones

Logical groupings of systems with common traits (such as those in the same building, or of the same basic type)
A point to define settings that compose across systems

5. Settings

Settings are the configuration info that define how an ACAEngine deployment should behave. They are ultimately ingested and used by modules, but can be defined against zones, system, driver or modules and compose to create an overall system configuration that can be managed at scale.


{
  "key": "value",
  "foo": [1, 2, 3],
  "bar": true 
  "baz": { 
    "qux": 1.234
  }
}

JSON is a common, simple data-interchange format that is designed to be easy for humans to read and write, and for machines to parse and generate. If it is a new concept, you can learn more here.

The naming and expected values are defined within drivers and will vary based on the integrations in use within each deployment

Settings lookup

To simplify large deployments, standardise systems and reduce management overhead, settings are designed to be defined at different layers which then combine to produce the final configuration.

Settings defined on a zone are inherited by all systems in that zone.

Similarly, settings defined on a driver are inherited by all modules created from it.

ACAEngine Settings

When settings are inherited from a zone or driver they will be aggregated with any settings defined directly on a system or module. If an inherited setting has the same key as one that is defined specifically for that system/module, the latter will override the inherited attribute. This allows a general config to be applied at the highest ‘shared’ point of a system, with more specific configuration applied on a system or individual module basis.

6. Interfaces

Interfaces are web pages or native apps that provide users with a direct method of interaction with an ACAEgnine instance. Common examples of these are a staff app, control UI, booking system or other experiences that lend themselves to screen-based interaction

7. Triggers

Triggers provide the abiity to dynamically link state and behaviour across different modules. They are used to define actions that fire based on a certain system state, time, or external input from a webhook.

Using backoffice it’s possible to create, assign and manage triggers to build event driven behaviour that accompanies core system logic.

Ref

ACAEngine: https://docs.acaengine.com/