Integration - http => blockchain

so, die erste „integration“ läuft hier mal. worum gehts?

ich habe einen ttn-node, der mir battery/temperatur/licht alle 10min schickt. ich habe dann eine „http-integration“ am ttn-dashboard hinzugefügt, die die daten (also auch info zu id, gateway,…) auf unsere blockchain-instanz schupft. dort landet sie auch schon, ich arbeite an einer halbwegs vernünftigen visualisierung via plot.ly

vorteilhafterweise ist, dass wir hier das radl nicht neu erfinden mussten. die „http-integration“ ist so einfach und doch so flexibel, dass wir hier im wesentlichen nur meinen X-ApiToken hinterlegen und den zielserver (URL) angeben mussten. natürlich wäre es fein, wenn man noch in den datensatz eingreifen könnte und zb nur die payload schickt oder die gateway-infos (oder eben nicht) oder unsere zusätzlichen datenfelder mitschicken könnte - zum herzeigen ist das aber jedenfalls mehr als ausreichend.

normalerweise kommen solche daten ja selten, zb temperatur 1x/h oder alle 10min oder so. abfragen von extern via REST-API sind zwar möglich aber natürlich sehr ineffizient. entweder fragt man zu selten, dann hat man den neuen datenpunkt optimal spät :wink: oder man fragt andauernd und belastet die server sinnlos. daher ist die http-integration, die vom ankommenden datenpaket getriggert wird die optimale lösung.

to be cont’d

bei interesse gerne hier posten, ich beantworte gerne fragen (sofern ich kann… :slight_smile: )

details bitte :kissing_smiling_eyes:

gerne! wöchane genau? :-))))

naja erst mal

  • wem „unsere“
  • welche chain/plattform/protokoll
    dann
  • warum nicht mqtt?
  • und wohl noch einiges mehr …

aber vor allem:

endlich! :hugs:

„unsere“

ein kollege hat da einiges aufgebaut und ist schon länger in der materie unterwegs.
wir haben letzten märz beschlossen von der powerpointeritis und „man könnte…“ einfach mal nodes aufzubauen und mehr oder weniger wahllose daten zu sammeln - zwecks erfahrungssammlung.

„plattform“

basis von dem ganzen ist die multichain (www.multichain.com), opensource, die sehr agil entwickelt wird und echt schon schöne dinge kann :slight_smile:

da ich das datenfunknetz der ma22/luftgüte wien seinerzeit gebaut habe und ich die kollegen dort sehr schätze (nerds eben :slight_smile: ), wollte ich sie dafür gewinnen, die messdaten bei uns revisionssicher einzukippen. das provisorium war, die daten von ogd-daten zu holen und eben selber reinzuschreiben. das aktive reinschreiben wien=>uns scheiterte schlussendlich am … äh … politischen willen :frowning: - egal.

christian betreibt einen node bei sich daheim am arbeitsplatz-pc (win) sowie als docker-instanz auf seiner synology und die „haupt“-instanz (was ja bei einem dezentralen system schon falsch ist - egal) ist sein hetzner-server. bei mir gibts 2 win-instanzen, eine docker-instanz auf meiner synology, weiters ein virtuelles ubuntu1804 auf einer 2ten synology sowie auf meinem mini-asus-chromebook (jetzt ubuntu-mate). dazu kommt noch eine aws-instanz in paris, man muss ich ja mit den wolken beschäftigen :wink:

christian arbeitet viel für/mit der wko und ist dort dabei eine grosse „notarisierung“ zu realisieren,
die von der wko auch den unternehmen zur verfügung stehen wird. hier gibts einen testserver sowie eine fertige API, bei der man (so wie bei anderen services) mit einem api-token „beliebige“ zu notarisierende daten einkippen kann. in der blockchain werden diese daten verteilt und robust, revisionssicher und unmanipulierbar verspeichert.

im prinzip haben wir die http-integration mit ziel-url sowie custom header name:value genommen. leider kann man bei ttn nicht in die datenstruktur eingreifen, wir wollten nämlich noch zwei keys einfügen. macht aber nix, dafür habe ich mir den „proxy“ erspart, der das 1x „übersetzt“

inzwischen gibts anfragen von firmen, die selber nodes betreiben wollen, ich versuche auch da dran zu bleiben, man möchte ja manntage verkaufen… interessant ist es, dass sich firmen langsam vorstellen können sowas zu verwenden und leute sich auch langsam von dem ICO/bitcoin/usw-wahnsinn lösen und unterscheiden können, das wir zb NICHT den stromverbrauch von der slowakei haben um ~10 transaktionen je sekunde zu erledigen (so wie im bitcoin-netzwerk). ach ja, ethereum-nodes haben wir auch laufen, habe auch schon smart-contracts geschrieben, nur das ist alles noch zu fancy und (mir) nicht stabil genug. obwohl es zukunft haben wird. auch die anderen sachen muss man sich mal anschauen, waves, 0bsnetwork und was da alles spriesst …

