A different measure?

[ghost]

Measures are defined as numeric values. This is useful and works well for measures like "temperature", etc.

However, we may also see situations where devices return something other than a number - e.g. "bin_full: true", "status: needs_tuning", "room: free", "room: occupied" - I want to call these "higher order measures" because I can't think of anything better. The hardware sensor may have returned number (or lots) but the device has interpreted that to return a value.

Do you think this is a real possibility and if so how do we handle it?

[alanepaull]

I agree.

We could have an extensible taxonomy for measurement, using key/value pairs. Project Haystack has a good example, I think: https://project-haystack.org/tag

I've started a new file to give an example of how this might look: https://github.com/Cetis/intelligent-campus/blob/master/sensors/measurement_taxonomy.md

We wouldn't necessarily have to prescribe the scale, though I think standards here might help implementation.

[ghost]

Just been thinking about how we put the measurement API together and have:

Device -> Measurements
-> Aggregations

which then got me wondering about the third category (Room occupied) and wondered about adding "Observations" next to "Measurements" - and observations are fairly unstructured JSON:

Observation:
{
'from: ...,
'to': ...,
type: 'room occupancy',
result: 'occupied'
}

Just wanted to note that here so I don't forget it.

[alanepaull]

Let’s talk about this one :). I have drafted something to suggest that occupied/not is a measurement, not a separate entity.

…

-- Alan Paull [email protected]<mailto:[email protected]> On 24 Jun 2019, at 12:22, Peter Cliff <[email protected]<mailto:[email protected]>> wrote: Just been thinking about how we put the measurement API together and have: Device -> Measurements -> Aggregations which then got me wondering about the third category (Room occupied) and wondered about adding "Observations" next to "Measurements" - and observations are fairly unstructured JSON: Observation: { 'from: ..., 'to': ..., type: 'room occupancy', result: 'occupied' } Just wanted to note that here so I don't forget it. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#4?email_source=notifications&email_token=AEC5VJYFNVGDU3DGAPRC3D3P4CU5LA5CNFSM4HD2MGIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYMTI6A#issuecomment-504968312>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AEC5VJ4EY3EQVH3PVHCG76TP4CU5LANCNFSM4HD2MGIA>.

[alanepaull]

Following the measurement_taxonomy, this example:

"measurement": {
        "id": 129,
        "type": “occupied”,
        "value": “false”
	},
	"sensor": {
		"id": "15"
	}

shows a space that is not occupied.

Typically, this will have a context showing an ID (Room_id) for the space.

The context timestamp will show when the measurement was taken. In our appreciation of timestamp, this could be interpreted as a a pre-determined time range; for example, it might be the mid-point of a particular hour.

For Lone Rooftop: "Isempty: true" would convert to

        "type": “occupied”,
        "value": “false”

[ghost]

This sounds good. There will have to be a bit of work handling this kind of data in our API - e.g. currently you can request time series values for display on a chart as timestamp/value pairs and the value is a Float. Should be OK though - either convert to a Float on the way in/out or return some other type based on the measurement type/scale_name - scale_name of Boolean e.g.