Der FiPy von PyCom kann mit minimaler Stromversorgung genutzt werden (im Gegensatz zum Beaglebone). Er hat als Herzstück einen ESP32.
@clemens und @didilamken sind schon schwer damit beschäftigt, die Software für das Einlesen der Sensordaten und die Anbindung an den zentralen Server zu realisieren. Wer Lust hat, ihnen beim Testen und implementieren der noch fehlenden Features zu helfen, ist herzlich eingeladen und kann hier Fragen und Antworten los werden.
Jetzt ist hier auch @Andreas mit am Start, voll gut. Da ja auch @Ron schon viel für die Pycom-Boards gecoded hatte, sieht der Stand momentan so aus:
Es gibt sowohl in C (Arduino) als auch in Mircopython Code, der die Sensoren ausliest und über WLAN per MQTT an unseren Server schickt.
Was noch fehlt:
(1) eine Einrichtungsroutine: wir hatten für den Raspi schon mit einer Weboberfläche experimentiert, die sich öffnet wenn der Pi einen Accesspoint aufmacht. Dort kann man in einer GUI seine WLAN-Daten eingeben, testen, ob man die Sensoren richtig angeschlossen hat und die Waage kalibrieren.
Für den FiPy wünschen wir uns etwas ähnliches. Wenn man seinen Knoten einrichtet, soll Folgendes passieren:
man wählt aus, wie die Daten übertragen werden sollen: WLAN, LTE oder LoRa.
man gibt die entsprechenden Zugangsdaten ein.
man kalibriert seine Waage
man lässt das System wissen, in welcher Anordnung man die Temperatursensoren eingebaut hat (welcher Sensor ist an Pos1, Pos2,…,Pos5) und macht einen Temperaturabgleich. Hierfür wäre eine Variante denkbar, die eine Thermoskanne mit heißem Wasser verwendet. Der Prozess: man hängt nach einander die Sensoren in das Wasser. Sobald das Skript den Temperaturanstieg erkennt, bestätigt es und man hängt den nächsten rein. Zum Schluss hängt man alls Sesnoren gemeinsam rein und tariert die Temperaturmessung, in dem ein Abweichunngsfaktor vom Mittelwert für jeden Sensor gespeichert wird.
Jeder Schritt sollte einzeln durchführbar sein. Nur weil ich mein WLAN-Passwort ändere, sollte ich nicht die Waage neu kalibrieren müssen.
Das ganze soll als Webapp betriebssystemunabhängig sein. Es sollte so viel wie möglich lokal auf dem FiPy gemacht werden, damit unser System auch bei schlechter Verbindung genutzt werden kann.
Bestimmt hab ich was vergessen…Ich freue mich über euer Feedback!
schön Euch alle hier gemeinsam versammelt zu wissen. Vielen Dank für das Anlegen des Beitrags, @caro!
Nach einer etwas längeren Pause von ca. zwei Jahren nehmen wir nun die Arbeiten an einer soliden MicroPython firmware wieder auf, weil sich durch die Anforderungen des BOB Projekts eine einmalige Gelegenheit dafür bietet.
Nachdem @Ron, @RalfL und @tonke aktuell schon wunderbare Grundlagenarbeit geleistet haben (dankeschön!), wärmen wir unsere Vorarbeiten in Richtung flexibler und robuster Telemetrie wieder auf und konnten sie auch endlich auf echter Hardware erfolgreich testen.
Details zum Thema haben wir unter Terkin for MicroPython abgelegt, später kommen noch weitere Zusatzinformationen hinzu, wie wir damit alle unsere softwareseitigen Wünsche und Anforderungen bündeln könnten.
Das meiste kam zwar ohnehin aus der Community, aber bislang fehlte noch jemand, der die zahlreichen versprengselten Errungenschaften einsammelte und gebündelt unter einen Hut brachte. Dem hatten wir uns vor kurzem im Rahmen eines Frühjahresputzes annehmen können.
Unsere Arbeiten daran wurden allgemein gut aufgenommen, in Summe ist also eine kleine Erfolgsgeschichte daraus geworden, weil die Verbesserungen natürlich automatisch der ganzen Community wieder zur Verfügung stehen.
Viel Vergnügen damit und gib natürlich gerne Bescheid, falls Du Dir weitere Verbesserungen oder Erweiterungen daran wünschst. Durch den erfolgreichen Vorgang haben wir dort aktuell einen recht guten Stand, denke ich.
Caro hatte gefragt, was notwendig ist, um den FiPy mit Atom zu verbinden.
Vincent und ich mussten den User noch in uucp und dialout zufügen, also sudo gpasswd -a <user> uucp
Können wir vielleicht ab jetzt alle zusammen im Hiveeyes-Repo basteln? Kannst du uns einladen, Andreas? Dann können wir auch dort Issues anlegen. Der erste Workshop soll ja schon in ca. 2 Wochen stattfinden.
@Andreas, magst du hier mal drüber schauen und einen Vorschlag machen, wie wir, und welche Teile wir in den gemeinsamen Code ins hiveeyes-Repo rüber bekommen können.
Hallo,
da mein kleines Webinterface hier ja schon erwähnt wurde, möchte ich hier meine Erfahrungen zusammenfassen.
Basis:
Als Basis für den Webserver habe ich folgendes Github Projekt genutzt und bis jetzt keine Probleme gehabt: MicroWebSrv.
Mit dem MicroDNSSrv von dem gleichen Programmierer lässt sich ohne Problem ein Captive Portal einrichten.
Einschränkungen:
Es gibt die Möglichkeit Python und HTML zu kombinieren (ähnlich wie Jinja2), in meinen Versuchen schien das jedoch Recht langsam zu sein.
Das Webinterface von mir liefert momentan einfaches HTML aus (für jede Rubrik von Einstellungen eine eigene Datei) und lädt die Daten aus der Konfigurationsdatei per JavaScript. Das Speichern geht über eine Python Funktion, die HTTP-POST Daten in eine JSON-Datei schreibt.
@Andreas: Wir sollten uns mal kurzschließen, wie wir das Webinterface am besten in euren Code integrieren. Ich werde mir heute mal genauer angucken, wie euer Code aufgebaut ist und ein paar Ideen dazu entwickeln.
Tiptop, beides sind ja auch die Platzhirschen in diesem Bereich, daher: Gute Wahl! Exzellent, dass Du diese bereits miteinander integriert hast und damit warm geworden bist, hier hat unser Code bisher noch eine Lücke.
Das wäre grandios! Meinst Du, wir können im Laufe des Nachmittags kurz telefonisch zusammenkommen? Ab ca. 15:30 Uhr werde ich für ein paar Stunden mit @einsiedlerkrebs zusammensitzen, kurz davor gegen 15:15 Uhr wäre optimal.