Dann erzählen wir uns jetzt ein bisschen was über CTN oder The Sinks Network. Sonstweise dem Stack der Community Edition. Stage ist yours. Ja, vielen Dank. Ich bin Caspar, das ist Jens. Wir sind direkt zur Info vorweg geimpft und getestet.

Also wir sind sonst ein bisschen zu nahe sonst in diesen Zeiten. Wir haben auf der PowerPoint oder im Slides hier tatsächlich einen richtigen Titel. In der Vorschau steht noch V2 zu V3 drin. Mittlerweile wurde der V3 The Sinks Stack zum The Sinks Stack Community Edition umbenannt.

So ist es richtig, so wie es jetzt hier steht, wenn man das mal so ganz genau nehmen möchte. Kurz vorweg. Wer sind wir eigentlich? Das bin ich. Ich bin Caspar. Ich gestalte eigentlich Fernsehstudios, also Set Designer.

Ich beschäftige mich aber auch mit dem Thema IoT professionell. Wir haben einen kleinen Verein in Hannef, der heißt das Digi-Dinks, eingetragen, gemeinnützig und so weiter. Da erzählen wir gleich ganz kurz auch was zu. Da bin ich Vorstand drin. Ich habe das The Sinks Network hier im Rhein-Sieg-Kreis mit aus der Taufe gehoben. Und wenn man mich sonst außerhalb von Corona auch hier in der Region finden will,

dann bin ich auch im OK Lab von Rhein-Sieg, also von der Open Knowledge Foundation, kennt man das Ganze. Genau. Und mein Name ist Jens Nowak. Ich sage auch ein herzliches Hallo in die ganze Runde an unsere Zuhörer, sowohl im Livestream als auch im Chat.

Ja, ich bin Digital Immigrant. Also ich kenne auch die Zeit vor Internet und vor IoT und vor The Sinks Network. Im wahren beruflichen Leben bin ich im Sondermaschinenbau Projektmanagement tätig. Und in meiner Freizeit, die bleibt neben meiner Tochter, habe ich halt ganz viel mit Ehrenamt zu tun, Digitalisierung, unter anderem auch im Vorstand vom Digidinks e.V., was Caspar gerade schon anmoderiert hat.

Ansonsten beschäftige ich mich eben noch mit dem Vorstand vom Heimatverein, also auch so richtig klassisches Ehrenamt auf dem Dorf. Gründungsmitglied von der Dorfquelle. Das geht in die Schiene digital. Ja, auch digitales Ehrenamt, Nahversorgung auf dem Dorf,

das Abholen von älteren Herrschaften, um den Möglichkeiten beizubringen, wie man eben digital teilhaben kann, Nahversorgung organisiert, Dienstleistungen digitalisiert und solche Geschichten. Ja, und dann mit Caspar gemeinsam eben The Sinks Network rein Sieg.

So, vorweg kommt die ganz kurze Werbung für den Verein, den wir sind. Neben der Infrastruktur, da kommen wir gleich noch drauf, machen wir ganz viel Arbeit mit Kindern und Jugendlichen. Jetzt in den Sommerferien mehrere Wochen programmiert mit Kindern hier im Jugendprogramm. Wir machen regelmäßig jeden Freitag eineinhalb Stunden Coding mit Kindern über die Stiftung Lesen

zusammen mit dem Kinderschutzbund der Stadt Teneff, nennt sich Media Labs. Wir bilden Multiplikatoren aus, also Grundschullehrerinnen, wenn es um die Digitalisierung geht. Wir haben während Covid einen eigenen Minecraft-Server mit aufgesetzt hier mit der Stadt zusammen, um den Kindern irgendwie Kontaktmöglichkeiten untereinander zu geben, weil sonst die normalen Offline-Kontakte ja relativ weggebrochen sind.

Um mal zum Beispiel zu zeigen, was wir mit dem Verein machen und die zweite Seite des Vereins. Genau, das ist dann eben halt dieses ganze große Thema, was wir eben schon mal ganz kurz angerissen haben. Digitale Infrastruktur. Das bedeutet, dass wir Hauptinitiatoren von The Sinks Network rein Sieg sind, von der Community.

Wir betreiben einen Großteil der Gateways, die hier in der Region laufen, die dann eben die Möglichkeit bieten, dass die Sensoren, die dahinter laufen, eben auch ihre Daten irgendwo in der Cloud loswerden können. Beispielsweise haben wir gemeinsam mit dem Amherd Sinksnet mittlerweile 32 Feinstaubsensoren,

die in der Nähe rund um Bottrop laufen, aufgebaut und betreiben diese. Lokal betreiben wir verschiedenste Sensoren. Da geht es um Hochwasservorwarnsystem. Da geht es auch um Umweltsensorik, CO2-Sensorik in Klassenräumen, Thema Lüften und Coronavirus. Und unter anderem, wo wir auch ganz stolz drauf sind, wir haben einen tollen Partner gewonnen.

Wir arbeiten mit dem Freifunk Rhein-Sieg-Eng zusammen. Die stellen sehr viel von der Infrastruktur und vom Backend vom Freifunk, was wir dann eben in Zusammenarbeit erweitern mit LoRa-Gateways, die dann gegebenenfalls hinter einer Freifunkinstallation noch angebunden sind.

Das war der Werbeblock. Jetzt geht es richtig los. Der Weg zur V3. Früher nannte man das Ding V3. Um ganz kurz auszuholen, es gab auch eine V1-Mal ganz am Anfang von The Sinks Network. Das wechselte relativ schnell zu dieser Version 2. Und seit der Version 3 ist es tatsächlich richtig open source. Also man findet die ganzen Sourcen auf GitHub, kann sich da natürlich auch einbringen.

Also wer Fehler findet oder Probleme mit der V3 hat, ist gerne aufgerufen, sich dort auch ganz konstruktiv einzubringen. Die V3 heißt jetzt eigentlich The Sinks Stack Community Edition. Und das ist der offene Teil des LoRaWAN Netzwerkes,

was The Sinks Industries für uns quasi alle zur Verfügung stellt, wo wir alle kostenfreien Zugriff haben und welches wir selber erweitern können. Also quasi die Infrastruktur selber bauen, anstelle die, ich sag mal diese Magenta-Riesen und so abzugeben oder die damit zu beauftragen, das zu machen.

Das Ganze wurde schon eigentlich letztes Jahr angekündigt, aber richtig aktuell dieses Jahr zur Conference. Immer am Ende des Monats Januar im Jahr gibt es die The Sinks Conference in Amsterdam. Dieses Jahr natürlich, wie alles mögliche andere auch virtuell. Dort wurde die Roadmap für dieses Jahr bekannt gegeben.

Und der erste Hammer, der dann quasi auch veröffentlicht wurde, war der Freeze im Juni 2021 für die alte Version. Das heißt, seit Juni kann man quasi keine neuen Geräte mehr an die alte Version anmelden oder dort irgendwie verändern. Das, was läuft, läuft noch. Aber das war es dann auch. Der Beginn in die V3 war natürlich, wie bei allen neuen Software,

nicht ganz, ich sag mal, fehlerfrei und hatte auch so ein paar holprige Dinge dabei. Gerade auch das Zusammenspiel zwischen Community und The Sinks Industries war sicher nicht immer unangespannt, um es mal so zu sagen. Da wurde zum Beispiel auf relativ schnelle Art und Weise entschieden,

dass die Payload-Decoder nur noch 4K Zeichen groß sein durften. Und das funktioniert vielleicht für ein Gerät, was einen Sensor irgendwie betreibt. Aber in dem Moment, wo man so multifunktionelle Payload-Decoder schreibt, ist man schnell mal bei der doppelten oder dreifachen Größe. Und das funktionierte dann plötzlich nicht mehr. Also man konnte zeitweise tatsächlich auch kommerzielle Sensoren

wie den Clux oder so, den man kaufen kann, der zum Beispiel die Stromdaten überwacht, nicht mehr ins The Sinks Network anmelden, weil man die Daten nicht mehr herausbekam, weil der Payload-Decoder, der dort mitgeliefert wurde, sich nicht mehr eintragen ließ. Mittlerweile ist das wieder angehoben, das Limit. Und es gibt auch Wege drumherum.

Aber das sind so ein paar Teile, die nicht ganz einfach waren. Das Gleiche gilt für, da steht so schön TTIG, das ist das The Sinks Indoor Gateway. Genau, danke. Wo es nach wie vor jede Menge Probleme gibt. Und wenn man das im Forum, also Probleme sind es eigentlich nicht, sondern eigentlich sind die alle gelöst. Aber im Forum tauchen immer wieder Menschen auf,

