Freedomotic is composed by a core (the framework) plus some plugins.
The core part is a framework that:
1. implements a language independent messaging system based on Enterprise Integration Pattern. So you can develop in your favorite language and just exchange messages with the other software components. The aim of the messaging system is to link all software modules together in a flexible and abstract way, relating them using the concept of channels (publish-subscribe to different levels of a topics hierarchy)
2. maintains an internal data structure representing the environment (topology, rooms connections as a graph, ...), the things in zones and their state (on, off, open, closed, 50% dimmed, ...)
3. creates an abstraction layer so users and external software modules can use a high level logic like
turn on kitchen light instead of
send to COM1 port the string #*A01AON##. This way a developer can leverage other plugins features at a high logical level because the
modules can see the same environment map as the user. All data component (environment, objects, triggers, commands) can be defined
in XML and easily exchanged on the network between different nodes of the P2P Freedomotic network
4. provides a rules engine coupled with a natural language processing system to let the user write automations in plain English like
is dark turn on living-room light. You can add, update and delete this automations at runtime using any human computer interface like GUIs,
or even speak them.
Freedomotic plugins can add more features to the framework and can be developed and distributed as completely independent packages on our marketplace.
They usually are developed to communicate with automation hardware like X10, KNX and so on, but also graphical frontends and “web service readers” are Freedomotic plugins just as any other source of info, like webcams, text to speech engines and SMS senders.
You can also develop object plugins which are pieces of software which models the behavior of objects like lamps, doors, etc... instructing the framework on how they behave.
For example a lamp object plugin tells the framework that a lamp has a boolean behavior called powered and a dimmer behavior which is represented by an integer from 0 to 100. A lamp can turn on, turn off and dimm. If dimmer = 0% the lamp powered behavior is set to false and if dimmer > 0% powered becomes true.
The final goal is to define an automation which can turn on the livingroom light when it’s tea time (17 o’Clock).
event.time.hour == 17 AND event.time.minute == 0.
#. At this point all the corresponding automation
IF (trigger: it's tea time) THEN (command: turn on livingroom light) is loaded by the system and the command is executed forwarding
the generic request
turn on livingroom light to the plugin which can transform it to a protocol dependent command (eg: send string
A01AON on serial port /dev/ttyUSB0).