IoT-Apps mit der SensorThings API entwickeln #42 - podcast episode cover

IoT-Apps mit der SensorThings API entwickeln #42

Oct 24, 202337 minEp. 42
--:--
--:--
Download Metacast podcast app
Listen to this episode in Metacast mobile app
Don't just listen to podcasts. Learn from them with transcripts, summaries, and chapters for every episode. Skim, search, and bookmark insights. Learn more

Episode description

Die OGC SensorThings API ist eine Spezifikation für den Austausch von IoT-Daten. Sie gibt ein Datenmodell für den Zugriff auf Sensordaten über das Internet vor. Die SensorThings API wurde vom Open Geospatial Consortium (OGC) entwickelt und basiert auf der ISO 19156. Das Fraunhofer IOSB hat die SensorThings API in seinem FROST®-Server implementiert. Die Implementierung steht als Open-Source-Software zur freien Nutzung zur Verfügung. Da wir bei der Heisenware IoT-Apps für und mit unseren Kunden entwickeln, ist es ein Muss, die API und ihre Implementierung genauer unter die Lupe zu nehmen.

Links zur Folge:

Starte kostenlos mit Heisenware unter

⁠⁠⁠⁠⁠https://heisenware.com/einfach-komplex⁠⁠⁠⁠⁠

---

⁠FROST®-Server beim Fraunhofer IOSB⁠

⁠SensorThings API bei der OGC⁠

---

Einfach Komplex ist ein Podcast von Heisenware. Alle Infos und Kontakte findest du im Linktree:

⁠⁠⁠⁠https://linktr.ee/heisenware⁠⁠

---

Dr. Burkhard Heisen und Gerrit Meyer sprechen heute über:

(00:00) Einführung

(08:10) FROST®-Server

(12:30) API-Design und -objekte

(28:00) Anwendung der SensorThings API

Transcript

Einführung

Moin zufolge 42 von einfach komplex. Heute mal wieder ein IOT, also ein Internet der Dinge. Thema Burkhard, Was haben wir vorher? Erzähl du mal bitte. Mein gerät cool, folge 42 die 42

besonders gerne. Ich sag warum weiß warum glaube ich ja wahrscheinlich alle Hörer wahrscheinlich schon, egal genau, wir machen heute ne richtig schöne Folge mit IOT und zwar nicht nur irgendwie, dass wir drüber reden, sondern wir gucken uns ein eine Implementierung an, eine einen API Standard um das Internet der Dinge. Digital und technisch festzuhalten und zu beschreiben ist nämlich ganz schön kompliziert.

Aber das tun will dann Internet der Dinge heißt ja, wir haben ja irgendwie Sensoren im Feld, und die sind auch irgendwo und die lesen irgendwas aus und die Leben halt auch nicht nur eine Sekunde, sondern haben Lifecycle und so weiter und das muss man erstmal abbilden. Und genau, und da erzählen wir heute mal ein bisschen was dazu. Prima. Also dann lass doch konkret machen, welche API handelt es

sich denn da eigentlich? Ja, das ist die die sogenannte Sensor Things API und wie folgt einem gewissen Standard, dem OGC Standard. OGC steht für Open Geospatial Consortium und das ist halt so richtig krasser Standard Kram.

So ja kannst du jetzt nachlesen bei Wikipedia, irgendwie hängt sogar noch irgendwie nen ISO Standard mit dran, also beschreibt nämlich die Observations and Measurements den Standard dafür, dass der ISO 19 156 Standard da war ich mir die Standards nicht durchgelesen, Herr aber. Also was ich sagen will, also wenn man so ein ISO Standard gemacht wird, dann haben ein paar Leute drüber nachgedacht und was jetzt halt zusammen kommt.

Oft hast du ja dann haben clevere Leute nachgedacht und dann hast du aber auch das Problem, da gibt es politische Unwägbarkeiten wie in der normalen Politik verschiedene Interessen, dann kommen Kompromisse dabei raus und wenn es dann auch noch technisch wird, dann hast du Salat weil irgendwie du willst keinen technischen Kompromiss Standard Krams haben und ganz oft hatten wir immer Salat und Salat war dann irgendwie XML und und und Soap und Krempel was so also d.

Vorgänger davon ist alles Salat und ich sagen jetzt haben wir erstmal was, wo sich ja wo sich die Leute irgendwie zusammen

haben. Wir brauchen echt was hier für dieses IOT ist ja jetzt nicht so ne Kleinigkeit, wir müssen und zwar vor allen Dingen auch Leute wie Fraunhofer, dazu komme ich gleich gesagt, wir müssen jetzt mal was machen wir das endlich mal in Griff kriegen und die haben halt die coolen Sachen zusammen, nämlich Rest APIS hatten wir ja schon ja du weißt ich mag Rest AP eigentlich, aber es ist halt schon defacto Standard insofern finde ja i passt da schon die basieren alle

die ganze Datenformaten Krams alles Jason. Ja, Jason hat mir schon auch. Ganz gut. Dazwischen, ja, und dann ist auch noch die Frage, wenn API designed, dann hatten wir auch schon mal. Kannst du machen wie du willst. Im Prinzip kannst du Bild machen, kannst du gut machen, die haben das sehr gut gemacht, sogar die Folgen dem sogenannten O Data Standard. Ohne jetzt genau zu sagen, was O Data ist, aber im Prinzip einen Regelsatz für wie ich Rest APS gestalte.

Wenn sie dann verschiedene Dinge, die zum Beispiel auch Inter konnektiert sind, abfragen und so weiter damit das ganz klar ist. Ja und wie die wie die US aussehen, ja, dass die immer glatt sind und so weiter und der O Data Standard ist halt noch weiter als jetzt nur die Sensor Things APID wieder besprechen, aber die folgt diesem Standard und immer den einmal drauf hat, dann ist alles ganz glasklar OK voll. Easy?

