Duty Cycle Nach Update auf 3.53.34.20201121 sehr hoch

[Matthias K.]

oder vielleicht auch wenn aufgrund fehlerhafter firmware die auf "router" konfigurierten hmip-steckdosen einen funksalat erzeugen der dann den eigenen homematic-funkverkehr stört?

das wär aber dann systemebene bereich eq3, oder?

Alles was HmIP angeht läuft über den HmIP-Server, und der ist Closed Source, d.h. da kann nur eQ-3 was dran ändern. Sie akzeptieren Bugmeldungen aber ausschließlich (manchmal), wenn man eine Original CCU ohne jegliche Add-Ons verwendet und das Problem nach Werksreset nachgestellt hat.

[ikarst]

Hallo zusammen,

vielen Dank für die rege Diskussion.

Wie geschrieben lief alles problemlos vor dem Update mit einem Duty Cycle zwischen 20 und 30. Ich habe alle Programme durchgesehen. Da gibt es nirgendwo "bei Aktualisierung" sondern immer "bei Änderung". Ich hab viele Programme. Alle neu zu erstellen schaffe ich nicht. Jedenfalls jetzt nicht. RaspberryMatic ist ein tolles Projekt und wie immer bei Open Source und privatem Engagement muss man dankbar sein für alles, was man bekommt. Einzelfälle sind doof, aber so ist es eben. Für mich ist es grad schwierig, denn der hohe Duty Cycle hebelt viele Funktionen aus. Die Räume überheizen, nur so als Beispiel. Also muss nun vieles wieder "manuell" laufen. Das ist ärgerlich, in Anbetracht der hohen Kosten für die Home Automation. - Vielleicht wird es ja beim nächsten Update wieder besser.

Das mit dem mehrmaligen Reboot und alten Versionen hab ich nicht richtig verstanden. Ich vermute, es geht darum, dass der Update-Prozess vielleicht irgendwo geklemmt hat und ich nun versuchen soll, durch nochmaliges Update das ganze zum Abschluss zu bringen? - Ich versuche, die Nachrichten zu verstehen und eine Vorgehensweise zu erkennen und es dann mal zu machen, wenn die Tage ruhiger werden demnächst.

Danke & VG
ikarst

[ikarst]

Nachtrag...

ich habe die ersten Antworten nochmal genauer gelesen und verstanden, dass die Sache mit den alten Versionen und x-mal booten eher nichts bringen wird. Dann streiche ich das erst mal von der ToDo-Liste und warte auf die nächste Version.

Danke nochmal!

[Xel66]

Für mich ist es grad schwierig, denn der hohe Duty Cycle hebelt viele Funktionen aus.

Das ist nun mal so und die Ursache liegt mit relativ hoher Wahrscheinlichkeit in Deinem Umfeld (Geräteeinstellungen/Programmierungen). Es reicht nicht, nur zu schauen, ob irgendwelche Trigger auf "bei Änderung" stehen. Das Triggern von Programmen ist komplex und bei einer geeigneten Auswahl kann man auch ein "bei Aktualisierung" selbst verursachen (Abfrage von Komplementärzuständen innerhalb eines Progamms). Werden dann "viele" Geräte dadurch angesteuert, ohne deren Zustand abzufragen, dann treibt sowas auch den Duty Cycle. Als Beispiel sei nur mal ein Programm, welches von beiden Zuständen einer boolschen Systemvariable getriggert wird (z.B. in einem WENN und einem SONST WENN). Steuert dieses dann mehrere Aktoren an ohne deren Zustand noch mal abzufragen, geht der DC nach oben. Gerade auch in komplexeren Programmen können zyklische Trigger auch den DC treiben (wenn man z.B. die Übermittlung von Soll- oder Isttemperaturen von Thermostaten, die ihre Status alle drei Minuten übermitteln, als Trigger hat). Und an solchen schlechten Programmen ändert auch ein Firmwareupdate nicht.

Jetzt kommt das Argument: "Ja, aber bis zu einem Update hat es doch funktioniert". Möglich und bis zu einem gewissen Grad auch wahrscheinlich. Da aber bei einem Systemstart Status neu gesetzt werden können vormals inaktive Programme (weil ein Status z.B. während des normalen Betriebes durch äußere Umstände gesetzt wurde) zur Ausführung angetriggert werden. Man hatte vorher einen statischen Zustand. Das kann sich aber durch einen Neustart ändern, weil dort z.B. andere Status gesetzt wurden (z.B. Defaultwerte wie 0°C oder Fensterkontakt geschlossen oder Statusabfragen von netzversorgten Aktoren).

