Für Gartenbewässerungsprojekt inkl. kleiner Wetterstation bin ich gerade hinsichtlich uC etwas indifferent und wollte mal eure Meinung hören. Folgendes sind die Eckpunkte: - Schalten von sechs Kanälen zur Gartenbewässerung via Relais (mache ich schon seit Jahren mit nem Raspi) - Messen von 2 x DHT22 - Messen von 1 x BME280 (I2C) - Einbindung von 1"-OLED-Display via I2C - Einbindung von Drehencoder - Ggf. Port-Expander mit MCP23017 (I2C) - Konnektivität über WLAN oder Ethernet - Kommunikation via MQTT - Stromversorgung via Netzteil - Verwendung von Arduino-Devboards - Realisierung als Arduino-Projekt Datenaustausch erfolgt mit einem Raspi (auf dem openHAB läuft) via MQTT. Die Positionen 2+3 habe ich seit ein paar Wochen testweise mit einem ESP8266 gemacht (WLAN-Anbindung) - keine Probleme. Also speziell im Winter ist es so, dass der uC nur alle fünf Minuten aufwacht, die Sensoren ausliest, per MQTT pusht und wieder schlafen geht. Da ich im Sommer aber nicht fünf Minuten warten möchte, bis mal Wasser kommt, habe ich in openHAB einen virtuellen Schalter definiert. Anhand des Zustandes entscheidet der uC, ob er sich wieder schlafen legen darf oder wach bleiben muss. Nun ist es so, dass am Installationsort Ethernet vorhanden wäre. Bei Sonoff S20-Steckdosen (steckt ein ESP drin) mache ich gerade die Erfahrung, dass die Verbindung doch öfter mal abreißt. Das bringt mich ein Stück weit zur Überlegung, ob ich dieses Projekt einfach mit Ethernet anbinde - zumal die Infrastruktur ja auch bereits da ist. Meine Frage ist nun, welchen Microcontroller ich dafür verwende. Daheim rumliegen habe ich die folgenden Arduino-Entwicklerboards: Nano v3 (Atmel 328P), NodeMCU ESP8266, NodeMCU ESP32s. ESP8266: + Bringt WLAN mit, funktioniert im Testbetrieb auch bereits + Lässt sich via OTA flashen + Eth-Anbindung könnte ich mit W5500 (SPI) machen, habe ich eh noch daheim + schnell (vermutlich für das Projekt aber egal) - Hat deutlich zu wenig Ports, daher Port-Expander notwendig i Braucht im Betrieb durchschnittlich etwa 70 mA, im DeepSleep 1,4 mA ESP32s: + Bringt WLAN mit + Lässt sich via OTA flashen + Hat Eth-Support integriert, Anbindung via MII oder RMII + Sehr schnell (vermutlich für das Projekt aber egal) - Eth-Anbindung via LAN8270 (RMII) belegt neun Pins ? GPIO0 wird nicht rausgeführt, man benötigt jedoch 50 MHz Clock. Man kann wohl auch eine interne Clock nehmen, aber mir ist unklar, wie gut das funktioniert - Hat zu wenig Ports, daher Port-Expander notwendig - Ich habe noch keine Erfahrung damit, wie viel Strom der LAN8270 benötigt - beim W5500 habe ich da bereits Erfahrungen i Noch keine Strommessungen durchgeführt Nano V3: + Port-Expander nicht notwendig, da ausreichende Anzahl GPIOs vorhanden + Von einem anderen Projekt habe ich bereits Erfahrung mit der Eth-Anbindung (W5500) - Eth-Anbindung braucht etwas mehr Strom (85 mA @ 5V inkl. uC bei fest konf. 10 MBps) als WLAN beim ESP ? Mir unklar, ob der Speicher für die gesamte Umsetung reicht i Braucht im Betrieb durchschnittlich etwa 85 mA, im Schlafmodus (mit per Transistor abgeschaltetem Eth-Board) 7 mA Also grundsätzlich stelle ich fest, dass es schon ein bisschen Arbeit ist, Ethernet an den ESPs zum Laufen zu bringen. Ich bin mir nicht so ganz sicher, ob ich mich da in etwas verrenne und vielleicht einfach WLAN nehmen sollte. Beim Nano fände ich es etwas schade, dass ich keine OTA-Updates machen könnte. Es wäre aber kein Show-Stopper, die Stelle ist einfach zugänglich - lediglich ne Komfortfrage. Über Anmerkungen, Einschätzungen etc pp würde ich mich freuen.
Ich würde ESP32 nehmen, wozu brauchst du ETH wenn du WLAN hast? Wie es aussieht, möchtest du die Bewässerung auf Basis von lokalen Sensoren realisieren und nicht über einen Wetterdienst. Wenn da WLAN zwischendurch streikt ist es doch Wurst (ist ja kein Schrittmacher). Wenn du auf Kabel stehst und es komliziert haben willst, kann ich dir eine Platine mit STM32F407 + PHY, 2 Relais, 12 N-FET Ausgängen, 12 12V DC sicheren Eingängen und RS485 verkaufen :/
Nein, die Sensoren haben für die eigentliche Bewässerung keine Bewandtnis. Wann bewässert wird, entscheide ich entweder manuell oder zur Not per CronJob (Wasser kommt aus nem Brunnen, wenn ich da mal zu viel bewässere, fällt das nicht ins Gewicht). Zum Thema Ausfallsicherheit: Nun, wenn ich die Pumpe einschalte, dann muss ich tatsächlich sicherstellen können, dass ich sie auch wieder abschalte. Aber sei es drum: Ich übergebe via MQTT auch immer eine Ausschaltzeit (als Backup quasi). D.h. wenn diese abgelaufen ist, dann wird der jeweilige Kanal so oder so wieder abgeschaltet - egal ob die Verbindung weg ist oder nicht. Der Grund für Ethernet ist einfach, dass mich die Konnektivitätsprobleme bei den Sonoff-Steckdosen (läuft Tasmota drauf) gerade etwas nervt. Wenn ich mit vergleichsweise einfachen Mitteln Ethernet einbinden kann, dann würde ich das wohl tun. Mit WLAN wäre auch für mich der ESP32 die Präferenz, da er einfach mehr GPIOs hat als der ESP8266 und ich diese hier auch brauche.
Torsten schrieb: > Für Gartenbewässerungsprojekt inkl. kleiner Wetterstation bin ich gerade > hinsichtlich uC etwas indifferent und wollte mal eure Meinung hören Vielleicht hilft Beitrag "Projekt fertiggestellt: Temperatur- und Feuchtigkeitssensor mit ESP8266/BME280 und MQTT-Publishing" Vielleicht wechselst du deinen Namen aber auch nur schneller als die Projekte.
Torsten schrieb: > Der Grund für Ethernet ist einfach, dass mich die Konnektivitätsprobleme > bei den Sonoff-Steckdosen (läuft Tasmota drauf) gerade etwas nervt. Daran sind aber weder die SonOff-Steckdosen noch Tasmota schuld. Da ist wohl dein WLAN-AP eifach Murks oder die Verbindung zu schlecht. Letzteres kannst du durch aufstellen eines weiteren AP lösen, und dafür tuts auch ein billig-Router von TP-Link (z.B TP-Link WR841N für <20€) Hier laufen ca. ein Dutzend SonOff-Geräe mit Tasmota 24/7 ganz ohne Netz-Ausfälle.
Keine Angst, ich habe meinen Namen nicht geändert :-) Vielleicht sollte ich mich auch einfach hier mal anmelden. Ich denke ich werde jetzt einfach mal mit dem ESP32 starten und es auf WLAN-Basis entwickeln. Wenn ich dann noch Bock habe, binde ich Ethernet ein. @Harry: Ich habe ja auch nicht behauptet, dass die Steckdosen die Übertäter sind. Es ist halt nur Fakt, dass ich diese Probleme grundsätzlich nicht habe, wenn ich Ethernet benutze :-) Eingesetzt wird eine FB7490 und mittels Handy/Laptop habe ich hier eigentlich keine Probleme. Aber es gibt, obwohl es sich um ein freistehendes (Fertig-)Haus handelt, halt doch inzwischen echt viele WLANs in der Ecke. Vielleicht ist auch das ein Problem. Auffällig ist allerdings, dass oft nur die MQTT-Verbindung wegfliegt. Den Raspi, auf dem mosquitto läuft, habe ich extra schon per Ethernet angebunden, aber das hat dieses Problem auf jeden Fall nicht behoben.
Torsten schrieb: > Eingesetzt wird eine FB7490 und > mittels Handy/Laptop habe ich hier eigentlich keine Probleme. Aber es > gibt, obwohl es sich um ein freistehendes (Fertig-)Haus handelt, halt > doch inzwischen echt viele WLANs in der Ecke. Vielleicht ist auch das > ein Problem. Ja, und die FB. Ich habe festgestellt, daß das WLAN der FB sich in einigen Fällen recht zickig verhält. Seit ich der FB das WLAN weggenommen und über APs von TP-Link mit OpenWRT verbinde sind Verbindungsabbrüche schon sehr selten geworden. > Auffällig ist allerdings, dass oft nur die MQTT-Verbindung > wegfliegt. Ja, das ist so ein Henne-Ei Problem. Wenn die Verbindung abreißt, verbindet sich der ESP neu. Sobald die Verbindung phys. steht, wird der MQTT Client gestartet, da ist die Verbindung aber noch nicht bereit (DHCP usw.), so das der MQTT ins Timeout läuft. Das wird bei den Beispielen im Arduino oft falsch gemacht. Es ist aber schon interessant zu sehen, daß immer mehr Leute diese auch von mir bevorzugte Kombination aus Ethernet und MQTT zwecks Steuerung benutzen. Ich hatte mit der Kombination aus Atmel und LAN immer ein bißchen Pech, so daß ich letztlich als Alternative auf den kleinsten OrangePi mit H2+ Prozessor und 256MB RAM ausgewichen bin, die Kombi läuft bei mir sehr zuverlässig. Es ist schon ganz schön "mit Kanonen auf Spatzen geschossen", für ein paar Relais ein Linux hochzufahren, aber bei weit unter 10€ HW-Kosten für die Recheneinheit bei besagter Zuverlässigkeit ist mir das egal. Mir ist es auch egal, was verschiedene Leute hier behaupten: alles, was mir wichtig erscheint, läuft bei mir per Draht (Ethernet oder Subbus), der unwichtige WAF-Kram (Ambiente-Beleuchtig etc.) wird auch per WLAN erledigt, dank ESPs (H801 und Konsorten ;-) )... Just my 2 Cents Gruß Elux
Torsten schrieb: > ? GPIO0 wird nicht rausgeführt, man benötigt jedoch 50 MHz Clock. Das ist wohl lösbar: https://sautter.com/blog/ethernet-on-esp32-using-lan8720/
Danke erstmal für die Kommentare. @Reiner: Auf einem Atmel328P (Arduino nano) habe ich Ethernet wie gesagt ans Laufen bekommen. Ich habe mir so ein kleines Board mit W5500-Chip geholt - kriegt man aus China zB via Ebay für knapp über drei Euro. Aber es war nicht ganz trivial sag ich mal. Erstmal hat sich für mich die Frage gestellt, wie genau das zu verbinden ist. Nachdem ich das wusste, stellte ich fast, dass Eth samt uC satte 130 mA frisst. Habe dann das Datenblatt gewälzt und gesehen, dass man per Register auch auf 10 MBps stellen kann und der Stromverbrauch dann geringer sei. Dafür musste ich die Ethernet2-Lib aber erstmal erweitern. Auf 10 MBps ging es dann runter auf 85 mA. Da ich im besagten Projekt nur ein Aussenlicht steuern möchte, welches an der Hauswand ist und lediglich dekorative Zwecke hat, war mein Wunsch, dass der uC aus Energieeffizienzgründen fünf Minuten schläft, dann aufwacht und schaut, ob was zu tun ist. Aber selbst wenn man PHY abschaltet (geht über das gleiche Register wie 10 MBps) frisst die Schaltung immer noch 45 mA. Ich habe es jetzt final so gelöst, dass ich das Eth-Board via GPIO über einen Transistor abschalte und der 328P selbst schläft. Dann lande ich im Sleep bei 7 mA, damit kann ich gut leben. Ethernet habe ich hier übrigens verwendet, weil die Steuerung in der HV im Keller hockt. Im Keller gibts halt kein WLAN und in einem Metallschrank schon gar nicht :-) Also was ich sagen will ist: Ich stelle auf jeden Fall fest, dass Ethernet-Anbindungen (auch wenn ich Ethernet mag) mit uC ganz und gar kein Mainstream sind. Ich befasse mich erst seit November mit uC, insofern tue ich mich da mitunter mal etwas schwer, da ich noch nicht genügend Wissen habe, damit das alles selbsterklärend ist. Aber es wird besser :-) @Rufus: Ja, den Link habe ich zwischenzeitlich auch entdeckt. Ich bin gerade dabei, das Ganze erstmal auf WLAN-Basis zu entwickeln, Vieles läuft auch schon. Das Eth-Board habe ich in China bestellt, wird eh noch ein paar Wochen dauern, bis es da ist. Wenn es dann da ist, werde ich mal Tests damit machen und mir dann überlegen, ob ich es für das Projekt wirklich Sinn macht. Auf jeden Fall werde ich dann einen Port-Expander verwenden müssen, weil die GPIOs sonst nicht mehr reichen. Aber das ist ja kein Problem.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.