Hardware für node im Feld (BOB Projekt, Phase 2)

Sorry, ich bin nicht so tief in der Materie, was Energieversorgung angeht. Könnt ihr mir nochmal kurz das Energiekonzept erklären? Sehe ich das richtig, dass es jetzt keine Möglichkeit gibt, den Lopy an ein Netzteil zu hängen? Man braucht einen LiPo, und muss den, falls man nicht an einem sonnigen Fleckchen wohnt, mit einem externen Ladegerät laden?

Wie kam es zu der Designentscheidung, den HX711 mit auf das Board zu holen? Handelt man sich da nicht recht viel Störung ein, wenn man die Analogsignale unverstärkt bis in die Beute hoch zieht?

G caro

Hey @Caro& @Clemens
das Energiethema ist ein guter Punkt.
Wir könnten einen optional usb-anschluss auf das Board bringen, sodass das System auch per USB betrieben (und falls man möchte aufgeladen) werden kann.

Ich rede mal mit unserem PCB-Designer dazu.

Den Hx711 haben wir auf dem Board verbaut weil bei unserer Waage das Board in der Nähe der Wägezelle liegt, der Hx711 deutlich günstiger ist als der ADS1232 und die gängigen Breakout-Boards für den Hx711 für 5v und nicht für 3V ausgelegt sind und damit unbrauchbar (siehe beelogger-Solar - Beschaltung & Aufbau - Arduino Datenlogger mit Stockwaage für Imker unter Modifikation HX711-Board)

Hx711 lassen sich (anscheinend) günstig über alibaba - bestellen.
für erste Tests werden wir die von den Breakout-Boards runterlöten.

Entschuldigt bitte die späte Störung in diesem Thread, aber nachdem ich mal auf einen Vergleich der Messwerte von DHT22 und BME280, wie sie im luftdaten.info-Netz benutzt werden schaute, kann/muss/will ich nur sagen: Benutzt keinen DHT22! Lieber nen BME280!

Das sind pro Stück maximal 1,5€ mehr. Der DHT22 wirft häufig genug (ab Werk oder nach einigen Monaten) dauerhaft eine Feuchte von >= ~99% und ist damit unbrauchbar.

Bzgl. einer meteorologisch grob fachgerechten Anbringung verweise ich an dieser Stelle noch auf den Thread zu Klein-Wetterhütten.

3 Likes

Wieder einmal eine super geile Grafik von @wtf, Danke! Frage mich gerade warum die Luftdaten-Daten (LDI = LuftDaten.Info) bei der Temperatur ganz andere Wertebereiche haben als der DWD. Ich gehe mal von mir aus und sage, da sind auch indoor-Sensoren dabei? Verfälscht das dann den Feuchte-Vergleich?

Ja, es ließe sich ja nur am Wert erahnen ob der Sensor drinnen hängt. Wie erwähnt ist der “Ausschnitt” aus dem LDI noch sehr groß: Teile Norditaliens und Kroatiens sind südlich mit drin. Eine fleißige Biene namens @Andreas plant dazu aber schon ne schöne Wabe namens “Stationsliste”.

Ein Verfälschen findet also gleichsam überall statt: Wir haben ja auch keinen Einfluss auf die Verteilung der unterschiedlichen Sensortypen oder treffen eine repräsentative Auswahl. (Noch nicht? ;)

Heyho,
Unsere erste Version des Boards ist jetzt gebaut und getestet. Ein paar kleine Fehler haben sich im PCB noch eingeschlichen aber es läuft!
Hier ein Bild und hier der Link zum Github-repository: GitHub - jacobron/EasyHive_Pycom_Shield: a Shield for pycom-modules with Weight, Temperature, audio and I2C sensor-connections and a powerpath manager ic

5 Likes

Hallo Ron,

wir gratulieren Euch vielmals zum ersten Release der Arbeiten an diesem Datenlogger. Sehr spannend was Ihr da treibt: Zum Entwickeln von solchen Geräten mit der Leistungsfähigkeit des ESP32 und dann obendrein mit dem Komfort von Python programmierbar ist die ganze Angelegenheit eigentlich mein derzeitiger persönlicher Wunschkandidat, was Firmwareentwicklung angeht.

Pycom und Adafruit kommen uns da ja grade grundsätzlich sehr entgegen (siehe ESP-IDF and beyond: Lua with NodeMCU, Pycom's MicroPython fork and Adafruit's CircuitPython), nur selbst hatte ich zum Rantasten bisher noch nicht die Gelegenheit. Umso toller ist es nun, dass Ihr Euch nun schon stellvertretend die Finger schmutzig gemacht und die Grundlagenarbeit geleistet habt (danke!), auf der man weiter aufbauen kann.

Auf Englisch würde ich dazu im TLDR; Stil sagen:

[quote blueprint]

Nice to see some MicroPython code from the wild in the context of beehive monitoring, looking forward to send some PRs.

Viele Grüße,
Andreas.

