HTTP- und webbasierte Konfiguration des Terkin-Datenloggers zur Implementierung eines Captive Portal

Bee Observer BOB Entwicklung
1

Die anstehende Firmware-Hochzeit haben wir bereits bei Terkin for MicroPython erwähnt. Während sich ein Teil der Entwicklung gerade noch Dingen bei Kontinuierliche Verbesserungen des Terkin-Datenloggers (600er) widmet, legen wir hier mit entsprechenden Vorbereitungsarbeiten los.

Das Ziel ist, die GitHub - hiveeyes/hiveeyes-micropython-firmware: Hiveeyes MicroPython Datalogger - data logging for humans Firmware mit einem captive portal zu versorgen, um Einstellungen interaktiv über ein HTML-basiertes Benutzerinterface vornehmen zu können. Ein Großteil der Funktionalität steht dazu bereit und ist bereits per GitHub - Hiverize/Webinterface von @vinz und @Diren implementiert worden.

Danke, @Diren, @vinz, @MKO und @pinguin!

P.S.: Dieser Beitrag ist ein Wiki, Ihr könnt also alle ggf. die Einleitung zum Thema mit-editieren.

2

Hallo,
ich hab mal mit dem Mergen/ Schnittstellen vereinheitlichen von


und

angefangen und dazu einen Pull-Request bei Hiveeyes erstellt. Vielleicht können wir da ja zusammen dran weiter arbeiten.

Der Stand: Ich habe den Micro-Webserver zum Repo hinzugefügt. Das ist der Grundstein, um Webinterface und Hiveeyse-Datenlogger zusammen zu testen. Nach dem Starten und dem ersten Messzyklus/ Deep-Sleep kann der Reset-Button gedrückt werden, und dann startet der Webserver. Hier wäre auch die richtige Stelle um in den AP-Mode zu gehen. Um die Messschnittstellen hab ich mich noch nicht gekümmert (bzw. ich hab viel drüber nachgedacht, und konnte mich nicht entscheiden, was der beste Weg ist). Aber man kann das Webinterface dann schon öffnen und nutzen, um den FiPy neu zu starten ;)

Viel Zeit ist drauf gegangen, weil ich vergessen hatte, wie ich in den Hot-Reload-Modus vom Webinterface kommen kann.
Vincent hatte dann den richtigen Tipp: Evtl. muss das Öffnen des AP auskommentiert werden, um erstmal an die IP zukommen/ den Webserver zu starten. Sonst lief aber alles nach Anleitung. Bei dem jetzigen Stand im Hiveeyes-Repo ist das aber so wie so kein Problem.

Viel ist natürlich noch nicht passiert, aber vielleicht hilft euch der Pull-Request, um schneller einzusteigen.
Ich versuche mal genauer aufzuschreiben, was die nächsten Schritte sein könnten:

  • Routes in webserver.py anpassen. Hier ist die große Frage, was für eine Design-Entscheidung wir treffen: Wie kommt der Webserver an die Sensor-Messwerte? Bei Hiverize wurden die Sensoren über das Paket initialisiert. Soll er sich einen eigenen Datenlogger erstellen? Kann er den oder den SensorManager übergeben kriegen? Soll er die Sensoren direkt ansprechen?
  • Wie kann aus dem Webinterface in die Python-Config geschrieben werden?
  • AP-Mode implementieren (zum Testen allerdings nicht so wichtig)
  • Version ohne Reset-Causes implementieren

Was mir noch beim Entwickeln in den Kopf gekommen ist:
Kann “make sketch-and-run” so verändert werden, dass damit noch weitere Dateien aktualisiert werden?

Viele Grüße,
Diren

3 Likes
3

