SensorSDK Building Blocks
Web Server
| From the diagram you can tell that the user only interacts with OpenProximity web service, not with OpenSensors directly or your plugin it self, rather it reuses OpenProximity infrastructure. So for example if the user requests a chart OpenProximity asks OpenSensors for the chart page, and then OpenSensors finds all the available plugins, all the available sensors for each plugin and finally asks your plugin for which variables can be charted. This way you can not only store what ever you want into the database without making your system insecure, you also don't have to worry about the complex process of creating a chart.
Some plugins might have some special needs regarding administration, for example you might want to setup the sensor name, or set calibration parameters for your sensor, it's up to your plugin to define a django admin class and just add it to the OpenSensors admin. Alarms creations is also been handled by OpenSensors web server. Alarm dispatching is handled by OpenSensors RPC Client so you don't have to worry about it either. |
RPC Client
| The RPC side is a bit complex, but it's easy to understand by looking at the chart on the left.
We mainly have three large blocks one is remote device it self: Sensor, rpc clients: SensorSDK Client and Scanner Client. And the server side it self RPC Server with SensorSDK Plug-in, Sensors Plug-ins and the database it self. As you can see there's no direct link to the presentation layer (web site) other than through the Database itself, (except for a few control commands which are specific to OpenProximity). On each one of the Sensors we have BASIC code running, that includes SensorSDK BASIC Services and real sensor code (for example code that tells temperature from millivolts measured). SensorSDK BASIC Services is handling history storage, communication protocols, buttons, leds and screen handling for you. So your code only needs to know how to talk to your sensor The SensorSDK Client and the Scanner Client are outside the control of your code, and so out of the scope of this docs. Basically the idea is that the Remote Sensor will became visible when ever it has enough data to share, the Scanner Client will pick it up, and will inform the RPC Server for this event. The RPC Server based on certain rules (sensor campaign) will decide if it's time to do the synchronization of data, if it's so then it will inform the SensorSDK Client to connect to the Remote Sensor and exchange the history data, device parameters synchronization and BASIC code upgrades will be handled by SensorSDK Client too (pending feature as of February 2010). On the RPC Server is where most of the fun takes part. On this side we have the SensorSDK Plug-in which will handle the initial history parsing, battery reading and clock management for you, then your code will get the history lines along with the time when the reading was taken and it's your code responsible of parsing your history and storing it back to the database. |
