Schritt 9 - Gehäuse-Bau und Dauerbetrieb

Der Gehäuse-Bau war schmerzlos. Es hat insgesamt weniger als drei Stunden gedauert.
Die zwei TicTac-Dosen passen gut und sind schön schwergängig drehbar.
Der Akku-Pack mit vier Mignon-Akkus ist ebenfalls außen auf dem Gehäuse gelandet. Spart das Öffnen des Gehäuses zum Wechsel.
Vorne die Lebenszeichen-LED, hinten der Reset-Taster.
Das einzige, was mir nicht 100% gefällt, ist die Höhe des Gehäuses. Da ist jetzt reichlich Luft drin.
Aber das war das einzige aus meinem Fundus der vor Jahren "auf Vorrat" gekauften Gehäuse, in das die Lochraster-Platte reinpasste.
Beim nächsten Projekt sollte ich das Gehäuse frühzeitiger auswählen, um dann die noch unbestückte Leiterplatte ggf. ein paar Millimeter verkleinern zu können.

Jetzt hat die Schaltung seit drei Tagen ihren Dienst an den Rollläden zuverlässig erfüllt.
Lediglich ein kleines Detail stört mich noch: ich habe extra Aufwand betrieben, damit sich die Schaltung zweimal am Tag auf die Sekunde genau beim Python-Script meldet - und dafür sogar mindestens doppelten Akku-Verbrauch für die WLAN-Phase in Kauf genommen.
Trotzdem zeigt mir das Python-Script, dass die Connects immer pünktlich um 03:00:03 bzw. 15:00:03 erfolgen. Ich will die aber nicht drei Sekunden nach der eingestellten Zeit haben....
Bei erneuten Tests (mit einem anderen ESP8266-Modul an einem ArduinoUNO) habe ich mich gefragt, warum eigentlich immer erst der dritte Connect-Versuch erfolgreich ist. Dann habe ich aus Spaß einfach mal den Hostnamen durch die entsprechende IP-Adresse ersetzt. Siehe da...nun ist bereits der erste Connect-Versuch erfolgreich. Da ist wohl die Befragung des DNS etwas langsam...oder was auch immer!?
Folgende Werte für die Dauer des jeweiligen Funktionsaufrufs waren auf ±10 Millisekunden stabil:

Funktion	Hostname	numerische IP-Adresse
ESP8266_power_on_setup_and_wait_for_ip()	3779 ms	3787 ms
ESP8266_connect_TCPIP()	2671 ms	102 ms

Der einzige Unterschied war:
    ESP8266.println(F("AT+CIPSTART=\"TCP\",\"gw\",2626"));
bzw.:
    ESP8266.println(F("AT+CIPSTART=\"TCP\",\"192.168.42.254\",2626"));

Weiterhin war in ESP8266_wait_for_ip() noch ein kleiner Denkfehler: wenn der ESP8266 bereits über AT-Befehle ansprechbar ist, wird der nach ESP8266.println(F("AT+CIPSTATUS")) folgende ESP8266.find("\r\nSTATUS:") nie in den Timeout von einer Sekunde laufen. Somit muss in ESP8266_wait_for_ip() aktiv gewartet werden, um den als Parameter übergebenen timeout_seconds einzuhalten.
Nebenbei habe ich die Zeit für die Lebenszeichen-LED von 50ms auf 10ms runtergesetzt. Das ist immer noch erkennbar und spart Strom.

Heute (08.11.2015) habe ich den Socket-Server insofern umgebaut, dass er jetzt von einem Überwachungs-Script abgefragt werden kann.
Gestartet wird er mit:
    screen -S SocketServerESP8266v7 -d -m /home/dede/SocketServerESP8266v7.py

Im Log der Version 7 werden Warnungen jetzt farblich hervorgehoben:

Noch läuft das Überwachungs-Script im Terminal bzw. Text-Modus und liefert z.B.:

ip_address                 =192.168.42.101
hostname                   =ESP8266-1
current_authorization_state=WAIT
was_authorized             =True
current_socket             =None
last_seen_here             =None
last_connect_local_time    =2015.11.08 19:30:18
last_time_delta_seconds    =0
last_voltage               =5.12
last_firmware_version      =1.6.1
last_restart_timestamp     =2015.11.08 19:30:18
last_warning_code          =1