Hi Diren, würde ein neues ‘branch’ erstellen und das nach der Entwiklung mit dem master ein zusammenführen (merge). Das ist soweit ich weiß und kenne der übliche und unkomplizierteste weg, so das beide zweige weiterentwickelt werden können. Es muss natürlich koordiniert werden. wenn in beiden zweigen gleichzeitig intensiv an einer Datei gearbeitet wird, wird ein merge schwierig oder unmöglich.
Das ist, aber denke ich hier kein Problem.

Ich bin auf alle fälle dabei, hab mich die Tage schon Intensiver mit dem Thema beschäftigt.
Wie ich auch schon mehrfach geschrieben, aber bisher noch keine Antworten erhalten habe.

4

Ja kann man.
steht im Makefile

123 sketch-and-run: install-sketch reset-device-attached

führt dann das hier aus

139  install-sketch: check-serial-port
140	$(rshell) $(rshell_options) --file tools/upload-sketch.rshell

und in tools/upload-sketch.rshell steht dann das hier:

# Install program to MicroPython target device using "rshell".
# Upload main application assets
cp boot.py /flash
cp main.py /flash
cp settings.py /flash
# Just drop into REPL after upload
# repl

was möchtest du dort mit rein haben ?

1 Like
5

Hey Michael, jo klingt super! ich mein ich hab schon einen neuen Branch erstellt und den “mergeTest” genannt. Hab nur keine Schreibrechte im Repo.

Tut mir Leid, ich bin nach meinem Urlaub nicht so ganz mitgekommen, was die Posts hier im Forum anging. Aber schön, dass du dabei bist!

6

@Diren Super, können theoretisch auch mit deinem externen Branch arbeiten.
Es ist das hier richtig?


Zusammenfügen geht dann später trotzdem.
Oder @Andreas richtet eines ein und vergibt Schreibrechte für das Branch oder kümmert sich selbst um die Pull requests.

7

Genau, das ist mein Fork

8

dann würde ich sagen wir arbeiten erstmal dort zusammen @Andreas hat aktuell sicher auf den anderen Baustellen genug zu tun. Richte dort aber Andreas aber mal auch Schreibrechte ein.
In der Leiste wo Code und Pull requests sind ganz rechts auf settings und dann den reiter Colladorators.
Ich muss erstmal noch ein wenig weiter Üben.

9

Heyho,
die ersten Messwerte vom Terkin/Hiveeyes-Logger kommen im Webinterface an!
image

Ich hab jetzt den Terkin-Datenlogger zu einer Singleton-Instanz gemacht. Auf die kann der Webserver dann einfach zugreifen.
Achtung: Aktuell taucht im Webinterface der BME-Temperaturwert noch bei den DS18B20 auf, aber das ist leicht zu ändern.

Das Ganze ist jetzt auch unter GitHub - DieDiren/hiveeyes-micropython-firmware at mergeTest
und im Pull-Request.
@MKO wenn du MKO1640 bist, dann bist du schon seit heute Morgen als Collaborator eingeladen :)
Ich fände es tatsächlich auch nicht schlecht direkt im Hiveeyes-Repo zu arbeiten und hoffe, dass Andreas mit einsteigt ;)
vg
Diren

2 Likes
10

Hi Diren,
Hab gestern leider nicht die Zeit gefunden viel zu machen. Hänge dabei eine Verbindung vom Webinterface zum FiPy aufzubauen.
Hab dein Branch auf den FiPy hochgeladen und das Webinterface von Hiverize/Webinterface mit yarn Installiert und mit yarn run serve gestartet.
Vorher natürlich die .env umbenannt und die IP eingetragen. Reset am FiPy gedrückt.
Messwerte werden bei mir noch nicht angezeigt, oder habe ich noch einen entscheidenden Schritt übersehen? Wie gesagt die Zeit fehlte mir da groß weiter zu machen, oder zu testen ob überhaupt eine Verbindung besteht.

Hattest du vom Webinterface auch schon ein neues Branch erstellt? Müssen dort ja auch noch ein paar Änderungen machen und Optionen verfügbar machen die es Aktuell noch nicht gibt?

