HTTP- und webbasierte Konfiguration für Terkin-Datenlogger (captive portal)

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.

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

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.

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

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!

@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.

Genau, das ist mein Fork

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.

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

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?

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.

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

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 code for sensor and telemetry nodes. 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

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