rdmtc / RedMatic

Node-RED packaged as Addon for the Homematic CCU3 and RaspberryMatic 🤹‍♂️
Apache License 2.0
533 stars 47 forks source link

Frage: Gibt es einen regelmäßigen, wöchentlichen Job-Schedule in RedMatic? #495

Closed djiwondee closed 3 years ago

djiwondee commented 3 years ago

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:

Mar 28 03:13:04 ccu3 node-red[9324]: [deconz-server:deCONZ raspi] WebSocket connection timeout, reconnecting
Mar 28 03:13:15 ccu3 node-red[9324]: [deconz-server:deCONZ raspi] WebSocket opened
Mar 28 03:14:43 ccu3 node-red[9324]: [deconz-server:deCONZ raspi] WebSocket connection timeout, reconnecting
Mar 28 03:14:53 ccu3 node-red[9324]: [deconz-server:deCONZ raspi] WebSocket opened

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:

# crontab -l
0 * * * * /bin/setHWClock.sh >/dev/null 2>/dev/null
1 */6 * * * /bin/SetInterfaceClock 
0 4 * * * /usr/sbin/logrotate -f /etc/logrotate.conf || logger -p error -t "logrotate" "logrotate aborted with error $?"
*/5 * * * * /usr/local/addons/mediola/bin/watchdog

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!

Sineos commented 3 years ago

Ist das ggf eine Zwangstrennung deines Providers?

djiwondee commented 3 years ago

@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.

Sineos commented 3 years ago

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 😏

djiwondee commented 3 years ago

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 -lwohl 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!