Zentrale hängt sich auf - keine Systematik erkennbar

[Hugo Oberstein]

Hallo Zusammen,
vielen Dank schon mal für eure Idee und Anregungen. Sowas in der Art hatte ich auch vermutet. Vielleicht schwankt auch nur das Stromnetz kurzzeitig (wir haben eine kleine PV Anlage) und bringt so den Pi durcheinander?? Ich hatte den Logfile ja angehängt (siehe post 1), aber da konnte ich nichts finden. Ich habe ihn jetzt von "alles loggen" auf "nur Fehler" gestellt, da die interessante Uhrzeit beim Logfile fehlte (vermutlich zu voll?).
Oder gibt es die Möglichkeit am Raspberrypi einen Logfile zu erzeugen - da müsste er ja den Disconnect auch mit loggen ?!
Falls ja wie mache ich das ?

Vielen Dank für eure Hilfe.

Hugo

[deimos]

Hi,

das Kernel Log vom Host wird nicht in das Log der CCU geschrieben, es braucht den Befehl.

Viele Grüße
Alex

[Hugo Oberstein]

Hi,

das Kernel Log vom Host wird nicht in das Log der CCU geschrieben, es braucht den Befehl.

Viele Grüße
Alex

Hi Alex,
Das werd ich tun.ich melde mich, wenn es soweit ist. Vielen lieben Dank für die Hilfe.

Hugo

[Hugo Oberstein]

Hallo Alex,
jetzt ist der Fehler wieder aufgetaucht.
Ich schicke dir mal eine PN mit der kompletten gespeicherten Ausgabe als txt Datei. Vielleicht kannst ja was anfangen.
Ich wollte hier nicht zu viele sensible Infos posten, ohne zu wissen, was ich tue.


Das waren aber die letzten Einträge:

Code: Alles auswählen

[182356.735546] eq3loop: eq3loop_close_slave() mmd_bidcos
[182357.874299] eq3loop: eq3loop_close_master() mmd_bidcos
[182357.874327] eq3loop: eq3loop_close_master() mmd_bidcos destroy device
[182357.874565] eq3loop: eq3loop_close_master() mmd_hmip
[182358.819706] eq3loop: eq3loop_close_slave() mmd_hmip
[182358.819728] eq3loop: eq3loop_close_slave() mmd_hmip destroy device
[182360.866230] br0: port 2(vethpivccu) entered disabled state
[182360.877022] device vethpivccu left promiscuous mode
[182360.877049] br0: port 2(vethpivccu) entered disabled state
[182361.060016] br0: port 2(vethpivccu) entered blocking state
[182361.060045] br0: port 2(vethpivccu) entered disabled state
[182361.060262] device vethpivccu entered promiscuous mode
[182361.060676] br0: port 2(vethpivccu) entered blocking state
[182361.060693] br0: port 2(vethpivccu) entered forwarding state
[182361.066227] eth0: renamed from vethLhz7Nu
[182361.091400] IPv6: ADDRCONF(NETDEV_CHANGE): vethpivccu: link becomes ready
[182508.425986] eq3loop: created slave mmd_hmip
[182508.426437] eq3loop: created slave mmd_bidcos
[182510.493685] eq3loop: eq3loop_open_slave() mmd_bidcos
[182529.902942] eq3loop: eq3loop_open_slave() mmd_hmip
[182529.903806] eq3loop: eq3loop_close_slave() mmd_hmip
[182529.906023] eq3loop: eq3loop_open_slave() mmd_hmip
[182529.906296] eq3loop: eq3loop_close_slave() mmd_hmip
[182529.906919] eq3loop: eq3loop_open_slave() mmd_hmip
[182529.907207] eq3loop: eq3loop_close_slave() mmd_hmip
[182529.924487] eq3loop: eq3loop_open_slave() mmd_hmip
[241390.508257] eq3loop: eq3loop_close_slave() mmd_bidcos
[241390.883360] eq3loop: eq3loop_close_slave() mmd_hmip
[241391.933616] eq3loop: eq3loop_close_master() mmd_bidcos
[241391.933642] eq3loop: eq3loop_close_master() mmd_bidcos destroy device
[241391.933925] eq3loop: eq3loop_close_master() mmd_hmip
[241391.933939] eq3loop: eq3loop_close_master() mmd_hmip destroy device
[241392.947983] br0: port 2(vethpivccu) entered disabled state
[241392.955426] device vethpivccu left promiscuous mode
[241392.955447] br0: port 2(vethpivccu) entered disabled state
[241393.078730] br0: port 2(vethpivccu) entered blocking state
[241393.078751] br0: port 2(vethpivccu) entered disabled state
[241393.078909] device vethpivccu entered promiscuous mode
[241393.079186] br0: port 2(vethpivccu) entered blocking state
[241393.079196] br0: port 2(vethpivccu) entered forwarding state
[241393.083746] eth0: renamed from vethLaUnZ0
[241393.104103] IPv6: ADDRCONF(NETDEV_CHANGE): vethpivccu: link becomes ready