die die Geräte neu haben oder die jetzt umziehen wollen und die den Fehler machen, die erst mal aus der alten V2 herauszulöschen, um sie dann in der V3 neu anzulegen, was nicht funktioniert. Es gibt einen besonderen Weg für diese Geräte. Man muss sie sogenannt claimen. Also man muss quasi nachweisen, dass man selber der Besitzer dieses Gateways ist,

über einen WLAN Schlüssel, den man dann entsprechend auch eingeben muss. Und dieser Weg ist halt nicht der einfache. Also wenn ich ein anderes Gateway umziehen würde, würde ich einen anderen Weg gehen. Und speziell für dieses muss man den einen Weg gehen. Genau. Und da darf ich an dieser Stelle mal ganz deutlich auf das Forum vom The Sinks Network hinweisen,

weil diese ganzen Fragen, die sich einem Benutzer auf einmal stellen, weil er Schwierigkeiten hat, die sind alle erklärt. Und auf der Webseite von The Sinks Network gibt es mittlerweile, ich betone es ganz klar, mittlerweile ganz tolle Leitfäden Schritt für Schritt, wie man die WLANs umzieht, wie man Gateways umzieht und eben was Caspar angesprochen hat, wie man das Indoor Gateway

von The Sinks Industries eben halt claimt, also von der V2 in die V3 hebt. Ein weiteres Problem, was hier stand, ist die Einbahnstraße Packet Broker. Ganz am Anfang war es so, dass man die Daten, also der Packet Broker, um das vorzustellen, ist so eine Art Hub

hinter den verschiedenen LoRaWan-Netzwerken oder beziehungsweise das ist die Idee, den da drüber aufzubauen. Man kann, wenn man private oder öffentliche LoRaWan-Netzwerke betreibt, sich an diesen Packet Broker anklemmen. Das Ganze geht per MQTT und werden die Daten nachher ausgetauscht. Und so kann man quasi auch netzwerkübergreifend Daten austauschen

zwischen verschiedenen LoRaWan-Netzwerken. Jetzt war allerdings die alte Version, die V2 und die neue Version V3, waren beide über diesen Packet Broker verbunden, aber nur in eine Richtung. Das heißt, ich konnte die Daten nur in eine Richtung schleusen und nicht wieder zurück. Das hat sich mittlerweile auch eingespielt. Auch das geht in beide Richtungen. Aber so gab es halt jede Menge Dinge, wo man, ich sag mal,

Spezialwissen im letzten halben Jahr brauchte, um die Sachen umzuziehen. Dem ist jetzt, wie Jens das eben auch sagte, nicht mehr so. Also mittlerweile sind die Anleitungen alle geschrieben. Also natürlich kann man die immer noch weiter verbessern. Das ist klar. Es gibt jede Menge Know-how bei verschiedenen Personen, in verschiedenen Communities und im Forum, im Wiki von The Things Industries.

Und jetzt wurde halt auch vor kurzem die Abschaltungen von der V2 auf den 1. Dezember. Bis jetzt hieß es immer Ende des Jahres. Das ist nun noch mal 30 Tage vor Ende des Jahres angekündigt. Das heißt, dann ist wirklich Schluss. Und an der Stelle muss man sagen, wenn noch jemand überlegt,

ob er umziehen soll, das ist die falsche Überlegung. Es geht nicht darum, ob umziehen, sondern es geht darum, wann umziehen. Da kann ich nur sagen, wir sind jetzt auf dem Punkt, wo die V3 tatsächlich das Maß der Dinge ist und die V2 nur noch Legacy quasi im Betrieb ist. Man sollte eigentlich sofort umziehen. Also am liebsten morgen.

Sprecht uns an, wir helfen auch gerne dabei. Oder wer gleich noch im Anschluss seine Sachen schon umziehen möchte, je schneller, desto besser, würde ich jetzt an dieser Stelle behaupten. Weil die V3 sicher auch noch ihre Unstabilitäten hat, aber sie ist zur Zeit der Stand der Dinge. Und wenn es über den TTN-Mapper und so weiter geht, dann ist in allen Bereichen im Grunde genommen mittlerweile die V3 zu bevorzugen.

Und also Umzug, wenn nicht jetzt, wann dann? Genau, wir waren relativ früh natürlich dabei. Also während der Konferenz haben wir schon das erste Gerät umgezogen, so einen klassischen Arduino Pro Mini mit einem BME 280. Wir hatten eben einen Kollegen von Bosch da, die baute diese ganz hervorragenden kleinen Sensoren,

ob das jetzt ein BME 280, BMP 280, BME 680, wie die alle heißen. Es gibt da ja quasi eine ganze Wundertüte an Sensorik. Das erste Device haben wir schon umgezogen während der Konferenz, um es einfach direkt mal auszuprobieren. Das, was die behaupten, funktioniert das auch. Und es funktionierte mit so ein paar Hürden

und ein paar Fallstricken, aber es funktionierte. Direkt zwei Wochen danach haben wir unser erstes Gateway-Test umgezogen. Das ist so ein Low X1. Wer das kennt, ist so ein Schweizer Modell, sieht aus wie so ein Lichtschwert. Also wenn man Lichtschwert Gateway sagt, dann wissen die meisten Bescheid, was das ist. Das haben wir nicht nur auf die V3 umgezogen, sondern wir haben auch direkt das Protokoll gewechselt.

Es gibt neben dem Multi-Packet-Forwarder, der früher verwendet wurde, gibt es jetzt ein neues Protokoll. Das nennt sich Basic Station. Hat Vor- und Nachteile, kann man auch darüber diskutieren. Einer der Vorteile ist, dass die Datenübertragung zwischen Gateway und dem Netzwerks-Server

jetzt auch noch TLS-verschlüsselt ist. Einer der Vorteile davon. Also doch obendrauf auf die normale, sonstige Verschlüsselung. Genau, und dann ging es Schritt für Schritt weiter, dass wir eben gesagt haben, wir haben den ersten Promini umgezogen und jetzt widmen wir uns den weiteren Sensoren,

das war eben, Caspar hat ihn eben schon angesprochen, diesen Clux, diesen optischen, die optische Schnittstelle, um die Stromzelle auszulesen. Wir haben die Pax-Counter dann in die V3 migriert. Wir haben die Taps-Sensoren migriert. Das sind diese kleinen Dinger, die einen Fensterstatus überwachen können

oder Temperatur vom Innenraum oder die Belegung vom Innenraum über einen PIR-Sensor. Dann ging es weiter über diese Rack-Sensorik, zum Beispiel den 7204, der die Luftgüte im Innenraum überwacht. Ja, dann haben wir diesen Ursalink UC11. Das ist ein Gerät, was eigentlich mehr

für die professionelle Automatisierungstechnik als Lauerwand-Schnittstelle gedacht ist, wo man eben auch echte analoge Sensorik hinterhängen kann, die auf 4 bis 20 milliampere läuft oder 0 bis 10 Volt und weitere verschiedenste Selbstbausensorik

wie Feuchtigkeitsüberwachung und solche Sachen. Ganz spannendes Thema ist gewesen, unsere Feinstaubsensoren umzuziehen. Ich habe es in der Anmoderation schon einmal gesagt. Wir haben 32 Sensoren in dem Netzwerk in Bottrop laufen, wovon wir, nachdem der erste Umzug als Einzelgerät in die V3 geglückt ist, alle 31 verbleibende Sensoren

mit einem Mausklick umgezogen haben. War natürlich ordentlich Vorbereitungszeit und ordentlich Herzklopfen, aber es hat tatsächlich funktioniert. Wir haben auf einen Schlag 31 Sensoren umgezogen. Danach kamen natürlich die Gateways. Das lag damals an der Sache, dass Gateways

aus der V2-Daten an die V3 weitergehen konnten, aber nicht in die Gegenrichtung. Also war die Idee zuerst, die Sensorik, die ganzen Devices umzuziehen und anschließend die Gateways umzuziehen. Mittlerweile, wie gesagt, geht das in beide Richtungen, also mit so ein bisschen stolpern und holpern, aber es funktioniert. Das heißt, wir haben auch ganz viele unserer Gateways schon umgezogen.

Das Logix 1 habe ich erwähnt. Wir haben vor einigen Jahren sehr viele Raspberry-Pi-Gateways gebaut, zum Teil auf EMST IC 880A, Zungenbrecher, Concentrator Boards aufgebaut. EMST ist ja ein Niederrhein-Unternehmen, was die tatsächlich hier auch baut. Wir haben aber auch Rack-Heads

