search

Cetis / intelligent-campus

6 stars 0 forks source link

Pare Down Sensor? #3

Closed ghost closed 5 years ago

ghost commented 5 years ago

Talking with Michael he said the Sensor event should be limited to what the sensor itself knows - in the case of the Safehouse one that is its device ID, perhaps the sensor ID and the measure values. In other sensors you may get a lat/long if the sensor or device contains GPS or other way of knowing its location but nothing else.

Given that we think it best to pare down the sensor event. This mostly means stripping out fields from the context - event_frequency, location, location.room_id, etc. These fields are valuable so it might be they are relocated to the Device class in UDD?

The connection between sensor and device is made through deviceEUI.

alanepaull commented 5 years ago

Many of the properties in the current model are optional. This is on the basis that we might get this data from some sensors, or from systems providing the data (like BACNET).

Current minimum data for the Sensor Entity is: sensor.id

There would also be a Measurement Entity containing the measurement data. Minimum is: measurement.id measurement.value

Current context mandatory items are: context.id (in Safehouse, this is derived from Safehouse data as provided in the Jisc examples) context.location - I presumed this would be mandatory, as otherwise we don't know what the sensor reading refers to; though it might be inferred from the sensor.id. context.timestamp

I think the only critical changes here might be making context.id and context.location optional?

I suspect that we need a diagram for this, so I'll make one.

ghost commented 5 years ago

"I think the only critical changes here might be making context.id and context.location optional?"

I think optional would cover it yes. I discussed this with Michael and argued that storing the location against the event produces a significant amount of redundant data. If we have the deviceEUI and can link that back to Device in UDD then we only need to store the location once.

I just realised that there may be sensors on moving things though so optional is beter than removed.

scottbw commented 5 years ago

We may have cases where services are reporting sensor events to us but nothing about the devices themselves. For example, Lone Rooftop will give us estimates of occupancy level by room or site, but won't tell us where the devices actually are (which wouldn't help anyway, as its a triangulation from devices all over the place). Likewise most BMS sensors will report a measure against a room or building, but not their own location. So I'm not sure we want to be building a database of devices in the UDD.

scottbw commented 5 years ago

That also gives us an example where we obtain sensor information not from the sensor itself, but from middleware that the provider is using. Which could be something like SkySpark Server in the case of BACNet sensors. So we may get a measure of temperature in a room or building, and a time range for the measurement, but not the actual 'raw' sensor readings. Which is fine, we want to use this for analytics, not controlling the air vents.

alanepaull commented 5 years ago

The connection between sensor and device is made through deviceEUI.

We don't have this currently. Is it LoRoWan specific? Described as: "64 bit end-device identifier, EUI-64" on https://www.thethingsnetwork.org/docs/lorawan/address-space.html.

Suggests that the device identifier may need to be technology independent or a key/value pair: MAC,[address] deviceEUI,[address] ...

So, instead of sensor.mac, we have sensor.device. This would be optional, referencing Scott's comments above.

ghost commented 5 years ago

See the other thread - I'm still not sure how we link the events to the UDD - but I suspect I'm missing something obvious. :-) The answer to that question may well determine the device/sensor ID question.

"That also gives us an example where we obtain sensor information not from the sensor itself" We may well get sensor readings, sentiment analysis output or any other useful data from alternate sources - like CSVs - so that all makes sense.

scottbw commented 5 years ago

Basically we have two types of use cases for inbound data.

One is fairly 'raw' data that we need to link to the UDD within the data warehouse/service rather than at source. In that case we need to use metadata from the sensor event to try to link it to the UDD - perhaps at Site level if nothing else matches up. (In the info model, this is when events come direct from an activity source not connected to a context source)

The second is where the data is coming from some sort of middleware platform at the provider side, and they've already added in contextual metadata for linking to the UDD, like the room ID. For example, if a sensor is identified in Archibus with a room identifier, and the identifier is the same in CELCAT, then the sensor event passed to the service can contain the correct room_id in the context. (In the info model, this is when events come from an activity source linked to a context source)

Does that make sense?

alanepaull commented 5 years ago

Updating sensor model...

alanepaull commented 5 years ago

Just to note that in xAPI in the LA we have a statement template for "answering a question" - this is designed to be used for gathering data on sentiment for example: https://github.com/jiscdev/xapi/blob/1.0.3/recipes/studyapps/app-answered-question.md