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

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

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 Added Webserver to Repo. You can start it by pressing the Reset-Butto… by DieDiren · Pull Request #12 · hiveeyes/hiveeyes-micropython-firmware · 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

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. ↩︎

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 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/config.py at master · Hiverize/FiPy · GitHub, die das auf Basis einer JSON-Repräsentation der Gerätekonfiguration tut.

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?

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.

In “mpconfigport.h” -> set MICROPY_STACK_CHECK to zero.

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

Momentan funktioniert die Sache auch ohne Rekonfiguration der Basisfirmware. My comment was really just for the records.

Die Dokumentation bei Terkin Datalogger Settings gibt nun einen kurzen Einblick in den aktuellen Stand des Konfigurationssubsystems. Die neu hinzugekommene settings-user.example.json und entsprechende Routinen versuchen nun vorsichtig, Konfigurationsänderungen zur Laufzeit abzubilden.

There might still be dragons.

1 Like

Hallo @Diren und @vinz,

auf Basis des aktuellen Firmwarestands (master) könnte die oben angesprochene Laufzeitkonfiguration bereits funktionieren. Wir haben sie jedoch noch nicht in allen Lebenslagen testen können, daher freuen wir uns über entsprechende Rückmeldungen, damit wir ggf. nachlegen können.

Viele Grüße,
Andreas.

1 Like