Om te komen tot een wat breder en toepasbare manier van meetdata uitwisseling is er bij MySense een eerste concept voor meetdata uitwisseling in de vorm van een test programmatje (Python) opgesteld.
Zie https://github.com/teusH/MySense/blob/master/scripts/LoRaCode.py
Het eerste concept is ontsproten nav enkele jaren van ervaring met MySense. Het omvat twee nivo’s: LoRa payload dataformaat (compressie en decompressie) voor verzending meetdata via LoRaWan en een hoger nivo data uitwiseling: het nivo tussen diverse software modules bijv opslag naar database of dataportalen.
Het is nu nog een concept dat aanvulling en verbetering behoeft. Nu kan het nog nu
Naar mijn idee is JSON het meest handig voor de high-level codering. Alle APIs die in de sensor.community sensor/luftdaten kit zitten, gebruiken dat. Hoe de data vervolgens in JSON is gecodeerd verschilt soms subtiel.
Voor LoRaWAN is het heel belangrijk dat de data compact wordt overgestuurd. Ik heb gekeken wat voor codering er in verschillende projecten gebruikt wordt, en dat hier opgeschreven: https://revspace.nl/LoraWanDustSensor#Payload_encoding
Voor mijn eigen LoRaWAN fijnstofnode gebruik ik de “Cayenne” encoding. Die is redelijk compact (maar kan nog compacter) en heeft voor verschillende datatypen al een codering, o.a. voor luchtvochtigheid, temperatuur en luchtdruk. Voor fijnstof is er geen standaard data-item, daarom heb ik voor fijnstof gekozen voor de generieke “analoge waarde”, waarbij je per analoge waarde nog een id kan toewijzen. Analoge waarde “1” is voor PM10, analoge waarde “2” is voor PM2.5 en analoge waarde “0” is voor PM1.0, naar voorbeeld hoe ze in de sensor.community node worden gecodeerd als “P1”, “P2” en “P0” respectievelijk. Het bereik gaat van ca -327.67 tot +327.67. In extreme gevallen zou je qua fijnstof boven 327 ug/m3 uit kunnen komen.
Cayenne is een codering die door TheThingsNetwork geinterpreteerd kan worden zonder een “custom” decoder te moeten specificeren. Data in Cayenne-formaat wordt ook direct gesnapt door bijvoorbeeld het dashboard van http://cayenne.mydevices.com Voor dat dashboard kan je bij TheThingsNetwork een integration aanzetten en dan ben je heel snel klaar.
In mijn implementatie ontvang ik de data van TheThingsNetwork met een Java applicatie, decodeer ik de Cayenne en stuur de data weer door naar sensor.community en naar opensensemap. Wanneer er echt een “officieel” formaat zou zijn, zou dit mogelijk ook als een “integration” bij TheThingsNetwork kunnen draaien.
De LoRaCode.py bevat twee concepten:
De Json gebaseerde formaat voor ‘hogere’ nivo’s. Dit voorstel is gebaseerd na nu 4 jaar gebruik en heeft de tekortkomingen gedekt die bij andere implementaties tegengekomen was. Vooral tav generieke oplossing tav meta data bijv lokatie en type sensor. Kompressie is op dit nivo niet het issue. Bedoeling is dat mbv dit voorstel enige uniformiteit gaat ontstaan zodat koppeling makkelijker wordt en software modules ook uitgewisseld kunnen worden. Het is een basis voorstel dat uitwerking behoeft. Zie het als een soort Request for Comments wat in internet protocolland (IEEE) een normale gang van zaken is.
Het LoRa payload gedeelte is een compressie engine. Zie het als een manier om mbv een soort ‘programmaatje’ de bovengenoemde json record impact in een payload of uitpakt naar een json record. Als voorbeeld zijn een paar ‘programmaatjes’ aangegeven.
Helaas is de LoRa payload engine een statisch verhaal. Nadeel het kan altijd compacter maar mi is de winst dan te gering ivm de complexiteit, flexibiliteit en toekomstige ontwikkelingen.
Heb enkele jaren geleden ooit een voorstel gedaan voor payload compressie techniek bij The Things Network forum. Die methode had een heel hoge payload compressie efficiency. Paste zich automatisch aan indien het meetwaarde domein zich in de loop van tijd veranderde. Kreeg veel bvelangstelling maar was te complex en heeft het nooit gehaald.
Maw er moeten keuzes gemaakt worden en tav meer algemene toepassing moet je dat zodra dat nog kan ook doen. Ofwel anders gezegd: Lossen we een N*N orde verhaal op of een N+N verhaal?
Voor mij is het gemakkelijk forwarden naar sensor.community een essentieel ingredient van elke oplossing.
Vandaaruit kan gezorgd worden voor archivering, forward naar RIVM etc.Beide oplossingen (Teus en Bertrik) vergen een prive server die het LoRaWAN pakket parst en het forwarden naar sensor.community doet.
Een oplossing zonder prive server, maar via een officiele integratie van TTN richting sensor.community
zou een grote stap voorwaarts zijn: niet meer afhankelijk van prive servers, maar onderdeel van
een onderhouden community infrastuctuur.
Om TTN te bewegen dit te implementeren zullen zij enige randvoorwaardes hebben.
- een minimale lengte van de payload
- een algemeen gebruik, ook internationaal
- uitbreidbaarheid naar andere luchtkwaliteit
- wat biedt deze integratie TTN bovenop de huidige meachanisme ?
Wat we verder nog duidelijker moeten definieren is welke grootheden we precies bedoelen en welke nauwkeurigheid nodig is.
Een enkele, acute PM10 meting hoeft m.i. niet op tienden/honderdsten van ug/m3 te rapporteren, de meetnauwkeurigheid rechtvaardigt dat niet.
Als we in de sensor zelf een poos middelen (bv half uur) alvorens te rapporteren, dan hebben we het strict genomen over een ander,
nauwkeuriger bepaald PM10 gehalte.
Voor mij heeft hogere prioriteit het doel:
“Gemakkelijker goedwillende eindgebruikers zelf laten koppelen van hun meet apparatuur”
De payloaddefinitie zou drager onafhankelijk moeten zijn (LoRaWAN, NB-Iot, …)
Ingewikkeld gedoe van configuratieparameters instellen door eindgebruikers moet vermeden worden.
De oplossing die Bertrik nu heeft (Dev_eui zichtbaar maken op Oled, vaste applicatie_eui, vaste app_key, vaste access key)is een stap in de goede richting.
Wellicht is in samenwerking met TTN nog iets eenvoudigers te verzinnen.
Het probleem met sensor.community is dat er indertijd nogal op hardware pin nivo keuzes gemaakt zijn die nu in de weg zitten om een betrouwbare stroom van meetdata te verkrijgen. Meta data bijv lokatie, etc. is apart en niet flxibel gescheiden van sensorwaarden. De sensor waarden zijn tav verschillende sensoren niet goed te onderscheiden en zijn incompleet. Timestamps worden gehaald uit de POST datum. Maw tijd om de architectuur te redesignen. Jammer.
Door te komen met een hoger nivo data uitwisselings standaard kunnen we een simpele stap maken weg van de Toren van Babel met diverse begin aannamens.
TTN is puur LoRaWan transportmiddel. Payload compressies verschillen per definitie (bijv fabrikant Libelium heeft zijn eigen payload compressie) en het voorstel is dan ook dat stuk niet proberen uniform te maken maar heruitvinding van het wiel te voorkomen door een programmeerbare payload compressie engine ter beschikking te stellen. MySense gebruikt al een concept vorm hiervan.
TTN benader je via Mosquitto (MQTT) subscribe data stream interface. Door dat interface via een standaard formaat (bijv JSON) te doen kan iedereen simpel een aansluiting maken en software hergebruiken en voorkom je dat het wiel oneindig heruitgevonden hoeft te worden. Gebruik je MQTT/InfluxDB als subscribe (pull) en/of submit (push) techniek.
Voor een push situatie hangt er meestal een prijskaartje aan tenminste als er ook sprake is van opslag.
Een jaar geleden heb ik eens gepolst of er belangstelling was een rack met servers bij een bereidwillige grote hosting bedrijf te plaatsen (snelle verbindingen, teveel diskruimte, Open Source). Kosten eenmalig 1K plus 100 euro per jaar per initiatief. Er was niet voldoende belangstelling. Maw te vroeg in de tijd. MySense draait dus op een prive server tav data collectie, data monitoring, data analyse, data statistiek, data opslag, web service, data transport, etc. Met dank aan TTN, mijn internet provider en diegenen die een LoRa TTN gateway gedogen. WiFi is een no go gebleken.
Blijft over de analyse (statistiek) en visualisatie kant. Dat laatste zal het interface zijn van de casual gebruiker. Voor de statistiek zal het handig zijn als er wat co-existentie in opslag zou zijn bijv alleen al welke database (SQL en tabel structuur) en bijv CSV (standaard ontbreekt: gevolg telkens veel gedoe). Visualisatie: welke dashboard (niet mijn voorkeur) of soort grafieken (ik gebruik RRD en HighCharts wat interactieve grafieken mogelijk maakt maar ook die is niet ideaal). Hier valt nog veel te leren van elkaar.
De aanleiding om de MySense data acquisitie software te herzien was velerlei:
- TTN MQTT LoRa service ondergaat een herziening van V2 stack naar V3 met een ander datagram formaat.
- Privacy overwegingen en de enorme behoefte om nabij gelegen meetkits meetdata mee te nemen in de visualisatie op de website
- De operationele monitoring op validiteit en manko’s in de meetdata van de sensors (ja ze gaan soms kapot).
- De calibratie en correctie tussen de diverse (fijnstof met name) sensors van verschillende fabrikanten (kunnen we de metingen wel vergelijken?).
- Ontdekken van meetkits die blijkbaar ‘in repair’ zijn.
- De eerste implementatie van Meet Data Uitwisselings Formaat (MDEF 2021 draft).
- Nav ervaringen afgelopen jaren veranderingen in de database structuur.
- etc.
was aanleding om de MySense datacollector te herzien. De versie staat nu als alpha release op https://github.com/teusH/MySense in de folder MyDatacollector beschikbaar. De software bevat veel test en data formaat voorbeelden. Bedoeld voor tenminste een tweede implementatie van de MDEF draft.