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:> 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
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.
