DutyCycle Auslöser ausfindig machen und darstellen/anzeigen

[tis-cs]

Is your feature request related to a problem? Please describe.
Ich erhalte ständig Alarme, da meine CCU in den DutyCycle läuft. Ich logge zwar die Uhrzeiten, aber letztendlich sind die Zeiten nicht eindeutig einem Programm etc. zuzuordnen. Anhand der DutyCyle Übersicht auf der Startseite kann ich erkennen, dass nur die CCU3 und nicht das originale Lan Gateway oder das RapsberryMatic Gateway betroffen sind.

Describe the solution you'd like
Es wäre perfekt, wenn man in der Geräteübersicht sehen könnte, ob ein Gerät den DutyCycle ungewöhnlich stark nach oben schraubt

Describe alternatives you've considered
Eine simple Auflistung unter dem jeweiligen DutyCycle Balken, welches Gerät vermeintlicher Verursacher ist.

Additional context

[jens-maus]

Dies ist ein bereits geplantes Feature das aber sicherlich noch eine weile dauern wird bis das überhaupt so technisch möglich ist, denn momentan gibt es keinen mir bekannten weg technisch herauszufinden welches Gerät wieviel DutyCycle-Last auf der CCU verursacht. Es sind also dafür Änderungen von eQ3 in Hauptkomponenten (rfd, multimacd, etc.) notwendig damit so eine Auswertung überhaupt praktikabel möglich ist.

Nichtsdestotrotz wird daran quasi gearbeitet, es kann aber wie angedeutet schon einige Zeit dauern bis das überhaupt umgesetzt werden kann.

[tis-cs]

Das habe ich mir schon gedacht. Aber gut, dass es generell schon in Planung ist, auch wenn man vom Hersteller abhängig ist.

Dann werde ich wohl so lange damit leben müssen oder versuchen mit nem SDR den Fehler zu finden :)

Danke schon mal für die schnelle Antwort!

[jp112sdl]

@tis-cs Schau dir auch mal das an: https://github.com/jp112sdl/AskSinAnalyzer
bzw. https://homematic-forum.de/forum/viewtopic.php?f=76&t=51161

[friedpa]

Hallo Jérôme,
gibt es den Analyser auch irgendwo fertig käuflich zu erwerben? Bin zwar gut im löten, aber bei den SW dingen vor 20 Jahren stehen geblieben .....
Liebe Grüße

[pantau1962]

Ein Fertiges Gerät würde ich auch gern kaufen. Mir fehlt einfach die Zeit.

[jp112sdl]

Fertiggeräte gibt es leider nicht.
Programmieren können muss man aber auch nicht, denn der Quellcode ist bereits fertig. Man muss ihn lediglich auf den Arduino Pro Mini sowie den ESP32 flashen.

Aber: Fragt mal ganz höflich bei @stan23 an.
Er hat eine Platine designt und mit etwas Glück hat er noch bald wieder welche, die er verkauft.

[tis-cs]

Die Platine würde mich tatsächlich auch interessieren. Den Krams habe ich gestern mal auf AliExpress geklickt. Denke mal, dass ich dann in vier bis sechs Wochen flashen und löten kann um endlich der faulen Zahn zu finden. EDIT: sorry, war unterwegs und habe einfach als Mail geantwortet. Habe nicht dran gedacht, dass under Server noch Unmengen an Zeug dranhängt ;) Aber danke @jp112sdl für den dezenten Hinweis :)

[jp112sdl]

Wenns irgendwelche Probleme mit dem Nachbau gibt, einfach einen Thread in der Selbstaukategorie erstellen oder (wird dann aber langsam unübersichtlich) die Frage an den bestehenden anfügen.

P.S.: Ein Mail-Reply mit 2% Content und 98% AW+Signatur ist in Github auch unhübsch 🤓 ;)

[Echsecutor]

Wie ist denn hier der Stand? Ist im letzten Jahr etwas passiert? Ich habe auch das Problem, dass der Duty Cycle regelmäßig auslöst und würde offensithctlich gerne herausfinden warum. ;)

[Ronie80]

Hi zusammen,
bei der Frage möchte ich mich gerne anschließen, da heute aus heiterem Himmel der DutyCycle auf 99 Prozent innerhalb weniger Minuten hoch geschossen ist und ich keinerlei Ansatz für die Ermittlung des Übeltäters habe. Ich habe zwar keine sooo riesige Anlage, aber über 50 Aktoren sind es mittlerweile doch... selbst da den richtigen herauszufinden dürfte ein aufwendiges Glücksspiel sein. 🤪🥴
Und wenn ich schon mal dabei bin hier zu schreiben - etwas OT aber ein herzliches Dankeschön an Jens für die Arbeit und das tolle RaspberryMatic Projekt!

[jp112sdl]

da den richtigen herauszufinden dürfte ein aufwendiges Glücksspiel sein