Hugo

[Hugo Oberstein]

Ist gerade wieder aufgetreten. Konnte aber noch über Tinymatic auf die Systemvariablen zugreifen und die Alarmanlage "aus" schalten. Merkwürdigerweise reagierten zumindest die Homematic IP Sirenen noch, aber ansonsten half nur noch ein Neustart der Zentrale....

[Hugo Oberstein]

Hallo liebe Experten,
mir ist da noch was aufgefallen und vielleicht kann jemand das bestätigen.
Wie berichtet, hängt sich meine CCU ab und zu auf, das ist vor allem im Winter deutlich seltener als im Sommer. Diesen Winter war es nur einmal, im Sommer kommt es häufiger vor, aber ich habe bislang keine Systematik erkennen können. Nun meine ich aber, etwas erkannt zu haben.

Meine CCU scheint sich immer dann aufzuhängen, wenn der Duty Cylcus extrem in den Overrun geht. Das kommt bei mir dann vor, wenn die Alarmanlage aktiv ist und die Bewegungsmelder rund ums Haus permanent zwischen Bewegung und keine Bewegung wechseln (und daraufhin die Anwesenheitssimmulation los geht). Dann gehen z.B. die Rolladen runter und nach einer Zeit wieder hoch. Passiert dieser Wechsel häufiger, weil z.B. die Nachbarskinder bei uns im Garten spielen (was für uns ok ist ), steigt der DC permanent schneller an, als er abgebaut wird.

Wenn der DC bei 99% ist und dann permanent neu befüttert wird bevor er sich abbauen kann, scheint die CCU nach einer Zeit die Füsse hoch zu machen. Dann fällt die Carrier Sense anzeige aus, der DC geht auf 0% und die CCU liefert Servicemeldungen bis zum Reboot. Und warum ist das im Sommer häufiger als im Winter? Im Winter sind die Verschattungsprogramme nicht aktiv, d.h. die Rolladen werden weniger häufig hoch und runter gemacht. Im Sommer, werden die Rolläden nach den Helligkeitssensoren getriggert (mit einer SV und 15 Minuten Zeitverzögert). Aber wenn wir ein häufigeres Wechselspiel aus Sonne und Wolken haben, die Alarmanlage an ist und dann noch die Rolladen runter gehen wegen der Spielenden Kinder geht der DC halt schneller und häufiger hoch.....

Kann jemand so ein Verhalten bestätigen bzw. wie könnte ich meinen Verdacht überprüfen ?

Vielen Dank für eure Mühe.

Hugo

[MichaelN]

Ich würde die Programmierung überdenken. Ist bestimmt auch nicht der Lebensdauer der Rollos zuträglich, wenn da so ein Ballett abspielt wird.

Meine Schatten / Sonnen Erkennung ist zum Beispiel mittlerweile so ausgefeilt, dass die Rollos vielleicht eine zusätzliche Fahrt machen bei wechselhaften Wetter.

Und ob so eine Show eine wirksame Abwesenheit simulation ist, kann man auch trefflich streiten.