11

Hi,
das hört sich eigentlich alles gut an.
Evtl. noch http:// vor die IP schreiben.
Ich glaube in meiner letzten Version sollte der Webserver automatisch starten. Es wird ‘enabled AP’ in die Konsole geschrieben, dann sollte er da sein. Im Webinterface dann mal testweise auf die Temperatursensoren gehen, oder einfach schauen, ob der Restart übers Webinterface funktioniert.
Was wird denn bei dir so geloogt?
Stimmt, nen neuen Branch im Webinterface brauchen wir auch.

12

Stimmt das habe ich glaube ich vermasselt.

Geloggt wurde bei mir noch nichts zumindest nicht in der CMD wo das Webinterface gestartet wurde.
Und die Temp Sensoren haben auch noch nichts von sich gegeben.
Im repl des FiPy stand glaube ich nur was von enable Interface, hab das aber nicht komplett durchgesehen , war schön ein bisschen zu spät um sich dort tiefer mit zu beschäftigen.

Was hältst du und vor allem @Andreas von dem Vorschlag, das erstmal in einem Unterverzeichnis in diesem Branch zu kopieren. Durch die “Magie” der Sandbox wird sie ja erst mit auf dem FiPy übertragen, wenn wir es nicht ausdrücklich wollen. So bleibt alles zusammen. Und in einem Entwicklungsstand.
Wir müssen eh den Zweig zu hiverize/FiPy abtrennen, damit das Webinterface auch dafür erhalten bleibt.

Finde übrigens toll, das du gleich bei make sketch-and-run den webserver.py hinzugefügt hast. Praktisch für die die erste Entwicklungsphase.
Irgendwann ist sie denke ich bei make Install besser aufgehoben.

Ich werde wahrscheinlich erst zum Wochenende richtig einsteigen können. Hast auf alle Fälle jetzt schon ne tolle Arbeit vorgelegt.

1 Like
13

Wir haben dazu auch bereits Überlegungen angestellt. Obwohl sich die volle statische Integration praktisch anhört, gibt es an dieser Stelle sehr gute Gründe für eine unabhängige Unterbringung in verschiedenen Repositories.

Wenn man das als Leitlinie betrachtet, bleibt die – genau für solche Dinge vorgesehene – Integrationsmöglichkeit über Git-Submodule übrig. Eine gute Einführung dazu gibt Git Submodules basic explanation · GitHub und für weiterführende Dokumentation schaut man bei Git - Submodules oder Git - git-submodule Documentation vorbei.

Wir haben bereits das Repository GitHub - hiveeyes/arduino: Arduino-compatible MCU firmware code for sensor-, telemetry-, and gateway-appliances. mit dieser Art und Weise gestaltet, dort in erster Linie die Integration mit den benötigten Bibliotheken im libraries/-Unterordner. Auch wenn für den Umgang damit eine kleine Lernkurve notwendig ist, zahlt es sich meist aus, gleich den “richtigen Weg” ™ einzuschlagen, statt kurzfristig andere Integrationsmöglichkeiten (Copy, Symlink, etc.) anzupeilen.

Da dem Konzept der Git-Submodule inhärent ist, auf Git Referenzen zu zeigen, kann man damit auf jeden Fall die Entwicklungsstände zwischen Repositories so synchronisieren, dass sich ein kohärentes Ganzes ergibt.

2 Likes
14

Moin.

Genau dort war mein Fehler.
Jetzt bekomme ich die Sensorwerte rein.

Hab mir dann Mal die nächsten Schritte angeschaut. Das Routing in der settings.py wird bestimmt kein Zuckerschlecken. Gerade da sie so schön variabel einsetzbar macht das ganze hier doch einiges komplexer.
Es sind z.B. mehrere Bob Ziele in der Telemetrie möglich, was ich gerne behalten und unterstützen würde.

