(F)OTA-update für FiPy

Hört sich bekannt an. I’m with you.

Nun läuft es reliabel und halbwegs stabil! Habe den port 8000 in der firewall freigegeben, nutze Rechner und node näher am WLAN-Router und verwende als OTA-lib jetzt pycom-libraries/OTA.py at master · pycom/pycom-libraries · GitHub – da ist eine andere, ältere Version im Verzeichnis /1.0.1/flash/lib

Wenn es funktioniert schaut das so aus: Der node übermittelt seine aktuelle Versionsnummer als URL-Parameter an den Server:

http://192.168.178.21:8000/manifest.json?current_ver=1.0.0

Der Server spuckt nun das aus:

{
    "delete": [],
    "new": [],
    "update": [
        {
            "URL": "http://192.168.178.21:8000/1.0.2/flash/main.py",
            "dst_path": "/flash/main.py",
            "hash": "9f372699c1ade7a182459367f2e84c2918677cd9"
        }
    ],
    "version": "1.0.2"
}

dann holt sich der node die neuen Dateien, in unserem Fall nur die geänderte main.py, dann wird auf dem node eine neue Datei OTA_VERSION.py, angelegt, die als Variable

VERSION = '1.0.2'

enthält. Der node macht einen restart und checkt – jetzt mit seiner neuen Versions-Nummer 1.0.2 nochmal die Lage. Keine neuere Software da, dann passt es!

auf dem node

Initializing filesystem as LittleFS!
Starting loop
Performing OTA
Requesting: manifest.json?current_ver=1.0.0
Requesting: 1.0.2/flash/main.py
ets Jun  8 2016 00:22:57

rst:0x7 (TG0WDT_SYS_RESET),boot:0x12 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff8028,len:8
load:0x3fff8030,len:2156
ho 0 tail 12 room 4
load:0x4009fa00,len:19208
entry 0x400a05f4
Initializing filesystem as LittleFS!
Starting loop
Performing OTA
Requesting: manifest.json?current_ver=1.0.2
Already on the latest version

auf dem Server

root@XPS13-CGruber:~/ota-server# python3 OTA_server.py
Got query for: /manifest.json?current_ver=1.0.0
192.168.178.28 - - [27/Sep/2019 16:59:06] "GET /manifest.json?current_ver=1.0.0 HTTP/1.0" 200 -
Generating a manifest from version: 1.0.0
Got query for: /1.0.2/flash/main.py
192.168.178.28 - - [27/Sep/2019 16:59:07] "GET /1.0.2/flash/main.py HTTP/1.0" 200 -
Got query for: /manifest.json?current_ver=1.0.2
192.168.178.28 - - [27/Sep/2019 17:01:02] "GET /manifest.json?current_ver=1.0.2 HTTP/1.0" 200 -
Generating a manifest from version: 1.0.2
3 Likes

Der Python-OTA-Server ist ganz clever und vergleicht die in seinem Dateisystem abgelegten Dateien für verschiedene Versionen, dann gibt er fürs update nur die Dateien an, die tatsächlich Änderungen habe.

Weiter kann man auch duch Depublikation auf dem Server wieder zu einer früheren Version downgraden, wenn ich auf dem Server Version 1.0.1 und 1.0.2 habe und auf dem Gerät auch die 1.0.2 holt sich der node, wenn ich die 1.0.2 auf dem Server (!) lösche wieder die 1.0.1 als “neueste” bzw. latest available version.

Exzellent!

Fein!

Es wäre (für die nächsten Schritte) praktisch, wenn man dieses Detail (“latest available”) feiner konfigurieren könnte – nicht?

Was meinst du da genau? Nur stable, oder auch beta oder alpha?

Wahrscheinlich irgendwas in dieser Richtung, ja. Ich denke es wird sich im weiteren Verlauf etwas ergeben.

Gut, war ein bischen fies, habe als neueste Version das Hiveeyes-Release 0.6.0 auf den Server gepackt, da mag die OTA-Routine was nicht:

