Sensor Board Data nodes may come in as many different formats. We've already gone through 3 iterations for Cloacina. Up to this point we had one parsing function that detects the string format and parses accordingly. To avoid hacking the Sensor Hub code to allow for additional string formats we should allow separate modules to declare their own parsing functions. We could follow a similar architecture to Views plugins where hook_views_plugins() allows modules to declare plugins with associated meta data.

function somemodule_shub_plugins() {
  $plugins = array();
  $plugins[] = array(
    "parser" => array(
      "somemodule_custom_format" => array(
        "title" => "Some Module's custom format",
        "handler" => "somemodule_parse_custom_format"
      );
    );
  );
  return $plugins;
}

The example above adds a parsing plugin with associated callback to perform the parsing.

A logical place to select which parsing function to use would be on the Sensor Board node edit page where all of the registered Sensor Board parsing plugins would be displayed in a select box.

Comments

R.J. Steinert’s picture

R.J. Steinert commented

It's possible that we can take advantage of the plugin architecture already set up in the Feeds module. The following are my ideas on the how this can be accomplished.

# Feeds plugins

## Fetcher

Can optionally check for Sensor Board Data nodes that do not have a Sensor Board related to them yet. Then select all Sensor Board Data nodes given a specific Sensor Board ID.

## Parser

Parsers should be swappable depending on the Sensor Board. Different hardware will send strings with different formats that need to be parsed accordingly.

## Processor

The Processor will save all entries in the returned array to Sensor Readings. We can use the already created Node processor and just save the settings and mappings in code using Features. This is dependent on being able to map CCK node reference fields though which the current BETA cannot do. For d6 see -> #724536: Mapper for nodereference field in Drupal 6 and for d7 -> #988856: Feeds mapper for node_reference and user_reference fields

# Additional UI on the Sensor Board nodes

## Edit page

The most important part of this being the end user has the ability to pick the parser on the sensor board edit page. How the Job Scheduler module that Feeds uses will require some more investigation (ie. Do we keep the current 'Process on cron' field?

## View page
They must be able to launch the parsing from the sensor board view page.

# A note on the importance of Sensor Board independence

Sensor Board Data nodes must *always have their node reference field to Sensor Board filled out before Fetcher, Parser, or Processor is run. The reason for this is so that in each Sensor Hub installation we can have separate settings for each Sensor Board. Some will be active with Cron enabled, some will be inactive with Cron disabled, and for some Sensor Boards they will still be collecting Sensor Board Data nodes but only need to be parsed into Sensor Readings when told to do so manually. This is about giving the end user control over when the data is parsed ensuring the system is not moving without them triggered by a cron job they may or may not have control of.

R.J. Steinert’s picture

R.J. Steinert commented

A new Feature request #1050642: Feed Importer (definition) as Node, Fetcher plugin: Fetcher Selector, Parser plugin: Parser Selector, etc.

R.J. Steinert’s picture

R.J. Steinert commented
Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.