Sensors for continuously changing real valued properties

[draggett]

trafficstars

Sensors may measure continuously changing real valued properties where the sensor readings represent piece-wise approximations to the value being measured. The data points could involve time domain or frequency domain approximations where each data point conveys several parameters. The data points could be at a fixed interval, or at irregular intervals where each data point is associated with a timestamp. Piece-wise approximations enable a reduction in the number of data points required to adequately represent the measured property. The generic sensor API spec should identify this design pattern and provide guidance.

[tobie]

So I'm not sure I understand this properly. Let me got through your comment line by line:

Sensors may measure continuously changing real valued properties where the sensor readings represent piece-wise approximations to the value being measured.

So data is either discreet or continuous. If it's discreet, the API consumer wants to listen to onchange events, if it's continuous, to ondata events (maybe those should be called onpolled). This distinction isn't properly made in the spec at the moment and this is definitely something I need to work on. From the perspective of the API consumer, a remote sensor that would do some transformations to turn continuous data into discreet data would appear as the latter.

The data points could involve time domain or frequency domain approximations where each data point conveys several parameters.

I'm not sure about what the first part of this means. Are you suggesting a sensor reading could combine multiple readings of the same sensor? So that's also one of the areas that need more work, as there are clearly requirements for this.

Else are you suggesting that a single reading could include data point from multiple sensors? That's sort of the case, for example a barometer reading could include the output of the temperature sensor it most certainly contains as well as the derived pressure.

The data points could be at a fixed interval, or at irregular intervals where each data point is associated with a timestamp.

So that seems taken care of already.

Piece-wise approximations enable a reduction in the number of data points required to adequately represent the measured property.

Yes, but that is not really something the API consumers need to worry about, is it?

The generic sensor API spec should identify this design pattern and provide guidance.

So I'm not sure what you mean by this other than the points I've noted above (clear way to specify multiple readings in one event, distinction between pushed and polled data, and ability to have complex sensors with multiple properties).

[zolkis]

I think what Dave may have meant here is to provide a mechanism

• by which clients could tell the transformation algorithm and its parameters to be applied at source to the data before being exposed, and
• for attaching metadata,

so that less data is actually transferred, and by knowing the algorithm and the metadata, much of the missing data could be reconstructed on the client side. Basically, codec stuff. Also relates to negotiation mechanisms, see here.

Problems with this is unlikely support from the sensors (unless they are expensive, with a lot of computing power to serve different clients needs). Also, we need to be explicit about use cases (because the "codec"s involved).

What we could do now is to find real-world use cases, and be forward-compatible with eventual changes like the above would take.

[tobie]

Thanks for your comment, @zolkis, this helps clarify.

I agree with your assessment that this needs use cases.