Hi Ron, super!! Da sitzt gerade ein GPy drauf, von den pins könnte aber auch ein LoPy für LoRa oder ein günstiger WiPy für WiFi only drauf, oder? Habt ihr schon sourcen für den HX711 als chip alleine gefunden? Bisher habt ihr den ja von einem HX711 breakout runtergelötet.

Hi,
kann man über diesen USB jetzt auch Code auf den ESP32 schieben? Oder welche Möglichkeiten hätte man da?

Noch eine zweite Sache, die uns hier beschäftigt hat: wie könnten wir es hinkreigen, das Nicht-Techies, also Leute, die keine Scripte kompilieren können, das System benutzen? Wie könnte man z.B. das Einrichten des WLAN lösen? Habt ihr dazu ne Idee? Ist das bei LoRa auch ein Problem?

1 Like

Hi Caro,

vielen Dank der Nachfrage. Ja, das war uns ebenfalls von Anfang an eine Herzensangelegenheit, deshalb hatten wir uns bereits ausführlich mit dem Thema beschäftigt. An entsprechende Dinge können wir jetzt gerne wieder anknüpfen und sie aufleben lassen.

Einleitung

Lass uns vielleicht zwei Unterthemen daraus machen: a) Kompilierung und Aufbringen der Firmware und b) Einbringen von individuellen Konfigurationseinstellungen.

Also die Frage nach a), richtig?

Das geht in Richtung b), stimmts? Es gibt ja noch eine Reihe anderer Konfigurationseinstellungen wie die Datensenke für die Telemetriedaten oder die Justierungswerte für die Wägezellen, um mal die beiden populärsten Dinge zu nennen.

Wir werden im Verlauf sehen, dass man a) und b) zusammenwürfeln, aber auch getrennt lösen kann. Wann was besser passt, ist meist abhängig von der Geräteklasse, deshalb gibt es hier für die Lösung verschiedene Varianten.

a) Kompilierung der Firmware

Status quo

Inspiriert von Features der Mbed Plattform:

Applications for the Mbed platform can be developed using the Mbed online IDE, a free online code editor and compiler.

oder des NodeMCU cloud build service:

NodeMCU “application developers” just need a ready-made firmware. There’s a cloud build service with a nice UI and configuration options for them.

haben wir ein entsprechendes - deutlich generischer angelegtes - Pendant im Angebot, den “Kotori Firmware builder”. Momentan kann er Firmwares direkt aus Git Repositories kompilieren. Serverseitig haben wir dazu die SDKs für Arduino/AVR sowie Arduino/Espressif im Angebot. Hier ein Überblick über weitere Details:

Wichtige Details

Der Firmware Builder realisiert bereits wichtige Aspekte im Bereich von b), konkret handelt es sich um jeden beiden Features aus Firmware builder usage :

  • Decode the firmware specifications (environment and features) from parameters of the HTTP POST request.
  • Amend the source code according to these specifications.

Am ausführlichen Beispiel für die node-wifi-mqtt Firmware kann man exzellent erkennen, dass man damit über einen einfachen HTTP Request individuell konfigurierte Firmware Binaries beziehen kann. Der Mechanismus erfolgt über die Interpolation von #define Konstanten im Quelltext, bevor er an den Compiler weitergereicht wird.

Ausblick

Die Unterstützung für Pycom/MicroPython/ESP32 können wir gerne für Euch nachlegen, wenn Ihr in diesem Kontext darauf aus seid, die Firmware von @Ron und seinen Kolleginnen von EasyHive für Euch zu erschließen. Nachdem diese nun open source ist, wollten wir das ohnehin bald gerne angehen ;].

Ein webbasiertes User Interface für den Firmware Builder fehlt halt noch, aber die Maschinerie unter der Haube könnte man als “1.0-beta1” (eigentlich fertig) bezeichnen. Es sollte also machbar sein, diese Infrastruktur im Kontext von BOB zum Einsatz bringen zu können.

Falls Ihr auch in Richtung OTA (over-the-air update) schielt: Der Firmware Builder kann in diesem Bereich ebenfalls als Basis dienen: Irgendwo müssen die zur Verfügung gestellten Firmware Binaries ohnehin kompiliert werden.

Bei Fragen: fragen!

b) Individuelle Konfigurationseinstellungen

Es soll hier um Konfigurationsmöglichkeiten zur Laufzeit gehen. Das Szenario ist also: Fertiges Gerät inkl. aufgebrachter vanilla Firmware wird verschickt und der Endnutzer kann es auf einfache Art und Weise selbst konfigurieren. Die Konfigurationseinstellungen müssen dann im non-volatile Speicher des Geräts untergebracht werden, d.h. sie werden überhaupt nicht in die Firmware einkompiliert.

Gedanken zu diesem Thema wurden bereits hier im Forum ausgetauscht.

