RuuviTag auf dem Tangle – IoT, IOTA und MAM [blockcentric #6]

IOTA gilt als Next Generation Blockchain für das Zeitalter von IoT. Diesem Ruf wird IOTA auch dahingehend gerecht, dass immer wieder neue spannende Projekte auf Basis des IOTA Ledgers veröffentlicht werden, etwa IOTA Data Marketplace oder IOTA Ecosystems .

Eines dieser Themen sind die Masked Authenticated Messages oder kurz MAM. Neben Transaktionen für Zahlungsvorgänge können im Tangle auch Datentransaktionen abgelegt werden. MAM dienen nun, vereinfacht ausgedrückt, dazu, eine aufeinanderfolgende Reihe dieser Datentransaktionen sicher und zugriffsbeschränkt im Tangle abzulegen.

Im Umfeld von IOTA stolpert man schnell über RuuviTags , ein IOT Device zum Auslesen von Umwelteigenschaften wie Temperatur und Luftfeuchtigkeit, und praktischerweise lag gerade ‚zufällig‘ eines auf unserem Tisch.

Was lag also näher, als die Idee die Messdaten des RuuviTags in Form von Masked Authenticated Messages im Tangle zu hinterlegen? Wir wollten uns mit euch dieser Idee in Form einer Experimentiersession nähern. Der Plan ist es, etwas möglichst schnell und nachvollziehbar zum Laufen zu bekommen. Unsere Erfahrungen und Eindrücke während der Session könnt ihr nachfolgend als zeitsouveränen „Liveticker“ nachlesen.

Übrigens: Warum IOTA als Blockchain bezeichnet wird, dabei aber ganz ohne Blöcke und ohne Kette auskommt, überspringen wir in diesem Artikel und verweisen stattdessen auf unseren Kollegen Jannik und seinen Artikel Tangle – Eine Einführung .

Liveticker

RuuviTag und Bluetooth Low Energy

8:54: Erstmal grob die Ruuvi-Dokumentation und den Blog überflogen, da gibt es ja schon was für MAM .
8:56: Der Modus Operandi heute: Probieren geht über Studieren. Also nicht einfach das fertige Projekt aus dem Blogpost nehmen…
8:57: Start des RuuviTags
Die Folie von der Batterie entfernt, der RuuviTag blinkt rot und grün auf, Suche nach Bluetooth-Geräten: nichts.
8:59: Zurück zur Doku: erstmal Firmware updaten.
9:15: Merke: Es gibt zwei Modi: grüne Lampe blinkt -> URL Modus , rote Lampe blinkt -> RAW Modus
9:20: Mit der passenden App  lässt sich das erste Lebenszeichen im URL-Modus erkennen:

9:24: Spanned, welche unbekannten Geräte hier noch so alles ihre Daten durch den Raum funken.
9:25: Wir fragen uns ob, wir das Gerät auch mit dem Laptop auslesen können.
9:30: Erster Versuch RuuviCollector auf Windows aufsetzen.
9:34: Versuch unterbrochen: nicht zielführend.
9:35: Über ein paar Google-Suchen sind wir auf Noble gestoßen, das sieht vielversprechend aus.
9:36: Wir beginnen mit einem leeren NodeJS-Projekt (Code) .

> yarn init

9:37: Die Noble Dependency wird installiert. Mal sehen ob wir das MacBook zum Lesen des RuuviTags kriegen. (Code)

> yarn add noble

9:40: Ein Haufen Informationen wird geloggt.

noble.on('discover', (peripheral) => { console.log(peripheral.advertisement.manufacturerData); })

9:45: Rätseln, welches Gerät welches ist. Wir setzen den RuuviTag testhalber in den RAW-Modus.
9:46: Ein neuer Datensatz ist reingekommen. Wir fragen uns, ob das der RuuviTag war.
9:50: Der Scan nach allen Geräten ergibt eindeutig zu viele Informationen.
9:51: Es identifizieren sich: 4x MacBook, 2x iPad, 1x Apple Watch und 1x iLaunch Thunder.
9:55: Die Kollegen schauen uns böse an, als wir per Skript versuchen, uns mit allen Geräten zu verbinden.
10:00: Alle möglichen Apps aus dem Store wurden ausprobiert, um an die ID des RuuviTags zu kommen.
10:10: Das muss doch irgendwie einfacher gehen.
10:15: Haben herausgefunden, dass in den Noble-Daten unter „peripheral.advertisement.manufacturerData“ das fünfte und sechste Zeichen „03“ ergeben muss (Quelle: https://github.com/ojousima/node-red/blob/master/ruuvi-node/ruuvitag.js) (C o de)
10:30: Jetzt geht auf einmal alles ganz schnell: ein bisschen den Code aufgeräumt, und schon sieht man die Sensordaten auf der Konsole.(Code)
10:35: Um immer wieder neue Daten zu empfangen, einfach das passende Flag in Noble setzen. (Code)
Der RuuviTag liefert keine Services oder dergleichen, sondern verbiegt das Datenfeld „manufacturerData“, welches eigentlich zur Device-Identifikation genutzt wird, zum Übertragen der Sensordaten. Daher müssen auch bereits erkannte Geräte immer wieder neu identifiziert werden.
10:37: Neue Daten werden nun kontinuierlich ausgegeben.
10:40: Wir fragen uns, was den RuuviTag besonders macht. Bis jetzt kann man einen beliebigen Sensor nehmen.

IOTA Transaction

10:45: Egal, wir wollen jetzt die Daten in den Tangle bringen. Erst einmal noch „normal“ ohne MAM mit einer Testnachricht.
10:50: „iota.lib.js“ zum Projekt hinzugefügt. (Code)

> yarn add iota.lib.js

10:55: Wir konfigurieren einen Client mit einem Knoten von iota.fm mit aktiviertem POW. (Beste Grüße an die Kollegen aus Köln!)
11:05: IOTA-Client ist eingerichtet, Zeit, die Daten in den Tangle zu bekommen. (Code)
11:10: Kurze Kicker-Pause…
11:30: Generieren erst einmal einen neuen Seed und daraus eine Adresse als feste Zieladresse für unsere Nachrichten.
11:40: Warum denn immer Bytes? Müssen unsere Testnachricht in Trytes konvertieren.
11:50: „iota.api.sendTransfer“ macht die Magic im Hintergrund.
11:51: Erste Testnachricht ist im Tangle (Code)

11:52: Zeit, die Informationen vom RuuviTag in den Tangle zu packen.
12:00: Kurz den Code umsortiert und voilà (Code)

12:14: Résumé: Wir haben die Daten vom Sensor in den Tangle bekommen, aber wir wollen noch die Masked Authenticated Messages ausprobieren.

Masked Authenticated Messages (MAM)

12:16: MAM Client Dependency hinzufügen

> yarn add mam.client.js

12:17: Es gibt drei Möglichkeiten „public“, „private“ oder „restricted“ Streams. Wir wollen mit „public“ beginnen.
12:20: Wir initialisieren MAM-Client und MAM-Nachricht.
12:25: Funktioniert nicht so wie dokumentiert.
12:28: Wir stellen fest: In NPM ist der Code veraltet.
12:30: Ah, was gelernt. Man kann direkt eine NPM Dependency aus einem Git-Repository einbinden.

> yarn add https://github.com/iotaledger/mam.client.js.git 
oder
> yarn add git+ssh://git@github.com:iotaledger/mam.client.js.git

12:40 Ist ja noch einfacher, als „normale“ Nachrichten einzustellen (Code)

12:45: Auch wenn noch sporadisch Fehler auftreten, ich glaube es erst, wenn ich auf einer anderen Maschine die Nachrichten lesen kann (Code)

> node src/mamClient.js

12:46: Next root?

12:50: Vermutung: Die Fehler bei der „Tip Selection“ sorgen dafür, dass die verkettete Liste der Nachrichten bricht.
12:51: Neuer Versuch:

13:00: Läuft bei uns!

Das Endergebnis kann in Form eines kleinen NodeJS-Skripts in einem GitHub-Repository gefunden werden.

Erkenntnisse und offene Fragen:

1. Wir haben keinen Explorer für öffentliche/public MAM-Channels gefunden -> Memo an uns selbst: Bei Gelegenheit bauen.
2. Was passiert mit dem Channel und den Informationen nach einem Snapshot des IOTA-Netzwerks?
3. Wir haben die Sensordaten auf dem PC als MAM signiert, so dass diese dadurch potenziell manipulierbar sind. Der RuuviTag kann bereits MAM-Payload erzeugen -> bis zum nächsten Blogpost.

---

In unserer Kolumne “blockcentric” bloggen wir, zusätzlich zu den bewährten Themen des codecentric-Blogs, über die Blockchain. Dabei möchten wir das Thema uneingeschränkt sowie breit gefächert betrachten: Technologie, Projekte, Organisation und Geschäft. Die Artikel können Ergebnisse unserer 20%-Zeit-Projekte sowie Neuigkeiten aus dem Themenbereich sein und zielen darauf ab, Ihnen die Blockchain näher zu bringen.

Auch auf unserer Blockchain Landing Page können Sie sich über unsere Aktivitäten und Angebote in dem Bereich informieren.

Wir freuen uns auf Ihr Feedback zur Kolumne und spannende Diskussionen über Ihre Use Cases.

Bisher veröffentlichte blockcentric-Posts