ZACplus Citizen-Science Workshop vom 03.12.2025

Ort: hybrid, OpenEcoLab Rahden und Berlin.

Teilnehmer: 2

Vorschlag von Robin zur Verbesserung der Netzwerkanbindung des Mess-Rigs und des Raspi Zero

Robin:

bzgl. dem raspi setup ... so wie das bis jetzt laeuft .. also ich finds nicht os optimal, weil es schon recht kompliziert ist, und vor allem kann mans nicht einmal aufsetzten und dann immer wieder nutzen egal wo.. muss immer ans WLAN angepasst sein. Heisst: beim transport anderstwo hin, muss man raspi OS neu aufspielen; das ist muehsahm/aufwendig/unflexibel.

Eine alternative dafuer hab ich mit Timm mal ausgeknobelt:

Den Raspi so einrichten, dass er sein eigenes WLAN hostet. Die mess-station waehlt sich dann da hin ein. dann kommt an den raspi (direkt oder ueber nen USB-Hub, damit man noch mehr zeugs anschliessen kann) ein USB-LAN-adapter. am notebook (oder handy mit USB-LAN-adapter) waehlt waehlt man sich.. irgendwie ins internet ein (ueblicherweise per mobil-netzwerk oder WLAN), und shared dann internet per LAN. notebook oder handy wird dann per LAN kabel mit dem raspi verbunden. darueber kriegen wir dann zugrif auf den raspi, der immer gleich sein wird, egal wo wir gerade damit sind. der raspi hat auch internet zugrif, ohne neu konfiguriert zu werden. Ohne internet funktionierts auch. Nachteile:

1. Mehr hardware ist notwendig, und 2. das initiale setup ist etwas aufwendiger.

Punkt 2 gilt aber auch nur, wenns beim bisherigen initialen setup keine probleme gibt. Wir hatten ja welche, wegen security restrictions im WLAN.

alternativ koennt man auch am notebook/handy nen USB-WLAN-adapter (anstatt LAN) anschliessen (und das selbe beim raspi), und somit das kabel durch ein (weiteres) WLAN ersetzten. Stelle ich mir aber muehsahmer und verwirrender vor.

Ich finde kabel grundsaetzlich sympatischer. da ist auch direkt sichtbar was abgeht, und es ist auch per foto einfach dokumentierbar und gleich verstaendlich usw.

Oli, geht das evtl. auch fuer das CYD, irgnedwie per kabel?

Oliver:

bin mir nicht sicher ob ich alles richtig verstehe, aber pauschal kann man sagen dass es auf jedenfall viele Wege gibt wie man diese Struktur aufsetzen kann. Und es kommt auch immer auf die jeweiligen Vorlieben an oder was der einzelne gerade als einfach empfindet oder was nicht.

So ist das einbinden eines Raspis in ein lokales WLAN normalerweise ein Standard-Vorgang auf einer Art Standard-Plattform, bei dem ich davon ausgehen kann, dass er im Internet tausendfach dokumentiert ist. Ich hab aber selbst auch schon oft genug mit nem Raspi-Setup rumgeeiert um zu wissen wo da das Problem ist, welches man mit einem Wort auf den Punkt bringen kann: "headless". Soll heissen, hat man gerade nen HDMI-Monitor (mit passendem HDMI-Mini-zu-HDMI-Standard-Adapter) und ne USB-Tastatur und-Maus zur Hand gehts relativ easy, aber falls nicht muss man schon ziemlich genau wissen was man da tut ... und kann sich trotzdem mitunter noch verheddern.

Ähnliches rum-Ge-eiere mit der Netzanbindung: Selbst wenn sich der Raspi auf Anhieb mit dem lokalen WLAN verbindet muss man immer noch irgendwie rauskriegen, was der gerade für ne IP-Adresse hat und diese ist dann obendrein noch dynamisch da zumeist mit DHCP zugewiesen und kann beim nächsten mal schon wieder eine andere sein. (Eine statische IP würde das Problem lösen aber auch die müsste erstmal korrekt eingerichtet werden was gewisse Netzwerk-Kentnisse erfordert.)

Und wenn dann noch so wie bei Euch das WLAN besonders gut gesichert ist dann ists nochmal komplizierter, das war wohl auch ein Teil der Schwierigkeiten mit dem wir neulich zu kämpfen hatten.

