vorige Seite
 Inhaltsverzeichnis nächste Seite

Nachlese 2

Die Schaltung hat nun eine knappe Woche lang ihre Arbeit getan (ich war auf Dienstreise).
Genauer gesagt vom 22.11.2015 11:29 bis zum 28.11.2015 10:00.
Die Rollläden wurden (laut meiner Frau) immer zum gewünschten Zeitpunkt angesteuert.
Es gab jedoch zwei Auffälligkeiten im Log:
Auf den ersten Blick sonderbar, auf den zweiten Blick aber doch nicht.
Glücklicherweise protokolliere ich hier ja so einiges.
Dazu gehört auch die Erreichbarkeit meiner Systeme mittels pinger.
Und in dessen Log finden sich im relevanten Zeitbereich die drei folgenden Einträge:
20151124-065832 offline r43b
20151124-065936 offline voipwz
20151124-070145 online  r43b, voipwz
Unter dem Namen r43b fühlt sich der WDR4300 im Wohnzimmer angesprochen, der die SSID "FreifunkWees01.2 (http://ffw)" bereitstellt.
Wenn der WLAN-Router um 07:00 Uhr (warum auch immer) gerade mal verwirrt ist, kann der ESP8266 darüber logischerweise auch keine Verbindung zum Python-Script herstellen. Ergo: kein Problem der Schaltung.

Der Zeitpunkt für den Log-Eintrag mit dem Neustart war wie immer - bzw. nicht verspätet.
Somit wird sich die Schaltung sehr wahrscheinlich just in dem Moment aufgehängt haben, in dem die Funktion ESP8266_power_on_setup_and_wait_for_ip() aufgerufen wurde. Und darin wird als erstes das Relais und damit auch der 3.3V-Regler eingeschaltet.
Weiterhin wurde in dem Log-Eintrag eine Akku-Spannung von 5.18V gemeldet. Davor waren es die Woche über immer konstant 5.20V.
Tja....da die Schaltung einen sauberen Reset gemacht hat, ist der einzige Nachteil der, dass die Variable sleep_PWR_DOWN_duration_g auf 8400, statt auf dem um 01:00 Uhr ermittelten Wert steht.
Sehr fraglich ist allerdings, ob man sich auf einen sauberen Reset verlassen kann.
Eben so gut könnte der ATmega328 wahrscheinlich auch in einer Tot-Schleife landen und dann so lange nix sinnvolles mehr tun, bis der Reset-Taster betätigt wird.
Sehr unerquicklich.
Und der Einsatz eines Hardware-Watchdogs mit NE555 ist bei genauerem Hinsehen auch keine wirkliche Option, weil das den konstanten Stromverbrauch in den Milliampere-Bereich katapultieren würde.
Dann schon eher zu der Idee zurückkehren, die Spannung für den ESP8266 über drei Akkus abzugreifen.
Und den Spannungsteiler für die Spannungs-Messung mit einem MOSFET ein- bzw. ausschalten.
Aber bevor ich jetzt sozusagen ans Reißbrett zurückkehre, werde ich das erst mal einige Zeit lang beobachten.
....so bezüglich Häufigkeit und vielleicht sogar Regelmäßigkeit.

Andererseits lässt mir das keine Ruhe...... Im Programm für den ATmega328 habe ich keine einzige Schleife, die endlos (bzw. ohne timeout) auf irgendwas warten würde - zumindest nicht in meinen selbstgebauten Funktionen. Jedoch wird der ATmaga328 wohl auch auf der Von-Neumann-Architektur basieren. Damit wäre es zumindest theoretisch möglich, dass der ProgrammCounter nach einer elektrischen Störung in den Daten-Bereich zeigt, Daten als Programm interpretiert und diese Daten zufällig eine Endlos-Schleife ergeben. Folglich kann ich ohne Watchdog nie ganz sicher sein, dass das Programm nach einer solchen Störung irgendwann in einen definierten Zustand zurückkehrt.
Mein erster Glotzregulator läuft allerdings schon seit einigen Jahren absolut zuverlässig. Das ist schon bald verdächtig.... und der steuert ebenfalls ein Relais an ..... und kommt ohne Watchdog aus.

Jetzt habe ich bald eine Stunde darauf verwendet, irgendwas Watchdog-IC-artiges zu finden, das folgende Parameter besitzt:
- DIL-Gehäuse.
- low power (ein- maximal zweistelliger µA-Bereich).
- mehr als acht Sekunden Timeout-Dauer.
- bei Reichelt oder Segor verfügbar.
War nix. Der MAX 1232 CPA würde mir ja durchaus gefallen (speziell auch preislich), aber so wie ich das deute, will der mindestens einmal alle 1.2 Sekunden einen Retrigger haben, wenn er keinen Reset auslösen soll. Und deswegen jetzt meine Tiefschlaf-Phasen von acht auf eine halbe Sekunde runterzudrehen, gefällt mir auch nicht. Schließlich kostet ja jedes Aufwachen Strom.