Bei uns fahren die Rollos bei Dämmung runter und morgens wieder hoch. Immer. Wie soll da einer daran Abwesenheit erkennen. Das höchste der Gefühle ist, dass ich eine Lampe im Wohnzimmer nach Helligkeit schalte für die Zeit wo das Rollo noch auf ist. Das ist simulation genug.

[Matthias K.]

steigt der DC permanent schneller an, als er abgebaut wird.

Es sollte selbst bei einer Art Anwesenheitssimulation nicht vorkommen dass der DC durch die Decke geht.
Ich denke da gäbe es bei deinen Programmen einiges an Optimierungspotenzial.

Zeig doch mal exemplarisch 1 oder 2 der relevanten Programme als Screenshot, da fallen sicher diverse Tipps ab wie man optimieren könnte...

Nichtsdestotrotz sollte auch bei DC 100% die CCU nicht hängen, außer du hast Programme mit Scripten die z.B. irgendwas externes aufrufen oder auf Rückmeldung warten und dann die ReGaHSS blockieren.

[Hugo Oberstein]

Hallo Zusammen,
ja vielen Dank - da gäbe es vermutlich noch das ein oder andere, wo man optimieren könnte.
Wobei ich einige Bewegungsmelder/ Präsenzmelder Innen und Außen habe, so dass mein DC im Besten fall im Leerlauf bei 19% liegt.

Im Anhang habe ich mal ein Beispiel für die Anwesenheitssimulation gemacht, wobei es von dieser Art 4 Stk gibt, je nachdem auf welcher Seite des Hauses eine Bewegung detektiert wird.

Und bei den Sonnenschutzprogrammen :
Das ist besonders in den Schlafzimmern sehr kompliziert (finde ich).
Auf der einen Seite möchte man nicht, dass die Rollos was machen, wenn sie unten sind und man noch schläft.
Wenn Sie nach oben gefahren wurden, dann sollen sie prüfen, ob die Helligkeit so groß ist, dass sie wieder runter fahren sollen. Da ist dann noch ein Puffer drin, dass sie nicht ständig hoch und runter fahren.

In Kombination mit der Anwesenheitssimulation passiert jetzt manchmal folgendes:
1. Rollos gehen in Sonnenschutzposition.
2. Bewegung wird erkannt - Rollos fahren runter
3. Bewegung wieder weg - Rollos fahren ganz hoch
4. Periodisch wird überprüft, ob die Rollos oben sind und es hell genug ist --> dann fahren sie wieder in die Sonnenschutzposition.

Und das strapaziert natürlich den DC.

Insgesamt 15 Bewegungsmelder Innen HM-Sec-MDIR und Außen HM-Sen-MDIR-O-3
3 Präsenzmelder

Skripte läuft höchstens das Telegram Push skript, aber das hängt nicht.....

Hugo

[Matthias K.]

Das sind sehr komplexe Programme mit mehreren Sonst-Wenn. Wenn man da nicht ganz genau weiß was man tut kann einem das mächtig auf die Füße fallen (wie bei dir mit hohem DC und unerwartetem Ergebnis).
Die Besonderheiten bezüglich Programmabarbeitung (Trigger ist unabhängig von Bedingunbgsprüfung) sind dir bekannt?
Wenn nicht gibt's hier Lesestoff: viewtopic.php?f=1&t=22801 -> B2

Bei Unklarheit lieber die einzelnen Zweige in separate Programme packen.

Grundsätzlich entzieht sich meinem Verständnis aber, weshalb bei jeder Bewegung die Rolladen fahren müssen, v.a. wenn dort häufig erwünschte bzw. geduldete Bewegung stattfindet.
Evtl. solltest du hier auch das gesamte Konzept der Abwesenheitssimulation überdenken.
Die Frage ist bei solchen Dingen immer: Was bringt es? Erwartest du dadurch einen geringere Einbruchwahscheinlichkeit? Oder gibt es andere Gründe für ein häufiges Fahren der Rollläden (was ja auch durchaus der Motorlebensdauer nicht zuträglich ist)?