Posted by: BenLR | August 7, 2013

HiveSense Flexibility

The latest update to the HiveSense Project implements a new flexible system for sensors and alarms.

System architecture reminder

  • Hardware – Gadgeteer device polling a number of sensors (situated in an simulated beehive) and pushing their data to the web.
  • Back-end – Node.js server hosted on Windows Azure exposing a data API for easy storage and retrieval of the Gadgeteer data.
  • Front-end (GUI) – Web-based application written in Javascript, serving to showcase live and historical data from the API with graphs, tables and alarms.

Flexibility

With the expected growth in off-the-shelf Gadgeteer sensors, and the need for more sensors to improve HiveSense (e.g. mass sensor for honey measurement), flexible front and back ends are clearly important. The front and back-end already have a good degree of independence thanks to the implementation of the RESTful API, but until now there was excessive dependence of both on the Hardware – in particular they were quite tied to the precise sensors being used. Now, independence has been achieved by re-writing the data model used to store data points in the Azure database. In fact, the API will happily receive any arbitrary data from a named sensor and store it. Similarly, the front-end is, in part, dynamically built from a settings file specifying which sensors to show, and what alarms to use, so it doesn’t rely on what the back-end is saving (it is free to ignore some sensors, for example).

Testing the flexible design

Semi-random values for a virtual mass sensor (a real sensor was attempted but failed due to unknown electrical problems) are now being thrown at the API by the Hardware. By adding a few short lines to a JSON settings file, the GUI has responded and is displaying this sensor along with graphs and custom alarms.

GUI-based modification

To showcase the new flexibility in a very user-friendly way, I have added the ability for anyone to add/delete/modify alarms through the GUI itself. Have a go (navigate to the settings tab and play around). Sensors could also be modified this way, but time is running short (they can still be modified very simply by anyone with basic JSON knowledge).

Other Changes

  • Server-based sending of emails to the beekeeper when alarm thresholds are breached
  • Historical data tables using the new HiveSense History API
  • Fully-documented the API.

Remaining Tasks

Full documentation is being developed to make the project remotely comprehensible. Some proper software testing needs to be done too, along with a good deal of code refactoring.  All these will be worked on in the remaining three weeks.

GUI Picture Dump

The live site is best for viewing this, but cannot be relied on so I submit these for security and convenience.

Alarms can be added, deleted and modified. Changes take place immediately.

Alarms can be added, deleted and modified. Changes take place immediately for easy previewing, and can be committed to the server by the beekeeper (admin).

Historical tables - can also be exported to CSV for easy manipulation.

Historical tables – can also be exported to CSV for easy manipulation.

API docs. Useful for easiy development of the front-end, and for giving access to the data to external sources (sharing with others for aggregation of data from multiple hives, for example).

API docs. Useful for easiy development of the front-end, and for giving access to the data to external sources (sharing with others for aggregation of data from multiple hives, for example).

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: