Mit TTS-/TTN-Daten an Kotori weiterleiten ist es nun möglich Daten von einem node via TTN an Kotori zu schicken, der Hauptweg uplink, vom Sensorknoten zum Server ist damit sehr gut und elegant erschlossen.
TTS-/TTN bietet aber auch die andere Richtung an, Werte von TTN über downlink vom Server an den node zu schicken, was man z.B. verwenden kann um Konfigurations-Parameter wie Zeitintervalle zu modifizieren und Tarierung von Stock-Waagen vorzunehmen (?) oder auch Sensorwerte anderer Geräte an nodes zu schicken. Hier als Beispiel Konfigurationsparameter, die beim Pax-Counter darüber geändert werden können.
Nun könnten wir anschließen mit:
Ist noch nix implementiert davon. Aber da die Basis der LoRaWAN/TTN Integration jetzt ja ganz gut dasteht, können wir weiter denken und planen.
Super, dass du das aufgreifst, @Andreas, die uplink-Implementierung ist sicher das Wichtigste was wir bei TTN nutzen, mit der downlink-Richtung könnten wir aber einige nette Szenarien abdecken, besonders so “unschöne” Dinge wie nachträgliche Umkonfiguration von Wetterstationen / Bienenwaagen / anderen Geräten, die schon im Feld verbaut sind und an die man auch physikalisch schlecht ran kommt.
Szenario 1 In der Vergangenheit war das z.B. bei Systemen der Fall, die durch einen Akku-Ausfall die Zeit der RTC “vergessen” hatten oder Systeme, die durch mangelnde Akku-Ladung im Winter den Dienst quittiert haben und wo ein neues Messintervall (1x am Tag) gereicht hätte, den Dienst trotz mangender Sonne aufrechtzuerhalten. Oder bei Bienenwaagen bei der z.B. die Wägezelle getauscht wurde Tara- und kg-Parameter neu eingestellt werden mussten. Dafür brauchte es in der Vergangenheit immer einen Rechner mit der entsprechenden Software (und einem Menschen der das bedienen konnte und physikalisch in der Nähe war). Solche Probleme und Umkonfigurationen wären bei TTN-nodes remote mit downlink-Richtung machbar.
Szenario 2 Weiter kann man sich Szenarien vorstellen bei denen nodes aus dem Netz Daten abrufen bzw. die per downlink gepushed werden. Ein node arbeitet erst wenn ein bestimmter Wert – von einem anderen node weiter weg – einen Grenzwert überschreitet oder gibt den Wert über ein Display aus …
Für #1 bräuchte man (human) eine (Web-)Oberfläche oder eine Kommandozeile mit der man Konfigurationsparameter eingeben kann. Die Variante #2 kann auch autark laufen, aber auch da braucht es einen Ort wo man z.B. die Infos ablegt, wenn Wert A > x dann TTN-downlink an node sowieso mit den-und-den Parametern.
Die Firmware muss zu allererst dafür fit gemacht werden - möglichst standardisiert über alle Plattformen. Ich nutze bereits Downlinks in Verbindung mit dem Terkin-Dataloger zum Setzen des DeepSleep-Intervalls für einen Remote-Bienenstand und diesem Codeblock [1]. Das passiert zwar zuverlässig aber so selten, dass ich den Downlink über das TTN Webinterface initiiere und mir das kein Unwohl ob des Aufwands hervorruft. Ich sende dort einfach das Sleep Intervall in Minuten als Hex-Wert über Port 1. Ports und Interpretation/Kodierung müssten also vorher festgeschrieben werden.
Ja, man könnte sowas direkt über die TTN-Konsole machen, Andreas hat dieses hier dafür ins Spiel gebracht:
The Data Manipulation Panel is a conceptually new plugin for Grafana. It is the first plugin that allows inserting and updating application data, as well as modifying configuration directly from your Grafana dashboard.
Haben sogar eine YT-Video dazu: :-)
Wäre natürlich super, wenn wir da möglichst wenig selbst stricken müssten und wir zumindest die UI für unsere downlinks damit schon hätten.