die lorawan-daten sind einfach eine willkommene datenquelle um schnittstellen anzudenken und zu realisieren :slight_smile:

mqtt: brauchen wir hier nicht, es gibt ein demo von christian, wo er bei der iot-austria gezeigt hat, wie man mit einem raspi auf einer blockchainbasis das asset „lichtsekunden“ transaktionieren kann und so zb 20sekunden „kaufen“ kann und damit eine lampe für 20s einschalten kann. ich gehe davon aus, dass trotz sehr guter erklärung dort maximal 3 leute verstanden haben, was es bedeutet transaktionen tatsächlich sichtbar zu machen. war aber eben nur eine demo.
da gabs so einen mqtt-mosqito-notered-etc. wahnsinn … wo das packerl durch gefühlte 20 hände geht

inzwischen schreiben wir - quasi ohne sinn und zweck :slight_smile: - ozon österreich sowie radiation österreich mit (umweltbundesamt) und nach dem schluckauf vom 10.1.2019 auch die 50hz-frq (gridradar) … einfach weils geht. und stromnetze mein thema sind - eigentlich.

an der visualisierung der ttn-pakete arbeite ich noch, bin nur grade anderweitig eingespannt. zumindest habe ich meinen ttn-node mal auf 10min runtergeschraubt, man kann durch schütteln eh pakete spontan erzwingen … wird eine plot.ly-implementierung werden - ein geniales tool

sind mal alle klarheiten beseitigt? :wink:

wennst eine anwendung weisst wo du zahlenfriedhöfe notarisieren willst, nur her damit :slight_smile:

73
roman

ps: ich habe mir eine kiste lorazeugs ausgeborgt und versuche nach und anch das zum leben zu erwecken. eben einen node, ein uno liegt noch da, das gateway funktioniert (endlich) … vll muss ich dann mal den node retourgeben, das gateway (raspi+ic880) möchte ich mal fix installieren. dzt ist es ein mobiles gateway == kiste mit mikrotik-router und lte-stick

2 „Gefällt mir“

es gibt jo so vü sochn… ich war schon mal versucht mit ethereum was zu starten, dann aber doch wieder eingeschlafen…

ja, aber. wie läuft die oben angesprochene „http-integration“ jetzt? da macht eine payload-function(/„format“) einen api-call?

schön wenn’s so läuft, aber dass jeder TTN-node auch ein MQTT-Topic hat ist bekannt? ich krieg so zb. die Daten in influx-DBs… und man könnt aus dem JSON halt auch schön nur einzelne Felder rausziehn, was ja wenn ich’s richtig verstanden hab ein intressanter Punkt wär: API Reference | The Things Network

hab ich mir auch schon paar mal gedacht … wobei’s da mit (zb) IOTA auch Ideen gibt die schon von Haus aus dafür konzipiert wurden… intressant wär’s ja auch so eine Anbindung direkt im LoraWAN-stack zu haben…

um’s „notarisieren“ güngs mir eigentlich weniger als ganz einfach mal andere datenbanken bzw ähnliche konzepte praktisch zu nutzen und zu wissen was/wie geht… wer weiss für was mans mal brauchen kann :man_shrugging:

cheerio.

ethereum ist … gewöhnungsbedürftig …

die http-integration hat als parameter hauptsächlich die ziel-URL, die methode (GET/POST) und zusatz header. wenn ein packerl (von meinem device) reinkommt werden zwei sachen getriggert, 1x „storage“ (weil ich es angelegt habe, d.h. das packerl geht in den 7-tage-speicher) und 1x http-integration. letzteres schupft es mit meinem api-token versehen auf den zielserver - fertig. da in diesem setup kein mqtt vorkommt, nehmen wir es auch nicht. :slight_smile: wenn jemand jetzt eine haussteuerung mit mqtt und allem hat, ist das mqtt-topic natürlich besser - klar.

IOTA … siehe 1. :wink:

notarisieren ist ein sehr weiter begriff. aber natürlich bauen wir dzt. so sachen „weils geht“, es verlässt aber langsam aber sicher den bastel-status

/roman

nachtrag, falls noch nicht bekannt: requestbin

requestbin zeigt dir an, welche daten da von der http-integration auf einen zielserver geworfen werden

requestbin => “create a requestbin” => es wird ein “endpoint” https://“zufallszeichen”.x-pipedream.net erzeugt.

diesen URL trägt man in der http-integration als ziel ein und kann nun genau sehen, wie das json genau aufgebaut ist und was da daherkommt…

weiters gibts beispiele für curl,js,node,python,php,go,ruby um einen teststring auf die reise zu schicken

beispiel (für die kommandozeile)

curl -d ‘{ “name”: “Luke Skywalker” }’ \
-H “Content-Type: application/json”
https://“zufallszeichen”.x.pipedream.net/

zum testen sehr praktisch wie ich finde