Wir haben vor kurzem von @RainerWieland ein paar Fragen zur Installation des Backendsystems erhalten, der Kontext war
Wo liegt Hardwaredingen? Spaß bei Seite, unsere Platine wird diese Woche fertig. Momentan spinnt noch der LoRaWAN-Empfang aber das bekommen wir hin. Bauteile sitzen alle auf einer Seite. Morgen wollen wir in der Schule mal euer Paket auf Debian installieren bin gespannt.
@florian hat im schulischen Kontext ähnliche Dinge im Sinn und kam gerade aus der Richtung Gruß aus Berlin auf uns zu.
Vielen Dank!
Wir werden uns bemühen, Euch im Laufe der Woche noch ein wenig mehr Informationen zukommen zu lassen.
Ein paar Fragen von @RainerWieland vor allem zu den Themen Telemetrie und Backend.
Gibt es einen Demozugang?
Wie klappt das mit dem Frontend?
Gibt es bereits eine mobile Anwendung?
Gibt es bereits eine Web-Ansicht?
Wie sieht es mit der Rechteverwaltung bzw. Unterbringung verschiedener Nutzer/Mandanten auf einem gemeinsamen System aus?
Hat das Datenformat eine Versionsnummer um Abwärtskompatibilität zu gewährleisten?
Wie sieht es aus, wenn die Datenschnittstelle um weitere Entitäten ergänzt werden soll?
Zum Beipiel können wir ab Q4 auch Sounddaten (Frequenz und Intensität) und positionsbestimmte Temperaturdaten aus dem Innern des Bienenstocks übermitteln.
Grafana hat den Nachteil, dass nur 2 unterschiedliche Datenarten in einem Grid dargestellt werden können (Beispiel Temperatur und Luftdruck).
Wie ist das geregelt, wenn weitere Datenarten hinzu kommen (zum Beispiel Gewicht und Ladespannung der Batterie).
Zur Systemkontrolle sind darüber hinaus auch Informationen wie SNR und RSSI wichtig. Damit läßt sich u. A. ein möglicher Datenabriss hervorbestimmen (Antennenkabel “säuft ab”).
Wie werden diese Expertendaten übertragen bzw. wie müssten diese übertragen werden?
Liefert die TTN-API dazu eine geeignette Schnittstelle?
TTN bietet über MQTT und dem entsprechenden JSON-Prozessor eine einfache Anbindung die Daten zu subscripten (mosquitto_sub -h eu.thethings.network -t ‚+/devices/+/up‘ -u ‚<AppID>‘ -P ‚<AppKey>‘ -v).
Wird dies unterstützt, und wenn ja, wie wird im Backend sichergestellt, dass die Appkey nicht missbraucht werden kann?
Wird von Eurer Software die Verwaltung der Nodes, die Applikationszuordnung, deren Owner und Kollaborateure über das TTN-SDK genutzt oder wird von euch davon ausgegangen, dass jeder Hoppyimker neben dem Hiveeyes-Login noch einen weiteren TTN-Zugang hat und diesen auch selbst verwalten kann?
Bemerkung: Die Inhalte sind sinngemäß wiedergegeben.
Neben dem didaktischen Einsatz an Schulen - wie oben erwähnt - suchen wir im Rahmen des IoT4Bees / LoRaWAN-Bienenwaagen an der Bergstraße Vorhabens auch noch nach einem System für Imkervereine.
Es soll einer Imkergruppe erlauben, ihre erhobenen imkerlichen Daten ordentlich zu verwalten und miteinander zu teilen.
Die Auswertung und Anzeige der Daten ist dabei erstmal untergeordnet, dafür haben wir bereits gute Lösungsansätze mit Grafana und InfluxDB.
Was wir vielmehr suchen, ist eine Lösung für einen Imkerverein mit einer Benutzeroberfläche, bei der ein Imker neue Beuten anlegen kann und die dazu erhobenen Daten mit anderen Imkern teilen kann. Die Beute hat Eigenschaften (Sensoren, etc.) die er aktivieren kann, wenn er sie sehen will.
Neue Benutzer können sich registrieren (Double-Opt-In, Single-Sign-On, Google Sign-In, …). Benutzer die ihr Passwort vergessen haben bekommen den üblichen Mechanismus zum Zurücksetzen. Benutzer können andere Imker einladen um ihre Daten miteinaner zu teilen.
Wenn eine neue Beute am System eingerichtet wird, hat diese eine DeviceID entsprechend der TTN-Konvention. Was diese Beute alles liefert, erfährt das System bei entsprechender Abfrage zum Beispiel über die TTN-CLI => JSON.
Bisher habe ich bei Eurem System den Eindruck, dass Ihr Euch auf die Auswertung mit Grafana konzentriert und die Benutzerverwaltung durch einen Administrator organisiert werden muss. Das wäre nach unserem Geschmack zu technikgetrieben und zu wenig am Imker orientiert.
Beep.nl kommt der Sache da schon etwas näher aber wir fragen uns, ob wir damit wirklich den typischen Imker erreichen können.
Auch @florian hat vor, an einer Berliner Schule eine Bienen-AG zu gründen. @florian : Wollen wir sie vielleicht gleich Datenimker-AG oder Technoimker-AG nennen? ;]
Auch ich möchte mich kurz vorstellen. Ich bin einer der vielen Hobby-Imker und Lehrer (Mathe, Informatik) an einem Berliner Gymnasium. Zusammen mit zwei meiner Kolleg/innen möchte ich eine Bienen-AG an unserer Schule gründen.
Ursprünglich wollte ich Live-Videos aus den Bienenstöcken in das Schulgebäude streamen. Auf der Suche nach passenden Komponenten bin ich dann auf Eure Seite gestoßen und lese seitdem sehr viel bei Euch und bin begeistert. Nun frage ich mich, ob solch ein Monitoring, wie Ih…
Auch an Dich vielen Dank, Florian.
Andreas:
Wir werden uns bemühen
unsere Inhalte ein wenig besser in Form zu bringen. Ggf. können wir dazu aber auch kurz für einen kurzen Rundflug telefonieren.
@RainerWieland und @florian : Folgendes hatte ich gerade da drüben mit @poesel ausgegraben. Es wird noch nicht alle Eure Fragen beantworten, aber ist bzgl. der Gestaltung der Telemetrie - und die steht ja im Zentrum - hilfreich für einen ersten Einblick in zugrundeliegende (leichtgewichtige) Konzepte.
Einleitung
Die Hiveeyes Plattform unterstützt die Meßdatenübermittlung per MQTT und HTTP. Beide Varianten verwenden das gleiche Adressierungsschema, das - unabhängig vom Aspekt der Authentifizierung - eine vollständig anonymisierte Datenübermittlung an das System gewährleistet.
Bei beiden Protokollen werden die Daten vorwiegend im JSON-Format übermittelt, die Plattform bietet jedoch auch auch das CSV-Format sowie das HTTP-Formular-kompatible x-www-form-urlencoded an.
Unser Datenakquise-Host he…
[1] Data acquisition — Hiveeyes system documentation 0.9.0 documentation Data acquisition - Kotori DAQ
@florian , @poesel und @RainerWieland : So wie bei Albergue para EasyHive sähe es ungefähr aus, einen neuen Teilnehmer auf “Realm ”-Ebene ins System einzuhängen, wahlweise auf der kollektiven Plattform swarm.hiveeyes.org oder im selbstgehosteten Betrieb. Auch für @JerryBee und seine Kollegen ist das unter Umständen interessant.
Der “Realm” als “data domain” beschreibt hier die Top-Level Mandantenstufe, innerhalb derer sich wiederum beliebig viele reale Teilnehmer einhängen bzw. Datenkanäle für Meßknoten und Datenlogger graben lassen.
Wenn Euch das gefällt, kommt gerne zum Start des nächsten Schuljahres noch einmal auf uns zu.
P.S.: An einer ordentlichen TTN-Konvergenz arbeiten wir bei Terkin for MicroPython und TTN-Daten an Kotori weiterleiten .
Johannes und Jana von Stadtbienen e.V. hatten mich ebenfalls angefragt wegen hardware für die Bienenbox für ein Schulprojekt!
1 Like