Ja prima, jetzt hast du mal Rundumschlag gemacht und bist schon voll reingegangen in ein paar Details eigentlich. Aber wir wissen noch nicht, was die Sensor Things API mal auf hoher Flughöhe eigentlich tut, wofür sie genutzt werden kann. Was ist denn der Zweck davon oder die Aufgabe? Ja, da gucken wir vielleicht mal einfach ein paar Anwendungsfälle an. Ne, also alles was halt das IOT

so ist. Ne also die die Sensor Things I versucht, wie soll ich sagen Sensorik io t Sensorik zusammenzubringen, die vielleicht gar nicht so direkt erst mal was miteinander zu tun habt ihr verschiedene Anwendungsfälle, ich sag mal was was qualitätsmessungen. Entlang des Rheines zum Beispiel.

Jetzt, es gibt tausende Anwendungen, das war so typisch i Projekt, du fängst an Bein und steckst halt irgendwie alle 2 Kilometer irgendwie so ein Sensor ins Wasser und machst halt ne komplette Messung vom Start bis zum Ende ja vom Rhein

und Wert ist das irgendwie. Alles aus OK, das ist IOT, weil diese ganzen Sensoren sind dann verbunden mit irgendeiner Sondereinheit mit irgendwie einem Gateway oder sowas in der Art, dass sendet zum Beispiel über Mobilfunk in die Cloud und sprechen über t, weil das ne Komponente hat, also ein Sensor irgendwie Cloud Komponente wo die Daten zusammenlaufen und. Ausgewertet werden oder gespeichert oder sowas würde. Ich sagen hast du mehr Details genutzt als wir?

Ja, wir brauchen IOTH Internet der Dinge würde es noch einfacher unterbrechen, da sind Sensoren die irgendwie die irgendwie miteinander kommunizieren können übers Internet typischerweise ja oder im Internet quasi dann erfasst werden am Ende des Tages, wie siehst du denn? GSM, Lorawan, da gibt es Tausende Pfund oder so.

Das erste Mal sei mal dahingestellt, wichtig ist, es gibt sehr viele Sensoren im Feld und die messen irgendwie was und die sind irgendwo und die Spielen quasi ihre ganzen Daten irgendwie an eine zentrale Stelle und dann und dann kann ich mit dieser mit diesen Daten und den Messungen und Sensoren irgendwas machen ja auswerten ja zum Beispiel wissen O am Kilometer Abschnitt zwischen Kilometer 5760 dropt quasi die Wasserqualität immer ganz stark, ja.

Was ist denn da los, oder? Weniger Stickstoff irgendwie so, oder? Vielleicht gibt es eine Firma, die am Rand steht oder irgendwas.

Ja und was einleitet, was da nicht hin soll oder keine Ahnung, ja so und in von diesen Projekten und dann ich meine das ist alles IOT, kennt er unsere Zuhörer aber so Smart City zum Beispiel, ja, wir haben zum Beispiel auch J. Und deswegen sprechen wir heute über das kurz mal ausmachen n bisschen Smart City und zwar in Lübeck und da geht es um um um Temperatur, Co 2 Gas wert, Messungen und so weiter in öffentlichen Gebäuden sag ich mal und das ist genau das

gleiche ja Anwendungsfall, also viele Sensoren irgendwo ich. Wir müssen natürlich wissen, wo, und die werden irgendwelche Daten aus ne und das muss ich organisieren, wenn ich das irgendwie technisch aufsetzen will, dann brauche ich irgendwas, was mir diesen ganzen Krams organisiert. Ja so. Jetzt noch eine Frage zwischendurch. Bevor du jetzt in die Organisation und die Beschreibung kommst. Du hast bisher nur Sensoren erwähnt.

I kann ja auch Aktoren enthalten, also irgendwie steuernde Elemente, die mit dem Internet verbunden sind, oder? Ja, das stimmt, da hast du mich jetzt also die also die Sensor API, die kommt glaub ich in 2 Abschnitten daher soweit ich mich erinnere mich kurz n bisschen ich es geht der erste Teil von dieser Standard von diesem standardisierungs Pamphlet befasst sich tatsächlich nur mit der Sensorik, also nur mit dem Auslesen.

Ne das ist auch der einfachere K. Ja es gibt jetzt glaube ich einen zweiten Teil, nämlich nicht wie heißt jetzt nicht mehr gefunden 1.2 glaube ich da geht es halt auch darum die Aktuatoren. Ne, die Aktuatoren mit einzubetten irgendwie und die zu schreiben, das würde ich für die heutige Folge erstmal weglassen. Das war vielleicht mal in Folge oder einer weiteren Folge irgendwie noch machen, wenn wir auch selber ein bisschen tiefer. Ja, ich wollte nochmal das erwähnt haben.

Hast du recht zum IOT irgendwo gehört oder? Nicht stimmt aber ist also das, was wir heute besprechen, befasst sich quasi nur mit dem Auslesen, also mit der Sensorik und nicht mit der. Dann haben wir abgegrenzt. Dann sag mal einen in die steigen, wenn ich will, jetzt meinen häufig zu sagen Sensor Things API, weil das ist ein gefährliches TE an der Stelle ja. Ja, ich krieg es auf jeden Fall nicht. Hab mir heute ausnahmsweise eine Haselnuss eingegossen hat.

Vielleicht schauen wir mal. Genau, wir steigen ein bisschen ein und wir gucken mal. Und das tue ich einfach, weil ich selber jetzt damit gearbeitet hab. Deswegen sprechen wir darüber im Detail, und zwar um den sogenannten Frost Server Frost wieder Winter, ne. Frost steht für Fraunhofer Open Source Sensor, Things API Server Frost. Ja ziemlich coole Open Source

