Farm sensor API

What if we just set up something relatively simple, and then provided hooks for other modules to use?

Here's what I'm thinking:

New module: Farm Sensor - provides a new asset type called "Sensor". Sensors can be assigned to any asset in the system (including Areas (once this is done: #2363393: Make "Area" into a type of Farm Asset), Compost Piles (#2393103: Compost module), etc (even Sensors can have Sensors!)

Sensors are each assigned a specific "type". The available types should come from other modules, via a new hook_farm_sensor_type().

Each type should also define sensor-specific settings that are needed for that type. For example: the URL of the sensor's data feed, or other stuff that is specific to the actual sensor you're setting up.

So, for example, you could write a Fido module that implements the hook like this:

/**
 * Implements hook_farm_sensor_type().
 */
function fido_farm_sensor_type() {
  $types = array(
    'fido' => array(
      'label' => t('Fido'),
      'settings' => array(
        // ...
      ),
    ),
  );
  return $types;
}

To start, the Farm Sensor module could ask other modules for a simple "Summary" output of the sensor - this could be "Latest Temperature", or it could be something more complicated. There could also be a way to link to a more detailed display of the data, either within Drupal, or offsite (within the sensor's web UI itself, if it provides one).

With an approach like this, we don't have to figure out how to store sensor data within Drupal - just how to communicate in a standardized way with remote sensors or devices. It does assume that the sensor/device itself will have some way to communicate... which isn't a problem for Fido or Atmospi. So maybe those should be the first ones we add support for.

I guess I assumed most sensor devices stored their own data on the device - I don't have any experience though, other than the Atmospi software I wrote for my Pi temperature and humidity sensors. Those are sort of self-contained servers+sensors, which store data in a simple SQLite3 database and serve it via a web UI and JSON. Fido is similar, right? But with couchDB?

So, with your points in mind, I guess we shouldn't assume that most devices store data. And maybe creating a simple data storage mechanism makes sense.

I guess we can divide sensor devices into two camps: those that are only concerned with the present moment (don't store logs of data), and those that keep a log. There's no reason we NEED to enforce keeping a log for devices that don't do that already. We can start with just a simple Farm Sensor API module that allows the CURRENT reading of those devices be displayed in the farmOS UI. It doesn't need to store data or show graphs or anything... yet.

Then, after that, we could create a secondary module that provides some basic mechanisms for storing and graphing data... on behalf of devices that don't do that themselves. But I think that should be an add-on, and we shouldn't assume that all devices will use it. For example, I would like to be able to query my Atmospis for historic data from farmOS, but still leave all the data storage up to them. I'm not married to that idea, though, so I could be swayed. :-)

Just read through your #8 comment... cool, I'll take a look at Phant. It sounds like that's basically what we want to be able to do. I need to wrap my head around the concept of sensor "streams" though... not sure I get that yet. We should do a Hangout sometime and just talk about farmOS Sensors! :-)

RJ, Dogi, and I had the chance to discuss a lot of these things at iFARM in New Hampshire this past weekend.

I put together two proof-of-concept modules for it: farm_sensor and farm_sensor_atmospi. I'll be pushing those up to public repos soon...

http://drupal.org/project/farm_sensor
http://github.com/mstenta/farm_sensor_atmospi

I'm going to close this discussion thread, and move it to the Farm Sensor project. I started creating more specific feature requests in that module's queue, so let's continue discussion in those (and create more as needed).

Data storage: #2493225: Data storage
REST API: #2493227: REST API for pushing data
Graph sensor data: #2493511: Graph sensor data

Remember to subscribe to those issues (or the whole project) so that you're notified when people comment!

Also, Bruce: wanted to point you to this new one... #2497223: Farm Sensor: Alert

My friend Dylan also mentioned integrating actuators... and how it would allow Drupal to finally become self-aware. :-)

Moving old issues to the canonical farmOS project for easier searching. Apologies for email spam if anyone is following these. :-)