spinarr commented 7 years ago

Proposal for standard devices is being created.

Standard Sensor

PNUM:0x50 (sensor) PCMD:0x00 (read) / 0x01 (read with types) HWPID:0xXX.XX (manufacturer+type) BITMAP:0xXX.XX.XX.XX

3 options to use BITMAP

Not present in dpa request (reading first sensor) Empty in dpa request 0x00.00.00.00 (enumeration ... return sensors types only) Mask is provided (only selected sensors are read)

Sensor types

0x01 Temperature 0x02 CO2 0x03 VOC 0x80 Humidity 0x81 Binary data

FRC Commands

0x90 1-byte value 0xE0 2-byte value

UserData[0] 0x50 (sensor) UserData[1] sxxi.iiii (sleep, reserved, index 0...31) UserData[2...4] same format as cmd_os_sleep

JSON structure

We have first JSON proposal here, but review is need. https://github.com/iqrfsdk/iot-starter-kit/tree/master/workshop/json-messages/4-dpa-std-dev

Roman3349 commented 7 years ago

@spinarr @fmikulu: Please add sensor type: atmospheric pressure.

fmikulu commented 7 years ago

We need a data base of:

sensor types, units, scaling, representation, ...
list of standard devices compatible with std-dev spec
the sensors mappings in the devices

To support human readable JsonDpaMessages and correct consistent parsing/encoding Json/DPA Lets call it the Repository a kind of DB. It is not important for now if represented by a configuration file, downloadable file, relational DB a HttpService, etc. It shall represent these structures:

Sensor types

Sensor	Id	Value Type	Min	Max	Units
thermometer	1	int8_t	-30	100	Celsius
co2	2	uint16_t	0	100000	ppm

...

Standard Devices

Device	HWPID	Manufacturer
DD-CSE	0x0101	Microrisc
PRT-01	0x0201	Protronix

...

Sensor Mapping (could be large - relation between the previous one)

HWPID	Sensor	DPA Flag Mapping
0x0101	1	0x01
0x0101	2	0x02
0x0201	1	0x11
0x0201	2	0x12

...

Then the messsages could be (just mandatory pars) shall be easy based on known structures above:

JsonDpaRequest:

{
    "ctype":"dpa",
    "type":"std-dev-sen",
    "nadr":"01",
    "cmd":"READ",
    "device":"PRT-01",
    "temperature":"",
    "co2":"",
}

JsonDpaResponse:

{
    "ctype":"dpa",
    "type":"std-dev-sen",
    "nadr":"01",
    "cmd":"READ",
    "device":"PRT-01",
    "temperature": "25.2 °C",
    "co2": "50000 ppm",
}

To be discussed:

values text with units or numbers with units separated?
how to return all sensors output?
method to return supported sensors?
FRC?

fmikulu commented 7 years ago

To @Roman3349 it is just proposal how to cope with it for now, but indeed barometer is important as well

fmikulu commented 7 years ago

Standard devices

Proposal of standard devices repository structure (as it would be implemented by SQL DB)

Sensor types

According the draft IQRFA-StandardSensor_V009.pdf it is not easy to prepare formal parametric description of general evaluation algorithm of measured data. It differs significantly for all described sensors up to now.

If we have an ambition to allow future online download of a new sensor, it seems unavoidable to download a shared library (driver) and install it during runtime (shall be possible in v2.0.0) - precompiled for supported platforms running the iqrf-daemon

It could be:

SensorName	SensorId	Driver
temperature	0x01	StdTemperature
CO2	0x02	StdCO2
VOC	0x03	StdVOC
Humidity	0x80	StdHumidity

...

An alternative would be to find out a general function (or two for signed and unsigned values) to describe the conversion from binary format to float, eq:

*_F = resolutionVal + offset_**

Then it could be (coding discussed bellow):

SensorName	SensorId	resolution	units	coding
temperature	0x01	0.0625	Celsius	normal
CO2	0x02	1	ppm	normal
VOC	0x03	1	ppm	normal
humidity	0x80	0.5	%	normal

...

However according the draft it differs even for return value and FRC-1,2B so there shall be more lines or more columns per sensor, e.g (just an example, numbers are not accurate according the draft):

SensorName	SensorId	resolution	offset	units	coding
temperature	0x01	0.0625	0	Celsius	ret
temperature	0x01	0.5	4	Celsius	frc1
temperature	0x01	0.0625	22	Celsius	frc2

...