Forum: Mikrocontroller und Digitale Elektronik Entscheidungshilfe für uC bei Gartenbewässerungsprojekt


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Torsten (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von A. F. (artur-f) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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 :/

von Torsten (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Harry L. (mysth)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Torsten (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Reiner O. (elux)


Bewertung
0 lesenswert
nicht lesenswert
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

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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/

von Torsten (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.