FROST®-Server

Reference vollständige Implementierung der Sensor Things API ja geschrieben glaube ich in Java unten drin aber völlig Worms, weil die Herren verteilen das so elegant, dass jeder einfach nutzen kann, nämlich im Docker Container ja oder um besseren genau zu sein s 2 Docker Containern. Denn der eine ist der Server, der Frost Server, der die Rest API zur Verfügung stellt. Und der spricht mit dem zweiten Container. Kannst du dir, hast du dann was sein könnte Master. Klient.

Nee, wir müssen ja irgendwo speichern, also eine Datenbank, also, die haben das so aufgeteilt, und es ist sinnvoll, dass man ganz oft also ein Microsoft hat quasi die Business Logik drinne, also die die die die API also nach quasi zum Nutzer hin die Rest API und nach innen hin verwandelt sich das in SQL Command spricht mit einer in diesem Fall Postgres Database. Ja, so, und die speichert quasi alle Informationen, die

gespeichert werden müssen. Es ist komplett, dann kapselt System. Also wenn du kannst dann diese 2 Docker Container installieren und bringst sie hoch und dann bist du fertig und Ready to go um fettes IOT System darin zu beschreiben. Und dieser diese Datenbank ist jetzt auch, also ist das. Wie ist der Zusammenhang von dieser EI Beschreibung dieser Standard Beschreibung und der Implementierung? Also man da inwieweit würden Sachen vorgegeben wird zum Beispiel ergeben, dass man

Postgres als Datenbank benutzt. Ja, genau das ist kapselt ne. Also du kannst also die beiden Container kommen als Blackbox ne, du kannst die beide starten, dann startet diese Postgres was da drin passiert und was sie macht. Aber ich meine. Dass der Standard auch so. Nein, das gibt der Standard nicht vor. Ne, OK, wie das, wie das tatsächlich das ist die implementierungs Wahl. Also du kannst der Standard tatsächlich nur vor wie haben die US auszusehen?

Ja, also die Rest Apis rest OS. Welche Abfragen kannst du damit machen und wie ne, also welche welche Queries und so weiter und wie wie haben die. Wie haben die Anfragen vom Client auszusehen und wie haben die Antworten von der API

auszusehen? Also die Jason im Prinzip der Inhalt der Jason Objekte, mit denen ich Anfrage, also die Request Jasons und Response Jasons alles das ist Teil der der Spezifikation wie das aber realisiert oder in anderen Worten implementiert wird, das ist völlig völlig frei, ja und die haben das jetzt zum Beispiel irgendwas genommen als Programmiersprache und haben damit umgesetzt und und die Datenbank die du brauchst um diese richtigen Responsive zu

generieren ne also du brauchst du brauchst ja Existenz. Wenn du jetzt einen neuen Sensor anlegst. Und fragst danach nach diesem Sensor. Dann muss er sich irgendwie gemerkt haben, dass die angelegt hast, wie du denn Blockchain machst oder sowas kannst du auch. Ja. OK, wahrscheinlich so. In diesem Falle brauchen wir wie sagen sehr dringend eine relationale. Datenbank, das heißt, Diese OGC, Die Open GEO Special Konsortium, die haben die diesen Standard angelegt.

Also da sind wahrscheinlich auch viele Menschen. Genau. Papier und Fraunhofer hingegen gesagt, Wir implementieren das jetzt in dieser Art und Weise. Und wenn das Frost zu. Erwarten genau, perfekt genauso. Man kann es vergleichen mit MQTT zum Beispiel jetzt auch Papier.

Ja, gibt MQT Standard, mehrere sogar verschiedene und dann gibt es viele Firmen, die gehen dahin und implementieren quasi diesen Standard moskito QQ, keine Ahnung ja also sind alles verschiedene Implementierungen und haben manchmal Nachteile, manche manche decken quasi Standard vollständiger andere weniger, andere sind schneller und langsamer, keine Ahnung, aber die Frauen haben sich hingesetzt und das tatsächlich implementiert plus das ist umsonst.

Kannst du runterladen ja und es ist ziemlich zügig, das kann nicht sagen aus meinen eigenen Erfahrungen funktioniert hervorragend. Dann jetzt habe ich alle Fragen beantwortet bekommen. Du kannst gerne mal ein bisschen erklären, hast ja gerade von den 2 Microservices gesprochen, aus denen diese Plementierung jetzt besteht.

Genau, genau und können jetzt auch wieder vergessen, weil die bringe ich dann quasi hoch und dann habe ich meinen, dann kann ich meine Anfragen mit jedem x beliebigen Klienten, es ist ja n Server, also dann schreiben wie ich lustig bin ne ich hab jetzt zum Beispiel genommen, kannst ja mal sagen wir sind ja Freunde von PS also hab ich einen mit Axios ein Typisches HTTP

API-Design und -objekte

klienten tool axios. Was habe ich in wenigen Zeilen Code nochmal einer drüber geschrieben, mit dem ich quasi

diese ganze API bedienen kann? Ne ziemlich easy also das dauert ein Tag mit vielleicht 2 wurden auch die Dokumentation macht ja OK so und jetzt jetzt wird es aber inhaltlich und was ich so toll finde an diesem Ding ist es realisiert die ja die Verwaltung eines ziemlich dicken Problems, nämlich von dem Internet der Dinge ja in sehr klaren und und und ja, einen sehr klaren und autonomen Strukturen will ich mal sagen, ja, ich hab sowas vorher noch nie gesehen, wir hatten bei diesem Projekt

überlegt, wie wir selber machen irgendwie Datenbank Design und dann kommt man ziemlich schnell ins in die Verzweiflung als Softwareentwickler merkt. Wie derartig komplex eigentlich