Requesting: manifest.json?current_ver=1.0.2
Requesting: 1.1.0/dist-packages/cayennelpp/lpp_type.py
[Errno 19] ENODEV
Error downloading `http://192.168.178.21:8000/1.1.0/dist-packages/cayennelpp/lpp_type.py` retrying...
Requesting: 1.1.0/dist-packages/cayennelpp/lpp_type.py
[Errno 19] ENODEV
Error downloading `http://192.168.178.21:8000/1.1.0/dist-packages/cayennelpp/lpp_type.py` retrying...
Requesting: 1.1.0/dist-packages/cayennelpp/lpp_type.py
[Errno 19] ENODEV
Error downloading `http://192.168.178.21:8000/1.1.0/dist-packages/cayennelpp/lpp_type.py` retrying...
Requesting: 1.1.0/dist-packages/cayennelpp/lpp_type.py
[Errno 113] ECONNABORTED
Error downloading `http://192.168.178.21:8000/1.1.0/dist-packages/cayennelpp/lpp_type.py` retrying...
Requesting: 1.1.0/dist-packages/cayennelpp/lpp_type.py
[Errno 113] ECONNABORTED
Error downloading `http://192.168.178.21:8000/1.1.0/dist-packages/cayennelpp/lpp_type.py` retrying...
Traceback (most recent call last):
  File "main.py", line 45, in <module>
  File "/flash/lib/OTA.py", line 69, in update
Exception: Failed to download `http://192.168.178.21:8000/1.1.0/dist-packages/cayennelpp/lpp_type.py`

[edit] die Dateien waren im root-Verzeichnis, da gehört aber noch eine Ebene /flash/ dazwischen, daher ging hier einiges nicht!

Das Release-Archiv mit vorkompilierten Quellen [1] ist kompakter und lässt sich damit u.U. robuster auf das Gerät übertragen.

[1] https://github.com/hiveeyes/hiveeyes-micropython-firmware/releases/download/0.6.0/hiveeyes-micropython-firmware-0.6.0-pycom-mpy.tar.gz

afaik kann das OTA-Tool kein vorcompilierten Quellen, zumindest hab ich dazu nix gefunden.

Mir ist nicht klar, was ENODEV bei uns konkret bedeutet

https://www-numi.fnal.gov/offline_software/srt_public_context/WebDocs/Errors/unix_system_errors.html

ENODEV 19 /* No such device */

Also das device ist ja da! Datei zu groß? Kann auf 3. Verzeichnisebene nix ablegen? Nicht zwischenspeichern? …

… unter Umständen out-of-memory o.ä., ja.

Vom Server aus gesehen war es die erste Datei, die angefordert wurde, wenn der Fipy nicht ganz schräge Dinge macht, sollte noch reichlich Platz sein.

Sobald die Übertragung robust genug ist, könnte man einen Blick auf Tankful / update-server · GitLab werfen. Siehe auch New OTA Update Server | Pycom user forum.

Hier ist gerade gar nichts robust, was vor ein paar Tagen noch funktionierte geht heute wieder nicht, der FiPy kam zuerst nicht ins Netz, jetzt funktioniert es, der Python-Server kann vom gleichen PC gelesen werden, aber vom FiPy aus geht es nicht, er kann manifest.json nicht laden. Dann geht es wieder nach einem kompletten Win10-Systemneustart, agrrr!

Um der Frage nachzugehen, ob es an den Verzeichnisebenen liegen kann habe ich mal ein paar Dateien ins Hauptverzeichnis verlegt und den update-Prozess angestoßen. Aber auch hier gleiches Ergebnis:

Starting loop
Performing OTA
Requesting: manifest.json?current_ver=1.0.2
Requesting: 1.1.0/sensor_bme280.py
[Errno 19] ENODEV
Error downloading `http://192.168.178.21:8000/1.1.0/sensor_bme280.py` retrying...
Requesting: 1.1.0/sensor_bme280.py
[Errno 19] ENODEV
Error downloading `http://192.168.178.21:8000/1.1.0/sensor_bme280.py` retrying...
Requesting: 1.1.0/sensor_bme280.py
[Errno 19] ENODEV
Error downloading `http://192.168.178.21:8000/1.1.0/sensor_bme280.py` retrying...
Requesting: 1.1.0/sensor_bme280.py
[Errno 113] ECONNABORTED
Error downloading `http://192.168.178.21:8000/1.1.0/sensor_bme280.py` retrying...
Requesting: 1.1.0/sensor_bme280.py
[Errno 113] ECONNABORTED
Error downloading `http://192.168.178.21:8000/1.1.0/sensor_bme280.py` retrying...
Traceback (most recent call last):
  File "main.py", line 45, in <module>
  File "/flash/lib/OTA.py", line 69, in update