quasi auf den Raspberry-Pis verwendet, also das Rack 2245 zum Beispiel und haben auch die umgezogen. Dafür gibt es eine komplette Anleitung bei uns auch im GitHub. Ganz am Ende, Hinweis dazu, haben wir eine ganze Seite mit Links. Also wir werden die Präsentation natürlich nachher auch zur Verfügung stellen,

dass man die über die Froscon-Seite abrufen kann. Und da sind einen Haufen Links drin, zum Beispiel in diverse Githubs. Also das Raspberry-Pi-Gateway, wir ziehen gleich ans Live um. Also nicht gleich, sondern am Ende wollen wir tatsächlich noch ein Gateway-Live mit euch zusammen umziehen auf dieser Raspberry-Pi-Basis. Die Microtik sind glaube ich sehr verbreitet. Auch die laufen natürlich schon unter V3,

weil die so relativ preiswert sind. Das waren quasi die ersten, ich sag mal, kauftlichen Outdoor-Gateways, die so unter die 300 € gefallen sind. Also die kosten noch 150 €. Aber wir haben uns auch mit den eher teureren schon auseinandergesetzt, also eine iStation for Curling zum Beispiel oder so entsprechend umgesetzt.

Genau. So, der Umzug an sich ist das eine. Was gehört jetzt alles dazu? Wir gehen jetzt erst mal von der Seite der Devices dran und anschließend gehen wir von der Seite der Gateways dran, um also ein bisschen zu zeigen, an was muss ich alles denken, wenn ich ein Device aus der V2 hole und in die V3 packe.

Wir machen das einfach mal für den Pax-Counter, also ESP32-Pax-Counter, der ist sehr bekannt, vom Cyberman54 auf GitHub zu finden. Open Source, großes Riesenprojekt, wahrscheinlich eines der bekanntesten Sensorprojekte überhaupt im LoRaWAN-Umfeld.

Mit, weiß ich nicht, wie viel mittlerweile umgesetzten Hardware, wie oft er umgesetzt wurde, läuft auf quasi so alle möglichen Boards, die es mit ESP32 gibt. Also wenn ihr ein Board da draußen habt, aus was LoRaWAN und ESP32 draufstehen hat, sehr sicher, dass die Software von dem Cyberman dort läuft.

Genau, ein anderes Stichwort in der Thematik ist dann halt einfach eben dieser klassische T-Beam oder LoRaWAN. Ttgo und wie sie alle heißen, von Haltech. Also es gibt ja Chinaware genug, ja, das ist die Software, das ist unsere Wahl, der Software dafür, weil mittlerweile, der hat angefangen als Pax-Counter,

deswegen heißt er auch so, was ist Pax? Das ist quasi ein People-Counter, also der zählt Bluetooth- und WLAN-Geräte in der Umgebung, was der ESP natürlich toll kann, weil er ja WLAN- und Bluetooth-fähig ist und übermittelt dann quasi die Anzahl der Geräte. Also der kann niemanden persönlich tracken, sondern nur die grobe Anzahl der Geräte

quasi wird dann übermittelt. Macht zum Beispiel auch während unserer Covid-Krise natürlich Sinn. Also wie viele Menschen habe ich jetzt gerade hier in diesem Ladenlokal oder so, um sowas einfach zu überwachen. Kann man an allen möglichen Stellen zum Einsatz bringen. Ich weiß davon, dass wir das in einem Museum,

das Outdoor-Dinge hatte, zum Einsatz gebracht haben, um zu schauen, wo sich welche Menschenströme, also nicht wirklich bewegen, sondern wo sich Menschenansammlungen bilden, in welchen Bereichen des Museums. Das ist mal als Beispiel. Und als wir den ersten davon in die V3 geschoben haben,

fiel uns auf, dass sich das Format vom Payload-Decoder verändert hat. Wir konnten quasi nichts mehr lesen. Von den Daten, die wir empfangen haben, kam einfach nur noch ein ganzer Haufen Anzahl an Hex-Feldern. Und zwar wurden plötzlich anstelle von zwei Variablen, einmal mit dem Inhalt, mit den Bytes, die übertragen werden und einmal der Port,

wurde uns ein JSON-Objekt übergeben. Also quasi ein Objekt übergeben, wo diese beiden Daten drinstecken. Und schon funktionierte quasi das Dekodieren, also das Auseinanderreißen der Daten und dann das entsprechend zu vernünftigen Werten zu machen, nicht mehr. Also haben wir uns hingesetzt und haben diesen Payload-Decoder angepasst und dann auch entsprechend das Repo wieder zurückgebracht.

Daraufhin sind uns noch ganz viele andere Payload-Decoder unter die Finger gekommen, von den Taps zum Beispiel, vom Clux, ich weiß es gar nicht, von der Sensebox. Also wenn man bei uns ins Repo guckt, findet man sehr, sehr, sehr viele Payload-Decoder, die wir für die V3 entsprechend angepasst haben. Ich sag's einfach mal, kitap.com slash dasdigidings,

ganz einfach am Stück durchgeschrieben. Wir sind hier im Rheinland, wir machen irgendwas Digitales, also dasdigidings. Zurück, neben dieser Payload-Funktion ist uns halt aufgefallen, das war gerade damals, war die Krise mit diesen 4K großen Payload-Decoder,

wo unser dann größer war als diese 4K, weil der PaxCounter sehr, sehr viele andere Geräte auch Daten übermitteln kann. Nicht nur die Pax, sondern von Feinstaub über CO2, über diese ganzen BME-Sensoren und so weiter, kann man alle dranhängen und die können alle Daten übermitteln. Also ist der Payload-Decoder sehr groß. Ein Weg, da aus dieser Sache herauszukommen ist,

es gibt vom Systems Industries quasi ein offizielles Lora-Warn-Device-Repo, in dem die Daten sammeln zu professionellen Devices. Also wenn ich jetzt Hardware-Hersteller bin, kann ich dort mein Device, also meine Firma registrieren, mein Device registrieren und zu dem Device entsprechend Daten mitliefern. Ich muss zum Beispiel eine ganze Testroutine mitliefern,

wenn die und die Hex-Werte übertragen werden, welche Daten kommen hinten aus dem Payload-Decoder entsprechend raus und das wird auch entsprechend überprüft. Und wir haben uns irgendwie die Mühe gemacht und haben gesagt, das wäre doch ganz cool, wenn wir das auch für diesen PaxCounter machen würden, dass der in dieser offiziellen Geräte-Liste irgendwie auftaucht. Und das haben wir dann einfach mal gemacht. Also sprich, wir haben entsprechend uns das Repo gefolgt,

haben dann die ganzen Dinge dort eingetragen. Das ist ein nicht unerheblicher Haufen Arbeit. Wer weiß, so Testroutinen aufzusetzen und mit diesen ganzen Hex-Werten, was man da rückwärts rausrechnen kann, haben das quasi aufgesetzt und haben das quasi dann entsprechend Pull-Request und so weiter eingereicht.

Und The Things Industries hat das tatsächlich auch angenommen. Und deswegen ist unser Gerät jetzt als Open-Source-Hardware, also nicht unser Gerät, sondern der PaxCounter, natürlich in Absprache mit dem entsprechenden Entwicklerteam dort in diesem LoRaWarm-Device-Repo gelistet.

Und dieses Repo wird alle 14 Tage, alle drei Wochen quasi immer dann, wenn eine neue, kleinere Versions-Update im The Things-Stack ist, wird das mit übernommen. Das heißt, wer zurzeit The Things-Stack im Backend ein Gerät anlegen möchte, kann dort Open-Source-Hardware auswählen, kann dort PaxCounter auswählen und hat ganz viele Einstellmöglichkeiten, die er nicht mehr von Hand einstellen muss.

Die Oberfläche im V3-Bereich ist sehr, sehr komplex geworden im Gegensatz zur V2-Bereich. Und wir geben jetzt ganz viele Werte schon vor. Wir geben Frequenzbereiche vor und so weiter, die sonst immer mühsam ausgewählt werden müsste. Wer weiß, ob sein Gerät LoRaWarm 1.01 oder 1.02 Revision B kompatibel ist.

Die wenigsten Leute wissen, wie ihre Kompatibilität zum Beispiel da ist. Solche Daten geben wir jetzt zum Beispiel für den ESP PaxCounter vor. Und der Nutzer braucht sie nicht mehr eingeben. Genau, der Riesenvorteil ist also das, was die allermeisten von euch, die Züren wahrscheinlich aus der alten, ehemaligen V2 noch kennen, dass man mit drei Mausklicks ein neues Device anlegt.