Final möchte ich ein kleines Fensterchen auf dem Desktop, in dem per wxWidgets (oder zur Abwechslung vielleicht auch mal per Gtk) die relevanten Daten angezeigt werden.
Also sowas wie:

Zeitpunkt des letzten Connects
Dauer seit des letzten Connects
letzte Uhren-Abweichung
letzte Akku-Spannung
letzte Warnungen

Wenn das Überwachungs-Script mit GUI läuft, werde ich nochmal alle Programme in neuster Version hier verlinken.

Nun ist der RollladenMonitor auch fertig.
Sieht so aus:

oder mit maximalen Warnungen Screenshot RollladenMonitor mit allen Warnungen

Der linke Screenshot ist die normale Ansicht und zeigt die Attribute der Schaltung von der letzten Kontakt-Aufnahme.
Beim rechten Screenshot kommuniziert der RollladenMonitor mit einem SocketServer, der seine Daten statt von einer Schaltung von einem Test-Script bekommen hat. Darüber wurde der maximale Fehler-Status eingestellt. Also "letzte Verbindung" älter als 12 Stunden, Akku-Spannung unterhalb von 4.4V, mehr als drei Sekunden Abweichung der RTC und alle Warnungen eingeschaltet, außer der Restart-Warnung.
Die Warnungen werden im Fenster (aus Platz-Gründen) als Zahl dargestellt. Wird der Mauszeiger auf die Zahl bewegt, erscheint ein Popup mit der Bedeutung der in der Zahl gesetzten Bits.

Hier noch die Programme in aktueller Version:
ESP8266-AnsteuerungV7.ino
SocketServerESP8266v7.py
RollladenMonitor.py

Die Attribute "letzter Restart" und "letzte Verbindung" im RollladenMonitor sind in Ortszeit angegeben.
Somit wird die "letzte Verbindung" einmal pro Jahr eine Stunde lang anzeigen, dass die 12 Stunden zwischen den Meldungen überschritten wurden.
Am letzten Sonntag im März wird um 02:00 Uhr Normalzeit auf 03:00 Uhr Ortszeit vorgestellt. Die Nacht ist eine Stunde kürzer.
Damit ist es für den RollladenMonitor um 02:00 Uhr Normalzeit bereits 03:00 Uhr Ortszeit, die Schaltung wird sich aber erst um 03:00 Uhr Normalzeit, also 04:00 Uhr Ortszeit melden. Folglich gibt es jeweils am letzten Sonntag im März zwischen 03:00 Uhr und 04:00 Uhr Ortszeit eine Fehlermarkierung. Da mich das zu dieser nachtschlafenden Zeit nicht stört, bleibt das so.

Nach der oben erwähnten Änderung des Connects von Hostname nach IP-Adresse kamen die Connect-Meldungen gerne mal um 02:59:59 bzw. 14:59:59. Was ich eigentlich nicht ganz verstehe. Die Abweichung der Uhren wurde mit 0 Sekunden gemeldet, trotzdem kam der Connect etwas zu früh. Außerdem schicke ich die aktuelle Uhrzeit mit abgeschnittener Millisekunden-Information zur Schaltung und berücksichtige weder die Zeit für die Übertragung noch für die Verarbeitung. Da mein Programm erst aktiv wird, wenn die eingestellte Zeit laut RTC erreicht wurde, kann m.E. nur noch die RTC innerhalb von 12 Stunden soviel vorgehen, dass sowohl die Übertragungszeit als auch die Verarbeitungsdauer kompensiert wird und dann noch ein paar Millisekunden dazu kommen. Um der Sache auf die Schliche zu kommen, könnte ich die Log-Anzeige im SocketServer temporär so umbauen, dass auch die Millisekunden-Information angezeigt wird. Aber eigentlich ist das auch nicht so wichtig. Daher habe ich den Vorlauf zum Anglühen des ESP8266 wieder ausgebaut und fange erst zum eingestellten Zeitpunkt damit an, den ESP8266 mit Strom zu versorgen. Damit kommt der Connect dann garantiert bzw. mindestens drei Sekunden zu spät, aber ich spare pro Connect locker 10 Sekunden Zeit, in denen Relais und ESP8266 sonst schon Strom ziehen würden.

vorige Seite

nächste Seite