search

Cetis / intelligent-campus

6 stars 0 forks source link

LoRa, Gateways and Decoding #11

Open ghost opened 5 years ago

ghost commented 5 years ago

Following up on one of the calls regarding LoRa, gateways and decoding and if a sensor knows where it is, I did some investigation with a Multitech gateway (MTCAP-LEU1) - this is basically a small BusyBox linux router and is the version with a GUI for configuration. Other gateways may behave differently and hopefully I'll have access to a Kerlink Wirnet Station soon and can also try all this with a Laird Sentrius.

Anyways - as you know - a sensor (node) broadcasts its data and that data is picked up by one or more gateways. The gateway forwards the packet on (using internet or cellular backhaul) to a LoRaWAN network server which hands the packet off to an "application server" which then forwards the data on to an application (via an "integration"). That application might be the Jisc data ingest endpoint or (more likely) an application created by the member site.

This suggests a couple of places where the location of a sensor can be injected:

1) On the sensor itself 2) At the gateway 3) On the network/application server 4) As part of an ingest at the application 5) A member application forwarding measurement events to Jisc

Taking each in turn:

1 - the sensors we've seen thus far are pretty dumb and do not know their location - though some LoRa nodes do have GPS this is unlikely to help if the sensor is inside a building. Unless we have complete control and can encode a location as part of the packet (this would be doable on a home-grown sensor e.g.) it doesn't seem possible. (LoRa-geolocation is currently not accurage enough for room-based location though that may improve).

2 - I've only tried the Multitech mentioned above - in this instance it is a linux box so in theory you could write your own code to attach additional data at the gateway but that is unlikely to be something our members would do (perhaps we can suggest it to gateway vendors though). Out of the box it supports two modes - packet forwarder or network server. The former uses Semtech's basic packet forwarding to send data to a remote network server, the latter takes on the role of network server. I need to investigate more the network server option - I've seen mention of NodeRED on multitech gateways so I need to see if this one supports it - that could be an easy-ish way to attach a location to a measurement event.

3 - I've only used TTI so far. TTI applications have an built-in workflow - decoder -> converter -> validator for uplink messages (and an encoder for downlink). These could be used to add location data e.g. by providing a deviceEUI -> location mapping in the converter function. This would require maintaining via the TTI console. This would be manageable I think and I'm thinking to try this with our office sensors.

4 - Maintaining a device -> location mapping at a member site would work well and puts the maintainence near to the data owner which makes a lot of sense. I'm not sure Jisc would want to maintain that mapping centrally for all members though we could build an application that would enable that for data ingest if we saw a need for it.

5 - If a member site forwards the data to Jisc for central processing, aggregation, etc. and that member wants to make use of location data they would have to send measurement_events with their preferred location set.

I hope you don't mind but I wanted to share that all with you as it has been buzzing around in my head for a week or so now... :-)

Suggests a couple of things to try next:

1) NodeRED or similar workflow engines on the gateways 2) TTI workflow to map sensor to location

scottbw commented 5 years ago

Thanks for these Pete - I think there are going to be a few different options that providers have for marking up their sensor data. For lightweight sensors these are really going to need a mapping of hardware IDs to location tags at stage 3-5. For BACNet, and BMS sensors more generally, its possible to set custom properties on the device itself, or it can be done at the BMS gateway, or on an IoT database server like SkySpark. Ultimately I think it feels right for the provider to manage their own mapping methods for their hardware, and deliver data to Jisc already marked up with location tags.