Da an dem Status sind wir jetzt wieder. Ihr wählt ein neues oder ihr legt eine neue Application an, ihr legt ein neues Device an, sagt eben, dass es das PaxCounter Board ist, also ein Open-Source-Projekt. Sagt noch einfach, in welcher Region ihr euch befindet. Klickt auf Gerätfertigstellen, zack, habt ihr das laufende Gerät in der V3 angelegt.

Genau, ihr bekommt dann im Gegenzug natürlich noch eine EOE, die ihr dann wieder in die Firmware brennen müsst, damit die die Verschlüsselungskies austauschen. Aber das Anlegen des Geräts ist tatsächlich jetzt Mausklicks und sehr, sehr einfach. Genau.

Grundlegend in der Vorstellung oder in der Terminankündigung ist ja gewesen, dass wir euch auch ein bisschen erzählen wollen. Nicht nur was jetzt der Umzug von der V2 in die V3 ist, sondern wie wir jetzt die Daten uns abholen können, wenn wir einmal ein Payload-Decoder haben und was wir dann mit den Daten, die in der Cloud, im Thesings-Network zur Verfügung stehen, auch weitermachen können.

Eine ganz große Änderung ist jetzt, dass wir zum Beispiel, wenn wir die Daten mit Node-RED abholen, eben nicht mehr mit dem Thesings-Network-Knoten, wenn ihr euch erinnert, das war dieses hellblaue Dingen, dass damit nicht mehr gearbeitet wird, sondern wir arbeiten jetzt ganz klassisch mit einem MQTT-Client,

weil uns Thesings-Network freundlicherweise ein MQTT-Broker zur Verfügung stellt. Das heißt, sämtliche Datenübermittlungen können per MQTT-Protokoll einfach abgeholt werden. Das war ursprünglich mal, will ich gar nicht lange drauf eingehen, gedacht für die Satellitenkommunikation zwischen Erdesatellit und Satellit-Satellit

und mittlerweile hat sich das ganze System zum Internet der Dinge-Protokoll entwickelt und wird da eben quasi zu 95% genutzt. Wie ich gerade gesagt habe, der MQTT-Broker, das ist der Server, der uns die Daten zur Verfügung stellt, der liegt bei Thesings-Network, für alle kostenlos dürfen wir alle nutzen

und der MQTT-Client, in unserem Fall, wir benutzen Node-RED, aber es gibt undenkbar viele andere Lösungen aus der Home-Automatisierung oder was auch immer, MQTT, wie ich schon gesagt habe, standardisiertes Protokoll, können wir die Daten mit abfragen. Toll ist, wenn wir mit MQTT-Daten lesen, dass wir einen JSON erhalten,

was ich rechts im Bildschirm schon mal dargestellt habe, wo quasi lesbare Daten dann tatsächlich auch dargestellt werden. Hier sieht man nochmal ein Bild, das ist ein Screenshot von einem unserer Node-RED-Flows, wie wir Daten abholen und verwalten, wenn ich mich recht erinnere,

das sieht mir ganz schwer aus, wie das Portraupfeinstaub-Projekt. Wie ich gesagt habe, ihr seht in der Mitte vom Bild diesen hell-lilen Button, das ist quasi der MQTT-Client, der holt sich die Daten aus der Cloud ab, dann kommen verschiedenste einzelne Nodes, die dann halt irgendetwas tun

und machen, umrechnen, Werte anpassen, umrechnen, da passiert ganz schön viel und am Ende schubsen wir die Daten in eine Datenbank, bei uns ist es die Influx-DB, kennt ihr wahrscheinlich auch alle.

Ihr seid alle irgendwie informatikverbandelt, ihr kennt das EFA-Prinzip, Eingabe verarbeiten, Ausgabe. Was hier halt ganz toll ist, was ich noch mal ganz klar rausstellen möchte, der Umstieg von der V2 in die V3 ist eigentlich nur, dass sich die Eingabe verändert, denn die Daten werden immer noch in ihrer Art und Weise verarbeitet

und ausgeben, tun wir sie auch noch. Die Eingabe ändert sich, wir arbeiten jetzt mit MQTT. Casper hat es eben schon gesagt, dass wir eben den Payload-Decoder entsprechend anpassen mussten, damit wir die Daten wieder lesbar machen. Und die Daten liegen in einem etwas anderen Format da,

wenn wir sie aber einmal mit MQTT abgeholt haben, passen wir die variablen Namen an. Danach passiert die Verarbeitung wie bisher und die Ausgabe passiert auch wie bisher, sehr einfache Sache. Genau. Wenn wir auf dieses Netzwerk von The Things Network schauen,

dann hatten wir bis jetzt die Möglichkeit, per API auf die V2-Daten zuzugreifen oder auch per API auf die V3-Daten zuzugreifen. Jetzt haben wir im Hintergrund schon mal über diesen sogenannten Packet Broker gesprochen, der diese Netzwerke zusammenhält. Und der hat seit wenigen Wochen, zwei oder drei Wochen ist das erst alt,

selber eine API bekommen. Und über diese API kann ich zum Beispiel auf, jetzt wechseln wir zur Gateway-Seite mal hin, kann ich zum Beispiel auf Gateways Zugriff nehmen und schauen, was da an Daten fließt, also wie viele Daten fließen, ist das überhaupt online, ist es offline? So Metadaten darüber kann ich mir abfragen.

Und wir machen das. Hier unten rechts ist ein Grafana-Dashboard von uns zu sehen. Das sind zwei offline, statt Heneff. Da oben, das ist alles Community und unten die Grünen sind auch alles Community-Gateways hier aus der Region. Sieht man, die sind online und die haben noch ein paar mehr Daten, die die angezeigt bekommen.

Im Grunde genommen ist das jetzt wirklich kindereinfach. Man braucht auch keine Authentifizierung dazu, wie man das zum Teil für andere Zugänge braucht. Also wenn ich auf die V3, auf dem The Things Stack V3 zugreifen möchte, muss ich mich authentifizieren. In dem Fall ist das nicht der Fall. Das ist für jeden offen. Also wer da mal reingucken möchte. Mapper.packetbroker.net, dann API.

Gut, das ist die V2-API. Gateways kann ich mir zum Beispiel anschauen. Jetzt habe ich hier so eine NetID. Das ist die 000013. Das ist quasi das The Things Network, also was von TTI zur Verfügung gestellt wird, wenn sich an den Packet Broker noch andere Netzwerke andocken. Das haben auch schon, also von KPN ist es, glaube ich, angedockt

und von The Things Industries. Die haben natürlich auch noch private Netzwerke, die bei verschiedenen Industriekunden und so zu laufen haben. Dann haben die dort andere Mummern. Also die 13 ist unser offenes Netzwerk, unser öffentliches Netzwerk. Die Tenant ID ist TTN. Hier sieht man auch schon schön, weil ich muss an der Stelle angeben, ob mein Gateway noch in der V2 oder schon in der V3 hängt.

Es ist hier unten TTN oder es ist TTN V2. Also da muss ich, ich muss wissen, in welchem Mein Gateway hängt und dann kann er auf die Daten zugreifen. Man sieht hier schön, dass es nicht TTN V3 heißt, sondern TTN V3 ist der neue Standard für The Things Industries. Also wir werden in einem Jahr nicht mehr von V3 oder so was reden, sondern wieder nur noch von TTN und Automatis, das ist V3 genannt.

Ein weiterer Grund, sich von der V2 langsam zu verabschieden. Und da brauche ich noch die ID. In dem Fall hier ist es unser TTN RheinSieg 01, unser erstes Gateway, was wir hier im RheinSieg-Kreis quasi hier oder weniger in Betrieb genommen hatten. Und viele Gateways haben hier eine EOE minus und eine lange Nummer.

Das ist auch okay. Als Selbstbau-Gateway können wir die ID tatsächlich selber vergeben. Manche von den Kauf-Gateways geben die halt entsprechend vor. Und wenn ich das dann eingebe, also noch kurz, hier ist der Node-Red-Flow dazu. Ich habe hier vorne die ganzen Gateways, die ich abfrage und so ein bisschen Datenverarbeitung.

Aber wenn ich das Ganze angebe, dann kommt sowas dabei heraus. Da werden natürlich die Daten zurückgespiegelt, die ich selber eingegeben habe hier oben. Ich sehe auch die EOE. Ich sehe die Location von dem Gateway, wo das steht. Die geht man von Hand an. Diese Gateways haben zum Großteil keine GPS-Chips