schon? Also eine Verwaltung von Sensoren und deren Daten und so weiter das ist halt einfach ein komplexes Thema, das kannst du nicht so schnell mal eben selber hin die sein ja das n bisschen sportlich sag ich mal ja und und dann wurde ich aufmerksam gemacht auf dieses auf diese Länder aus i und hat die Implementierung von Post Server und hat sich als cool herausgestellt, deswegen diese Folge hier ja für alle die sich interessieren und es ist

deswegen so einfach, weil es im Prinzip gibt es nur. Also es gibt offiziell 8 verschiedene Objekte datenobjekte, die gehen wir gleich alle Reihenfolge schnell durch. Tatsächlich braucht man nur 6, um es zu verstehen. Nicht reduziert das erstmal auf die 6 und bringen die anderen 2 gleich noch mit dran. Ne, ich geh mal einfach in der Reihenfolge durch, was nämlich diese dann gleich einen wirklichen Blick was los ist.

Ja also es gibt folgende Daten Objekte, es gibt Thing auf Deutsch das Ding, ja das beschreibt halt ein ein physisches oder auch virtuelles Dingen, ja ein ein ein Ding des Internets der Dinge. Also zum Beispiel ein Sensor. Nee, genau nicht entsorgt. Mensch, jetzt habe ich am Anfang gedacht so. Aber das ist, man muss bei so ein paar Sachen muss man irgendwie muss man irgendwie nochmal nachdenken. Aber es ist am Ende sehr sinnvoll, ja zusammengestrickt der ganze Kram.

Ja gut. Dann, ich halte mich jetzt zurück. Ja genau, also n Ding Ding. Ist zum Beispiel im Kühlschrank. Ja, ich gehe jetzt mal ein Beispiel dran, damit wir eine Geschichte im Kopf kriegen wir das Ding ist zum Beispiel im Kühlschrank, ja und dann als nächstes das nächste Daten Objekt ist ne Location ja also ein Ort zum Beispiel die Küche ja.

So, jetzt kann ich jetzt kann ich Orte an Dinge kleben, ne, also ein Ding kann einen Ort haben, ja dann kann ich sagen, also der Kühlschrank steht in der Küche.

Das schicke ich jetzt anders API und an dieser Implementierung, die haben gleich gesagt, Oh, das macht vielleicht keinen Sinn, nur eine Location zu erlauben, ja, sondern ich kann kann mehrere Location Objekte einem Ding zuordnen, das heißt aber das heißt aber, dass sie trotzdem logisch einen gleichen Ort beschreiben sollen, nur auf verschiedene encoding Arten.

Also wenn ich sage Küche, dann würde ich typischerweise sagen die Geo Koordinaten das geo Jason, also ne Latitude and longitude für den google Punkt sag ich mal. Ja das ist eigentlich immer Standard wenn ich n Location mache dann denken dann denkt die Sensor IP erstmal in. In einem Google Location Punkt, also Leon Brittan breiten Maß kannst du noch, da kannst du noch beliebig viele

Zusatzinformationen dazu geben. Ja du kannst aber auch sagen, hier habe ich n Bild was diese Küche anzeigt oder wo die Küche

markiert ist. Auf dem Flur planen oder Irgendsowas ja so das würde ja auch diese Küche beschreiben und auf eine andere Art und Weise und alle diese Locations, die kann ich aber an dieses Ding Kühlschrank dran kleben und verwalten ne einfach nur verschiedene Arten diese Location auszudrücken ne das ist wichtig und und jetzt ist es noch viel wichtiger und da brauchen wir ganz essenziell.

Und wenn ich jetzt zum Beispiel einem Ding ne Location geben, dann auch gar keine Location haben, ist auch ganz frei. Ja, wenn ich sie immer eine gebe und verändere die danach, also sage ich, sag zum Beispiel wie ich ziehe um, ja, und ich gehe mit meinem Kühlschrank in die nächste Wohnung rüber, ja.

Na dann ist der Kühlschrank umgezogen und das will ich vielleicht auch wissen, weil weil, weil, weil dieses ganze Lifecycle von dem Kühlschrank weggeschmissen so ja, und wenn ich jetzt irgendwie irgendwelche Daten angucke, dann werde ich vielleicht zum Beispiel im Statistischen Drop sehen, vielleicht in der nächsten Wohnung, ist irgendwie immer ein halbes Grad wärmer gewesen als in der alten. Ne, man fragt sich immer nur das, was da passiert.

Ja, und jetzt ist es gibt Historical Location, das passiert automatisch. Das nächste, das. Nächste Objekt, das ist eines von zweien, die ich gesagt habe, die nicht so wichtig sind. Ja, aber die, die das automatisch passiert, also wenn ich eine neue Location.

Gebe dann merkt sich quasi diese samanthas API, die alte Location mit Zeitstempel ja so dass ich dann im Nachhinein immer auf n Ding gucken kann und sehe seit der Existenz von diesem Ding, wo war es überall mal total wichtig, ja so Kleinigkeiten wie alt sind sie denn weiter? Dann gibt es nächstes die Observed Property. Also quasi die die Eigenschaft,

die ich angucken möchte. Ja, das sind klassischerweise sowas wie Temperatur, Druck. Co 2, Gehalt, lautstärke was weiß ich also alles was ich so also im Prinzip die Einheit ne was ich messen kann so ja und davon brauche ich eigentlich eine Temperatur anlege, dann habe ich angelegt ist im Prinzip nur dass. Quasi die brauche ich nur einmal anlegen. Ja, wenn auch wenn 1000 andere Sensoren innerhalb von diesem ganzen 6 p eine Temperatur messen, dann brauche ich nur diese eine Absage property

