Ich denke, hier muss man 2 Dinge auseinander halten:
1. Der Optokoppler.:
Wenn der bei 3,3V nicht "aufmacht", ist der rest eh egal. Da Optokoppler meist "open collector" Type sind, muss man ggf. nur den Vorwiderstand reduzieren, damit die OK-Diode leuchtet.
2. Das Relais.
Das wird 5V brauchen. Insofern muss die Platine mit 5V versorgt werden, völlig unabhängig vom ESP.
Der Optokoppler ist ja genau dafür da, beide Systeme galvanisch zu trennen.
Nachtrag: open-electronics war schneller 
Haben die das Datum zum Preis dazu gerechnet??? 
b) Ist die Parallelschaltung der Sensoren okay? Die Spannung liegt dann dauerhaft an. Messen dann auch die Sensoren dauerhaft? Dann müsste ich dies vielleicht auch ein- und ausschaltbar bauen.
Ja, die Sensoren messen dauerhaft, d.h., dass zwischen den Elektroden die ganze Zeit ein Strom fließt.
Dies Art der Sensoren misst über die anliegende Spannung den Leitwert des Mediums...
Falls du die Elektrodenflächen nicht vergoldet oder anderweitig passiviert hast, setzt eine Elektrolyse ein, die zur Korrosion der Elektroden und Entstehung von (meist giftigen) Kupfersalzen führt, welche die Erde langsam vergiften.
Zusätzlich ändert sich das Messergebnis langsam...
Ein temporäres Zuschalten der Spannung nur zum Messzeitpunkt verzögert das alles, das ungeschützte Kupfer zersetzt sich dennoch langsam bzw. bildet eine Oxidschicht aus (abhängig von den Bodenbestandteilen), die das Messergebnis verfälschen.
tltr:
Diese Art von Sensoren sich schlecht. Für kurze Demonstrationen für Kinder etc. ok, für einen ernsthaften, dauerhaften Aufbau ungeeignet.
Hier im Forum wurde das Thema ebenfalls schon durch-ventiliert, bitte einfach mal die SuFu benutzen...
Bzgl. HUB (back to the roots):
Ich verwende inzwischen diesen hier: https://www.amazon.de/gp/product/B076KJP376/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1 (Affiliate-Link)
Der hat ein getrenntes NT und liefert so um die 5,21V... ist stabil auch unter Last (2A)
BTW. Der Pi4 will mehr Spannung sehen, ich bin bei 5,37 Volt, damit der Blitz weg ist:
Bitte lies dir man meinen Beitrag RE: schlizbädas Projekte durch.
Dein Netzteil ist einfach zu weich, d.h. die Spannungsstabilisierung ist zu langsam, um die schnellen Lastwechsel auszuregeln.
Ein einfacher Elko ist ebenfalls, durch seinen Aufbau bedingt, zu langsam und nicht in der Lage, LastSpikes in kHz-Bereich zu kompensieren. Für die Spannungsstabilisierung von Motherboards gib es deswegen seit Jahre spezielle Elkos...
Neben den ausgefallenen Karten habe ich in den Geräten (Mobile, Tablett, MP3-Spieler, RasPi's usw... so schätzungsweise >10 Karten (teils seit Jahren im Dauer-) Einsatz.
Die Karten, wo überwiegend gelesen wird, sind bisher störungsfrei, wurden nur mal durch größere ersetzt, die "alten" Karten landen letztlich in Bereich RasPi.
Ich habe meine RasPi-Dauerläufer so konfiguriert, dass wesentliche Schreiblast auf ein remote Filsystem erfolgt, lokal werden nur die normalen Systemlogs geschrieben (mit Rotation).
Es gibt ein System, das die anfallenden Daten ins SD-FS schreibt. Monatlich so etwa 50-100MB. Diese Daten unterliegen ebenfalls einem Rotationsmechanismus ... monatliche Kompression + Ablöschen nach 12 Monaten...
Die SD in diesem Teil ist seit Frühjahr 2016 im Einsatz... der Füllgrad der SD liegt so zw. 50-70%... bisher ohne Auffälligkeiten...
Um noch einen weiteren Themenkomplex aufzumachen:
Die Haltbarkeit der Löschspannungsquelle.
Hier im Forum wurde mehrfach über das Phänomen berichtet, dass eine microSD-Karte nicht mehr überschrieben werden konnte (Lesen ging, Schreiben never, Reformat oder sowas ging auch nicht.)
Ich selbst habe hier 2 von diesen "ausgefallenen" Karten mit diesem Fehlerbild...
Nach Herumrecherchieren kristallisiert sich heraus, dass der Löschspannungsgenerator auf der Karte ausgefallen ist:
Zum Löschen der Zellen wird eine etwas höhere Spannung benötigt (10..15V). Diese Spannung wird aus der Speisespannung erzeugt.
Wenn dieser StepUp-Regler/Generator ausfällt, können die Zellen nicht mehr gelöscht werden.
Die SW erhält nach der Schreib-OP ein "ok", weil der Kontroller nicht prüft, ob die Daten wirklich geschrieben wurden (kein read after write).
nicht doch wenn es im .h File bekannt gemacht wurde! (genau deswegen macht man das doch!)
Nicht zwingen:
Im .h File wird oft nur der Zeiger "an sich" mit
int *results;
definiert.
Die Allocation (und Strukturierung) des Speicherbereiches erfolgt später (dynamisch) in irgendeiner Methode (oder du bekommst das (anonyme) Array "reingereicht" - alles schon gehabt) und das kann sogar unterschiedlich sein (was allerdings nicht besonders sauber ist) oder von Type "union", was dann nochmal "besonders" ist.
Dann kannst du aus dem .h-File nicht auf den Typen schlussfolgern...
Insofern braucht es eine saubere Interface-Dokumentation, welche man am besten im Header-File unterbringt (und oft NICHT gemacht wird)
(am besten in einem Format, welches z.B. doxygen verarbeiten kann...).
ESP gibt ERROR und braucht
Codenok5110.print( (char*)&menu[akt_screen][line][0] );ist und bleibt nervig, denn JEDER C-Programmierer weiss das & die Adresse auf einen Pointer setzt, hier Pointer auf char Array, zumal bekannt gemacht:
extern volatile char menu[MAX_SCREEN][MAX_LINES][MAX_CHAR+1];
Nun,
das "casten" auf einen char-Pointer (char*) ist aber die richtigerer Version des Kommandos, da der Kompiler dem Pointer nicht ansehen kann, was sich darunter verbirgt.
Das der AVR-Code das implizite annimmt (aktzeptiert) ist "nett", verbirgt jedoch dem Programmierer den wahren Sachverhalt..
BTW:
Es ist immer eine gute Idee, die ursprüngliche Datei zunächst NICHT zu überschreiben.
Ich mache das immer so:
Grundsätzlich ist es immer eine gute Idee, Abstandshalter zu verwenden.
Zum einen, wie du schon schriebst, um die Kühlung zu verbessern,
aber auch um keine unnötige mechanische Belastung auf die Lötpunkte zu geben.
Im Fall, dass Kondenswasser auftritt und die Pappe durchfeuchtet (die damit leitfähig werden kann), handelst du dir noch ganz andere Probleme bis zum Totalausfall des RP ein...
Bzgl. Netzteile:
Es ist neben der erforderlichen Strombelastbarkeit vor allem die "Härte" der Spannungsstabilisierung entscheidend:
Es nützt nichts, die Spannung wesentlich höher als 5,1V einzustellen, wenn das NT bei kurzfristigen (<0,5sec) Lastsprüngen einbricht.
Diejenigen, die die Versorgungsspannung auf 5,3V und höher einstellen, versuchen damit, das übermäßige Einbrechen der Spannung in den Lastspitzen zu kompensieren, riskieren jedoch damit einen Totalausfall des RPi.
Ich wiederhole mich ungern, aber viele haben meine Ausführungen dazu nicht gelesen:
Das Messen der Spannungen und Ströme mit Multimetern, um "rätselhaftes" Verhalten bzw. "gelbe Zeichen" vs. Unterspannungsanzeichen zu diagnostizieren bringt nichts - genau NULL!
Die Stromaufnahme des RP (wie auch aller anderen Rechner mit Core-Zu- und Abschaltung, WLAN, BT usw) ist extrem dynamisch und ändert sich im microSec-Bereich. Aussagekräftige Messungen erhält man nur mit einem Oszilloskop (10MHz-Klasse reicht dicke).
Damit sieht man, wie z.B. durch den WLAN-Chip in mehr oder weniger regelmäßigen Abständen starke Stromspitzen verursacht werden.
Ich habe vor Jahren da mal Messungen gemacht und hier gezeigt. Den Link hab ich jetzt nicht zur Hand, aber ein Suchen nach "mysterium" sollte helfen.
tl;dr:
kein Backup der SD-Karte ?
Um das von mir geschriebene bzgl der Laufzeiten der WUs nochmals etwas zu untermauern:
Im rechten unteren Bereich des unteren Bildes sind die Laufzeiten angegeben, die eingehalten werden müssen.
Aktuell ist hier ein Laptop mit
Nun möge man die Performance eines Core i5-6200 mit der performance eines RasPis vergleichen, um zu erkennen, dass der RasPi wirklich keinen Sinn macht...
Dingen wie Schlangengift oder Bachblüten, Schüssler Salzen oder homöopathischen Mittelchen anzusiedeln.
Moment:
Schlangengift hat keine Evidenz?
Widerspruch: Im Osten (damals..) gab es (hochwirksame) Reumamittel/Sportgels auf Schlangengift-Basis... (mit Bienengift übrigens auch) und die haben echt geholfen (Ich habe sie geliebt, die haben WIRKLICH geholfen).
Besser als die Pfeffersalben von heute...
Der Hersteller hatte allerdings damals versäumt, diese Hilfsmittel in der BRD (nachträglich) zuzulassen, so kam es zum aus für diese Salben.
Aktuell wird das nun (nach 30 Jahren) wohl nachgeholt.... weiß der Geier, warum jetzt erst...
Solange es noch so kalt ist, reicht da im Aussenbereich ggf. sogar schon ein dicht gewickelter Schal vor dem Mund..
Kann mich noch erinnern, wie ich da Eisklümpchen im Schal hatte, bei -10° ...
Selber so eine Maske schneidern und nutzen ist allemal besser als komplett ohne... die Asiaten machen es und wenn es alle machen, so wie unimatrix-0 beschreibt, bleibt die Raumluft auf jeden Fall virenärmer... ein Anfang..
Nachtrag:
F@H ist zum Teil openSource: https://foldingathome.org/support/faq/opensource/
Zumindest der Client, wenn ich es richtig gelesen habe...
F@H ist ...
Also, die benutzen keine freie Software und die berechnen (ja, im Moment ist Corona ganz oben) auch kommerzielle Sachen.
Denn, denn, dann BONIC. Obwohl die erst einmal Seit@Home beenden. Aber da soll es andere Projekte geben und sie benutzen einen quelloffenen Client.
Du kannst gerne deiner Meinung sein, geht aber am Thema dieses Threads vorbei:
Hier in diesem Thread geht es um Folding@home und die Möglichkeit, mit dem RasPi dort beizutragen.
Ob dazu jetzt freie SW oder nicht freie/offengelegte SW benutzt wird, ist erstmal Wumpe
(Oder ist die SW des nächstgelegenen MRT freie SW? Frag mal bei Siemens nach...).
Es geht um wissenschaftlich-medizinische Problemstellungen.
Nebenbei: Ich bekommen z.B. auch nicht immer WUs aus dem Corona-Workset, weil eben nicht immer verfügbar. Na und ?
Helfe ich eben bei der Krebsforschung oder Alzheimer...
Bitte mal nicht alles so eng sehen, gerade zur aktuellen Zeit