oder so was verbaut. Sondern beim Anlegen der Gateways kann ich im Backend Geodaten hinterlegen. Gut, es hat eine Antenne. Es ist online, kann ich sehen. Ich sehe, in welcher Region es ist. Ich kann sogar die Channel sehen. Es ist ein ganz normales Acht-Channel-Gateway. Und ich sehe hier noch eine Rate Rx und Tx.

Also wie viel ich empfangen und wie viel ich gesendet habe. Und das ist eine durchschnittliche Rate, die wird pro Stunde angegeben. Pakete pro Stunde ist dort die Einheit. Genau. Das ist ganz schön, dass wir jetzt einen Zugriff haben tatsächlich auf solche Daten.

Oh, jetzt geht es live. Jetzt bin ich gespannt, ob ich das noch hinbekomme. Das ist schon ein bisschen her. Also wir wollen euch jetzt mal zeigen, wie wir, das seht ihr unten in dem Bild, wie wir einen Raspi-Gateway mit dem IMST I880A, wie wir den von der V2, das Gateway läuft aktuell in der V2,

ungefähr 300 Meter entfernt von uns, wie wir das in die V3 holen. Das schauen wir mal. Live ist live. Dafür share ich mal den Screen. Das, was man jetzt hier sieht, ist tatsächlich live unsere Überwachung und das einfach auch mal, worüber wir gerade gesprochen haben.

Und ich kann auch ganz kurz mal das Notepad gucken, wo hier zum Beispiel die URL erzeugt wird hier. Mapper, Packet, Broker und so weiter. Das ist jetzt vielleicht ein bisschen klein. Aber ihr glaubt mir das hoffentlich. Was jetzt spannend ist, das ist das Gateway in der alten Konsole, die read-only ist mittlerweile. Das ist das TTN RheinSieg 02 Gateway.

Das ist connected für Ewigkeiten schon. Und das ist hier in Hanif. Man sieht, wo das ist. Und hier steht auch drin, was es ist, ein Raspberry Pi mit dem IMST IC880A. Und dieses Gateway wollen wir jetzt mal versuchen, gemeinsam umzuziehen. Und zwar habe ich hier die Konsole auch offen.

Hier sieht man da zwischen der 1 und der 3 ist eine Lücke. Die 2, die wollen wir füllen. Und dazu gehe ich mal in meinem Balena-Dashboard. Auf unseren Gateways läuft Balena. Warum läuft der Balena drauf? Balena ist eine relativ einfache Möglichkeit, Raspberry Pis über die Entfernung zu warten. Gerade, wenn ich im IoT-Bereich,

über den IoT-Bereich spreche. Und ich gehe mal gerade hier wieder hoch. Wenn ich fleets, heißt das mittlerweile früher, bei uns Applications. Über Balena ist es möglich, Docker-Container auf Raspberry Pis laufen zu lassen und remote zu starten und abzudaten und so weiter.

Und der ganze Weg, wie wir dort hinkommen, das zeige ich noch ganz kurz. Aber das gibt es auch als Link am Ende. Und zwar werden wir hier bei uns im GitHub, wenn wir hier reingucken, ich mache es mal ein bisschen größer. Das ist die komplette Anleitung. Ich scrolle hier nur mal durch. Wie man so eine Application hieß es früher,

jetzt heißt es fleet. Wie man das Ganze anlegt. Also das haben wir hier tatsächlich click by click im Grunde genommen zum Nachmachen dokumentiert. Und wir sind auch nicht die Ersten. Wir haben das umgebaut auf einen Docker-Compose. Normalerweise war es nur ein Docker. Aber wir haben gesagt, wir möchten gerne mehrere Docker parallel laufen haben.

Und deswegen haben wir einen Docker-Compose drauf gemacht, weil wir noch per CollectD zum Beispiel parallel Daten vom Gateway sammeln möchten. Um einfach die Übersicht über unsere Gateway zu behalten. Genau, das Ganze findet ihr, wie wir es schon einmal gesagt haben, in GitHub, das Digidinks, in dem Fall dann Slash Basic Station,

weil das Gateway mit Basic Station-Protokoll arbeitet. Genau. Und hier habe ich die Gateways in der V2. Ich gehe mal gerade zurück. Ich bin ja faul. Ich brauche da, glaube ich, gleich den Namen. Den kopiere ich mir schon mal. Genau, wir haben hier zwei Fleets. So heißt das früher, hieß das Applications.

Hier oben steht auch noch der Hinweis dazu. Das heißt, ich kann immer eine Fleet bauen und habe dort einen verschiedene Docker-Container, die ich dort vorgebe. Und jedes Gerät, was ich da reinschiebe, bekommt automatisch diese Docker-Container ausgerollt und setze dann über entsprechende lokale Variablen. Die kann ich dann die Docker-Container entsprechend beeinflussen.

IDs ändern, URLs ändern, was auch immer. Und hier, das ist mal unser V2 und das ist unser V3-Fleet. Und die V2-Fleet, wenn ich die nehme, da ist dieses Gateway drin. Und das ist... Ich gehe da jetzt mal drauf. Dann sieht man tatsächlich hier auch die Live, die Daten, die durchfließen. Jetzt haben wir irgendwie wahrscheinlich

eine Public-IT-RP-Adresse noch hier drin. Gut, die ändert sich. Das DSL davor. Kann keiner hoffentlich mit Mist bauen. Dieses Ding ziehen wir jetzt einfach mal um. Das ist relativ einfach. Es gibt hier Actions. Und unter Actions gibt es... Da war ich schon zu hoch. Da oben, Move Device.

Move to another fleet. Die V3 haben wir angelegt. Die kann man sogar jetzt hier schon auswählen. Die haben wir vorher angelegt. Dann klicke ich mal auf Done. Und jetzt sagt der mich, wie viele Devices sind das? Und das ist eins. Also nochmal eine Testabfrage, ob man das nicht aus Versehen gemacht hat.

Und jetzt lande ich auch sofort schon an der neuen Fleet, also in der V3-Version. Und dort ist mein Gateway drin. Dieses Gateway hat jetzt allerdings wahrscheinlich... Man sieht das schön hier. Die ganzen Services werden gestoppt. Und hier unten werden der Gateway und der CollectD-Container neu gedownloadet.

Das passiert jetzt quasi auf dem Gateway. Werden die, die wir vorher fertiggestellt haben, im Docker-Container, werden jetzt quasi hingespielt, hochgespielt. Und wenn die dort sind, muss ich das Gateway auch noch in der V3 im Backend einmal anlegen und einen Key entsprechend drüber kopieren,

damit da auch die Authentifizierung funktioniert. Ich lasse die jetzt aber erst mal in Ruhe einmal gerade hier laden. Das sollte relativ schnell gehen und dann wird der auch meckern, weil er keinen Key hat bzw. weil er sich nicht mehr anmelden wird, anmelden kann. Tech müssen wir uns dann noch die Device EOI wieder auslesen. Und wenn das nicht vorgegeben ist,

dann können wir das über das Terminal machen. Auch das ist bei uns im GitHub hinterlegt, zeigen wir euch gleich. Die Schritte kommen dann, um eben zu zeigen, wie wir das Gateway, was ja bisher noch in der alten V2 angelegt ist, in der V3 neu anlegen.

Noch könnt ihr sehen, es läuft noch. Der Gateway-Container, ganz unten am Bildschirmrand, wird noch heruntergeladen. Dauert alles einen kleinen Moment. Aber, Daumen drücken, Fingers crossed, sollte hoffentlich. Dann startet er die ganzen Services und jetzt fängt er natürlich an zu

entsprechend, wird er gleich meckern, weil er keine Connection herstellen kann. Und hier, der failed und das funktioniert nicht. Was aber völlig in Ordnung ist, weil wir es überhaupt noch nicht angelegt haben in der V3. Es läuft bis jetzt nur in der V2. Wir müssen das natürlich jetzt auch in der V3-Konsole erst einmal anlegen.

Und dafür ist hier in der Beschreibung, da gucken wir mal rein. Hier ist unsere Beschreibung, wie wir das Ganze anlegen. Also wir gehen zu Gateways, Add Gateway, geben wir entsprechende Daten rein.

Und dafür brauchen wir die EOI, dieses Gerät hier. Ja. Dann klau ich mir mal. Und den können wir auf dem Ballena hier ausführen.

Wo führen wir den aus? Host OS. Und zwar auf dem Host OS. Da können wir jetzt ein Terminal machen. Auf dem Gateway erzeugen wir jetzt ein Terminal, eine Connection. Und das ist mein Befehl. Und das ist unsere EOI. Ich hol mir die