temperature. Die dann aber durchaus mit mehreren. Wieder genau das. Relationale muss jedes Mal neu anlegen, so, deswegen ist das alles mit einer relationalen Datenbank aufgebaut und das Wichtige ist, es gibt auch da und hier sind wir wieder in den Standard, es gibt eine Standard Beschreibung wie Temperatur ausgesehen hat. Und die wird referenziert. Dann in diesem Fall mit einem Link tatsächlich RTPS la Irgendwie Standard Institut und da steht da genau drin, was ist

eigentlich Temperatur? Ob in Grad, Celsius oder fahrenheit. Und so weiter. Ja, weil weil wir in der deutschen Industrie sind, da muss halt alles irgendwie gedient und gestartet, eine Temperatur vielleicht einfach, aber vielleicht weiß ich ja irgendwie bei bei irgendeiner Akustik Einheit oder irgend so was. Du sagst, du sagst jetzt in der deutschen Industrie muss alles so standardisiert sein, aber die OPC nicht international. Also. Ja, ich habe gesagt, das ist sogar.

Es ist sogar internationalen Standards genau auf verschiedenen Sprachen so, dass jeder angucken, genau, ja, na

ja, da hast du recht. Danke für die Korrektur, so genau, also wir haben jetzt wieder mal hat jetzt ging die Location. Die Property jetzt kommt der Sensor ne der Sensor ist, das find ich cool also das Ding ist der Kühlschrank aber der Sensor ist halt der T der Temperatur Sensor ja zum Beispiel mal kurz geguckt, wir haben hier immer IR Sensor also Infrarot Temperatur Sensor gibt es MLX 90 615 irgendwas kannst du kaufen 6,15€ oder irgendwas ja beireichelt.de

den klatscht du dann halt in deinen Kühlschrank rein, dass die Temperatur misst, denn es ist ja nicht der Kühlschrank die Temperatur sondern der Sensor. Ja und jetzt kommt es nämlich du könntest nämlich auch der Kühlschrank ist deswegen das Ding könnte sogar mehrere Sensoren besitzen ne du kannst ja zum Beispiel auch noch feuchtigkeits Sensor drin haben. Dass du guckst, irgendwie, dass Salat nicht wird oder irgendwas. Ja, dann ist der halt quasi irgendwie Feuchtigkeit.

Ja, und dann ist das aber ein anderer Sensor. Ja dann hast du halt 2 Sensoren in einem Ding. Ja, das ist der logische Knackpunkt den wir da, den wir da haben muss die Sensoren an die Dinge denken, ja ja, das ist ziemlich irgendwie stellt sich heraus, dass das irgendwie cool benutzt und dann haben wir als fünftes Data Stream. So ne Data Stream ist ein ist quasi die Aufzeichnung von und jetzt muss ich gleich den nächsten noch mitnehmen um das zu erklären. Von Observations ja.

Also Observation ist quasi eine Messung zu einem Zeitpunkt, das

ist wichtig. Ja, also jetzt, ich nehme das Beispiel, den Kühlschrank ja und die Temperatur hat mir gesagt, dass die Observation Property dann ist eine Observation die Temperatur Messung zu einem bestimmten Zeitpunkt ja und das heißt in der Observation zum Beispiel steht drin, dass result 4,5 Grad am 23.7.1923 ja. Also n Wert und n. Und Time Stamp und ich vereinfache hier kurz n bisschen der Times sogar noch akkurater als n Time Stamp man

unterscheidet. Sogar zwischen Phänomenen Time, also wann ist das Phänomen, wann war das Phänomen, ja und wann war die Aufzeichnung tatsächlich in die Datenbank? Das ist manchmal unterschiedlich, wenn du eine

Latenz zum Beispiel drin hast. Ja, eigentlich ist das schon früher aufgetreten und zum Beispiel lorawan Sensor, keine Ahnung, der liest dann 5 Minuten bis zu den Rübergeschickt oder irgendwas, ja dann hast du quasi eine unterschiedliche Zeitpunkt des tatsächlichen Wertes, weil er in der Natur vorgekommen ist und der Zeitpunkt war r quasi technisch festgehalten wurde, all diese Dinge, ich sag nur so, da kann man halt in dieser Sensor. API spezifizieren ja, kann man,

muss man nicht. Im einfachen Fall ist beides gleich und dann muss auch nicht, ja reduziert sich zu den einfachen Defaults ja, aber es ist halt cool, man merkt halt an der Stelle, dass da viele Leute sehr scharf nachgedacht haben. Weil ja wahrscheinlich auch praktische Erfahrungen gemacht. Haben genau ganz genau. Ja, weil so ein Kühlschrank Temperatur ist maximal einfach. Ja du kannst auch Satelliten irgendwas auf der Erdoberfläche misst.

Ja dann hast du irgendwie, dann werden die schon wieder komplizierter. Ja das kannst du dann trotzdem noch mit diesem Modell schreiben. Jetzt muss ich noch mal zum Datenstrom zurück. Der Stream heißt es, der verknüpft immer genau einen Ding, einen Sensor und eine Observe Property.

Ja, das ist ein Datenstrom und und produziert dann verschiedene Observations. Also ich gebe das Beispiel, der Data Stream wäre zum Beispiel, wenn wir jetzt sagen, wir haben unseren Kühlschrank, und zwar einen ganz genau definierten ne Kühlschrank XY mit dem Sensor MLX 90 615 R Sensor drinne ja der in der Küche steht mit den Koordinaten breiten Grad soundso Längengrad so und so. Und wir messen die Observe Property Cambridger. Dann ist der Data Stream sind

quasi Messungen zu bestimmten Zeiten von allen diesen Datenobjekte nicht gerade genannt habe und dann wird ein Schuh draus, weil dann. Dann weiß ich ganz genau, was sind das für Observations? Ja von welchem von welchen Dingen an welchem Ort. Ja, mit welcher Property von

