What makes CSTBox different and attractive.
The CSTBox framework allows using at the same time various devices, including sensors, actuators, user interaction devices,… provided by different makers and using different communication protocols.
This make possible to assemble a configuration taking advantage of the most suited components, whatever they are.
In addition, information collected from sensors or sent to actuators is defined using a neutral model, fully decoupled from the involved hardware. It is thus possible to swap a given device by a functionally equivalent one without changing anything to the rest of the application. Such a feature is based on the concept of drivers, which role is to translate proprietary communications to and from neutral ones. Supporting a new kind of device is just a matter of developing a component implementing the services of a driver and adding it to the application.
An application is the assembly of a collection of building blocks, called software components or more simply components.
Among them, we can mention :
One key advantage of such an architecture is to allow subdividing complex functionalities into simple building blocks, easier to develop and maintain, since handling a limited set of concerns.
Another advantage of such a strong decomposition is allowing to swap an implementation of a given feature by another one, more efficient for instance, by just replacing a component by another one implementing the same services.
Since an application is just an assembly of components, it is easy to extend its features by adding the appropriate ones.
Even better, one can imaging deploying the full set of components, covering the maximum extent of the application features, but just activating some of them based on configuration settings. This makes then possible to activate (or deactivate) features on the field, without having to modify installed softwares.
Unlike many frameworks, you are not tied to a given programming language. Just use the one which is more suited to your needs and/or your taste.
The previous version of our framework was based on OSGi, and thus was 100% Java written. All in all, this worked quite well and we have had no special grief, but we finally draw a couple of conclusions which were pointing some flaws with this orientation.
This made us leave the OSGi world, looking for other solutions for inter-process message communication and remote procedure call.
Such a solution exists, and the expected features are provided out of the box by D-Bus which is present in many Linux distributions, including embedded ones.
D-Bus provides services for messages broadcasting and listening, but also for inter-process method calling. One of its major advantages is that it provides this in a programming language agnostic and neutral way, bindings being available for the vast majority of languages (C, Java, Python,…) Thanks to this, a Java component will be able to call services provided by a component written in Python, the involved D-Bus bindings taking care of marshaling and un-marshaling in a transparent way.
The newest version of CSTBox has thus been rewritten to take advantage of D-Bus and split its services as a collection of distinct independant processes. The core part and some common extensions have been written in Python, for taking advantage of its dynamic nature (we were forced to use quite convoluted implementations in the Java version for achieving the needed behaviours) and its power of expression.
We could check the validity of the approach by writing an extension in Java, based on a Java closed source library provided by one our our partners, and a couple of other ones in C/C++ for validating the architecture. During a transitional period, we had even connected the new version of the framework with a OSGi based sub-system, by writing a bundle featuring a gateway between the OSGi message bus and D-Bus.
In addition of a greater level of freedom, we could also notice a benefit in terms of system resources usage. The Python based version of the framework is far less demanding in memory than the OSGi one, and its starting time is several times shorter.
Beside making it possible to implement various parts of an application with the programming language of your choice, we do not enforce you to conform intrusive APIs.
We have followed the Unix philosophy : all is files. This is applied by making all manipulated data (configuration data, stored events, …) using simple, open and documented formats (tabulated text files, JSON,…).
We take for granted that software developers are adults and responsible people, having all the skills and knowledges needed to interact with the other parts of the environment without having to force them to go through contrived and over-designed layers of code.
This is true for stored data, be they persistent of just for the lifespan of a run, but also for messages exchanged between components.
Openness and flexibility requires an abstraction of the data and messages exchanged between the components making an application.
For not be tainted by the specificities of participating components, be they at system or at application level, data exchanges must take place at an abstracted level.
This means that while other systems are built around the concept of sensors and actuators, thus making intricacies such as addresses and alike surface up to the application layer, we have chosen to follow a different track.
In practical, this translates into the fact that what circulates on the message bus to notify that the temperature of the bedroom is 21°C is not a message conveying the identifier or address of the sensor which produced the information, but a message telling that the variable bedroom_temperature, which is of type temperature has presently the value of 21 using the units degC. This way, if ever the sensor is broken and must be replaced by a brand new one using a different address, the message will still be the same and nobody else will ever notice the change. This is still true even if the new equipment is from a different manufacturer, uses a different protocol or communication support, or whatever else.
We are not the only ones to do this, but all the other solutions we have analyzed use the home automation paradigm for abstracting the physical resources. So what about applications having nothing to do with home automation ?
We have stepped up one level in abstraction, and consider that an environment which is equipped with such devices is an instrumented system, which is observed and controlled by the mean of state and control variables, these variables not being inevitably tied to physical or concrete concepts.
For instance, the outside temperature can be provided by an online weather service at a time, and be replaced by an outdoor sensor some time later without any effect on the consumers of the data. Same if it is provided by a physics simulation program.
Maybe you could here again argue that the other frameworks we mentioned can do the same. This is true to some extent. But consider now an application dealing with behaviors and activities recognition, based on physical sensors inputs correlation. Such a processing should be packaged in a dedicated component, running on its own by listening to notification events pertaining to its concern, and producing in turn special events notifying the start and the end of the activities to be monitored. This is nothing less than a human behavior detector. How do you map such a sensor in available home automation oriented frameworks without using some trick to conform the paradigm imposed there ?
Of course, the principle applies the other way around for controls and commands of actuators. In this context, the message which will be used will contain the new value of the control variable, which reflects for instance the state of a power switch, the level of a dimmer,…
An interesting benefit of dealing with abstracted data instead of specialized commands here is the fact that several different command producers, be they physical devices or other software components of the application, can emit the same control message, without the controlled equipment making the difference if it does not care about the originator.
The CSTBox framework provides out of the box a collection of components implementing the frequently needed services.
The current catalog contains :