mal einfach in. Ich muss sie so kopieren. Die ist eben halt wichtig, dass wir die Information zuerst unserem Gateway entlocken, bevor wir das Gateway in der V3 anlegen. Weil damit kann es sich dann später eindeutig als dieses Gateway im V3-Stack anmelden. Genau.

Ich gehe jetzt hier auf Add Gateway. Wir erzeugen ein neues. Das bin ich. Die Gateway EOI, die haben wir eben hergeholt. Die paste ich mal hier rein. Das ist Ttn minus rein minus 02. Genau. Und einmal copy.

Und den machen wir mal groß. Nein, den lassen wir so wie er steht. In die Description setzen wir diesen auch noch einmal rein. Genau. Den Rest lassen wir gleich. Wir wollen uns an der EOI Cloud anmelden. Authentifizieren. All die ganzen Dinge benötigen wir nicht. Den Status, das Republic,

darf jeder draufgucken. Das, was ich mache, ich wähle noch den europäischen Frequenzplan aus. Weil wir hier in Europa sind. Da geht es um 868 Megahertz herum. Und wenn ich jetzt noch weiter runtergehe, dann gehe ich einfach auf create. Und habe dieses Gateway kreiert.

Wenn wir jetzt hier reingucken, dann sind wir auch damit schon fertig. Und jetzt brauchen wir einen API Key. dem muss man genau diese Rechte geben. Ich mache das mal gerade.

Es gibt hier API Keys. Und ich kann den addieren. Und den nennen wir jetzt Balena oder so. Damit wir wissen, wo wir ihn einsetzen. Und ich kann ihm den, das ist ja der Richtige, den setzen. Und dann sage ich, okay, create. Ich kopiere mir den mal, ohne dass wir den sehen.

Und diesen Key setzen wir jetzt ein auf der Seite. Und der heißt Device Variable. Das war der TC Key. Da machen wir hier ein Override. Und da kommt er rein. Und dann drücke ich hier auf add. Und dann wird er auf mich abgeschnitten.

Gut, da kann keiner was mit anfangen. Und da bin ich auf der 2. ja, Stopping. Der Stopp Ding gerade jetzt sowieso schon alleine. Und startet ihn neu. Wir haben ihn noch nicht als

IC. Wir haben noch eine Variable, die wir verändern müssen. Und zwar den hier. Dann muss das IC 880 auch rein. So. Okay, wir müssen ihm noch sagen, was für ein Konzentrator Board drauf ist, damit das funktioniert. Wo wir auch den Rack auswählen könnten, zum Beispiel. Genau. Also da könnte man auch Rack

2245 zum Beispiel drauf schreiben, wenn man den entsprechenden hat verwendet. Nur damit er den richtigen erkennt. Genau. Das Schöne ist, wie ihr jetzt sehen könnt, dass eben halt über diese Flottenverwaltung, dieses Gateway, was wir gerade von der V2 in die V3 geholt haben, automatisch auch wieder angepasst oder

verändert wird. In dem Fall jetzt nur dieses eine Gateway, weil wir es angefasst haben. Aber genauso könnten wir innerhalb der Flotte sagen, dass wir die gesamte Flotte neu starten wollen. Oder dass wir die gesamten Flotte an Gateways, die aktuelle Firmware verpassen wollen. Und wie man hier sieht, vor 23 Sekunden und folgende hat er sich das letzte Mal gemeldet.

Das heißt, der hat sich schon gemeldet. Genau. Der versucht jetzt gerade irgendwelche Firmware abzugleichen. Ich glaube, das ist ihm egal. Ganz richtig. Genau. Und da sollten wir jetzt die nächsten Daten durchfüßen. Das war's schon. Hier kommt was. Jetzt müsste jetzt noch eine Note natürlich in der Nähe von dem Gateway sein, um das tatsächlich ...

Ja, sonst machen wir es doch noch mal. Seht ihr den Live Traffic in der TTN-Konsole auf? Dann können wir mal reinschauen, ob vielleicht einfach was kommt. Einmal mal 5 drücken. Ich hoffe, ich schieße uns hier nicht ab. Nein, das funktioniert wunderbar. Jetzt müssen wir hier warten. Jetzt müsste jetzt hier gleich angezeigt werden, wenn entsprechend Traffic durchkommt, weil es das tatsächlich auch schon war.

Also wir sind schon an dem Punkt, dass das Gateway umgezogen ist. Ich lasse den Mayometergrund offen. Ich gucke mal hier durch, ob wir noch irgendwelche Fehler bekommen haben. Die Setting. Das sieht alles gut aus. Starting. Genau. Also für die, die mir jetzt noch

zuhören, während Casper noch mal ein bisschen die Datenboteien liest. Ihr habt gesehen, also die Schritte sind total simpel. Wenn ihr ein Gateway habt, was bereits in der Balena Cloud liegt oder wenn ihr eins in der Balena Cloud neu anlegt, lest euch die Gateway EOI aus, legt das Gateway bei

dem neuen Sync Stack V3 in der Community Edition an. Startet entsprechend neu, generiert den API-Key, tragt ein, welchen Concentrator ihr hier drauf habt. Bei uns in dem Fall war es der IC 880A. Genau. Dann sollte es eigentlich relativ entspannt anlaufen.

Gucken wir mal rein, ob wir Traffic haben. Nee, leider nicht. Nee, der müsste automatisch durch. Der läuft weiter. Das Gateway, muss man dazusagen, hängt bei mir auf dem Garagendach. Das hängt nicht besonders hoch. Das hat nur ein paar Hundert oder ein, zwei Kilometer Reichweite. Das ist jetzt nicht wie andere Gateways. Ich mache hier mal einen neuen Tab auf, dann sehe ich, wie die Daten sonst aussehen müssten.

Hier von eins. Wenn ich jetzt das gucke, dann laufen hier permanent Daten durch. Das ist das, wo ein Hupperschoss bei uns hängt. Das hängt sehr, sehr hoch. Das kann quasi bis Köln gucken und die ganze Köln-Wunder-Bucht hier mehr oder weniger abdecken. Jetzt könnt ihr mal sehen, da kommen Daten rein. Da kommen entsprechende Daten rein. Und hier müssten auch kommen, also der hat sich

entsprechend gemeldet, aber es ist gerade nicht in der Nähe, was quasi hier Daten sendet. Aber es ist connected und läuft. Es ist entsprechend online. Genau. Wenn wir jetzt in die Flotte gucken, noch mal eine Ebene zurück. Vorhin hatten wir fünf Gateways in der V3-Flotte und jetzt haben wir sechs Gateways in der V3-Flotte.

Und auch hier könnt ihr sehen, Stadt Henneph01 leider offline und TTN Rensik08. Das ist eins unserer Bastel-Gateways, was wir zu Kongressen oder zu Live-Veranstaltungen mitnehmen können. Den müssen wir natürlich auch anpassen. Genau. Das wollte ich jetzt gerade zeigen. Wir fragen hier noch ab über diese Packetbroker-API, von der wir eben

gesprochen haben, auf der V2-Ebene ab. Das ist natürlich jetzt falsch. Das kann ich jetzt auch live anpassen. Das ist dieses Gateway hier. Und dieses Gateway soll nicht mehr über V2, sondern über V3 angefragt werden. Ich schmeiße mal hier die Verbindung weg und schmeiße die in die V3-URL-Ezeugen-Verbindung.

ja, da ist ein Haufen Fehler, großartig. Jetzt müssen wir mal gucken, ob das schon kommt. Das wird jetzt ein bisschen dauern, dass der sich quasi die Daten holt. Pitch ging doch mal manuell. Ich wollte mal gucken, ob der Er macht den Divak-Not noch an.

Dann können wir ihn auch gleich sehen. Da ist er schon. Ich würde mal sagen, großartig. Das hat geklappt. Genau. Es kommen immer noch keine Daten durch. Ich müsste mal mit einer Note in die Nähe laufen. Dann würden jetzt auch gleich Daten kommen. Aber grundsätzlich ist das alles. Das heißt, wenn ihr schon

z.B. Balena verwendet für eure Selbstbau-Gateways, dann müsst ihr nur eine neue Application, jetzt heißt es Fleet, anlegen. Anleitung dazu funktioniert so ähnlich, wie das Anlegen vorher auch. Ist aber hier komplett dokumentiert. Entsprechend anlegen, das Gateway rüberschieben und schon läuft es im V3-Stack. Also es hat Sinn gemacht,