welchem Sensor gemessen ne? So, und wenn du das jetzt alles loslässt, auf verschiedene Dinge, verschiedene Sensoren, verschiedene Server, Properties und so weiter und da immer schön einen pflegst, kriegst du nen ziemlich organisiertes Bild von dem ganzen Kram. Auch wenn du die Dinge quasi durch die Gegend schiebst und eine neue Location hast, weil dann haben wir die Locations. So lass uns das mal als Beispiel durchgehen. Also was die Dinge durch die

Gegend schieben. Du hast vorhin gesagt, den Kühlschrank, jetzt neue Wohnung. Genau. Dann hat er immer noch die Küche als Location, aber halt ne andere Küche. Genau. So, und dann würde ich jetzt, wenn ich die entsprechende API nutze, gibt es da einen standardisierten Befehl, der nicht von irgendwo sendet, zum Beispiel aus einem. Frontend oder wo ich das manuell eingeben oder aus auch programmatisch von irgendwo nicht.

Ein Befehl an dieser API und sage OK die neue Location von diesem jeden Thing ist jetzt ne andere und das Ding automatisch alle Sensoren die mit diesem verknüpft waren auch natürlich dann woanders sind und genau das wird einfach alles für übernommen, sozusagen der. Genauso ist es ganz genau und du Sendest mit einem. Also wir machen n Cut ja die APIS create read Update delete ja mit den gemachten, das kann ich auch mal sagen, weil das alles standardisiert ist.

Das hatten wir schon mal. Frage also du benutzt die HTTP werben ja also get für ne auslesen von irgendwas, ja. Imposed für das Anlegen also jetzt in deinem Beispiel gerät, wenn wir die neue Küche haben, dann müssten wir mit einem Post eine neue Location anlegen. Die Küche, der Kühlschrank stehen sie noch nicht? Ja, machen wir Post.

Also das ist quasi das Create dann ja vom Cut Post und und wenn wir jetzt quasi jetzt müssen wir quasi den das Ding, nämlich den Kühlschrank updaten, dass der neue Location hat, also ist das Update ne Update und das machst du dann über einen über einen jetzt muss ich kurz überlegen über einen Put, in diesem Fall es gibt Put und Patch, beides als Verben im HTP, beides wird genommen um Updates zu machen, meistens wenn du die gesamte Ressource updaten willst Patch wenn nur Teile von der

Ressource. Updaten möchtest. Ja, vielleicht ist es hier ein Patch, weil du nur den Aspekt der Location von dem Ding ändern willst. Ja, aber egal, gut oder Patch ist das ist das ist die ist der Befehl für die Rest API und wenn du löschen willst zum Beispiel die Küche, ja das Haus abgerissen brauchen mehr geht nicht mehr machst Elite. Also die Leute ist auch das gleiche Verb im. Genau. Also das ist eigentlich der Kern von so Device Management Geräte

Management was man. Immer am Prinzip, nichts anderes. Ne. Also das ist das ist nicht machen, das ist ein logischer Kerne, du kannst Sachen kreieren, du kannst Sachen auslesen, du kannst Sachen verändern und du kannst Sachen löschen, ja und wenn du wenn du diese 4 Operations drauf hast und dann auch noch mit diesen Ganzen, das war wichtig was du gesagt hast, der ganze Rest passiert irgendwie automatisch.

Und dieser ganze Rest, der automatisch passiert, ist halt genau diese relationalen Dinge, weil alles hängt mit allem

zusammen. Haben jetzt gebucht erzählt ne und das ist nicht so einfach, hier steckt die hier steckt der Power von dieser von diesem Ding, es macht halt quasi diese ganzen relationalen Gefüge heile, auch wenn du von außen irgendwie das Manipulierst ja und verfolgt für dich genau was los war und legt quasi zum Beispiel die alte Küche in die historische Location an ne und die neue wird neu verknüpft.

Ist halt voll cool so. Ja, und diese ganze und diese ganze Art und Weise, wie du halt mit dieser PI sprichst halt über dieses O Data Ding standardisiert und das ist auch

ganz cool. Du kannst dann auch Anfragen machen, du kannst zum Beispiel sagen, für dieses Ding, zeig mir alle Data Streams an, du hast ja relationale Zusammenhänge, du kannst ja du kannst jetzt queries, nennt man das ne du kannst jetzt oder bei diesem reinen Modell was ich ganz am Anfang gesagt hast, du kannst jetzt 1000 Fragen stellen, Überlegungen überlegen was du wissen möchtest.

Ja du kannst zum Beispiel sagen. Innerhalb dieser Locations zeigen, welche Dinge da wieviel sind, so wie viele Dinge ich da hab. Ja und oder oder sogar welche Sensoren ich da hab und welchen Dingen die zugeordnet sind und so weiter also man kann sich fragen überlegen und die kann man sauber abfragen mit dieser API. Ja und du kannst auch limitieren wieviel Ergebnisse rauskommen und so weiter. Und das ist vielleicht doch. Ziemlich standardisiert. Noch spannender, wenn man sagt,

OK welche? Wenn du zum Beispiel in der Industrie 4.0 oder Produktion Maschine ein Ding ist, die hat dann vielleicht sogar 18 Soren verbaut oder sowas und ich krieg dann alle Daten, Streams angezeigt oder was du gesagt hast. Das Beispiel mit den öffentlichen Gebäuden zeigt mir alle. Sind alle Dinge oder alle Sensoren, die sich in dieser Location dann quasi befinden. Oder denken über finstere Sache nach. So zum Beispiel Smart City.

