Momentan funktioniert die Sache auch ohne Rekonfiguration der Basisfirmware. My comment was really just for the records.
HTTP- und webbasierte Konfiguration des Terkin-Datenloggers zur Implementierung eines Captive Portal
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.
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.
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?
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,
},
},
}
Gerade getestet, funktioniert einwandfrei!