im Nachhinein gesehen, direkt auf Balena zu setzen, bei der Anlage von den V2-Gateways. Man kann natürlich auf dem Raspberry Pi einfach einen Raspbian installieren und entsprechend die ganze Software von Hand installieren, macht aber nachhinein gesehen einen Riesenaufwand, wenn ich dann doch mal zwei oder drei davon draußen habe und an denen etwas ändern will, weil es halt immer

mehr zu tun ist im Grunde genommen. In dem Fall hier ist es ein Mausklick, die Docker-Container werden ausgetauscht, man übergibt vielleicht noch eine Variable und schon läuft das Ding in der entsprechenden anderen Version. So, jetzt halte ich mal meinen Screen an. Genau, hier sind die ganzen Links auch drin, Balena,

unser Basic Station und das ist die Basic Station Version, der untere Link, weil man nur das Gateway drauflaufen hat, ohne irgendwelche weiteren Docker-Container, also das ist ein einfacher Docker und kein Docker-Compose. Bei uns in dem Docker-Compose ist zum Beispiel auch noch ein Docker-Container für eine CollectD dabei. Also wenn ich eine CollectD in

InfluxDB kann das zum Beispiel, kann direkt CollectD-Daten abgreifen und deswegen bekommen wir so Sachen wie CPU-Auslastungen, Temperatur von der CPU und so weiter direkt auch bei uns in unsere Datenbank geschrieben. Dann schaut doch nochmal nach, ob wir jetzt vielleicht mal irgendein Device gehört haben. Ja, aber ich bin nicht mehr connectet und

genau. Aber damit haben wir eigentlich unser letztes Selbstbau-Gateway jetzt rüber geschubst, im Grunde genommen. Ja, das haben wir nämlich für euch aufgehoben, weil wir gesagt haben, ich fange ganz anders nochmal von vorne an. Wir waren erstaunt, wie einfach es geht, wenn man sich mit der Thematik ein bisschen auseinandergesetzt und dann

Balena-Gateway aus der V2 in die V3 zu schieben. Und dann haben wir gesagt, um das euch auch mal präsentieren zu können, dass es tatsächlich so einfach geht, heben wir das Zweier-Gateway tatsächlich auch für die Forscon und zeigen einfach mal im Livestream, dass es wenige Mausklicks sind, um Gateway eben in den aktuellen V3-Stack zu holen.

Genau. So. Damit nähern wir uns eigentlich auch schon uns am Ende. Wir haben uns ein bisschen mit den Devices beschäftigt, was da sich geändert hat. Payload-Decoder zum Beispiel, jetzt per MQTT statt der Node-Red, Nodes oder Knoten in Node-Red

drauf zuzugreifen. Und haben dann Gateways uns angeschaut. Gerade dieses Selbstbau-Gateway ist glaube ich total spannend, weil davon müsste es eigentlich noch relativ viele auch in Deutschland geben, die damals gebaut wurden, die alle wieder in Betrieb zu nehmen. Und wir haben noch ein paar Links. Also einmal haben wir hier oben zum Beispiel das GitHub für diese LoRa-Warn-Devices, falls einer sich das

nachmachen möchte, was wir gemacht haben und selber über offene Hardware und Software quasi in diesem Bereich was entwickelt hat und das gerne auch so einpflegen möchte. Natürlich der Link zu dem PaxCounter, grundsätzlich zu dem Repo, kann ich nur empfehlen. Jeder, der mit dem ESP32 und LoRa-Warn was macht, sollte in dieses GitHub bitte gucken.

Genau. Und an dieser Stelle Dankeschön an Cyberman57, weil der Support und die Zusammenarbeit, wo wir einfach gesagt haben, ob wir das für ihn oder in Zusammenarbeit mit ihm machen wollen, hat total klasse geklappt. Darf auch mal einfach gesagt werden an dieser Stelle? Genau. Da sind auch noch ein paar Issues offen. Also nicht jetzt an Baustellen, wo wir gerade dran waren, aber auch da ist gerne

immer Mitarbeit, wie bei allen Open-Source-Projekten. Also wenn man ein bisschen Zeit hat, das ist ein schönes Projekt, wo man Zeit versenken kann. Dann ein kleiner Hinweis, das ist auf dem Twitter von Stefan Bernod, der ist für Open Data zuständig, bei der Stadt Mörs. Die Stadt Mörs macht normalerweise im Frühjahr immer

ein Hackday oder ein ganzes Wochenende. Findet diesmal Ende Oktober, vielleicht Anfang November statt, war noch nicht ganz sicher. Bitte ihm folgen. Da gibt es Infos. Also wer hier aus der Region kommt und sich auch mit Lova und so mal beschäftigen möchte. Die Stadt Mörs hat da auch schon ein kleines Netzwerk laufen. Die sind da auch sehr aktiv. Da werden wir beide auch sein. Wir wissen noch nicht so genau, was wir machen werden.

Ich hab mal das Thema Senseboxen im Raum gehabt. Werden wir uns auch noch... Also wir werden dort wieder ein Workshop auch geben. Und da kann man auch mit uns einfach mal vielleicht live mit Masken und so und Abständen gucken. Auch mal uns kennenlernen. Das nächste ist ein Termin, der ist gar nicht so weit weg. Und zwar am 29.9. ist das

T3-Treffen. Das ist der The Things Tech Talk. Wie er heißt. Im Steam gerufen von The Things Network Mitteldeutschland. Hauptsächlich dem Steffen Grau. Aber da ist natürlich noch ein großes Team um ihn herum dort. Das gab es einmal bis jetzt im

Juli. Juli. Gab es ein großes Treffen. Und das ist das nächste. Das ist im Grunde genommen das größte Online-Treffen in Bezug auf TTN. Genau. Und weil es aktuell da ganz toll Community gibt, die anscheinend wirklich aktiv was voranbringen wollen, haben wir eben halt uns

bereit erklärt zu sagen, wir unterstützen diese Initiative und wir melden uns eben freiwillig und richten eben den zweiten T3-Konvent aus. Und unter dem Link gibt es auch schon einen Hinweis, worum es alles geht. Wir haben zum Beispiel eine Gästin da, die was über KI und Insekten erzählt. Also Insekten zählt per KI.

Und Feinstopp ist auch ein Thema. Und Multiplikatorenausbildung. Und auch nochmal das Thema V2 zu V3. Auch das können wir dort vielleicht auch nochmal vertiefen. Das Digi-Dings, unser Verein, der hier in der Region ist. Wir freuen uns über Unterstützer. Also vor allen Dingen über Menschen. Also geht nicht um Geld oder so, sondern Menschen, die was machen möchten in dem Bereich, die Bock darauf haben, Wissen weiterzugeben,

die sollen sich gerne bei uns melden. Die Open-Data-Map.net. Da gab es mal einen Talk von uns zu dem Thema in der Vergangenheit hier auf der Froskorn. Eine Karte, wo wir verschiedene Open-Data-Sachen drauf anzeigen. Unter anderem auch ein Mapping, quasi wie gut unsere LoRaWarn-Qualität

oder Empfangsqualität ist. Einfach mal drauf schauen. ttn-rein-sieg.de ist unsere Hauptinformations- ichquelle. Sondern unsere Präsentation, wo alle Projekte von uns sind da irgendwie drauf verlinkt. Entsprechende Fotos, Bilder, Texte gibt es dazu. Wird schon mal erzählt, was wir aktuell machen.

Was wir als nächste Aktion planen. Was wir... Welche Convents wir besucht haben, Kongresse, Vorträge gehalten. Wir haben im Sommer zum Beispiel hier in Zusammenarbeit mit der Stadt Hennef den Digitaltag NRW gestaltet und haben dort einen Slot gehabt und einen Workshop

angeboten. Also, die Links und Termine, die sind für euch natürlich alle dann später in der PDF- Datei noch zu finden. Ansonsten gerade mal schnell abpinnen. Casper liest jetzt gerade mal ein bisschen den Chatparallel mit. Pingu90 hat gefragt, wie das denn aussieht, wenn wir einen Raspberry Pi Gateway

mit einem IC 880A ohne Ballena umziehen wollen. Genau. Das geht auch. Also A kann man auch... Man muss nicht Basic Station verwenden. Also das alte Packet Forwarder, der funktioniert. Man muss dann in den neuen Backend von der Konsole halt Legacy Forwarder anklicken. Also es ist tatsächlich nicht mehr klar, wie lange er noch funktionieren wird. Aber er

funktioniert noch. Und im Grunde genommen gebe ich dann nicht viel mehr auch noch ein als die neue URL, wo das hingeht. Lege das Gateway natürlich entsprechend wieder an, muss die Keys entsprechend austauschen. Also damit das Gateway sich autentifizieren kann im Backend. Gateway EOI auslesen? Genau. Aber grundsätzlich ist das auch möglich. Mit dem

