With our prototype we had a few goals:
- learn about the technologies that are involved in the IoT space
- Follow a good architectural principle
- get the attention (and trigger their curiosity) of visitors at different events
Of course there were also the functional requirements of being able to effectively know when a user is present or not, the management of different lamps & devices as well as the implementation of rules that determine what actions should be taken if certain events are triggered.
We have had many projects in the Java enterprise application space so naturally we looked at frameworks in this domain. Having worked with Spring MVC before, it seemed to suit our needs just fine. A good environment to deploy a well structured REST API and have services that can take care of logic and handling different situations. Also using Hibernate as an interface to a H2 database, we didn’t have to worry about our database model.
The frontend was supposed to be multi-platform and just while starting our project, the first alpha version of the ionic framework came out, a framework that is based on AngularJS, a very popular and powerful MVC JavaScript framework. Since this was all about learning new technologies, it got thrown in the mix.
Lets talk Hardware: A Raspberry Pi as well as a 433mhz sender module attached to its GPIO pins were needed as base. Of course some radio controlled power plugs to test the system were needed as well.
We used Java JNI to create the connection between the 433mhz module attached to the GPIO pins and our Spring application. This closes the gap from native C code to our platform independent Java application.
So this was a good place to start. However, due to other developments we had a few more things to look at: Camunda BPM to be integrated into Spring, managing the process of reacting to a user state change to show the capability of Camunda’s BPM framework and have this then running on a Pi. Also Oracle’s CEP was asked for, since they recently also got involved in the whole IoT trend and use it on their gateway devices to perform some logic before sending events to backends in the cloud. We were curious about this so we included this technology as well, although as a separate module, not within Spring. We needed a second raspberry pi for this, since two Java applications for one Pi is a bit much. This wasn’t too bad though, since it underlines the idea of IoT, being several devices talking to each other and creating an interesting application through interaction with each other. Lastly we decided to include Drools as well, to model our business rules in a unified way. We integrated drools in camunda to access the rules from our user state change process.
All of this together and the project architecture (maven modules) looks like this:
Now we have a system that can control lights based on users presence / absence (or rather their smartphones presence/absence, which in todays world correlates with the user in 99% of the cases)
To summarize this all I found a sketching I created in the beginning of the project rather fitting, so here it is:
A few important sidenotes:
- Where possible we use REST API’s. We like to think this is a potential common language many devices that are TCP/IP capable could speak. Anything lower-level would then be managed with a gateway between the lower-level protocols and TCP/IP.
- Through our Service layer we could integrate further technologies like zigbee controlled devices etc. and publish them through one uniform rest service
- The parts are modular and could be replaced by some other technology (e.g. native iOS or Android app that integrated the user login/logoff through a geo fencing logic)
To keep on reading check the other posts about our prototype:
1 Kommentar
Pingback: IoT prototype – low-level thoughts about camunda BPM and Drools Expert (part 6) | The Cattle Crew