Um dieses zu analysieren schaut man unter "Status und Bedienung/Programme" nach den Zeitstempeln und prüft deren Ausführungszeitpunkte auf Plausibilität. Wenn z.B. ein Programm dass außentemperaturgetriggert die Heizperiode umschaltet alle paar Minuten die Systemvariable (Zeitstempel prüfen!) setzt (die dann ggf. im gleichen Takt alle Thermostate auf Automatik schaltet), dann geht der DC logischerweise auch hoch. Möglichkeiten der Diagnose hat man viele und auch Einflussmöglichkeiten (fragliches Programm deaktivieren und DC beobachten). Deshalb muss aber nicht ein Programm auf "bei Aktualisierung" stehen. Sowas wäre eine mögliche Ursache, aber wie eben beschrieben, kommt das nicht als alleinige Ursache infrage.

Gruß Xel66

[ikarst]

Danke, Xel66, für Deine sehr ausführliche Antwort! Ich werde nochmal alles durchsehen.

Nur soviel: Die Programme sind seit Monaten fast unverändert. Es gab schon mehrere Updates mit Reboots. Außerdem mache ich 1x die Woche per Programm & Timer ein Reboot des RaspberryMatic. Das System hat also nie unendlich Zeit, sich auf dem "erreichten Status" einzupegeln.

[Xel66]

Außerdem mache ich 1x die Woche per Programm & Timer ein Reboot des RaspberryMatic.

Grrrr.. Warum das denn? Ich hatte schon uptimes von über 300 Tagen, bis ich meinte, mal wieder ein Update mitnehmen zu müssen, weil ein nützliches Feature hinzugefügt wurde.

Das System hat also nie unendlich Zeit, sich auf dem "erreichten Status" einzupegeln.

Brauch es auch nicht. Im Normalfall sollte nach spätestens einer Stunde bei korrekter Programmierung wieder alles i.O. sein. Wenn nicht, dann stimmt was an der Programmierung oder Konfiguration nicht. An so Hypothesen, wie kaputte Updates für irgendwelche Hardware glaube ich eher nicht. Dafür fehlen einfach die Nachweise, dass das so ist. Irgendwelche gefühlten Veränderungen, die nicht reproduzierbar sind, sind eher keine Belege. Auch die angebliche Veränderung der Empfangsfeldstärke (RSSI) halte ich eher für Voodoo. Warum sollte sich die Feldstärke von anderen Geräte verändern, wenn an diesen nichts verändert wurde. Die Empfangsfeldstärke ist sehr stark abhängig vom Standort des jeweiligen Empfängers von Daten. Und im HF-Bereich reicht manchmal auch schon eine Ortsveränderung von wenigen Zentimetern aus. Von anwenderseitigen Modifikationen am Empfangssystem (Antenne) will ich noch nicht mal reden.

Gruß Xel66

[Martin62]

Also ich kann nur immer wieder bei solchen Problemen auf den AskSinAnalyzer hinweisen. Gerade bei dieser Situation ist alles andere Rätselraten. Gibt es auch schon als Fertiggerät. (Zurzeit wohl nicht!)
viewtopic.php?f=76&t=56395
viewtopic.php?f=76&t=56214

[twoxx]

hast du mehrere hmip-steckdosen als "router" aktiviert?

wenn ja, dann daktivier mal alle router (am besten auch bei allen hmip-geräten die routing-funktion deaktivieren) und dann schau ob der dc runter geht. wenn ja, dann nur da wo es unbedingt nötig ist den router aktivieren und auch nur bei den geräten die routing-funktion aktivieren.

ansonsten bliebe wie gesagt die möglichkeit mit deiner zweiten sd-karte die firmware 3.51 2x durchzubooten und dann die sd-karte mit der voll eingerichteten version 3.53 wieder zu booten.
dadurch wird das funkmodul auf die alte funkmodul-firmware zurückgesetzt und dann nochmal neu mit der aktuellen funkmodul-firmware geflasht