Und Autos können vielleicht das Ding ja und das Auto ist ja voll mit Sensorik. Ja, das hast du auf einmal n Ding mit 20 Sensoren und die Location von dem Auto, die updatet sich halt alle naselang und so, man muss dann halt immer gucken und das ist dann noch die Kunst. Aber also wir haben jetzt hier nen Modell, das muss nur einmal

Anwendung der SensorThings API

verstehen wie es gemeint ist und die Best Practices inhalieren und dann ist das aber so gut gemacht, dass man fast jedes Real World Problem. IO Problem dann in dieses Modell

mappen kann. Da muss man ein bisschen aufpassen, muss jetzt genau gucken was ist mein Ding, was ist mein Sensor, was ist meine Location oder habe ich mehrere Locations, wann ändere ich die, wann nicht und so weiter und sofort, das ist jetzt noch die Kunst desjenigen, der das irgendwie benutzt, diese PI, das ist auch jetzt in diesem Fall für unseren Kunden der Anspruch an uns, dass wir dass wir dieses, dass wir dieses Problem, dass wir haben, was erkunde,

beschrieben haben möchte, so verstehen und so verwalten, dass es gut verwendungs I Pasta. Aber da gibt es auch viele Tutorials im Internet und so. Und ich glaube, wenn n bisschen übt und man kann es gibt auch so Demo Servers und so, da kommt man schnell dahinter. Ja und wenn man merkt auch relativ zügig wenn man irgendwie falsch abgebogen ist. Ich hab auch nicht ganz am Anfang gleich richtig gemacht.

Auch mit den Locations und so. Das fand ich irgendwie am Anfang noch nicht, wenn es so erklärt, dann ist es klar mit mehreren Locations und so, dass sie einen Ort beschreiben, aber wenn man reinkommt, dann ist es vielleicht ja, aber man kriegt es gebacken. Bist du mit der technischen Beschreibung durch, dann habe ich noch. Ich bin durch, ich bin durch mit ich geh, ich würde einmal wiederholen kurz, was wir was jetzt diese 6 Modelle waren die wichtigsten sind. Macht es gibt noch ein.

Feature of Interest Das ist eigentlich die, also das gehört zur Observation, das ist quasi das sagt was Messe ich da eigentlich gerade und ist. Es normalerweise die Location vom Ding ja ist kann man, könnte aber nochmal extra beschrieben werden, aber die sind lass ich gerade raus. Also ich wiederhole nochmal hasi 6 wichtige Objekte ich sie gleich auf Deutsch das Ding den Ort vom Ding.

Die, die, wie soll ich da observe Property was Deutsche für den das war das Observe Property beobachtete Eigenschaft genau oder mehrere Eigenschaften Größe genau den Sensor. Einen einen Data Stream auch schwer zu übersetzen, eine die Folge quasi und die Observation selbst, also einen Messpunkt. Ja ja, so und und die sind alle wunderbar ineinander verhakt und mit einer API Einfügbar Update Bar abfragbar und da ist schon ne ja schon ist gut aber damit erledigt.

Man dann, wenn man die Probleme und wenn man wie du sagst dann beschreibt, kann man mit diesem Modell quasi. Ja, ich weiß nicht alle io t use cases abbilden, aber mindestens

mal ganz schön viele. Ja, und das Schöne ist ja, wenn und wenn das wenn sich so, also das ist wirklich und es zeigt sich in der Geschichte, dass sich die Standards durchsetzen, die einfach sind, und der ist einfach genug, ja, also wir haben hier 6 Objekte, ja und und je mehr Leute das benutzen, das muss ja auch dran denken, also stell dir vor, es ist schon irgendwas in dieser API eingetragen und man kann das selber auch, man kann ja auf einmal den ganzen Kram

zusammenbringen und sammeln, ohne dass das kaputt geht, ne und auf einmal habe ich riesige kann ich riesige Internet der Dinge Geschichten verwalten und die auch ganz neuen Beziehungen.

Essen kann ich zum Beispiel auf einmal, zum Beispiel vielleicht irgendwo werden die irgendwie im Forst Server abgespeichert wurden mittels Sensorik und jetzt kann ich auch einmal das Wetter in Beziehung setzen zur Wasserqualität oder Irgendsowas vielleicht sagen Einfluss, weil es mehr oder weniger geregnet hat, ja Salzgehalt im Wasser ja abhängig von der Regen Niederschlagsmenge und so weiter das sind ja die Fragen, die wir

beantworten wollen und und und. Die Daten Modelle, die wir verschaffen wollen und um die überhaupt zu haben, die Faktenlage hinzu bilden, damit wir Data Science drauf machen können und analysieren können, dafür brauchen wir halt solche standardisierungs Modelle wie Frost Server. Beziehungsweise wie 6 I in Form einer Frost Server Implementierung zum Beispiel genau. N bisschen hat schon die Frage beantwortet, die ich stellen

wollte. Du hast gesagt, Anfang hast du überlegt, dass vielleicht sogar selber zu implementieren, also etwas ähnliches ein eigenes Daten Modell quasi zu zu entwickeln und nicht 1 zu nehmen und das Problem darauf zu projizieren, quasi in welchen Fällen würdest du dich denn für etwas entscheiden was es schon gibt und in welchen Fällen entscheidest du typischerweise dafür etwas selber zu machen?

Hast du da faustregeln oder? Ja, Oh, das ist eine sehr gute Frage. Na, ich glaube, ich gucke mal nach, wo komme ich am schnellsten ans Ziel und also nee, nicht nur ja, also natürlich ist die erste wichtige Frage ist, wie komme ich am schnellsten zum Ziel, wenn ich natürlich irgendwie neuen Standard mir erst mal reinziehen muss, was ich musste, weil ich ihn nicht kannte, dann dauert das natürlich erstmal n Schluck Zeit bis du das irgendwie auf