WIe ich eben schon sagte sind viele Wege möglich. Die bisherige Anbindungsform ist für mich bislang die straightforwardeste, weil die Aufgabe "Bring einen Raspi in ein WLAN" eine Standardübung ist, aber aufgrund der ausgeführten Gründe kann ich auch den Wunsch verstehen, das irgendwie komfortabler zu gestalten und es spricht ja auch nix dagegen, da mehrere Alternativen zu entwickeln und anzubieten.

Im Detail ist mir noch nicht ganz klar, was genau Du da vorschlägst, im Hinblick auf die Sache mit dem USB-LAN-Adapter leuchtet mir aber soweit folgendes ein: Der Raspi spannt ein eigenes lokales Netz auf, über das er mit dem CYD kommuniziert. Soweit d'accord und es würde auch die IP-Konfig beim CYD vereinfachen weil man die dann darin quasi "hardverdrahten" könnte und das CYD nicht mehr ins lokale WLAN bringen müsste.

Der Raspi müsste dann als Router zwischen seinem eigenen Netz und dem äusseren WLAN fungieren und bräuchte demzufolge ein zweites network-interface, vielleicht ist es ja auch das was Du mit dem USB-LAN-Adapter meinst ?

Wobei man da aber immerhin nen LAN Zugang bräuchte d.h. der Raspi würde per ETH-Kabel direkt am Router angestöpselt ... aber ob das immer so realistisch bzw. vom jeweilige Betreiber erwünscht ist ? Und mir ist auch noch nicht so ganz der Schlenker übers Internet klar.

Und ich seh das Ganze auch eher nicht so als mobile Anwendung sondern extrem stationär ... man will ja schliesslich nicht andauernd mit nem 10L-Tank voll Kalilauge von A nach B wandern und später wirds ja noch mehr.

Was die Anbindung vom CYD via Kabel an den Raspi betrifft verstehe ich den Wunsch schon eher und da spricht auch im Prinzip nicht viel gegen, bis auf zwei Einwände:

1. Also der große Gag und einzige Grund für die Verwendung des CYD besteht darin, das es nen ESP32 und damit die Möglichkeit zur Datenübertragung per WLAN beinhaltet, da jetzt die Daten mit nem Kabel zu übertragen wäre wohl irgendwie ein bischen irrwitzig (aber technisch natürlich machbar).

2. Das Gewünschte kann aber trotzdem auf supereinfache Weise erreicht werden, indem man einfach das ganze CYD und den ESP32 weglässt und den INA219 direkt an den Raspi anbindet. Dann kann auf die Daten entweder gleich remote bzw. per Webbrowser zugegriffen werden oder man stattet den Raspi noch mit nem Display aus .... wobei ich der Einfachheit halber einen kleinen (4" oder 5") Touchscreen mit HDMI empfehlen würde, die kosten mittlerweile auch nicht mehr viel, siehe zB. von Waveshare).

Also wie gesagt, sowas könnte man noch als weitere Alternative hinzu entwickeln, ich würde aber dennoch darauf bestehen, die bereits existierende Variante endgültig ans laufen zu bringen, da wir hier ja quasi kurz vor dem Ziel sind.

In dem Zusammenhang sei auch noch darauf hingewiesen, das wir dieses ganzen Netzwerk-Datenübertragungsprobleme beim letzten mal ja im Endeffekt auch alle irgendwie lösen oder umgehen konnten (auch wenns natürlich nicht einfach oder komfortabel war), soll heissen, die Daten kamen ja schon auf dem Raspi an, es gab halt nur noch ein Problem mit dem Script, welches die dann in die Datenbank einträgt, aber wir waren damit ja schon dicht davor.

Hier, sowas zum Beispiel (gibts vielleicht auch noch günstiger od. mit besserer Auflösung):

https://www.berrybase.de/universal-5-0-display-mit-hdmi-vga-eingang-und-resisitivem-touchscreen

oder dieses

https://www.berrybase.de/universal-high-resolution-7-0-ips-display-mit-hdmi-eingang-und-kapazitivem-touchscreen-rev.-3.1

Timm:

Die wurden nicht wirklich gelöst: A) Handynetz, nicht gut, da nur temporär möglich B) Office Secure Main WLAN Daten auf die SD Card legen (das kollidiert mit der Datenschutz Policy)