Auch in der Telemetrie map von Bob sehe ich ein paar Probleme auf uns zu kommen. Bezeichnung und variabler Wert sind z.B. vertauscht.
Bin am überlegen was sinnvoller ist entweder das Webinterface verbiegen, oder den Datalogger .
Denke Mal das Webinterface, das kommt dann aber fast einem neuschreiben gleich.
Da es teilweise komplett umstrukturiert werden müsste.

Interessant wäre dann aber auch gleich eine Telemetrie-Map für die anderen Telemetrie Ziele.

1 Like
15

Guten Tag,

:sunny: Einleitung

Wir haben nun alles mögliche auf diese Funktionalität geworfen und die HTTP API ist mittlerweile hoffentlich einigermaßen so weit, dass angefangen werden könnte, mit dem Frontend dagegen zu entwickeln. Da das meiste beim GitHub - Hiverize/Webinterface schon steht, geht es vermutlich / hoffentlich nur um geringfügige Anpassungen.

Der Teufel steckt allerdings im Detail, daher bitten wir alle Interessierten, die damit während der nächsten Tage arbeiten werden, um entsprechende Rückmeldungen zur Verbesserung dieser Schnittstelle. Vielen Dank!

:blue_book: Dokumentation

Folgende Dokuschnipsel entstehen gerade.

:play_or_pause_button: Konzept

Die Implementierung entspricht in der Funktionalität hoffentlich ausreichend dem per Add webserver by DieDiren · Pull Request #12 · hiveeyes/terkin-datalogger · GitHub vorgemachten, wie sie aus dem FiPy/webserver.py at master · Hiverize/FiPy · GitHub kam – vielen Dank @Diren und @vinz!.

Kleine Unterschiede dazu finden sich jedoch im Integrationskonzept. Das sieht so aus, dass der Datenlogger nun “immer wie immer” läuft, also ganz herkömmlich. Auf dieser Basis kann optional der Webserver inkl. Terkin HTTP API gestartet werden.

Der Zugriff darauf klappt in jeder Lebenslage (WiFi station vs. WiFi access point), da der Datenlogger bis auf weiteres mit wifi_mode.STA_AP angefahren wird – daher steht die HTTP API in beiden Netzwerkumgebungen zur Verfügung.

Über GET /api/v1/reading/last kann sich das Frontend jederzeit die aktuellsten erfassten Meßwerte abholen. Wenn häufiger aktualisierte Werte gebraucht werden, kann dies kurzerhand über Anfragen wie

echo 4.42 | http PUT "http://$(cat .terkin/floatip)/api/v1/setting?name=main.interval.field"

nachjustiert werden.

:next_track_button: Nächste Schritte

Für uns gibt es noch einige Lücken zu füllen (s.u.). Vielleicht wollen sich daher @Diren, @pinguin oder @MKO der Angelegenheit annehmen? In @clemens findet Ihr auf jeden Fall einen akribischen Tester, der sich ebensosehr auf das Benutzerinterface freut.

Wenn wir Euch seitens der API weiterhelfen können, gebt gerne Bescheid. Wir kümmern uns hoffentlich auch bald um die entsprechende Integration des Interface Bundles in die Firmware selbst.

Herzliche Grüße,
Andreas.

:warning: P.S.: Leider haben die Schnittstellen zur Ansteuerung von Konfigurationseinstellungen noch keine Persistenz. So schön die Welt also auch auf den ersten Blick aussehen mag, es fehlen noch entscheidende Details unter der Haube.

1 Like
16

Nachtrag

HX711

Für die Justierung der Waage (HX711) kann das Benutzerinterface nach der Anfrage an /api/v1/reading/last stabil den Wert bei scale.0.raw heranziehen. [1]

DS18B20

Es fehlt noch die Möglichkeit, die Liste aller beim Bus-Scan entdeckter 1-Wire DS18B20-Sensoren abrufen zu können.

