ich versuche das gerade zum laufen zu bekommen, scheitere aber schon am make setup
Nelson:hiveeyes-micropython-firmware markus$ make setup
cat: .terkin/floatip: No such file or directory
/bin/sh: --python=python3: command not found
make: *** [setup-virtualenv3] Error 127
Auch ich bekomme einen Fehler direkt nach dem Klonen des Repositories, allerdings an späterer Stelle:
offgrid:hiveeyes-micropython-firmware amo$ make setup
cat: .terkin/floatip: No such file or directory
Running virtualenv with interpreter /Users/amo/.pyenv/shims/python3
Using base prefix '/usr/local/Cellar/python/3.7.4/Frameworks/Python.framework/Versions/3.7'
New python executable in /Users/amo/tmp/hiveeyes-micropython-firmware/.venv3/bin/python3.7
Also creating executable in /Users/amo/tmp/hiveeyes-micropython-firmware/.venv3/bin/python
Installing setuptools, pip, wheel...
done.
.venv3/bin/pip --quiet install --requirement requirements-dev.txt
# Define path to the "dist-packages" installation directory.
# Install "upip", the PyPI package manager for MicroPython.
.venv3/bin/pip install pycopy-cpython-upip
Collecting pycopy-cpython-upip
Downloading https://files.pythonhosted.org/packages/e0/ac/5ddaf3cd3f86af13702721fff23623fa51382c0ac47082482a74d22f54e1/pycopy-cpython-upip-1.3.1.tar.gz
Collecting pycopy-cpython-cpython-uerrno (from pycopy-cpython-upip)
ERROR: Could not find a version that satisfies the requirement pycopy-cpython-cpython-uerrno (from pycopy-cpython-upip) (from versions: none)
ERROR: No matching distribution found for pycopy-cpython-cpython-uerrno (from pycopy-cpython-upip)
make: *** [download-requirements] Error 1
Damit man in solchen Fällen nicht völlig auf dem Trockenen sitzt, stellen wir seit der Version 0.4.0 auch fertig gebündelte Release-Archive zur Verfügung. Sie findet man bei Releases · hiveeyes/hiveeyes-micropython-firmware · GitHub jeweils im Abschnitt “Assets”. Sie enthalten alle Dateien, die zum Betrieb benötigt werden.
Erste Erkenntnis: pycom-mpy funktioniert (natürlich) nicht auf dem esp32. Da hätte ich auch vorher drauf kommen können…
Was anderes verwirrt mich jetzt aber sehr: der normale source spuckt die Fehlermeldung:
[main.py] INFO: Loading modules
Traceback (most recent call last):
File “main.py”, line 21, in
ImportError: no module named ‘terkin.logging’
MicroPython v1.11-219-gaf5c998f3 on 2019-08-18; ESP32 module (spiram) with ESP32
aus.
sys.path
[‘’, ‘/lib’, ‘/dist-packages’]
(ich hab die /flash Sachen rausgenommen, die gibts hier eh nicht)
Was super seltsam ist, dass das hier funktioniert:
import hiveeyes.sensor_hx711
Traceback (most recent call last):
File “”, line 1, in
File “/lib/hiveeyes/sensor_hx711.py”, line 5, in
ImportError: no module named ‘terkin.logging’
No wirrer wirds, wenn ich /terkin in /aterkin umbenenne. Dann funktioniert der import von aterkin.logging! Allerdings das Programm dann nicht mehr.
Ich verstehe nicht, wo der funktionale Unterschied zwischen /terkin und /hiveeyes ist??? init.py ist in beiden. Ich hab auch schon die Unterverzeichnisse aus /terkin gelöscht.
Zur Sicherheit hab ich auch nochmal die originale ausprobiert (+settings.py). No joy.
Ich hab es dann soweit vereinfacht, das eigentlich nur boot, main und das terkin Verzeichnis geblieben ist.
Resultat: heisst das Verzeichnis ‘terkin’ gehts nicht, heisst es irgendwie anders gehts.
???
Wir haben nun versucht, die Sanity-Checks bei den initialen Setup-Schritten der Sandbox zu verbessern. Nach einem git pull wirst Du vermutlich einen nun besser gestalteten Hinweis darauf bekommen, dass Dir das Python-Program virtualenv fehlt. Du kannst es auf einem Debian System per apt install python-virtualenv python3-virtualenv für beide Python Versionen installieren.
Außerdem haben wir den oben erwähnten Fehler bei der Installation einer der ersten wichtigen Abhängigkeiten (upip – der MicroPython Paketinstaller) behoben [1] und Upstream ebenfalls darüber informiert [2]. Auch @tonke war vor Kurzem von diesem Fehler betroffen.
Falls wir in ähnliche Systemzustände gelangen, was bei Umstrukturierungen im Rahmen von Module freezing for Pycom MicroPython öfters mal vorkommt, behelfen wir uns meist mit einem beherzten make format-flash, um die Inhalte des Flash-Dateisystems des Geräts kurzerhand komplett zurückzusetzen [3].
Wir hoffen, dass die oben genannten Verbesserungen dazu beitragen, dass das Sandbox-Setup nun wieder klappt. Falls es immer noch hakt, gebt gerne Bescheid.
Sobald man eine aktuell angepasste settings.py im Arbeitsverzeichnis liegen hat, sind normalerweise keine Dateien auf dem Gerät, die durch ein erneutes Aufspielen versehentlich überschrieben werden könnten. Vor einem unbeabsichtigten Löschen schützt aber noch eine entsprechende Sicherheitsabfrage.
$ make format-flash
Device port: ip => 192.168.178.30
[CONFIRM] Format /flash on the device with LittleFS? THIS WILL DESTROY DATA ON YOUR DEVICE. [y/n] n
schön, dass es bei Dir nun geklappt hat, auch wenn Du nochmal nachjustieren musstest. Ich schaue mir die Sache näher an, sobald ich mal wieder länger an den Tasten bin.