Der Witz mit lokalem WLAN vom Raspi ist ja, dann kann der am Router hängen per Kabel/USBLAN-Adapter (oder wahlweise auch mit zusätzlichem Wifi Adapter per Funk, aber das ist eher nicht simpler) und zur Messstation funken

Es geht ja erstmal darum mit der vorhandenen Hardware (USB Netzwerkadapter hab ich ggf sogar noch) irgendwie stabil an den Messaufbau für ne Langzeitmessung zu kommen

[04.12.25 20:23] Robin Vobruba: uff :D also ich weiss auch nicht ob es sinn macht das versuchen zu verbessern hier.

Oli: du hast das meiste verstnadne so wie ichs mir dachte, aussert dass ich den raspi nicht direkt an den router anschliessen wollen wuerde mit kabel, sondenr na nen notebook/handy, welches dann wiederum am router haengt (wahrscheinlcih dann per WiFi), oder im falle des handies alternativ auch am mobil-netz. internet kommt also dann geroutet ueber handy/notebook zum raspi. fast jeder weiss wie er am handy nen hotspot einrichten kann, und auf linux ist das auch sehr einfach (heisst nur da anderst... "share internet" oder sowas). [04.12.25 20:28] Robin Vobruba: also ich habe mir das ganze so vorgestellt bis jetzt: wir bauen gerade ne messtation. die benutzen wir fuer die ZAC+, und machen damit langzeitmessung/daten-aufzeichnung, wolen aber auhc live was sehen, und das aufzeichnen soll headless funktinieren (um das setup physisch halbwegs klein/mobil zu halten). solch ein setup waer dann grundsaetzlich ziemlich flexibel, also auch fuer andere messungen von anderen projekten: wind-rad, battery-box, solar-anlage, ... selbst fuer ein chemie-experiment, wo man ne zeitraffer aufnahme ueber monate per webcam machne will. Da waers doch shcon gut, da nicht jedes mal ein gebastel draus und drum zu machne, sondenr ein grund-system zu haben dass stabil lauft, und auf das man aufbauen kann, was man hinstellen kann in Olis labor, im office in Berlin, und was Timm nach Afrika mitnehmen kann (falls er nochmal geht). [04.12.25 20:29] Robin Vobruba: ich wuerde sagen, du (Oli) und ich brauchten sowas nicht, weil wir netzwerk gut verstehn usw. .. ist keine grosse sache fuer uns, aber wir haben ja schon gesehn, dass alle anderen die bis jetzt dabei waren, letztes mal nicht mehr mitkamen. [04.12.25 21:20] Oliver S.: ja ok, ich glaube so allmählich versteh ich schon besser worauf Ihr hinauswollt.

Also, zumindest das Argument das ein mittels Handy bereitgestelltes temporäres Netz nicht sonderlich ideal für Langzeitmessungen ist, leuchtet mir ein. 🙃

Und ich sehe auch dass Ihr das eigentliche Ziel, nämlich die Aufzeichnung der Daten, noch nach wie vor mit im Blick habt. Insofern würde ich eine kleine Arbeitsteilung vorschlagen:

- da bei mir das ganze NetzwerkSetup u. die Datenübertragung ja funktioniert würde ich mich erstmal weiter um dieses Datenbankproblem kümmern, welches bei mir ja auch neuerdings auftrat.

- Ihr versucht mal die Datenübertragung so wie Ihr hier vorschlagt noch zu konkretisieren und auf die eine oder andere Weise umzusetzen . Was dabei vielleicht recht hilfreich sein könnte (auch für die Kommunikation), das wäre eine Übersichts-Skizze, gern auch einfach nur manuell hingekritzelt und mitm Handy abfotografiert. Ich würde auch etwaige Hardwarekosten übernehmen, etwa für nen USB-LAN-Adapter oder was sonst so vonnöten ist.

Und hier noch ein Vorschlag / Spontan-Idee: Wie wäre es denn, wenn man etwa für kleines Geld bei eBay ne alte Fritzbox kaufen würde, die aber ausreicht um bei Euch ein separates kleines WLAN aufzuspannen ? Die hätte zwar keinen Internetanschluss, aber den braucht man auch für die reine Langzeitmessung erst mal nicht. Und um das ganze zu Monitoren würde man sich mitm Handy oder Laptop dann einfach mal mit dieser Fritzbox bzw. deren WLAN verbinden anstatt wie sonst mit dem Hausnetz.

