vorige Seite
 Inhaltsverzeichnis nächste Seite

das Programm ist quasi fertig

Mittlerweile habe ich meinem Test-Aufbau die RTC zugefügt und damit alle Komponenten beisammen, die ich im Programm steuern muss.
Lediglich der Transistor zum Abschalten des ESP8266 fehlt noch. Ob ich, wie im vorigen Abschnitt angedacht, den Reset-Pin des ESP8266 vom ATmega328 ansteuerbar mache, hängt davon ab, wie sich das Teil verhält, wenn es über den Transistor ein und ausgeschaltet wird.
Ach...und die IR-Sendeeinheit fehlt auch noch (die mir hier im Büro aber eh nix nützen würde, weil in diesem Raum nur ein einfacher bzw. nicht fernsteuerbarer Rollotron Schwenkwickler seinen Dienst erfüllt).

Beim Python-Script ist hinzugekommen:
  1. Allen über das WLAN zu übertragenden Daten wird eine Prüfsumme angehängt. (ich wollte sicher sein können, dass keine irren Zeiten für das rauf- oder runterfahren beim Programm ankommen und ausgeführt würden...und ASCII-Salat habe ich ja schon einigen ankommen sehen).
  2. Eine Datei mit Zeiten für das rauf und runterfahren wird gelesen und (nach Änderungs-Erkennung) zum ATmega328 gesendet.
Auf der ATmega328-Seite ist hinzugekommen:
  1. Allen über das WLAN zu übertragenden Daten wird eine Prüfsumme angehängt.
  2. Der Tiefschlaf-Modus ist implementiert (aber noch nicht bzgl. Strom-Aufnahme überprüft - ist ja eh noch ein ArduinoUNO).
  3. Die bisher einzeln entwickelt und getesteten Teil-Funktionen (IR-Senden, Zeiten-Tabelle lesen, RTC ansteuern) sind ins Hauptprogramm aufgenommen.
Für die Stromversorgung habe ich mir überlegt, vier 1.2V Akkus einzusetzen.
Für VBAT der RTC wird über zwei Akkus abgegriffen (2.4V), für das ESP8266-Modul über drei Akkus (3.6V) und für die restliche Schaltung über allen vier Akkus (4.8V). Mal schauen, wie sich die unterschiedliche Belastung der Akkus auswirkt...
Ein Akku-Wechsel führt bei dieser Art der Stromversorgung zwar dazu, dass die RTC keine Puffer-Batterie mehr hat, aber das macht ja nix, weil sie beim ersten Start nach Akku-Wechsel sofort über WLAN neu gestellt wird.

Auch wenn der Taster (oben S2) für den Programmier-Modus nicht mehr benötigt wird, soll die zugehörige LED gerne drin bleiben und alle acht Sekunden einmal kurz für 50mS aufleuchten - um damit anzuzeigen, dass der ATmega328 noch brav seine Tiefschlaf-Loop abarbeitet.

Eine kleine Erweiterung der Schaltung könnte sein, dass der Akku-Ladestand bzw. die drei Spannungen überwacht werden, um dann ggf. bei der nächsten WLAN-Kommunikation eine entsprechende Warnung senden zu können.

Rückschläge und Erweiterungs-Ideen

Schon kommt der nächste Frust.

Das Abschalten des ESP8266 mit Transistor funktioniert nicht. Oder genauer gesagt, der "Betrieb über einen Transistor" hat nicht funktioniert.
Stattdessen kann man aber den PD-Pin auf LOW setzen. Dabei zieht das Modul dann 0.5mA. Laut Specs von dem Chip sollten es aber 0.5µA sein.
Das wird wohl an der kleinen (roten) LED liegen, die immer leuchtet, sobald das Ding am Strom hängt.
Nach Ab-Löten der roten LED sind es bei PD=LOW 34µA und bei PD=HIGH 142mA (oder mehr).
Naja...34µA ist deutlich besser als 0.5mA - aber auch noch lange nicht 0.5µA. Dann wird wohl dieser zweite Chip die Differenz ziehen.

Und als nächstes: als ich das auf 3.3V eingestellte Labornetzteil durch ein Akku-Pack aus drei Mignon-Akkus (Eneloop, 1.900mAh) ersetzt habe, ging beim ESP8266 erstmal nix mehr. Mit einem 0.1F (SuperCap) Kondensator parallel zum Akku-Pack wurde es gefühlt etwas besser. Aber immer noch sehr unbefriedigend.
Dann habe ich einen mit Mono-Zellen (tecxus, 10.000mAh) bestückten Akku-Pack probiert. Wieder etwas besser, jedoch immer noch deutlich schlechter, als am Labornetzteil.
Ich verstehe das nicht. Die Spannung stimmt halbwegs und Strom sollte aus so einem Akku doch wohl reichlich rauskommen...!?
Es könnte was mit den Pegeln zwischen ESP8266 und ArduinoUNO zu tun haben. Auf ping antwortet der ESP8266 nämlich mehr oder weniger brav.