Nun habe ich gerade mal meine Annahme bzgl. der Von-Neumann-Architektur prüfen wollen und das hier gefunden.
Also hat das Teil eine Harvard-Architektur. Das ist ja schön. Aber wohl trotzdem kaum eine Garantie, dass er sich nicht aufhängen kann.

Und schon kommt die Bestätigung. Morgens am 30.11., noch vor dem Öffnen der Rollläden, hat die Lebenszeichen-LED nicht mehr geblinkt. Beim Druck auf den Reset-Taster hat das Relais geklickt. Schon vor dem Loslassen des Reset-Tasters.
Also war das Relais eingeschaltet und wurde durch den Reset abgeschaltet.
Damit war es dann wohl seit 03:00 Uhr an und hat Strom gezogen. Ebenso wahrscheinlich der ESP8266.
Im Log hieß es dann auch:
2015.11.30 06:49:02 Akku-Spannung: 4.88V

Der einfachste Workaround ist im ersten Ansatz ein zusätzlicher 100µF-Kondensator direkt an den Pins 7 (VCC) und 8 (GND) des ATmega328.
Den habe ich gestern Abend nachgerüstet. Mal schauen, wie es sich damit auf die Dauer macht.

Und wenn es weiterhin unmotivierte Resets gibt, könnte ich noch in ESP8266_enable()
    digitalWrite(ESP8266_POWER_PIN, HIGH);        // ESP8266 mit Strom versorgen
    delay(10);
    digitalWrite(ESP8266_CHIP_ENABLE_PIN, HIGH);  // ESP8266 aktivieren
den delay von 10 auf 100 Millisekunden anheben.
Das gäbe dem Kondensator etwas mehr Zeit zum Aufladen, bevor der ESP8266 statt 34µA plötzlich 142mA zieht.
Quasi kein Aufwand, aber dafür auch nicht sonderlich erfolgversprechend.

Schon eher erfolgversprechend sollte es sein, den Lade-Strom des 100nF-Kondensators am ESP8266 zu begrenzen.
Vielleicht erstmal mit 10Ω in Reihe.
Aber ob der dann noch den gewünschten Effekt hat, kleine Spannungseinbrüche abzufangen...?
Jedenfalls würden davon keine 3.3V mehr beim ESP8266 ankommen, weil ja immer etwas Spannung über dem 10Ω-Widerstand abfallen würde.
Bähh...Igitt....Spulen und RC-Glieder habe ich schon immer gehasst.
Oder ich entferne den 100nF-Kondensator am ESP8266 einfach wieder.
Jedenfalls dann, wenn sich der ATmega328 nochmal unerwartet ins Nirvana verabschieden sollte.


Nun läuft das seit 17 Tagen ohne Störungen oder Neustarts. Somit brauche ich die Änderungen wohl doch nicht.

Und noch ein (nicht getürktes) Bild:
3 Monate uptime
Drei Monate uptime, drei Monate 100% zuverlässiges Öffnen und Schließen der Rollläden :-)
Und es ist wirklich sehr viel geiler, die Zeiten mit nano der Jahreszeit anzupassen - als jedes mal an fünf Schwenkwicklern mit diesen fummeligen Tipptasten rumtüdern zu müssen. Abgesehen davon gehe ich davon aus, ab Dezember diesen Jahres mit der Zeiten-Anpassung durch zu sein. Dann ist ein Jahr rum und alle Sonnenuntergangs-Zeiten sind in die realen Dunkelheits-Zeiten geändert.

Ideen für eine mögliche nächste Version

Es sollte möglich sein, auf die RTC zu verzichten. Wenn ein- oder zweimal täglich das aktuelle Datum samt Uhrzeit per WLAN geholt wird, müssten sich ebenso gut die internen Zähler des ATmega328 (zur Zeitbestimmung über den Tag) verwenden lassen können.
Mit entsprechender Einarbeitung kann wahrscheinlich auch alles nur vom ESP8266 aus gesteuert werden. Ohne die RTC braucht es nur einen Ausgangs-Pin für die IR-LED. Zum ESP8266 käme also noch ein 3V-Akku, eine IR-LED, ein NPN-Transistor und zwei Widerstände hinzu. Theoretisch zumindest. Und dann könnte man das 5x bauen und jedem Schwenkwickler seine eigene Steuerung geben. Damit hätte man keine Kabel zu verlegen, immer ungehinderte IR-Kommunikation mit dem jeweiligen Schwenkwickler und lediglich gelegentliche Akku-Wechsel-Orgien.


Das Hintergrund-Bild dieser Seite ist übrigens nicht irgendwo geklaut, sondern vielmehr das (nur 7424 Byte große) Produkt aus einem Breadboard, einer Nikon D80 und GIMP 2.8.14.

Die einzelnen Seiten sind mit Hilfe von SeaMonkey Composer v2.39 unter openSUSE 13.2 erstellt worden. Ganz von Hand sozusagen.

vorige Seite
 nächste Seite