Closed djiwondee closed 3 years ago
Ist das ggf eine Zwangstrennung deines Providers?
@Sineos Nein, die Zwangstrennung des Providers findet circa 1:20 Uhr statt, täglich und nicht nur Sonntags. Außerdem ist die CCU und der Raspi in einem eigenen Netz hinter einem Switch. Dieses habe ich auch schon auf Power und Network shutdown hin geprüft.
Das witzige an dieser Uhrzeit: Etwa zur gleichen Zeit habe ich exakt das gleiche Phänomen mit meinem SolarLog, den ich abfrage. Jede Nacht zu dieser Zeit wird die Verbindung neu aufgebaut. Wobei das definitiv etwas im SolarLog ist, denn der Effekt tritt mit ioBroker sowie Node-Red auf und beide laufen auf unterschiedlichen Systemen... und es geht kein Licht im Schlafzimmer an 😏
Ok, Grund identifiziert: Es ist nachweislich wiederholbar auf meinem Setup und der Gewinner ist: Überraschung - pihole! Dieser Dienst läuft auch noch auf dem Raspi.
Dies geschieht während der Aktualisierung der Blocklists (pihole updateGravity
), die auf der Grundlage eines vom Daemon geplanten Cron-Jobs ausgeführt wird (deshalb hat das crontab -l
wohl nicht angezeigt - siehe sudo nano /etc/cron.d/pihole
):
# Pi-hole: Update the ad sources once a week on Sunday at a random time in the
# early morning. Download any updates from the adlists
# Squash output to log, then splat the log to stdout on error to allow for
# standard crontab job error handling.
12 3 * * 7 root PATH="$PATH:/usr/sbin:/usr/local/bin/" pihole updateGravity >/var/log/pihole_updateGravity.log || cat /var/log/pihole_updateGravity.log
Ich habe den Befehl auf der Konsole schon so oft manuell ausgeführt und habe dies nie bemerkt.
Wie vielleicht bekannt, hat das Update Gravity-Skript von Pihole mehrere Schritte auszuführen. Einer der Schritte ist eine Aufgabe namens [✓] Building Tree
. Der Netzwerkverlust geschieht genau innerhalb dieses Schrittes. Das habe ich herausgefunden, als ich den pihole updateGravity-Befehl in einem Terminal-Fenster ausgeführt habe, während ich die Ausgabe des node-red-log (tail -f ...) in einem zweiten Fenster beobachtete.
Aber - was soll ich sagen - die Lichter gehen nicht an, wenn ich es manuell teste...Das Issue hier zur Beantwortung meiner Frage kann ich aber damit schließen. Danke @Sineos!
Hallo,
habe eine kurze Frage und würde das nicht zwingend als redmatic-Issue klassifizieren. Ich nutze Redmatic auf eine CCU3. Zusätzlich läuft ein Raspi parallel mit einem deCONZ Rasbee II HAT für die Einbindung von zigbee devices. Für letzteren habe ich in redmatic den deCONZ node-red node eingebunden. Das funktioniert auch alles (fast) perfekt/erwartungsgemäß. Es gibt jeden Sonntag (und nur an diesem Tag und immer zur selben Uhrzeit für ca. 3:16/3:18 ein “network connection loss” im CCU message log:
Der hat zur Folge, dass im Schlafzimmer zwei Lichter eigeschaltet werden, wenn der deCONZ-HAT node den Websocket zu dem Raspi neu aufmacht. Manchmal werden wir auch wach davon ;-) Ich bin schon mit dresden-Elektronik im Service-Ticket-Infoaustausch.
Auf deren Rückfrage hin wollte mich in Sachen Redmatic auf der CCU gerne rückversichern:
--> Gibt es auf der CCU oder insb. in Redmatic einen Job, der jeden Sonntag gg. 3:16-3:18 Uhr ausgeführt wird?
Ich beobachte diesen Effekt seit Wochen. Die Crontab auf der CCU zeigt vier Jobs:
und auf dem Raspi gibt es keinen Cron-Job, was aus meiner Sicht alles nicht auf einen Neuaufbau der Netzwerkverbindung zwischen der CCU und dem Raspi hinweist zum angegebenen Zeitpunkt.
Danke für jede Antwort!