Per Collect information about all DS18B20 sensors connected to all 1-Wire busses können die vorhandenen DS18B20-Sensoren abgefragt werden.

# Request information about DS18B20 sensors.
GET /api/v1/sensors/ds18b20

[
    {
        "address": "28ff641d8fdf18c1",
        "bus": "onewire:0",
        "description": "Wabengasse 1, Rahmen 1",
        "pin": "P11"
    },
    {
        "address": "28ff641d8fc3944f",
        "bus": "onewire:0",
        "description": "Wabengasse 1, Rahmen 2",
        "pin": "P11"
    }
]

Backlog

  1. Ein aktueller Beispiel-Payload im Telemetriedatenformat v1 findet sich bei Terkin HTTP API » Get last reading und vermittelt einen Überblick über die Gestalt der derzeit verwendeten (technischen) Telemetriefeldnamenkonvention auf Basis eines flachen Datencontainers. ↩︎

18

Der Stand der Dinge

@wtf: Weil Du heute danach fragtest, wie hier der Stand hinsichtlich dem gelobten Land “Captive Portal” ist: Zwei Beiträge weiter oben bei HTTP- und webbasierte Konfiguration des Terkin-Datenloggers zur Implementierung eines Captive Portal - #15 by Andreas haben wir den aktuellen Stand beschrieben, hier wollen wir das Thema noch einmal aufgreifen und den status quo kompakter zusammenfassen.

Dort ist dokumentiert, wie die HTTP API der Terkin-Firmware gerade aussieht. Falls sich bei der Nachlese Mißverständlichkeiten ergeben, wäre jetzt noch der richtige Zeitpunkt, um ggf. bestimmte Details davon aufgreifen und beeinflussen zu können.

Synopsis

# 1. Settings

# Retrieve dynamic runtime settings in JSON format.
GET /api/v1/settings?format=json

# 2. Sensors

# Request information about busses.
GET /api/v1/peripherals/busses

# Request information about sensors.
GET /api/v1/peripherals/sensors

# Request information about DS18B20 sensors.
GET /api/v1/sensors/ds18b20

# 3. Data

# Get last reading.
GET /api/v1/reading/last

Beispiele

Vollständige Konversationsbeispiele zu diesen Endpunkten sind gerne als Nachtlektüre bei Terkin HTTP API request / response examples nachzulesen. Statt $(cat .terkin/floatip) kann dort einfach die IP-Adresse des Geräts eingesetzt werden.

Ausblick

Auf die hier beschriebene HTTP API müsste nun das GitHub - Hiverize/Webinterface adaptiert werden, da die HTTP-Schnittstelle der GitHub - Hiverize/FiPy Firmware leicht abweicht.

Außerdem gibt es derzeit noch das Manko, dass die Konfigurationseinstellungen noch nicht zur Laufzeit persistiert werden können, dafür fehlen noch ein paar Zeilen Code. Eine Vorlage dafür fände sich jedoch wiederum schon bei FiPy/lib/config.py at master · Hiverize/FiPy · GitHub, die das auf Basis einer JSON-Repräsentation der Gerätekonfiguration tut.

19

Die wäre nicht kompatibel zur aktuellen hiveeyes-Version in der settings.py, da “Python vs. JSON” lapidar gesagt.

Gibt es da Überlegungen oder Pläne das zu vereinheitlichen?

20

Just for the records: Manchmal erlebten wir absturzartiges Verhalten bei der Benutzung der HTTP API und hatten dazu vor einiger Zeit eine Eingabe beim Autor gemacht. Nun hat er uns geantwortet – bei Accessing filesystem from threaded webserver crashes the machine · Issue #58 · jczic/MicroWebSrv · GitHub könnt Ihr alles nachlesen.

21

In “mpconfigport.h” → set MICROPY_STACK_CHECK to zero.

neee… dann lieber auf den rewrite der lib warten ;)