CinnamonHAB
Description
As the technology progresses and microchips get tinier and tinier every year, in the last few years that has allowed for a rapid development of IoT. Almost every home appliance as well as industrial machine has become networked and, so to say, smartened up. Smart lights, smart climate control, smart TV, smart refrigerator etc… An example use would be heating up the house/apartment when returning home from work, or preparing hot water for the morning tea at a predetermined time.
This project, done at two sites, FER (Croatia) and MDH (Sweden), aims to connect two different systems, openHAB and Metric-FF, through an experimental implementation. The first system, OpenHAB, is a open source automation software for homes, which is vendor and technology agnostic. Through connection modules called bindings, openHAB can connect and communicate with smart devices from various vendors, which have a corresponding openHAB binding. OpenHAB utilizes its rule engine for which a user can define flexible logic rules, to issue commands to these connected devices. Metric-FF, our second system, comes from the family of Fast-Forward (FF) planning systems. The planning system is domain independent and implemented in C. What Metric-FF does, essentially, is that it generates a set of steps that need to be performed in order to reach a goal state from some initial state. This initial and goal states are specified in a so called problem file, while the domain in which domain objects, states and actions supported exist, is specified in the domain file. Metric-FF takes these two files as parameters and produces a resulting plan or a set of steps.
The intention behind combining the mentioned systems is to allow for much higher flexibility of the automation system. Using Metric-FF to generate plans instead of the user setting rules themselves allows for a better user experience, as well as an enhanced ease of use. Since Metric-FF can produce plans for any problem supported by the domain, if we have a robust enough domain, in theory, it is possible to support any kind of devices in any configuration without the user doing manual configurations or changing rules.
Features
- Managing devices - The system should allow the user to add, remove or configure devices, but it should also be smart enough so it can detect new or broken/missing devices automatically.
- Rules generation - Rules for controlling the devices should be generated automatically by MetricFF and fed into OpenHAB.
- Adaptability - The system should automatically adapt to the new situations such as turning off the heating when the user opens a window.
Technologies
- openHAB
- PDDL
- Python
- Ruby on Rails
- Javascript
- Vue.js
Architecture Overview
The whole system is composed out of 7 main modules as can be seen in the Figure underneath. Since there are a lot of modules, we will start describing the architecture from the bottom up. At the base of the system lies the openHAB runtime. This is the main engine of the system and its bindings are what enables the communication with smart devices. We can say that openHAB runtime is the systems interface with the external physical devices. As stated in the project plan, the main purpose of the project is connecting openHAB with the Metric-FF planning system. For this purpose we have developed a module we called middleware. Middleware communicates with the openHAB runtime through the REST APIs, receiving status of the devices, and sending openHAB commands to execute. These commands are extracted from the plan that is provided by the Metric-FF module. The whole process from receiving the status of the devices to returning commands to openHAB goes like following. When the middleware receives device statuses, it converts them into a textual PDDL problem file. Together with the prewritten domain file, it sends the problem file to Metric-FF via function call as a parameter. Metric-FF then calculates the steps and returns the plan to the middleware which converts the plan into openHAB commands. The commands are then sent to openHAB through its REST API. The modules mentioned so far, openHAB runtime, middleware and Metric-FF, form the internal part of the system, the one which users cannot see.
User can interact with our system via two modules. The first module is our CustomUI which offers the interface to control the devices. This module consists of a javascript front-end, and ruby on rails as the back-end API. Front-end displays the data provided by the rails API, and also sends user events down to it. The rails API serves here to pass the data to the UI and forward the UI actions to openHAB. Rails API also sends some information to the middleware to help it determine what is the goal state. The other module is our PDDL generator tool which we named LMA9001. LMA9001 consists of a front-end interface build in Vue.js and the back-end API which is ruby on rails like the CustomUI. User interacts with the front-end Vue app and can arrange different elements supported by the domain (from the domain file) and their relationships. This can then be pushed through the LMA9001 rails API to the openHAB and the middleware and essentially reconfigure the whole system without editing code or writing PDDL. This new layout of devices is will then be visible on the CustomUI.
