As written in previous release mail, we mainly focus our efforts on a new architecture for core-server. This is now time for us to present you concept of this new arch, why it will benefic for you and for us, and what it will change in your next upgrade.
Concept
1. Observation
Starting point of OpenplacOS project is that most of home automation systems are tweaked or realised DIY. To control these systems, we need flexibility in software control to adapt it to the system.Flexibility, extensivity are easy to say but hard to implement, deploy and maintain. We had many endless discussions about what control to give to user and considerations like that. What about externalize regulations ? Yes ? No? What about externalize constraint ? And so on …
This would take many time for us to discuss and implement each feature one-by-one, discussing of its benefits, implementing it, and debugging it.
To me, these kind of discussions took us too much time and we have many features there is left to do.
2. Back to basics
At light of theses observations, we wonder about the purpose of the project: The software architecture purpose is to give ability to built easily the system you want/need. The server has to be easily extensible. That’s the reason why we relied all plugins, drivers, sensors on dbus.Since the beginning of the project, we started on a multitier architecture to cover this need. However, features introduced in components were too restricted to what we autorized. The purpose of have a multitier arch is to have flexibilty and we too constraint it about there purposes.
That’s why we decided to agnosticly assemble plugins, drivers, objects in something generic called components, whatever theirs functionnalities. These components are assembled by matching their interface, and we only check that interfaces are compatible together.
This is the basics of a multitiers architecture. For those who knows, MVC frameworks are a particulier multitier: it’s a 3tiers architecture for webserver. We choose to be a N-tiers server, N configured by user and could be infinite :-)
3. Implementation
Here is a basic case of a component, let say it’s a component that converts an analog value to a celsius temperature. All components are introspect (to know dependencies) and launched by server. Server exposes pin connection though d-bus. Component will connect to theses pins for its inputs and outputs as shown below:
On these schema, if component is a temperature sensor, you will read an analog value (a voltage for example) on backend side, to have a graduable value in celcuis on frontend side.
Server will reproduce this scheme for all of its components downto the final one.. The final one will only have Pin frontend to expose since it’s a leaf.
Each pin is a particular interface (dbus talking) and support only 2 methods: read/write. Programmable interrupts will also be supported asap by adding a signal and methods to program it.
Let start with an example: An Arduino board with 1 temperature sensor, 1 heater and 1 regulation. This will result into 4 components. Please see picture below