Der Lauf der Zeit & stetige Weiterentwicklungen
Wie üblich mit solchen "Bastelprojekten" bzw. allgemein der Freiheiten die eine Hausautomation bietet, wird die Konfiguration auch ständig verändert.
Hier kommen Sonderwünsche die man sich selbst ausdenkt, da ein Wunsch der Frau usw.
So wurde neben dem Rundruf auf inzwischen 2 DECT Telefone sowie ein Tablet auch kürzlich eine Anwesenheitserkennung an der Tür realisiert. Allein mit dieser haben wir uns versehentlich einiges an Instabilität eingeholt. Warum beschreibe ich auch in diesem Beitrag.
Neue Fritzbox 7590 mit FriXtender Antennen
Eine der ersten Veränderungen war die 7490 Fritzbox durch eine neuere 7590 auszutauschen. Diese habe ich auch gleich mit FriXtender Antennen versehen, um eine noch höhere Stabilität zu bekommen.
Das Ergebnis war spürbar besser, der Raspberry vom DoorPI machte seltener Restarts wegen fehlendem Netzwerk, auch der ESP im Keller welcher die Klingeln, Licht und Türöffner schaltet war stabiler.
Aber wie schon in den anderen Beiträgen beschrieben, war der ESP nur dann stabil, wenn er direkt im Fritzbox-Netz angemeldet war. Kaum war er über eines der Repeaternetze online, waren die Verzögerungen bis zu 30s wieder vorhanden, was im Falle der Gongs unbrauchbar ist.
Fritz Powerline 1260E für die ESP8266 Schalter
In der Zwischenzeit habe ich 3 LinkNode R4 mit einem WLAN ESP8266 im Einsatz. Bei allen 3 kann ich unabhängig der Software feststellen, dass die Relais bis zu 30s benötigen, sobald diese über ein Repeater-Netz im WLAN angemeldet sind.
In sämtlichen Anwendungsfällen ist das völlig inakzeptabel, ich möchte natürlich dass entsprechende Geräte, Lichter oder die Türklingel gleich geschaltet werden.
Im Beitrag Einbau der VoIP Video Türsprechanlage im Haus habe ich die ersten Versuche sogar mit einem NodeMCU gemacht, welcher ebenfalls auf dem ESP8266 basiert. Auch hier gleiches Thema.
Fazit, es liegt weder an der Hardware noch an der Software. Möglich dass rein die ESPs hier ein Problem haben, denn in Foren wird auch von anderen Benutzern ähnliches geschrieben.
Einzig was wirklich hilft, dafür zu Sorgen, dass der ESP sich nicht in ein Repeaternetz anmeldet. In einem MESH Netzwerk ist das nicht wirklich möglich, einzige Lösungen wären:
- unterschiedliche SSIDs der Repeater
In unserem Fall sind inzwischen 4 Repeater im Haus. Bei unterschiedlichen SSIDs müsste ich jedes einzelne Gerät jedem einzelnen Repeater bekannt machen und verbinden. Ein erheblicher Aufwand und das jedesmal wenn ein neues Gerät dazu kommt.
oder - gleiche SSIDs jedoch mit MAC-Filter
Sind den Repeatern alle Geräte bekannt, hatte ich es lange Zeit so, dass ich MAC-Filter aktiv hatte. Entsprechend habe ich die ESPs bei den Repeater blockiert und nur bei der Fritzbox genehmigt, umgekehrt für den DoorPI Raspberry, der musste stets über den Gang-Repeater.
Lösung Okay, aber nicht wirklich optimal. Kommen neue Geräte hinzu muss doch wieder alles geöffnet werden und die Geräte verbinden wieder kuntabunt, sodass das Ent/-sperren von vorne beginnt.
Für den im Keller sitzenden ESP (2 Betondecken) habe ich deshalb ein Powerline Set gekauft. Die WLAN Gegenstelle ist knapp 1m vom ESP entfernt, sodass er gar nicht in die Versuchung kommt, sich in ein anderes Netz anzumelden.
Der ESP im Keller ist damit nun optimal angebunden, seit über 2 Wochen hatte ich auch keine Verzögerungen mehr.
Ein Gesamtbild meines Netzwerks zeige ich weiter unten.
Fritz Repeater 1750E für den DoorPI Raspberry
Irgendwie schienen die vorhandenen Fritz 310 Repeater (Anzeige) mit Ihren 300Mbit/s nicht optimal, sodass ich den neueren 1750E versucht habe. Auch mit Rücksprache von AVM sollten die Antennen des 1750E größer und besser sein, was ich auch etwas sehen konnte.
Die reine Stabilität für den DoorPI Raspberry wurde jedoch nicht spürbar besser, zumal dieser eh nur im 2,4GHz Band verbinden kann.
Der größte Vorteil den aber der neue Repeater hat, dass er eine LAN Buchse mitbringt, an welcher der Raspberry nun absolut zuverlässig seine Dienste leistet.
DoorPI Raspberry - Verbindungsprobleme & Lösungsversuche
Wie schon geschrieben, kämpften wir immer wieder mit schlechten Verbindungen des Raspberries mit dem DoorPI. Mal hatte er >200Mbit/s Verbindungen, mal waren sie <10 und völlig unbrauchbar.
Mit der Bluetooth Anwesenheitserkennung kamen ganz neue Probleme, so stören sich offenbar der Bluetooth & WLAN Chip gerne mal gegenseitig.
Also die kleine WLAN Antenne am Raspberry deaktiviert, ich wollte eh einen stärkeren USB-WLAN Empfänger versuchen.
Der USB-Stick nebenan wurde auch gleich perfekt vom Linux erkannt und konnte auch mit 300Mbit/s verbinden.
Auch hier wurde wieder eine kleine Verbesserung gesehen, zumal ich über ein kurzes USB-Kabel den Stick doch auch etwas ausrichten konnte.
Aber immer noch nicht perfekt.
Die einzige seit nun über 2 Wochen funktionierende Lösung ist, wie könnte es anders sein, ein LAN Kabel. Haha.
Dank der LAN Buchse vom 1750E Repeater habe ich den Raspberry nun per LAN angebunden. Der Repeater ist mit je ca. 300MBit im 2,4 sowie 5GHz Netz mit der Fritzbox verbunden. Da der Raspberry eh nur 100MBit Lan kann, ist das so völlig ausreichend.
Seither nicht einen Abbruch der Verbindung, nicht ein Stottern oder ein Wechsel auf <10Mbit. Das WLAN Modul am Raspberry ist komplett deaktiviert, hier kümmert sich lediglich noch der Bluetooth Chip um die Anwesenheitserkennung.
Hier ein Bild meiner derzeitigen W-/LAN-Abdeckung:
Letzter Feinschliff - neue IP Kamera
Um den Raspberry noch weiter zu entlasten, entfernte ich die Raspberry CAM und kaufte eine kleine WLAN IP Kamera.
Die nebenstehende Kamera hat neben den annähernd passenden Maße für die Blende auch eine deutlich bessere Auflösung als die Raspberry Kamera.
Vor allem aber wollte ich eine Kamera welche bereits IR-Nachtsicht eingebaut hat.
Wie durch Zufall passte die MICF Kamera fast schon perfekt in die Bohrung der ursprünglichen Linse wie im vorherigen DoorPI Beitrag beschrieben:
Beim ersten Anstecken der Kamera erstellte diese einen CM6F33... Hotspot mit welchen ich mein Handy verbinden konnte, nachdem ich die HDMiniCam App installiert hatte.
Ich hatte dann jedoch einen "kleinen" Kampf, dass die Kamera nicht gefunden wurde. Auch mit dem Scan des QR-Codes kam ich nicht sonderlich weit, da mir die Erweiterten Einstellungen der Kamera fehlten.
Ursache war dann doch denkbar einfach. Ich wollte die Kamera per Netzwerk-Scan suchen. Bei aktivierten Mobile Daten ging der Scan also sonstwohin und hätte vermutlich ewig gedauert. Kaum waren diese deaktiviert war die Kamera auch schon da und konnte ausgewählt werden.
Mit der Handy App konnte dann die WLAN-Verbindung mit dem Router hergestellt werden. Da ich gerade im Moment auch alle DHCP Adressen gegen statische IP Adressen tausche, fehlte hier leider die Option.
Allerdings kann man sich auch mit einem Browser auf die Kamera verbinden und hat hier nochmal einige Einstellungen mehr, vor allem was Zeitserver und die WLAN-Anbindung angeht.
Hier ein Live Bild der Kamera mit dem Browser:
Rechts unten sind die Kamera-Einstellungen, in welchen dann u.a. die manuelle IP-Adresse vergeben werden kann.
Das Bild habe ich übrigens vertikal gespiegelt. Der Grund dafür ist das deutlich kleinere Bild der Fritz Fone. Diese Stellen quasi mehr oder weniger die rechte Bildhälfte dar. Mit der normalen Einstellung sehe ich also fast ausschließlich die Türe.
Mit gespiegelter Einstellung sehe ich genau den Bereich den ich auch sehen möchte. Dass das Bild spiegelverkehrt ist stört nicht weiter, ich will ja nur sehen wer an der Türe steht.
Leider wird die Nachtsicht nicht automatisch bei Dunkelheit erkannt. Vermutlich könnte ich diese über die API aus Symcon heraus ansteuern, fürs Erste aktivere ich die IR-LEDs aber mit einem Zeitprofil zwischen 18 und 8 Uhr:
Hier ein Bild mit Nachtsichtbild:
Finale Arbeiten für den hoffentlich dauerhaft stabilen DoorPI Betrieb
Meine finale Arbeit was die Stabilität des Netzwerks angeht war, dass ich sämtliche IP Adressen auf Geräteseite statisch vergeben habe. Bei fast 100 Geräte ein ziemlicher Aufwand.
Hintergrund war, dass auch mit der 7590 ich immer wieder feststellen musste, dass Geräte nach Neustarts nicht mehr vorhanden waren, entweder hatten Sie andere IP-Adressen erhalten, teilweise musste ich auch immer wieder sehen, dass 2 Geräte die gleiche Adresse bekamen und somit überhaupt nicht erreichbar waren. Im Falle der Hausautomation mit Symcon wo die IPs der Sensoren oder Aktoren eingestellt sind, darf das nicht sein.
Weder die feste Vergabe in der Fritzbox noch der Haken "Immer diese IPv4 Adresse zuweisen" brachten Erfolg. Beim letzten Fritzbox Wechsel hatte ich eh auch festgestellt, dass diese Einstellungen wohl nicht Teil vom Backup waren und somit bei einer neuen Box auch wieder ganz neue Adressen vergeben werden.
Mit dem Umstieg auf statische Adressen der Geräte gehört dies nun der Vergangenheit an. Der Fritzbox DHCP arbeitet >100, alles darunter ist mein statischer Bereich. Eine Excel Tabelle hilft mir den Überblick zu behalten.
Auch die Verdrahtung in der DoorPI Dose habe ich deutlich optimiert, die Leitungen wurden entsprechend gekürzt und vor allem die Steuerleitungen auf die GPIO Pins mit einem geschirmten Netzwerkkabel umgebaut.
An dieser Stelle fällt mir noch ein Thema ein, dass ich teilweise Auslösungen des Gongs hatte, obwohl niemand den Taster gedrückt hatte. Dies war nicht oft der Fall, weshalb ich dies als EMV-Thema mit den kürzeren, geschirmeten Leitungen hoffentlich beseitigt habe:
Um die korrekte Ausführung des Anwesenheits-Skriptes zu erkennen, habe ich mein Startskript vom Netzwerk etwas erweitert.
Es wird alle 10 Minuten vom Cronjob wie im vorherigen Beitrag erwähnt aufgerufen und prüft, ob die Netzwerkverbindung vorhanden ist. Wenn nicht wird der ganze Raspberry neu gestartet. Dies gehört nun durch die LAN-Anbindung quasi der Vergangenheit an, es müsste schon der ganze Repeater keine Verbindung mehr haben.
Sofern ein Netzwerk vorhanden ist, wird nun noch überprüft ob es einen Python Prozess vom Bluetooth-Skript gibt. Wenn nicht wird es gestartet und somit meine Anwesenheitserkennung aktiv:
#!/bin/bash
# Check if network is connected and restart if not.
# @author Roland Meier
today=`date +"%Y%m%d_%H%M"`
ping -c4 192.168.XXX.XXX > /dev/null
if [ $? != 0 ]
then
echo $today: "No network available... reboot..."
sudo /sbin/shutdown -r now
else
pgrep python > /dev/null
if [ $? != 0 ]
then
python /PATHTOSCRIPT/bluecheck.py &
echo $today: "bluecheck.py not running... restart..."
fi
fi
