Hardware für node im Feld (BOB Projekt, Phase 2)

Bee Observer BOB Entwicklung
40

Hi Caro,

vielen Dank der Nachfrage. Ja, das war uns ebenfalls von Anfang an eine Herzensangelegenheit, deshalb hatten wir uns bereits ausführlich mit dem Thema beschäftigt. An entsprechende Dinge können wir jetzt gerne wieder anknüpfen und sie aufleben lassen.

Einleitung

Lass uns vielleicht zwei Unterthemen daraus machen: a) Kompilierung und Aufbringen der Firmware und b) Einbringen von individuellen Konfigurationseinstellungen.

Also die Frage nach a), richtig?

Das geht in Richtung b), stimmts? Es gibt ja noch eine Reihe anderer Konfigurationseinstellungen wie die Datensenke für die Telemetriedaten oder die Justierungswerte für die Wägezellen, um mal die beiden populärsten Dinge zu nennen.

Wir werden im Verlauf sehen, dass man a) und b) zusammenwürfeln, aber auch getrennt lösen kann. Wann was besser passt, ist meist abhängig von der Geräteklasse, deshalb gibt es hier für die Lösung verschiedene Varianten.

a) Kompilierung der Firmware

Status quo

Inspiriert von Features der Mbed Plattform:

Applications for the Mbed platform can be developed using the Mbed online IDE, a free online code editor and compiler.

oder des NodeMCU cloud build service:

NodeMCU “application developers” just need a ready-made firmware. There’s a cloud build service with a nice UI and configuration options for them.

haben wir ein entsprechendes - deutlich generischer angelegtes - Pendant im Angebot, den “Kotori Firmware builder”. Momentan kann er Firmwares direkt aus Git Repositories kompilieren. Serverseitig haben wir dazu die SDKs für Arduino/AVR sowie Arduino/Espressif im Angebot. Hier ein Überblick über weitere Details:

Wichtige Details

Der Firmware Builder realisiert bereits wichtige Aspekte im Bereich von b), konkret handelt es sich um jeden beiden Features aus Firmware builder usage :

  • Decode the firmware specifications (environment and features) from parameters of the HTTP POST request.
  • Amend the source code according to these specifications.

Am ausführlichen Beispiel für die node-wifi-mqtt Firmware kann man exzellent erkennen, dass man damit über einen einfachen HTTP Request individuell konfigurierte Firmware Binaries beziehen kann. Der Mechanismus erfolgt über die Interpolation von #define Konstanten im Quelltext, bevor er an den Compiler weitergereicht wird.

Ausblick

Die Unterstützung für Pycom/MicroPython/ESP32 können wir gerne für Euch nachlegen, wenn Ihr in diesem Kontext darauf aus seid, die Firmware von @Ron und seinen Kolleginnen von EasyHive für Euch zu erschließen. Nachdem diese nun open source ist, wollten wir das ohnehin bald gerne angehen ;].

Ein webbasiertes User Interface für den Firmware Builder fehlt halt noch, aber die Maschinerie unter der Haube könnte man als “1.0-beta1” (eigentlich fertig) bezeichnen. Es sollte also machbar sein, diese Infrastruktur im Kontext von BOB zum Einsatz bringen zu können.

Falls Ihr auch in Richtung OTA (over-the-air update) schielt: Der Firmware Builder kann in diesem Bereich ebenfalls als Basis dienen: Irgendwo müssen die zur Verfügung gestellten Firmware Binaries ohnehin kompiliert werden.

Bei Fragen: fragen!

b) Individuelle Konfigurationseinstellungen

Es soll hier um Konfigurationsmöglichkeiten zur Laufzeit gehen. Das Szenario ist also: Fertiges Gerät inkl. aufgebrachter vanilla Firmware wird verschickt und der Endnutzer kann es auf einfache Art und Weise selbst konfigurieren. Die Konfigurationseinstellungen müssen dann im non-volatile Speicher des Geräts untergebracht werden, d.h. sie werden überhaupt nicht in die Firmware einkompiliert.

Gedanken zu diesem Thema wurden bereits hier im Forum ausgetauscht.

Zwei Möglichkeiten schienen für uns am plausibelsten. Wir würden - passend zum Einsatzzweck - grundsätzlich gern beide für die relevanten Firmwares erschließen.

b.1) Individueller Konfigurationsdialog via »captive portal«

Bei allen WiFi-fähigen Geräten ließe sich dieses Thema so gestalten, dass man die persönlichen Einstellungen über ein sog. captive portal vornehmen kann. Dazu eröffnet das Gerät einen WiFi access point und bietet per Mini-Webserver eine HTTP API zur Laufzeitkonfiguration an, wahlweise noch mit einem kleinen Konfigurationsdialog, so dass man die Konfiguration mit einem handelsüblichen Browser vornehmen kann.

Dafür gibt es schon zahlreiche Beispiele aus der Praxis von populären Firmware Frameworks und wir haben auch schon ein zwei Bibliotheken zusammengesammelt, wie man so etwas selbst unternehmen kann. Ich versuche einmal, sie wiederzufinden und hier als Linkliste einzufügen, wo Ihr Euch erstmal informativ umtun könnt:

b.2) Signalisierung über HTTP/MQTT Rückkanal

Auf Basis von Wünschen wie “Es wäre ja schön, wenn man das Meßintervall auch vom Server aus steuern könnte”, würden wir diese Konfigurationsmöglichkeit ebenfalls gerne erschließen. Das Szenario ließe sich (from 10.000 ft) in etwa folgendermaßen beschreiben:

  • Der Meßknoten meldet sich mit eindeutiger ID beim Server (tut er beim Übermitteln der Telemetriedaten ohnehin). Wahlweise per HTTP oder MQTT.
  • Rückantwort vom Server enthält optional einen Satz von Konfigurationseinstellungen, die der Meßknoten dann einerseits anwendet und außerdem im nicht-volatilen Speicher ablegt, um sie persistent zu machen.

Viele Grüße,
Andreas.

1 Like