Ballena hat halt, wie gesagt, in dem Moment, wo du ein zweites oder ein drittes Gateway noch mitbetreust, ist es halt... Man kann viele Dinge so auf Knopfdruck machen. Und Docker ist nun auch keine, wie soll ich sagen, keine Rocket Science mehr. Da kann man reingucken. Die entsprechenden Docker-Dateien liegen ja alle bei uns im GitHub. Also das gerne einfach mal vielleicht ausprobieren.

Vielleicht ist auch Ballena... Ich will jetzt wirklich Werbung für Ballena machen, aber es ist halt ein nettes Tool, was funktioniert in unseren Augen. Genau. Damit sind wir tatsächlich durch. Genau. Und wir möchten euch jetzt in den verbleibenden Minuten noch die Möglichkeit geben. Fragt uns Löcher in den Bauch. Wenn ihr was wissen

wollt, schreibt es in den Chat rein. Alle Fragen, die wir jetzt sofort live nicht beantworten können, weil wir es einfach selber aktuell nicht wissen, die versuchen wir für euch rauszufinden. Und würden die dann im Nachgang nochmal irgendwie liefern. Ich würde zum Beispiel anbieten, wir können das auf unserer Webseite machen. Oder wenn ihr möchtet, uns euch nicht wegen Datenschutz

irgendwie zu gruselig ist, schreibt eine E-Mail-Adresse mit in den Chat rein. Dann können wir das einfach versuchen, im Nachgang noch zu beantworten. Genau. Und kommt zu diesem Tech Talk. Also gut, das ist jetzt Ende September. Das ist jetzt auch nochmal eineinhalb Monate hin. Ein bisschen weniger als eineinhalb Monate. Aber da ist tatsächlich, das ist ein großes Community-Treffen, wo es dann nur um LoRa war,

nur um das Things Network geht. Und da treffen sich, also von Leipzig, Berlin, über die Hamburger Kieler, ganz oben Flensburg ist normalerweise dabei, bis in den Süden von München oder von Stuttgart und Ulm. Oder im Westen hier, also Rhein-Sieg, Köln, Aachen, was es alles hier so in der Region gibt. Treffen sich dort

und tauschen sich aus. Lange geplant war mal ein reales Treffen, aber der Situation geschuldet haben wir gesagt, wir machen das jetzt regelmäßig alle paar Monate digital. Kommt dazu und löchert uns im Grunde genommen. Genau. Und wie es so schön auf unserer letzten Folge steht, es gibt keine dummen Fragen. Also fragt einfach. Und wenn die Fragen schon tausendmal beantwortet worden sind, das ist

egal. Wir beantworten sie auf das 1. und 2. Mal sehr gerne, weil das macht die Community aus. Genau. An Harald, du warst mit dem Bosch-Vortrag. Wir freuen uns immer über Sensoren. Das ist doch völlig klar. Neues Spielzeug, großartig. Mit dem 680 hatten wir, ich glaube, der relativ geschlossene Library, um

diese Yaku-Werte zu erzeugen. Kann das sein? Also wir bauen viel auf C-Basis, ganz klassisch Arduino IDE oder halt über den Platform I.O. Also das Packscouter-Projekt setzt darauf aus, also Visual Studio Code und eine Platform I.O. drauf. Und das Ganze ist in C programmiert.

Wenn wir damit irgendwie, wenn wir da rankommen an die entsprechenden Geräte, 680er oder so, gerne, wenn wir was zu spielen in die Hand bekommen, freuen wir uns immer. Gibt es weitere Fragen? Also wir warten jetzt gerne auf Fragen. Wir haben noch ein paar Minuten offen im Slot, wenn noch

einer von uns irgendetwas wissen möchte. Schuhgröße, Größe, Alter wäre jetzt nicht das Ding. Wenn es natürlich irgendwie um konkret V2, V3 Wechsel geht oder eben Ballena Gateway oder irgendwelche Sensorik JitHub löchert uns, fragt uns. Ich schaue nochmal gerade in den Chat.

Ja, vielen Dank für den tollen Vortag. Wir sagen bitteschön. Gern geschehen, hat uns wahnsinnig Spaß gemacht. Ist ein tolles Thema, über das wir heute referieren durften. Bingo sagt auch Danke euch. Ja, wie gesagt, Gern geschehen. Genau, wir kommen wieder. Keine Frage. Hoffentlich zur Frostcon beim nächsten Mal mit Pizza vor Ort wieder.

Oh ja. Dann auch von meiner Seite noch ein großes Dankeschön. Das war sehr interessant. Ich habe tatsächlich auch noch eine Frage. Als jemand, der überlegt, Raspberries auszurollen für ein Freifunknetzwerk, als Out-of-Band-Management, auch in der Landschaft verteilt, wo man nicht unbedingt hin kann, aber für einen anderen Zweck, frage ich mich tatsächlich,

wie lange leben die denn bei euch? Also mein Verständnis von dieser Balena-Lösung mit Docker ist, dass da auch durchaus geschrieben wird auf dem Flash. Also dass das keine Images sind, sondern dass da wirklich aktiv geschrieben wird dauerhaft. Also die Logfiles werden zum Teil geschrieben. Allerdings ist hinter dem Balena so ein ganz, ganz, ganz abgespecktes Linux. Ich weiß gar nicht, auf welcher Basis es ist.

Es gibt so ein super abgespecktes Linux für Raspberry Pi, die dann noch möglichst wenig Logdaten und so weiter schreiben. Und das steckt da, soweit ich weiß, dahinter. Also das System selber fängt nicht an, irgendwas zu loggen und deswegen schont das die SD-Karte schon allgemein. Wir haben jetzt bei unserem Docker-Container da eben keine Rücksicht drauf genommen und der schreibt einfach wild Logdata und so weiter. Aber das Balena grundsätzlich ist schon

sehr darauf optimiert, dass gerade SD-Karte ist ja das Hauptproblem, dass die geschont wird. Da gibt es auch irgendwo Beschreibungen, man muss bei denen suchen. Nachteil von Balena, ich will das direkt in den Raum werfen, ab 10 Geräten kostet es. Also für unsere Gateways, die ja schon mit dem Concentrator-Board, das kostet auch schon über 100 Euro,

also ein Selbstbau-Gateway ist schnell bei 200, 300 Euro. Da ist es beschränkt, da wird niemand, also gefühlt, niemand über 10 jetzt ausrollen, sage ich mal privat. Aber wenn du natürlich Raspberry Pi hast, könntest du sonst an diese 10er-Grenze vielleicht auch stoßen. Okay, danke. Achso, und was natürlich super funktioniert, das ist dem egal, Raspberry Pi 3B,

weniger Stromverbrauch als der Vierer, der geht aber auch, und auch das Compute-Modell wird auch unterstützt, also wer damit sich auseinandersetzt zum Beispiel. Balena läuft auch auf diesem Compute-Modell und da haben die ein eigenes Trägerboard, das nennt sich Balena Finn, wo das drauf eingesetzt werden kann. Also auch vielleicht mal, wer da draußen mit

Raspberry Pies bastelt, ein spannendes Ding. Ja, super. Aber Harald, habt ihr gewonnen als neuen Enthusiast? Ja, wunderbar. Also er hat ja gerade nochmal im Chat gefragt, ob wir noch kurz auf dem Schnack im Kaffee stand haben.

Ja, natürlich, total gerne. Ich muss dazu sagen, der war ja jetzt noch nicht dabei, aber ich habe letztes Jahr schon über TTN gesprochen und das vor das Jahr auch und über die Karte habe ich zusammen mit Leo, also Leo kennt vielleicht einige aus Jugend -Takt-Zeiten sehr stark, der hat, also eigentlich hat er die Karte hauptsächlich programmiert und ich habe geholfen, wo wir eben den Link zu hatten.

Ich bin regelmäßig auf der Vorsprung, wir kommen ja hier aus der Region, gerne uns weiter ansprechen und wie gesagt, wir suchen immer Mitstreiter, egal woher, die Bock haben, sich mit dem Team auseinanderzusetzen. Sprecht uns an bitte. Und wir kommen gerne jetzt gleich noch auf einen Kaffee in den anderen Raum rein.

Ja, dann würde ich von meiner Stelle auch sagen, herzlichen Dank fürs Zuhören, dass ihr um die Uhrzeit noch alle mit ausgehalten habt und ich sage Tschüss, auf Wiedersehen, Dankeschön und hoffentlich gesund und munter im nächsten Jahr.