Ich habe mir gerade mal fünf Pegel-Wandler-Module bestellt.
In der Bestätigungs-Email wurde dann allerdings eine Lieferzeit von zwei bis vier Wochen genannt.
So ein Scheiß. Habe ich wieder nicht richtig aufgepasst.
Der Händler hieß "März Gerste" und hatte die Dinger "auf Lager". Erst nach der Bestellung habe ich nachgesehen...und feststellen müssen, dass die Dinger (trotz Umlaut im Namen des Händlers) dann jetzt wohl aus China geliefert werden. Daher also zwei bis vier Wochen Lieferzeit. Dreck! Man muss sich doch zwingen, vor einer Bestellung nicht nur auf den Tag des voraussichtlichen Liefertermins, sondern auch auf dessen Monat zu gucken.
Weil ich nicht so lange warten wollte, musste ich also nochmal auf die Suche gehen. Der hier ist es geworden. Kostet zwar mehr als das Dreifache, aber soll morgen geliefert werden (...aber nur, weil ich mal wieder eine Amazon-Prime-Probe-Mitgliedschaft abgeschlossen habe :-) ).
...hat übrigens nicht geklappt mit der Lieferung am nächsten Tag.

Jetzt mache ich erst mal eine kleine Test-Reihe.
Und zwar mit Labornetzteil und Pegel-Wandlung bei den Empfangs-Pins (bzgl. ESP8266-Seite) mit Widerständen (2.2KΩ / 3.3KΩ).
Ein Testlauf wird mit dem Reset-Taster am ArduinoUNO eingeleitet. Dadurch wird der PD-Pin am ESP8266 kurz auf LOW gezogen, dieser dann auf HIGH gesetzt, 15 Sekunden gewartet, danach per AT-Befehl der Chip testhalber befragt und dann der Datenaustausch via TCP/IP gestartet.
Vcc ESP8266
 Antwort auf ping
 Reaktion auf AT-Befehle
 Datenaustausch mit dem Python-Script
2.2V
 nein
 keine Reaktion nicht möglich