Hast du dir den hier bereits weiter oben erwähnten AskSinAnalyzer mal angeschaut...?

[Ronie80]

'voranstehender Ratschlag eines Lösungsversuchs vorsichtshalber entfernt'

@jp112sdl
Ich hab's kurz überflogen. Das scheint eine feine Sache zu sein, die ich mir nun im Zuge dessen auf alle Fälle noch genauer anschauen werde. Macht auf alle Fälle Sinn sich damit zu beschäftigen, wenn man kein akutes Problem damit hat 😉 und sich ein wenig einlesen und sich die Zeit zum Basteln einteilen kann. Wenn so ein Problem aber ansteht und man einige Komponenten in Betrieb hat und dieses System zum gewohnten Komfort (und teils benötigten Wohnungs'gegenstand') geworden ist, dann muss das Problem idealerweise zu lösen oder stark einzugrenzen sein, bevor man eine Bastelarbeit und Lieferung per Post abwarten muss. 🙈
Ich werde mir den ELV Funk-Analyser EQ3-RFA mal genauer anschauen, um in Zukunft ggf. eine weitere Möglichkeit zur Ortung solcher Probleme zur Hand zu haben (was meint Ihr dazu?). Und natürlich den AskSinAnalyzer für die eigene RaspberryMatic. Danke nochmals für die Info!

[jens-maus]

@Ronie80

Die Schalt-Mess-Steckdose ausgesteckt - seither sinkt der DC wieder brav im gleichen Rahmen, wie er vorhin gestiegen ist (natürlich mit einstündiger Verzögerung). Das dürfte also der Übeltäter gewesen sein. Meine verwendete Firmware: "3.55.5.20201226". Eventuell kann das jemand bei solchen Problemen nachvollziehen. Wäre zumindest eine schnelle Selbsthilfe.

Wenn das so ist, dann bedeutet das, dass dieser PSM entweder nen Schuss hat oder du ihn schlichtweg falsch konfiguriert hast. Vmtl. (wie schon so oft bei Nutzern passiert) die Triggerschwellen zu gering eingestellt sodass der PSM andauernd sich genötigt fühlt eine Nachricht an die CCU zu schicken um die neuen Messdaten mitzuteilen. Das führt zu einem überladen des DC auf der CCU und dann irgendwann (wie bei dir) auch zu einem überladen des DC des PSMs selbst (deshalb auch das gelbe DUTYCYCLE in der Geräteliste! Ergo: Benutzungfehler!

[Ronie80]

Hmmm... Benutzungsfehler? Durch Belassen der Standardeinstellungen, weil der Aktor in Verbindung mit einem Bewegungsmelder nur als Schranklicht verwendet wurde und die Messwerte des Stromverbrauchs nie interessant waren aufgrund des LED-Lichts im Schrank und der verhältnismäßig seltenen Benutzung? Naja 🤷‍♂️ dann nehme ich das mal so hin und halte mich vorsichtshalber allgemein mit Ratschlägen zurück.
Ich werd an mir arbeiten. ;)

[12-uhr-mittags]

Hallo,
Ihr seid nicht die Einzigen die da ein Thema haben.
Seit ca. 2 Wochen knallt bei mir der Duty Cycle morgends durch die Decke.
Was dann dazu führt dass andere Geräte nicht mehr erreichbar sind und ich dann noch mehr Fehlermeldungen bekomme.
Ich habe eine Seite bei "Verdrahtet" gefunden:
https://www.verdrahtet.info/2021/01/29/duty-cycle-probleme-so-bekommst-du-sie-in-den-griff/#comment-158832
Aber ganz ehrlich, ich würde mir so ein Teil gerne fetig kaufen statt mich stundenlang mit Jund forscht zu beschäftigen bis das am Laufen ist.

[datenbank-projekt]

Hallo,

