Nach Update auf 3.73.9.20240130 Probleme mit Duty Cycle

[hm4jojo]

Verständnisfrage!
Warum braucht CCU viel mehr DC (39,5 %) beim Senden an Thermostat-Wohnzimmer (7,3 %) als umgekehrt?
Tortengrafik listet ferner viel mehr Geräte auf.

Mangels Beobachtungserfahrungen, kann ich das nicht einschätzen.
Ich werde im Forum auch nicht richtig darüber fündig.

Auch werden Nummer als Geräte aufgelistet, die auch was senden. z.B. "6577073" sendet einen "HmIP Multicast All Devices".
Aus Neugier habe ich mal in meinen 10 Gruppen zyklische Statusmeldung rausgenommen.
Prompt ist der DC Wert auf 81% und Carrier senses auf 40% gestiegen.
30 Minuten später ist DC 40 % und CS 0%!
In den 5h schwangt DC zwischen 35 - 55 % und CS ist in der Regel 0 % !
Durch Zufall konnte ich 3 x CS mit 1 bis 3 % beobachten.

[stan23]

Die Frage ist, wie kann ich verifizieren, dass RaspberryMatic DC korrekt ermittelt?

Das kannst und musst du nicht verifizieren.
Jeder Sender ist für seine Einhaltung des DutyCycle zuständig. Die Zentrale (bei dir die RaspberryMatic) ist damit die Primärquelle.
Den genauen Algorithmus kennt nur eQ-3 weil er in der Firmware des Funkmoduls steckt.

Wo ist denn der Unterschied zwischen AskSin und RaspberryMatic bei der DC Ermittlung?

Nachdem die Berechnung im Funkmodul nicht offengelegt ist, kann der AskSinAnalyserXS da nur seine eigene Interpretation berechnen und anzeigen.
Die alte Diskussion dazu ist hier:
https://github.com/jp112sdl/AskSinAnalyzer/issues/46

Verwende die DC-Berechung des AskSinAnalysers lieber nur um die Verhältnisse rauszufinden und nicht die absoluten Zahlen.

Mit der verwendeten Antenne hat es übrigens nichts zu tun. Die hätte nur einen Einfluss wenn der Analyser sehr weit von der Zentrale entfernt steht und nicht alle ihre Telegramme hören kann.

Warum braucht CCU viel mehr DC (39,5 %) beim Senden an Thermostat-Wohnzimmer (7,3 %) als umgekehrt?

Telegramm ist nicht gleich Telegramm.
Wenn die Zentrale geziehlt ein Batterie-Gerät anfunkt, schickt sie zuerst einen Wakeup-Burst um es (und auch alle anderen Geräte) zu wecken. Dieser Burst dauert sehr lange und frisst damit einen größeren Teil des DutyCycles als ein "normales" Telegramm ohne Burst.

[MrR]

so, nach langem Suchen habe zumindest ich mein Problem des Dutys gefunden. Schuld war ein PSM, warum auch immer (er lief fünf Jahre ohne Mucken) ist der nach dem letzte Firmware-Update der CCU (Raspberrymatic) wohl durchgedreht und auf Dauersenden gegangen, allerdings brauchte er wohl für den Fehler "Anlaufzeit". Selbst ein Reset etc hat diesen nicht mehr beruhigt. Er liegt jetzt im Elektroschrott.

Trotzdem Danke an alle, auch für die Geduld. Immer wieder super hier ! Und sorry für mein Zwidernsein....

[MrR]

nun habe ich das gleiche Problem mit dem neuen PSM.
Er bekam die aktuelle Firmware aufgespielt und zack ging der Duty nach oben.
Seltsamerweise läuft ein anderer PSM mit selber Firmware und identischen Einstellungen ohne mucken.




**EDIT er hat sich (gott sei dank) wieder beruhigt

[frd030]

Bitte mal einen Screenshot der Geräteeinstellungen posten.

[hm4jojo]

nun habe ich das gleiche Problem mit dem neuen PSM.
Er bekam die aktuelle Firmware aufgespielt und zack ging der Duty nach oben.
Seltsamerweise läuft ein anderer PSM mit selber Firmware und identischen Einstellungen ohne mucken.

**EDIT er hat sich (gott sei dank) wieder beruhigt

Interessant!
Da sollte ich mal alle auch vom Strom abziehen und nach der Pause wieder Strom geben.
Bei den BWTHs, welche alle auch so um die 3% Duty Cycle "produziert" haben, ging in der der Zentrale die Duty Cycle auch sehr hoch!
Siehe Screenshot!
D.h. nach dem Update kamen Hinweise auf neue Geräte-Firmeware.
Vlt. hat das uns zu einem Fehlschluss geführt und wir haben alle das neue RhaspberryMatic Update verdächtigt?
Auch wenn mit der Zeit alle sich "beruhigt" haben, ging es irgendwann wieder los. Spätesten nach einem CCU3 Reboot.
Die BWTHs, "verbrauchten" danach immer noch 3% in der Regel.

Nachdem ich die BWths mal (per Sicherung) vom Strom genommen habe und nach der Pause wieder auf Strom gesetzt habe, sind die Durty Cycle bei allen BWTHs unter 1%.

Ich frage mich, warum z.B. die Zentrale (hier RPI-MOD....) sehr viel Duty Cycle (rd. 8% von 11,4%) in Anspruch nimmt?
Oder woher kommt der Rest, wenn man die Werte für alle Geräte (3,33%) zusammenrechnet?
Siehe auch 2. Screenshot!

[MrR]

also bei mir war tatsächlich (wie erwähnt) ein PSM defekt, warum der allerdings genau NACH dem letzten Raspberrymatic-Update zum spinnen angefangen hat, kein Ahnung. Davor lief er jahrelang problemlos, trotz Updates, Neustarts, etc....

Der neue PSM, welcher eine alte Firmware hatte, hatte sich erst nach einem Tag/Nacht nachdem sein Firmware-Update fertig war, beruhigt. Seltsam, sonst geht sowas immer recht zügig, aber egal.

Zuerst hatte ich die PSMs auch vom Strom genommen und nen halben Tag gewartet, aber da tat sich erstmal nix. Hilfreich, allerdings arbeit, da ich kein Asksin und co habe, war am Ende einfach klassisch alles komplett stromlos zu machen, nicht nur die hauptverdächtigen batteriebetriebenen Geräte, sondern alles. Alle Stecker gezogen, BSMs, FSMs ausgebaut....Programme komplett deaktiviert und zwei Tage gewartet bis der Duty der CCU komplett auf null/eins gesunken war. Danach, ohne aktivierte Programme, immer ein Raum nach dem anderen wieder in Betrieb genommen, mit jeweils einem Tag Abstand und Test mit Neustart. So habe ich den Hundling dann gefunden. Kaum war der eingesteckt, zack 60 - 90 %.
Warum nicht beim ersten mal der Duty runter ging und warum er plötzlich spinnte, ist und bleibt ein Rätsel für mich.


Aktuell dümpelt wieder alles gemütlich bei rund 12% vor sich hin.

Grüße
MrR