Badtemperaturer
- Isak Styf (Unlicensed)
Ett lösningsförslag för hur badtemperaturer kan publiceras med hjälp av IoT-hubben.
Bakgrund
En lösning har utvecklats där Servanet mäter badtemperaturen på ett tjugotal olika badplatser i Sundsvallsregionen. Datat från dessa mätningar har sedan exporterats för att kunna presenteras i medborgarappen. Det här förslaget tar sikte på en ny lösning där dataproducenten frikopplas från de olika datakonsumenterna, genom att använda IoT-hubben som ett mellanliggande lager. I ett nästa steg är syftet att förbereda för en effektivare hantering av öppet data och möjlighet att publicera mätvärden till dataportal.se.
Datainsamling
Insamling av mätvärden från fältet sker i det här fallet med befintliga sensorer, vilka på samma sätt som tidigare rapporterar sina mätvärden via LoRa till Servanet:s applikationsserver. Dessa värden publiceras sedan vidare till IoT-hubben via en krypterad MQTT-koppling.
Datat som kommer från Servanet tolkas i hubben av en ingress-tjänst, som kodar av den LoRa WAN-formatterade nyttolasten, gör om den till en Fiware-entitet (Device) och vidarebefordrar den till sin context broker som hanterar att uppdateringen skickas till rätt ställe för lagring.
TODO: Rita en fin bild …
Behovet av att ha kunskap i hubben om att mätvärdet kommer från LoRa är ett olyckligt arv från “IoT för Tillgänglighet” och kommer så snart som möjligt att byggas bort i samarbete med Servanet. Målbilden är att de i stället kommunicerar direkt mot brokern via NGSI-LD över HTTPS.
Datamodell
För att bygga vidare på den datamodell som hubben redan använder sig av, är ambitionen att använda sig av befintliga entiteter i Fiware så långt som möjligt. När projektet City as a Platform tittade på badtemperaturer användes PointOfInterest och WaterQualityObserved. För vår Implementation rekommenderas att även vi använder oss av WQO, men att vi i stället använder oss av den mer specifika entiteten Beach, som är en undertyp till POI.
Eftersom Beach är en utbyggnad av https://schema.org/Beach, så är det möjligt att använda fler attribut från schema.org. Ett av dessa attribut är sameAs, vilket ger oss möjligheten att entydigt länka våra entiteter mot exempelvis wikidata.org. Fördelen med detta är att vårt data blir enklare att maskintolka och skapa kunskapsgrafer från.
NGSI-LD API
Ett förenklat exempel för hur det skulle se ut att hämta ut en lista med stränder ur hubben (URL:erna är exempel och inte fungerande, än):
GET https://sundsvall.diwise.io/ngsi-ld/v1/entitites?type=Beach
Accepts: application/ld+json
[{
"id": "urn:ngsi-ld:Beach:se:sundsvall:poi:bergafjaerden",
"type": "Beach",
"location": {
"type": "GeoProperty",
"value": {
"type": "Point",
"coordinates": [17.456939, 62.267724]
}
},
"sameAs": ["https://www.wikidata.org/wiki/Q16498519"],
"source": {
"type": "Property",
"value": "https://www.sundsvall.se"
},
"name": {
"type": "Property",
"value": "Bergafjärden"
},
"@context": [
"https://schema.lab.fiware.org/ld/context",
"https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld"
]
}]Att i nästa steg hämta ut mätningar av vattenkvalitet (temperatur) i närheten av en viss strand kan göras på ett par olika sätt. Första alternativet är att referera till stranden som en point of interest och låta hubben lösa ut vilka mätningar som skall anses höra till den refPointOfInterest som skickas med som query-argument i URL:
Andra alternativet är att fråga efter mätningar som ligger inom ett visst antal meter från en viss punkt, där den punkten kan hämtas från en tidigare returnerad Beach, eller sättas fritt för att leta i andra områden.
GET https://sundsvall.diwise.io/ngsi-ld/v1/entities?type=WaterQualityObserved&georel=near;maxDistance==200&geometry=Point&coordinates[17.456939,62.267724]
Oavsett hur frågan utformas, så skulle svaret komma att se ut ungefär så här:
[{
"id": "urn:ngsi-ld:WaterQualityObserved:se:servanet:elt-sensor-01:210308T125217Z",
"type": "WaterQualityObserved",
"dateObserved": {
"type": "Property",
"value": {
"@type": "DateTime",
"@value": "2021-03-08T12:52:17Z"
}
},
"temperature": {
"type": "Property",
"value": 2.4
},
"location": {
"type": "GeoProperty",
"value": {
"type": "Point",
"coordinates": [17.456939, 62.267724]
}
},
"refPointOfInterest": {
"type": "Relationship",
"object": "urn:ngsi-ld:Beach:se:sundsvall:poi:bergafjaerden"
},
"@context": [
"https://schema.lab.fiware.org/ld/context",
"https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld"
]
}]Anpassningar av data eller logik
IoT-hubben är byggd baserad på en standard för länkat data, med syftet att göra det så återanvändbart som möjligt mellan olika aktörer. Det betyder så klart att det kan uppstå situationer där det finns specifika behov av att lägga till attribut som standarden inte stödjer, eller att lägga till tjänster eller förmågor som förfinar data på något speciellt sätt.
IoT-hubbens lösning på detta är att göra det möjligt att lägga till egna tjänster som kan göra denna typ av anpassningar, lägga till beteenden eller till och med agera broker. I fallet med badtemperaturer skulle det kunna användas för att exponera enklare datamodeller, men det skulle minska återanvändbarheten av lösningen och bör vägas noga mot nackdelarna innan ett sådant steg tas.