RE: web intents version of sensor api

I added some edits marked as [bryan], for some of the current draft features that were not included in your proposal. I renamed Threshold as TriggerPoint per your suggestion.

I think the point is clear, that these Intents will be very similar across sensor types. I think that is only natural, as most of these sensors will return a single value within the applicable range, and the two main options proposed so far (report interval and threshold) are essentially the same for all sensors (with the threshold values of course being per the relevant range).

Perhaps we could define an “Intent class” which is specified in a single spec, with specific instances varying only in the type of sensor and range of values expected (and if needed, the privacy considerations)?

Thanks,
Bryan Sullivan

From: Carr, Wayne [mailto:wayne.carr@intel.com]
Sent: Saturday, March 24, 2012 9:36 AM
To: public-device-apis@w3.org
Subject: web intents version of sensor api

Before dropping the sensor API I think it would be useful to consider what a sensor API spec would look like if changed to using WebIntents.  Does the WG really want 7 different drafts for these sensor types that would all be virtually identical?

This is very informally sketched out just to show the general idea.  It seems very straightforward using webintents, but something does have to specify what the formats are.


Definitions:
* GetSensorData – one shot request to get a value.
* WatchSendorData – sets up stream of data from sensor.  Can ask for data only when trigger points are crossed or instead periodic reports but no more frequently than some interval.


**** fields for the webintents constructor for the request ****

Actions (one of these):
http://www.webintents.org/GetSensorData

http://www.webintents.org/WatchSensorData


Or “w3.org” instead of “webintents.org”

type (one of these):
http://w3.org/sensors/AmbientTemperature/

http://w3.org/sensors/AtmPressure/

http://w3.org/sensors/RelHumidity/

http://w3.org/sensors/AmbientLight/

http://w3.org/sensors/AmbientNoise/

http://w3.org/sensors/DevProximity/

http://w3.org/sensors/DevMagneticField/


function is passed for OnSuccess return data

For http://www.webintents.org/WatchSensorData only,
a message channel port is passed to the service in the intent request.
In extraData the following can be passed [optional]
ReportInterval= string containing a double value – requests service to send sensor data no more frequently than every ReportIntervalmilliseconds
[bryan] TriggerPoint = string containing a double value - applicable to sensors that provide single value readings, it indicates that sensor data must only be sent when the sensor value crosses the specified threshold (in either direction). [/bryan]


**** response from service to client ****

For http://www.webintents.org/GetSensorData” response from server is sent to OnSuccess function passed when making the intents request.
For http://www.webintents.org/WatchSensorData response is sent to the port passed to the server

Returned Information in “data” object from sensor sent in either the OnSuccess function for a GetSensorData action or to the port for GetWatchData
Fields in data object
* action (one of the above or new ones from future specs)
* type (one of the above or new ones from future specs)
[bryan] * accuracy – enumerated value in “high, medium, low, unreliable” (as defined in current sensor draft)
* timestamp - The time in nanoseconds at which the sensor data was read [/bryan]
* double minInRange – minimum value in sensor range
* double maxInRange – maximum value in sensor range
* string name – if the sensor has some friendly name for the sensor
* value -- array in the following units of measure (typically only the first value in array is set, but array in case future devices have more than one Proximity Sensor for instance)
http://w3.org/sensors/AmbientTemperature/  double centigrade
http://w3.org/sensors/AtmPressure/  double kiloPascal
http://w3.org/sensors/RelHumidity/  double percent
http://w3.org/sensors/AmbientLight/ double Lux
http://w3.org/sensors/AmbientNoise/ double dbA
http://w3.org/sensors/DevProximity/ double centimeter
http://w3.org/sensors/DevMagneticField/ objects containing double x,y,z in micro-Tesla

**** control messages on port to service ****

Client can send service a sensorControl object using the port – format of object sent is as follows:
* type (one of the above or new ones from future specs)
* command – one of the following
      setTriggerPoint value --- where value is a single double for the sensors that return a single value and a comma separate list of doubles for DevMagneticField – can send this repeatedly for different triggers
      removeTriggerPoint value --- same as what was set
      setReportInterval --- double seconds to indicate reports should not be sent more frequently than this
      stopWatchpoint – going to be closing the port

Service responds by sending a data object echoing the same but ending with result= string “success” or “fail”