der Karte hast. Ja, während wir nicht irgendwie angefangen hätten wir direkt meine Tabellen Design, dass ich sofort anfangen können, weil ich weiß wie man halt Datenbank, Tabellen, Design so ja das zweite ist was ist halt die nachhaltigere Lösung und wenn du n Standard nimmt uns nicht selbst immer nachhaltiger. Oder noch mal noch anders gesagt, irgendwas nehmen kannst. Schon gibt es immer besser, weil du den Code nicht selber warten musst.

Ich sag immer jede Zeile Code du selber schreibst oder jedes jeden Business Prozess den du selber denkst denkst du musst du halt ne ne selbst verantwortlich und wenn es schon da ist und schon getestet ist für dich oder dann ist ja easy. Ja, und dann auch noch ein gewisses Renommee vorhanden ist.

Genau das Fraunhofer. Und dann probierst du es natürlich aus im Kleinen, im kleinen Pilotprojekt und wenn ich dann auch überzeugt, ja gut, dann ist der Weg nicht mehr weit in den Sprung zu machen, hier an dieser Stelle ist es so, dass wir von diesen 6 oder 8 Objekten. Es gibt ja tatsächlich für dieses Kunstprojekt nur 3.

Brauchen wir diese Ganzen im Prinzip die ganzen Messungen und so weiter die die sind jetzt gerade nicht im Aufgabenspektrum, aber stell dir vor, es kommt soweit, dass wir vielleicht sogar das machen oder im nächsten Projekt ein ähnliches Projekt beim gleichen Kunden, die ihr vielleicht auch die. Messergebnisse abspeichern?

Egal, ja. Dann sind wir, dann sind wir sofort fertig, weil wir genau wissen, wie wir es machen, ne so, dann muss ich noch irgendwie neu und ich glaube ich wäre nie auf so ein geniales Datenmodell Datenbank Modell gekommen wie API. Da waren ein paar mehr Experten dran als mein klappriges Gehirn. So. Du, deine letzte Frage. Wer oder für wen könnte das dann noch interessant sein? Sich das noch mal genauer

anzusehen? Also. Ist das ein Entwickler reines Entwicklertool oder sollte man auf dem Schirm haben, wenn man Produktmanagement zum Beispiel macht oder so? Oder kannst du da eine Einschätzung abgeben? Na ja, also ich finde es immer schwierig. Ist auch die Frage ich, das weiß ich jetzt auch nicht wie, wie ist dieser Standard, wieviel nutzen das schon Standard ist ja auch erst dann Standard, wenn es irgendwie eine gewisse Menge an Leuten nutzt, da so gewisse

kritische Masse sag ich mal. Ja, ich meine jetzt aus ganz vielen da draußen, die sich mit OT beschäftigt. Ja genau darauf wollte ich noch k. Und es ist dieser Standard. Ist halt noch relativ frisch und während das Problem OT schon viel älter ist und ich glaube es gibt Tausende und eine Firma draußen. Die das Tausendundein mal gelöst haben. Genau dieses Problem, auch das wird ne.

Ich hab jetzt vor auch wieder zu machen ne und so haben glaube ich fast alle haben jeder hat so seinen seine Datenbanken und seine Art des zu verwalten ja garantiert ja. Ich würde allen empfehlen, dass man sieht es schon. Ich habe jetzt auch Palmen gesehen, die dann sagen, OK, cool, wir sehen diesen Standard und wir haben jetzt erstmal unseres eigenen, unseren eigenen Kram. Aber wir führen diesen Standard ein und synchronisieren quasi unser unser Daten Modell mit diesem Standard Modell um

wenigstens quasi. Also nach außen hin quasi eine zweite Schnittstelle zur Verfügung zu stellen. Ne in in der quasi standardisiert diese Daten abfragbar sind. Diese Firma die vielleicht diese o Firma schon längst irgendwie gesammelt und und abgespeichert hat, so, ja das bringt unheimlich Mehrwert, weil wenn es jetzt mehr und mehr und mehr Entwickler geben die diesen Standard kennen und mehr und mehr Tools die irgendwie drum herum gebaut werden, das ist typischerweise der Fall.

Und ne Firma sich entscheidet die schon immer IOT Sachen gemacht hat, diesen Standard quasi auch noch zur Verfügung zu stellen als zweite A. Keiner zwingt dich nur ein AB zu haben. Du kannst ja zig APS haben, ja sagst du hier ist unser Things I wenn das im Frost Server Format

Krams haben wollte. Ja und das kann unglaublichen Mehrwert schaffen, weil dann auf einmal andere Firmen total einfach erhöht werden, da die Daten abzufragen weil die quasi ihre Infrastruktur schon auf diese PI vorbereitet haben, also alle die mit IOT was machen finde ich sollten mal kurz wenigstens rechts blinzeln und mal drauf gucken und sich fragen ob das nicht vielleicht eine Sache ist und ob vielleicht sogar noch besseres Datenbank Design ist als man.

Wer sich ausgedacht. Hat OK alles klar, prima, dann machen wir den Deckel drauf für heute. Denn nochmal drauf, ich hab auch schon den Kaffee getrunken, meine Stimme wird heiser wie gehört ist vorbei. Ist aus aus, genau, danke fürs Zuhören und ja danke, wie immer Burkhard und bis nächste Woche bei einfach. Komplex, gerne und Tschüss. Hamburg. Einfach komplex wird produziert und präsentiert von Heisenberg. Weitere Informationen findest du unter heißen ware.com.

Vielen Dank fürs Hören dieser Folge und bis nächste Woche Tschüss Hamburg.

Transcript source: Provided by creator in RSS feed: download file
For the best experience, listen in Metacast app for iOS or Android