Sensors

The term Sensor means to "go out and get information, or a conduit through which information is received".

Sensors in HTM.java are "Network reception or retrieval objects". They come in 4 flavors; only 3 of which are of any concern to a user, the fourth (HTMSensor) is a wrapper around the other three - which is HTM Network aware. These are:

• FileSensor - Attaches to a file source specified by a path, and reads in CSV data, line by line.
• URISensor - Connects to a URL, and reads in CSV data line by line.
• ObservableSensor - Created by passing in a Publisher which can be programmatically fed CSV data, line by line.

Sensors are general data retrieval mechanisms and could potentially be used outside of the NAPI framework. A Decorator-Pattern is used with them to wrap them in an HTMSensor which grants it HTM Network awareness and transforms the Stream into an HTM specific source of data (i.e. The Header retrievable from the HTMSensor must be 3 lines long to support HTM Network specific headers).

---

Sensor Creation

Here is an example of Sensor creation for all 3 types:

// ---  File
Sensor.create(FileSensor::create, SensorParams.create(
                Keys::path, "", ResourceLocator.path("rec-center-hourly.csv")))

// --- URL
Sensor.create(URISensor::create, SensorParams.create(
                Keys::uri, "", "http://www.metaware.us/nupic/rec-center-hourly.csv"))

// --- Manual / Programmatic
Publisher manual = Publisher.builder()
    .addHeader("timestamp,consumption")
    .addHeader("datetime,float")
    .addHeader("T,B") //see SensorFlags.java for more info
    .build();

Sensor.create(ObservableSensor::create, SensorParams.create(
                Keys::obs, "", manual))

// From there, for "manual" input call something like: 
// (When the Sensor has been added to a Network, of course)

manual.onNext("7/2/10 0:00,21.2");
manual.onNext("7/2/10 1:00,34.0");
manual.onNext("7/2/10 2:00,40.4");
manual.onNext("7/2/10 3:00,123.4");

For more info on programmatic manual entry see ObservableTest

---

Method References...

Here we will go into more of the gritty details underlying the Sensor architecture.

Ok so what kind of magic incantation is this!?!?

Sensor.create(URISensor::create, SensorParams.create(
                Keys::uri, "", "http://www.metaware.us/nupic/rec-center-hourly.csv"))

It's not so bad, trust me... :-)

The create() method of Sensor, has the following signature:

Sensor<URI> sensor = Sensor.create(SensorFactory factory, SensorParams params);

The first parameter (SensorFactory) is a Functional Interface (Meaning that it is an interface with exactly one abstract method) Inside of which (inside Sensor.create()), factory.create(params); is called. This means we can "substitute" a specific type (URISensor) which has the create(params) method and returns a specific type. This results in the factory method of URISensor (URISensor.create()) being called which returns a Sensor of type Sensor.

This magical incantation allows us to keep the Sensor creation code very concise while still allowing minimal code to create and return specific types of Sensors!

The other half of the Sensor.create() formal parameters is the SensorParams parameter. This class has a static create method also:

SensorParams.create(Supplier<Keys.Args> keySet, Object... values)

SensorParams inherits from NamedTuple which takes an array of String keys and an array of Object values as its construction parameters. Here, we use the functional interface Supplier which contains one method (get()) that takes no arguments and returns an object (Keys.Args).

Keys.Args is class which returns an array of keys for the type indicated. This means Keys.obs() (or Keys::obs) returns an array of String keys used for retrieving ObservableSensor params from a NamedTuple. Likewise, Keys.path() (or Keys::path) returns keys for a FileSensor, and Keys.uri() (or Keys::uri) returns keys used to retrieve URI information of a URISensor. see the Args enum in the SensorParams java file.