Zwei Möglichkeiten schienen für uns am plausibelsten. Wir würden - passend zum Einsatzzweck - grundsätzlich gern beide für die relevanten Firmwares erschließen.

b.1) Individueller Konfigurationsdialog via »captive portal«

Bei allen WiFi-fähigen Geräten ließe sich dieses Thema so gestalten, dass man die persönlichen Einstellungen über ein sog. captive portal vornehmen kann. Dazu eröffnet das Gerät einen WiFi access point und bietet per Mini-Webserver eine HTTP API zur Laufzeitkonfiguration an, wahlweise noch mit einem kleinen Konfigurationsdialog, so dass man die Konfiguration mit einem handelsüblichen Browser vornehmen kann.

Dafür gibt es schon zahlreiche Beispiele aus der Praxis von populären Firmware Frameworks und wir haben auch schon ein zwei Bibliotheken zusammengesammelt, wie man so etwas selbst unternehmen kann. Ich versuche einmal, sie wiederzufinden und hier als Linkliste einzufügen, wo Ihr Euch erstmal informativ umtun könnt:

b.2) Signalisierung über HTTP/MQTT Rückkanal

Auf Basis von Wünschen wie “Es wäre ja schön, wenn man das Meßintervall auch vom Server aus steuern könnte”, würden wir diese Konfigurationsmöglichkeit ebenfalls gerne erschließen. Das Szenario ließe sich (from 10.000 ft) in etwa folgendermaßen beschreiben:

  • Der Meßknoten meldet sich mit eindeutiger ID beim Server (tut er beim Übermitteln der Telemetriedaten ohnehin). Wahlweise per HTTP oder MQTT.
  • Rückantwort vom Server enthält optional einen Satz von Konfigurationseinstellungen, die der Meßknoten dann einerseits anwendet und außerdem im nicht-volatilen Speicher ablegt, um sie persistent zu machen.

Viele Grüße,
Andreas.

1 Like

Danke @Andreas für die ausführliche Antwort. Wie die initiale Konfiguration auf user-Seite aussehen kann sieht man schön bei der Konfiguration des Feinstaubsensors von luftdaten.info.

siehe auch hier, als eine der Möglichkeiten (hier ESP32):

@Ron, wie habt ihr das bisher gemacht, hat das board ausgeführte FTDI-Pins oder musstet ihr den LoPy runter nehmen zum programmieren und habt das expansion board genutzt bzw. an ein FTDI-Kabel angeschlossen? USB geht glaube ich nicht, da der xPy kein USB-chip drauf hat. Ist glaube ich nur für die Stromversorgung bzw. zum Laden des LiPos.

Habe gerade von @tonke mitbekommen, dass er seinen LoPy über WiFi programmiert. Sehr komfortabel!

Micropython (da geht es afaik, einfach via SSH einloggen und über die Kommandozeile) oder Arduion-IDE (mein Wissensstand, da geht es nicht)?

HEy Clemens!
Den Chip gibts auch lose aus China bei ebay, da haben wir das her

2 Likes

BIsher muss der xPy über FTDI oder Wifi eingerichtet werden.
Bei Wifi besteht laut Pycom die Gefahr, dass man sich selbst vom Gerät aussperrt.

Für den Fall müsste man noch einen BUtton für Safe Boot mit einbauen, der P12 auf high setzt, damit man seinen xPY wieder resetten kann ohne Breadboard oder sowas.

Aber wenn man eine APP für’s Smarte Phone baut, die den xPy mit der custom Firmware einrichtet (so wie das bei OSBH glaube auch ist) dann sollte nicht so viel schiefgehen.

Für Die Eichung der Waage haben wir zwei Buttons auf dem Board gesetzt, ein Tarebutton und ein Skalierwert-Button. Problem bei denen ist aber die Gefahr, dass die später ungewollt ausgelöst werden. In der Firmware sollte es also ein Setup-Modus geben, bei dem dann die Weerte eingerichtet werden können. Und vielleicht sind dann die Buttons auch am Ende unnötig wenn man sowieso mit der APP alles einrichtet.

Grüße!

Hier noch ein wenig mehr Linkfutter:

Captive Portal

OTA

1 Like

@caro, @tox wir hatten telefoniert, inwieweit es sinnvoll ist neben dem WiPy 3 oder LoPy 4 auch den GPy bzw. FiPy einzusetzen, um Standorte ohne WLAN und ohne LoRa abzudecken, die nur GPRS/LTE haben.

Der deep sleep mode scheint bei denen gut zu funktionieren, da hatte ich am Telefon ja noch Recherchebedarf angemeldet:

Root causes of high deep sleep current [LoPy1, WiPy2 and SiPy], all the new modules **do not have deepsleep issues** | Pycom user forum

IMPORTANT: All the information available here is only application to the LoPy1, the WiPy 2.0 and the SiPy. The rest of the modules (W01, L01, WiPy3, LoPy4, FiPy, GPy) have proper deesleep mode that can achieve between ~5 and ~15uA.