Das was Du, Robin, da am Schluss noch gesagt hattest, leuchtet mir zwar soweit ein, aber das geht m.E. schon soon bischen in die Richtung "Universelles Messystem für Langzeit-Messungen und Monitoring". Das wäre m.E. schon eine nützliche Sache, die man auch in vielen anderen Anwendungen sinnvoll zum Einsatz bringen könnte, aber sowas würde man dann glaubich besser direkt als eigenständiges OpenHardware-Projekt aufstellen. [04.12.25 22:54] Oliver S.: wenn man den INA219-Sensor direkt am Raspi betreiben möchte. Oder anders formuliert, wenn man das CYD durch den Raspi ersetzen möchte anstatt es per Kabel an diesen anzubinden. [04.12.25 22:56] Oliver S.: Das CYD ist einfach nur ein ESP32 (WLAN-Chip) der direkt mit einem Touchdisplay kombiniert wurde und für einen niedrigen Preis angeboten wurde (CYD = Cheap Yellow Display) [04.12.25 22:56] Timm: Also ne alte Fritzbox hab ich noch aber wozu? Das macht doch auch der Raspi? Oder willst Du den dabei haben? Aber wie gesagt, wenn man den Raspi ich per USBC tethering oder so dann an ein sagen wir SIM Gerät anschließen kann? Dann ist es komplett autark [04.12.25 22:57] Timm: Ah nee das ist schon gut getrennt [04.12.25 22:59] Oliver S.: an sich ist diese Variante auch ok oder denkbar, aber wäre von hier aus glaubich mit mehr Aufwand verbunden, weil im Prinzip alles was das CYD ausmacht erst mal wieder auf dem Raspi implementiert werden müsste. [04.12.25 23:01] Robin Vobruba: find ich richtig gut! [04.12.25 23:02] Robin Vobruba: hier versteh ich nicht... du meinst, man muessts neu implementieren wenn man das CYD weg laesst und alles mit dem raspi macht ? nicht.. wenns getrennt bliebt, oder? [04.12.25 23:02] Oliver S.: Damit man sich mitm Handy oder Laptop da dran anmelden kann. Aber ich glaub Du hast recht, das müsste auch direkt am Raspi gehen. [04.12.25 23:04] Robin Vobruba: koennt man am raspi auch so ein kleines display wie das am CYD anschliessen? und das grosse dann nur immer wenn man eben wie du sagst... auhc tastatur und maus dran an schliesst, und den raspi wie nen PC nutzt (z.B. um einstellugnen zu aendern oder was weiss ich). oder macht das wenig sinn? [04.12.25 23:04] Oliver S.: Man müsste die Hardware-Abindung des INA219-Sensors an geeignete GPIO-Ports des Raspi neu machen, was zB. so Dinge beinhaltet wie 3V oder 5V und das Pin-mapping. Dann muss das gesamte Mess-Programm welches bislang als Arduino-IDE-Code vorliegt umgeschrieben werden als C-Programm oder irgendetwas anderes was in ner Linux-Shell laufen kann, usw. [04.12.25 23:05] Robin Vobruba: und wir sollten vielleicht auch mal schauen, obs sowas nicht schon gibt (universelle messtation auf nem raspi basierend, halbwegs gut dokumentiert und vielleicht schon praxis-erprobt [04.12.25 23:06] Robin Vobruba: ahhhhh gotcha! [04.12.25 23:06] Robin Vobruba: hast du das arduino programm geschrieben? [04.12.25 23:07] Timm: ### Zusammenfassung des Setups (mit Arduino IDE)

1. Cheap Yellow Display (CYD) als Messinterface

  - Der CYD (ESP32 mit 2,4-Zoll-TFT-Touchscreen) erfasst Sensordaten (z. B. über I2C-Sensoren wie BME280).  
  - Programmierung erfolgt via Arduino IDE – benötigte Bibliotheken: TFT_eSPI, XPT2046_Touchscreen, Adafruit_Sensor.  
  - Daten werden lokal auf dem Display angezeigt.

2. Datenversand an Raspberry Pi Zero

  - Der CYD sendet die Daten per Wi-Fi (HTTP/MQTT/ESP-NOW) an den Raspberry Pi.  
  - Beispiel: HTTP POST an http://raspberrypi-ip/data mittels HTTPClient-Bibliothek.  
  - MAC-Adresse oder IP des Pi muss im ESP32-Code hinterlegt sein.

3. Raspberry Pi Zero als Webserver

  - Der Pi Zero betreibt ein eigenes WLAN-Netzwerk (Access Point) und erhält gleichzeitig Internet über USB-C (via Ethernet-Adapter).  
  - Er hostet einen lokalen Webserver (z. B. mit Flask), der die empfangenen Daten anzeigt oder weiterleitet.  
  - Netzwerkkonfiguration über hostapd, dnsmasq und iptables für NAT.

4. Vorteile & Hinweise

  - Kompakt & günstig: Ideal für mobile oder isolierte Messsysteme.  
  - Eingeschränkte Leistung: Pi Zero eignet sich nur für kleine Clients.  
  - Stabile WLAN-Verbindung: ESP-NOW oder MQTT empfehlenswert für zuverlässige Datenübertragung.

So nicht? [04.12.25 23:07] Robin Vobruba: KI ? [04.12.25 23:08] Oliver S.: ja, genau das hab ich vorhin auch schon gedacht. 😁

Vielleicht sogar dieses Soop Meeres-Messbaukastensystem von Nils 🤔 [04.12.25 23:09] Timm: Ja aber iterativ. Na nix für heute Abend mehr [04.12.25 23:10] Oliver S.: ja. Und leider auf der neuen Arduino-IDE 2.0 und seitdem ist Arduino quasi für mich gestorben. Das war die letzte Anwendung die ich darauf gemacht habe. [04.12.25 23:10] Robin Vobruba: mm :/ [04.12.25 23:12] Robin Vobruba: koennte schwer werden sowas zu suchen, weils sooo viele seiten gibt die einfach nur schnell was zusammenbasteln mit raspi zum messen [04.12.25 23:12] Oliver S.: ich weiss zwar nicht was Du mit gross oder kleines Display meinst, aber ja, deswegen hab ich die Waveshare-Display-Links gepostet. Ich hatte ursprünglich eher an ein 5" Display gedacht, aber es scheint mittlerweile so zu sein, dass die 7" günstiger sind. [04.12.25 23:17] Oliver S.: jaa, so uuungefähr, wobei Punkt 1 und 2 ja schon den IST-Zustand beschreiben und es bei Punkt2 genau andersrum ist: Nicht das CYD sendet Daten an den Raspi, sondern es stellt die messdaten auf einer gaaanz rudimentären Webseite bereit und der Raspi holt sie sich von dort periodisch/crontab-gesteuert alle 2 Minuten ab. Woraus folgt, das der Raspi die (jeweilige aktuelle) IP-Adresse vom CYD kennen muss. [04.12.25 23:18] Oliver S.: Das hat aus meiner Sicht den Vorteil, das wenn irgendwas in der Kette nicht stimmt bzw. am Raspi keine Daten mehr ankommen sollten, ich mit nem Webbrowser auch direkt auf dem CYD nachschauen kann, ob es noch regelmässig neue Messdaten bereitstellt. (was bedeuten würde das beim CYD noch alles ok ist und das Problem woanders liegen musss) [04.12.25 23:19] Robin Vobruba: mit gross meinte ich sowas.. 5" oder 7", was man sozusagne als desktop monitor nutzen kann (wenn auch natuerlcih mit kleiner aufloesung). mit klein meinte ich, sowas wie das CYD, was nicht wie ein monitor unter linux funktionerit, sondern was ne andere nasteuerung benoetigt, baer auch viel weniger strom. [04.12.25 23:29] Oliver S.: Ja, das sind diese typischen ISP-Displays (wie ich sie auch bei meinen Gamepads verwende) die eine Diagonale von 2" über 2,4", 2.8" usw. bis max 3.2" haben und eine Auflösung von üblicherweise 240x320 bis max. 320x480 Pixeln. Die haben auch obendrein noch den Vorteil, das sie erheblich günstiger sind.

Aaaaaaber: Du musst in den Tiefen des Linux erstmal irgendwie den passenden ISP-Treiber ans laufen bringen und das ist so eine dermaßene Fitzelei und Du musst lange Zeit headless arbeiten usw. Also, wenn jemand schon allein das aufspielen eines RaspianOS mittels des Raspi-Imagers für eine schwierige oder komplizierte oder aufwändige Sache ansieht, dann ist er mit der Treiberinstallation und vor allem Config wahrscheinlich ziemlich lost.

Oder ich formulier es mal andersrum: Wenn das Display nen HDMI-Port hat, dann läuft die Anwendung out-of-the-box auf jedem frisch installierten RaspianOS, ohne irgendwelche Verrenkungen. Und das ist im übrigen auch der Grund, warum es bei mir in Zukunft wahrscheinlich nur noch Anwendungen mit solchen Displays geben wird, auch wenn die dann vielleicht 30,- EUR teurer sind. Aus meiner Sicht waren die früher noch viel erheblich teurer aber kommen jetzt in einen Preisbereich wo sich das Rum-Ge-Eiere mit den ISP-DIsplay-Treibern einfach nicht mehr lohnt. [04.12.25 23:31] Oliver S.: Ich hatte für meine Gamepads den Ehrgeiz, die mit diesen günstigen Displays ans laufen zu bringen, weil ich die auch in Schülerworkshops bauen und entsprechend die Materialkosten möglichst niedrig halten wollte, aber ich hab dann tagelang und wochenlang damit rumgehampelt.

Sowas ist echt ne Extremsportart für Leute, denn sonst nix Blöderes einfällt ! 😁 [04.12.25 23:38] Oliver S.: Nochmal kurz was zu der Frage, warum überhaupt die Aufteilung in CYD und Raspi und nicht eh gleich alles auf dem Raspi läuft:

Bei mir hat sich im Laufe der Jahre die Erkentniss etabliert, das es (für mich) sinnvoll ist, folgender Struktur zu folgen:

- alles was mit Sensoren und Aktoren zu tun hat, also messen steuern regeln mache ich mit UControllern wie Arduino

- alles was mit höheren Anwendungen wie Datenbanken, Webservern usw. zu tun hat mache ich mit Linux-OS-fähiger Hardware wie Raspi, Mini-PC oder PC

Dabei fungiert der Arduino als Client und der Raspi als Server (soll heissen: die kommunizieren natürlich miteinander).

Warum das m.E. Sinn macht: Du hast aufm Arduino quasi ne Echtzeit-SItuation (weil sehr hardware-nah), was gerade beim messen wichtig ist und hilft timing-Probleme entweder zu vermeiden oder relativ easy handlen zu können. Bei nem höheren OS wie Linux ist das nicht möglich, weil Du da das Task-scheduling hast. Wenn man unter Linux partout Echtzeitanwendungen machen will, dann muss man das Linux mit einem speziellen Echtzeit_Kernel booten (das tu ich zB. beimeinen Musik-Anwendungen, also wenn ich eine DAW laufen lassen will oder VCV-Rack). Aber selbst dann hat man immer noch das ganze OS als quasi trennende Schicht zur Hardware-Ebene .... das ist bei Linux Programm: weitestgehende modulare Abstraktion und Trennung von der Hardware-Ebene. Und macht auch Sinn bei nem höheren (Multi-User-)OS. Aber eher nicht bei nem Sensor.

Was aber nicht heisst das es nicht geht. Aber mir erscheint es sinnvoller die Dinge sozusagen gemäss ihrer natürlichen Ordnung zu nutzen. Aber wer Spass an nerdigen Extrem-Sportarten hat kann natürlich auch seine neue digitale Zahnbürste hacken und Doom darauf ans laufen bringen 😁 [04.12.25 23:56] Oliver S.: Achja, und ein weiterer Grund für einen dedizierten Raspi als Server wäre noch die Situation, wo man mehrere Sensoren hat, also wenn man jetzt mehrere ZAC+-Messrigs hätte die man dann gleichzeitig mit einem einzigen Server bedienen bwz. monitoren kann ... das ist bei uns zwar aktuell gerade nicht der Fall aber steckt irgendwie dennoch auch drin in der Vorstellung einer Client-Server-Anwendung (zumindest bei mir), also, das ein Server mehrere Clients bedienen kann.