2.4V
 ja (viele DUP's)
 ASCII-Salat nicht möglich
2.5V
 ja
 ASCII-Salat nicht möglich
2.7V
 ja
 korrekt
 braucht mehrere Versuche
2.8V
 ja
 korrekt
 braucht mehrere Versuche
3.0V
 ja
 korrekt braucht manchmal mehrere Versuche
3.3V
 ja
 korrekt stabil
3.5V
 ja
 korrekt stabil
3.7V
 ja
 korrekt
 braucht manchmal mehrere Versuche
3.9V
 ja
 korrekt
 stabil
4.0V
 ja (viele DUP's) korrekt
 stabil

Bei 4.0V wurde der Chip schon deutlich warm.
Noch höher wollte ich daher lieber nicht gehen, um das Modul nicht doch noch irgendwann wegzugrillen.

BTW: mit "viele DUP'S" meine ich sowas hier:
64 bytes from ESP8266-2.FreifunkWees01.local (192.168.42.102): icmp_seq=147 ttl=255 time=3.75 ms
64 bytes from ESP8266-2.FreifunkWees01.local (192.168.42.102): icmp_seq=147 ttl=255 time=16.9 ms (DUP!)
64 bytes from ESP8266-2.FreifunkWees01.local (192.168.42.102): icmp_seq=147 ttl=255 time=17.0 ms (DUP!)
64 bytes from ESP8266-2.FreifunkWees01.local (192.168.42.102): icmp_seq=147 ttl=255 time=17.0 ms (DUP!)
64 bytes from ESP8266-2.FreifunkWees01.local (192.168.42.102): icmp_seq=147 ttl=255 time=17.0 ms (DUP!)
64 bytes from ESP8266-2.FreifunkWees01.local (192.168.42.102): icmp_seq=147 ttl=255 time=17.0 ms (DUP!)
64 bytes from ESP8266-2.FreifunkWees01.local (192.168.42.102): icmp_seq=148 ttl=255 time=3.55 ms
64 bytes from ESP8266-2.FreifunkWees01.local (192.168.42.102): icmp_seq=148 ttl=255 time=4.56 ms (DUP!)
64 bytes from ESP8266-2.FreifunkWees01.local (192.168.42.102): icmp_seq=148 ttl=255 time=8.10 ms (DUP!)
64 bytes from ESP8266-2.FreifunkWees01.local (192.168.42.102): icmp_seq=148 ttl=255 time=11.2 ms (DUP!)
64 bytes from ESP8266-2.FreifunkWees01.local (192.168.42.102): icmp_seq=148 ttl=255 time=12.9 ms (DUP!)

Fazit: ohne richtige Pegelwandlung liegt der beste Betriebsbereich zwischen 3.0V und 3.5V.
Notfalls gehts ab 2.7V und bis zu 3.9V (zumindest, sofern kein Dauerbetrieb des ESP8266 geplant ist).
Da ist das Ding doch pingeliger, als ich gedacht hatte.
Ich bin ja mal gespannt, wie die Liste aussehen wird, wenn die Kommunikation über ein Pegel-Wandler-Modul läuft.

Eine Auffälligkeit bei den einzelnen Test-Durchläufen war noch, dass ich trotz der exorbitanten Wartezeit von 15 Sekunden nach ChipEnable den Eindruck hatte, als würde das Ding mit der Zeit besser reagieren. Also nach Änderung der Spannung war es erstmal eine gefühlte Minute recht gruselig, wurde dann besser und blieb so. Bis zur nächsten Spannungs-Änderung.


Erst wird jetzt aber nochmal der Test mit den Akku-Packs wiederholt.
Schließlich habe ich neue Erkenntnisse und eine Programm-Version im ArduinoUNO, die mir "Kommunikations-Stabilitäts-Infos" ausgibt.
Ich lade erstmal beide Akku-Sätze frisch auf. Der Spannungsverlust bei relativ geringer Last ist doch schon sonderbar.
Aber wenn die Schaltung nur mit frisch geladenen Akkus funktionieren sollte, würde mir das auch herzlich wenig nützen.
Häufiger als einmal pro Jahr wollte ich die nicht wechseln müssen.... Zumal ich derzeit keinen zweiten Vierer-Satz Mono-Zellen hätte.

Nun ist der Akku-Pack mit den Mono-Zellen randvoll geladen.
Liefert über zwei Akkus 2.75V, über drei 4.13V und über allen vier 5.51V. Das passt ja überhaupt nicht.

Vorsichtshalber werde ich mal ein paar 3.3V Festspannungsregler bestellen. Damit kann ich dann testen, wie sich das alles verhält, wenn ich die Schaltung mit einem Stecker-Schaltnetzteil mit 5V versorge und mir die 3.3V für den ESP8266 und die VBAT der RTC über so einen Regler abzweige.
Dabei muss sich dann zeigen, was das Steckernetzteil im Leerlauf so vernascht. Selbst wenn es nur ein Watt sein sollte, macht das immer noch 1W*24h*365 = 8.8kWh bei Betrieb rund um die Uhr. Somit jährliche Stromkosten von knapp 2€. Naja, könnte ich notfalls verkraften.

Und nach einem Stromausfall würde sich die Schaltung ganz automatisch wieder auf Stand bringen. Evt. sollte in der setup()-Routine für diesen Fall noch etwas länger gewartet werden. Damit auch der Rechner mit der Gateway-VM hoch ist, alle VMs hoch sind und die WLAN-Router sich auch wieder wohlfühlen und ansprechbar sind.

Dabei fällt mir gerade ein, dass der Load der Zeiten aus dem EEPROMs ins RAM zwar mit Prüfsumme abgesichert ist, aber nicht das Bedienen der Rollläden sperrt, wenn die Prüfsumme nicht zu den Daten gepasst hat. Stattdessen würden die im Programm festgelegten Daten verwendet werden. Ganz falsch sind die ja nicht. Trotzdem könnte die Zeiten-Tabelle mehrfach im EEPROM abgelegt werden. Platz wäre da noch. Erst wenn das EEPROM die Grätsche macht, würde auf die Zeiten-Tabelle aus dem Programm-Speicher zurückgefallen werden. Und das auch nur, wenn nicht mit dem Python-Script synchronisiert werden konnte.

Auch könnte es nicht schaden, die RTC regelmäßig auf korrekte Funktion zu prüfen. Vorzugsweise dann, wenn sie gerade neu gestellt wurde. Nach Stellen der Uhr könnte die gestellte Zeit gemerkt werden, eine Tiefschlafphase von acht Sekunden eingelegt werden - um danach zu prüfen, ob die RTC zwischen sieben bis neuen Sekunden weiter gelaufen ist. Wenn nicht, Info via WLAN an das Python-Script.
Aber was wäre in diesem Fall mit den Rollläden?
Nicht mehr ansteuern?
Nicht so gut.
Oder die Zeit über WLAN holen?
Könnte gehen: Wenn RTC=="dead", stelle WLAN-Verbindung her, hole Zeit und berechne daraus die Länge der nächsten Tiefschlafphase. Also müsste nur der RTC.getTime() in eine entsprechende Funktion ausgelagert werden. Und das Programm müsste damit umgehen können, dass so ein getTime() auch mal länger als ein paar Millisekunden dauern kann.

Das ESP8266-Modul muss auf der ATmega328-Seite nicht gesondert überwacht werden. Wenn das nicht mehr tut, sieht man das ja im Log bzw. der Ausgabe des Python-Scripts. Also die fehlenden Meldungen.

vorige Seite
 nächste Seite