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

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

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

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

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

Versuche gerade das Beispiel hier zum Laufen zu bekommen: terkin-datalogger/http-api-hacking.rst at master · hiveeyes/terkin-datalogger · GitHub

Dazu habe ich die HTTP-API aktiviert

services = {
    'api': {
        'modeserver': {
            'enabled': True,
        },
        'http': {
            'enabled': True,
        },
    },
}

Die IP des nodes im lokalen Netz herausgefunden und versuche nun die Status-Info bzw. last readings aufzurufen mit

# http "http://192.168.178.23/status"

http: error: ConnectionError: HTTPConnectionPool(host='192.168.178.23', port=80): Max retries exceeded with url: /status (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fba8924a898>: Failed to establish a new connection: [Errno 111] Connection refused',)) while doing GET request to URL: http://192.168.178.23/status

# http GET "http://192.168.178.23/api/v1/reading/last"

http: error: ConnectionError: HTTPConnectionPool(host='192.168.178.23', port=80): Max retries exceeded with url: /api/v1/reading/last (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f330994a898>: Failed to establish a new connection: [Errno 111] Connection refused',)) while doing GET request to URL: http://192.168.178.23/api/v1/reading/last

Anpingen kann ich das Gerät:

root@XPS13-CGruber:/home/cgruber/hiveeyes/sources/hiveeyes-micropython-firmware# ping 192.168.178.23
PING 192.168.178.23 (192.168.178.23) 56(84) bytes of data.
64 bytes from 192.168.178.23: icmp_seq=1 ttl=255 time=8.26 ms
64 bytes from 192.168.178.23: icmp_seq=2 ttl=255 time=11.0 ms
64 bytes from 192.168.178.23: icmp_seq=3 ttl=255 time=7.06 ms
64 bytes from 192.168.178.23: icmp_seq=4 ttl=255 time=6.02 ms

Hört der auf einem anderen Port als 80?

Ich habe es auch auf die gleiche Weise versucht und leider ebenfalls keinen Erfolg gehabt. In der Konfiguration des MicroWebsrv2 habe ich auch nur die Standard-Ports 80 und 443 (SSL) gefunden.

def __init__(self) :
    self._backlog         = None
    self._slotsCount      = None
    self._slotsSize       = None
    self._keepAlloc       = None
    self._maxContentLen   = None
    self._bindAddr        = ('0.0.0.0', 80)
    self._sslContext      = None
    self._rootPath        = 'www'
    self._timeoutSec      = 2
    self._notFoundURL     = None
    self._allowAllOrigins = False
    self._corsAllowAll    = False
    self._onLogging       = None
    self._xasSrv          = None
    self._xasPool         = None
    self.SetNormalConfig()

Und:

if self._bindAddr[1] == 80 :
        self._bindAddr = (self._bindAddr[0], 443)    

Ist der Webserver grundsätzlich vielleicht nur erreichbar, wenn man auf dem hosteigenen Accesspoint eingeloggt ist?

Hi @clemens und @Jan,

Findet sich denn irgendwo "Setting up HTTP API" in der Log-Ausgabe? Oder vielleicht irgendwelche anderen Dinge, die auf einen Fehler hinweisen?

Viele Grüße,
Andreas.

Es hatte sich ein kleiner Fehler eingeschlichen. Mit Fix webserver imports · hiveeyes/terkin-datalogger@a8ae993 · GitHub könnte es wieder klappen.

Mit Terkin 0.9.0 läuft der Webserver nun anstandslos bei mir auf macOS los und funktioniert scheinbar auch, siehe Weiterentwicklung von Terkin für CPython / Raspberry Pi.

$ http localhost:7654/api/v1/reading/last

HTTP/1.1 200 OK
Application-Name: Terkin Datalogger
Application-Version: 0.9.0
Content-Type: application/json; charset=UTF-8
Server: MicroWebSrv2 by JC`zic

{
    "system.memfree": 1000000,
    "system.runtime": 0.04175901412963867,
    "system.time": 1588556826.69218,
    "system.uptime": 1588556826.692182
}

Auf dem Gerät läuft der Webserver natürlich auf Port 80 ("0.0.0.0", 80), wenn er nicht anders konfiguriert wurde.

# Control the services offered by the device.
services = {
    'api': {
        'modeserver': {
            'enabled': True,
            'port': 6666,
        },
        'http': {
            'enabled': True,
            'port': 7654,
        },
    },
}
1 Like

Gerade getestet, funktioniert einwandfrei!

1 Like