nur so eine Idee ... als neuerdings Betroffener (dutycycle super schnell auf 99% und nichts geht mehr :-( ):
Wäre es nicht möglich, je Gerät einen internen Zähler zu bauen der erhöht wird, wenn das Gerät sendet - und einen CCU Zähler der mitzählt an welches Gerät zurückgesendet wird (jeweils mit Zeitstempel)? Damit ließe sich doch erkennen, wann das Zählenins Stocken gerät bzw. welches Gerät noch auf Antwort wartet.

[12-uhr-mittags]

Aus meiner Sicht ist es der größte Nachteil des HM Systems, dass es keinerlei interne Kontrollmöglichkeit gibt,
um festzustellen wo ein erhöhter DC her kommt.
Ich habe im letzten Jahr mein gesammtes System nieder gebrannt und von ganz neu Schritt für Schritt über ein paar Wochen wieder aufgebaut, um heraus zu finden, wo das Problem lag.
Und ich bin mit Sicherheit nicht der einzige Anwender wo es ein Problem mit dem DC gibt.
Schließlich ist der DC integraler Bestandteil der Funk Lösung.

[jp112sdl]

Eine Idee wäre, den seriellen Datenstrom zwischen multimacd und Funkmodul mitzulesen, die SEND Pakete (0x03) zu filtern und aus deren Länge dann den DC-Anteil zu errechnen (Überlegungen dahingehend gabs es mal beim jp112sdl/AskSinAnalyzer#46

Alex hat in seinem generic_raw_uart Kernelmodul ja sogar schon die Möglichkeit geschaffen, alles mitlesen zu können:
echo on > /sys/devices/virtual/raw-uart/raw-uart/dump_traffic

Viele DC Probleme sind jedoch auf schlecht durchdachte (WebUI-)Programme oder externe Tools zurückzuführen.
In der gesamten Homematic-Welt ist es jedoch nicht vorgesehen, dass auf der gesamten Strecke vom Auslöser bis zum Senden eine Art Absender-Token mitgegeben wird, aus dem man ableiten könnte, wer Initiator der Aussendung war.

[12-uhr-mittags]

Ich denke mal, der DC wird ja grundsätzlich in der CCU3 angezeigt.
Das heisst, er wird auch gelogged.
Also kommt ja irgedwo ein Wert daher.
Das mit den schlecht durchdachten Programmen ist aus meiner Sicht auch ein Thema.
Das hat aber auch etwas mit den jeweiligen Geräten zu tun, die in Ihrer Bandbreite sehr unterschiedlich funktionieren.
Ich hatte da auch schon meine Probleme weil z.B. nicht IP Geräte teilweise andere Funktionalitäten
zur Verfügung stellen wie IP Geräte. Dementsprechend hat dies Auswirkungen auf Programme.
Wenn sich Otto Normalverbraucher nicht 7 x 24 damit beschäftigen kann oder will, dann kann man dem Kunden keinen Vorwurf machen. Es ist ja schließlich so, dass es sinnvoll ist, von Seiten der Programmierung die Gefahrenstellen zu eliminieren. Ein Mobiltelefon war zu Zeiten von Blackberry mit dutzenden von Parametern zu konfigurieren. Heute ist das eliminiert und jeder kann sein Mobiltelefon einrichten.
Und ja, es ist einfach das auf den Kunden abzuchieben.
Nur wie wir alle bereits gelernt (oder nicht ?) haben, wir am Ende des Tages derjenige den Standard setzen,
der in der Lage ist, das einfachste System zur Verfügung zu stellen. (Siehe Apple)
Und in diesem Bezug ist EQ3 noch nicht aus dem Schneider.

[jp112sdl]

Ich denke mal, der DC wird ja grundsätzlich in der CCU3 angezeigt.
Das heisst, er wird auch gelogged.
Also kommt ja irgedwo ein Wert daher.

Der Wert wird direkt aus dem Funkmodul (Hardware) abgefragt, weil er dort auch anhand der tatsächlich anfallenden Sendezeit berechnet wird. So ist es gesetzlich vorgegeben.

[MichaelN0815]

Am Ende ist es ganz einfach

1. Batterien prüfen /auszutauschen
2. Programmierung prüfen mit https://homematic-forum.de/forum/viewtopic.php?f=31&t=68913

[jp112sdl]

@MichaelN0815 "C26 prüfen" fehlt noch ;-)

[datenbank-projekt]

@jp112sdl Was meinst du ("c26")?

[jp112sdl]

Ein Kondensator, der gern mal kaputt geht und das Gerät u.U. in eine Dauer-Reboot-Schleife bringt.
https://www.google.com/search?q=homematic+c26+site:homematic-forum.de

[datenbank-projekt]

Hallo,

danke für die Hinweise. Ich habe mit CCU Historian schon ganz gute Ergebnisse erhalten. Dazu habe ich mit https://www.amazon.de/nanoCUL-CC1101-Knick-Antenne-iobroker-Adapter-868MHz/dp/B09QJZ9KR4 und der zugehörigen Software https://github.com/psi-4ward/AskSinAnalyzerXS dem Problem nachgehen können: Es schien tatsächlich der Kondensator eines Tasters zu sein. Den habe ich von allen Programmen getrennt und dann ausgebaut - siehe da, keine DutyCycle Probleme mehr.

Vielleicht ist es ein Tipp über CCU Historian zu gehen wenn das Problem besteht.

[smartmatic]

Hallo,

eine simple Frage / Anregung.
Ich habe vor Raspberymatic FHEM genutzt. Dort war es möglich auszuwerten welche Geräte, wie viele Messages gesendet haben. Die mit einer extrem hohen Anzahl waren dann i.d.R. die Geräte welche den Duty Cycle nach oben geschraubt haben. Fehlersuche war so deutlich einfacher bzw. das identifizieren der potentiellen Geräte.

Wäre solch ein Ansatz auch für Raspberymatic denkbar?