Exception: Failed to download `http://192.168.178.21:8000/1.1.0/sensor_bme280.py`

Beim Server kommen die Anfragen aber an und werden auch ausgeliefert:

Got query for: /manifest.json?current_ver=1.0.2
192.168.178.28 - - [30/Sep/2019 12:17:30] "GET /manifest.json?current_ver=1.0.2 HTTP/1.0" 200 -
Generating a manifest from version: 1.0.2
Got query for: /1.1.0/sensor_bme280.py
192.168.178.28 - - [30/Sep/2019 12:17:30] "GET /1.1.0/sensor_bme280.py HTTP/1.0" 200 -
Got query for: /1.1.0/sensor_bme280.py
192.168.178.28 - - [30/Sep/2019 12:17:30] "GET /1.1.0/sensor_bme280.py HTTP/1.0" 200 -
Got query for: /1.1.0/sensor_bme280.py
192.168.178.28 - - [30/Sep/2019 12:17:30] "GET /1.1.0/sensor_bme280.py HTTP/1.0" 200 -

Vielleicht finden wir Unterstützung im Pycom Forum. Es gibt dort bereits einige Einträge zu OTA.

Gerade noch bemerkt, dass ich die hiveeyes-Dateien auf dem Python-Server im falschen Verzeichnis hatte, nämlich nach der Versionsnummer. Da gehört aber noch ein Verzeichnis /flash/ dazwischen.

Damit scheinen Standard-Szenarien abgedeckt zu sein, d.h. Dateien im Verzeichnis /flash/ und /flash/lib/ werden unterstützt

Requesting: manifest.json?current_ver=1.0.0
Requesting: 1.1.0/flash/settings.example.py
Requesting: 1.1.0/flash/lib/hx711_heisenberg.py
Requesting: 1.1.0/flash/lib/umal.py
Requesting: 1.1.0/flash/settings.example-bob.py
Requesting: 1.1.0/flash/boot.py
Requesting: 1.1.0/flash/settings.py
Requesting: 1.1.0/flash/lib/hx711.py
Requesting: 1.1.0/flash/lib/mininet.py
Requesting: 1.1.0/flash/main.py

Aber schon ein neues, bisher nicht vorhandenes Verzeichnis macht Probleme:

Requesting: 1.1.0/flash/foo/bar.py
[Errno 2] ENOENT

oder auch eine weitere Verzeichnisebene in /lib/ die noch nicht auf dem device existiert

Requesting: 1.1.1/flash/lib/terkin/api/__init__.py
[Errno 2] ENOENT

Damit kann weder die hiveeyes- noch hiverize-Software mit den bestehenden OTA-Mitteln von PyCom hochgeladen werden, da es in beiden Varianten weitere Verzeichnisse und geschachtelte Verzeichnisse gibt.

Wenn das Verzeichnis bereits vorhanden ist, kann der OTA-Service dort auch Dateien updaten!!

Requesting: 1.1.1/flash/lib/hiveeyes/sensor_hx711.py
Requesting: 1.1.1/flash/lib/hiveeyes/sensor_bme280.py

Ein Wechsel von der hiverize zur hiveeyes-Software oder vice versa ist aber mit den jetzt verfügbaren Boardmitteln nicht machbar. Dazu müsste das OTA-Skript Verzeichnisse anlegen können.

1 Like

Eine Alternative zum bisher getesteten könnte der Weg über pybytes sein

https://docs.pycom.io/pybytes/releases/

Mit der überarbeiteten PyCom-Firmware von @Andreas läuft das OTA-Skript wieder, sogar zuverlässiger als bisher! Leider kann das Skript immer noch keine neuen Ordner anlegen, d.h. Softwareänderungen, die neue Verzeichisse benötigen bekommen wir so nicht auf den FiPy, alles andere scheint aber gut zu laufen! Sehr schön!!

Pybytes kannten wir bisher primär zum erst-provisioning von Geräten. Wie oben schon angedeutet fährt der Zug aber weiter und mit der neuen Version kann auch code editiert und auf das Gerät geladen werden, quasi eine online-IDE jetzt mit Pymakr.

Damit ergeben sich für OTA-updates neue Möglichkeiten, wenn man die cloud von PyCom nutzen möchte.

[via: PyCom-Newsletter Mai, 2020]

5 posts were split to a new topic: Umstellung auf Terkin Firmware