"Cloudy" Sensors

[christophe-dupriez]

For "ELSA as a Service", sensor data will have to be uploaded with very simple transactions possible for a (radio)modules with sensors connected. A "VPN" should ensure data protection and privacy. Another possibility could be "https" support. A very simple API should be defined to upload "sensor id./value/timestamp" records. Granularity of uploads could vary as ELSA sensors may make some parsing and calculation on values. Timestamp, if coming from abroad, needs some kind of synchronization. Other set-points or configuration may also need to be addressed...

[christophe-dupriez]

ELSA will receive transactions "as is" from LoRa Radio Network. For one module at a given moment, they provide key/value pairs. Keys are a single letter (between A and I) followed by zero, one (or more) digits. M (for module) is added by the radio gateway, with the module ID as a value. This is supported by obliging the corresponding sensors definition to use the accronym "Mx_Cy" where x is the module ID, C is the sensor type (A=analog port, B=Battery voltage, D=1Wire data, , C=temperature, G=a badge ID just read, H=timestamp, I=I2C data, please look here for detais) and "y" is an optional rank (a I2C or 1Wire address in some cases). Each sensor of each module may and must be defined to be stored and managed by ELSA. We will improve this quick and easy "fix" in ELSA by adding a "Node" object to define the characteristics of each modules, gateways and servers participating in an ELSA based system.

[christophe-dupriez]

We need to implement now the support for G=badge ID to signal focus on a place / equipment / container / batch / user. An user badge is a context to identify the responsible of subsequent badging. If the radio module is associated to a Place, an equipment / container / batch badge signals its move within that Place (Transfer). This is needed for May 30th 2019.