Duty Cycle läuft Amok

Einrichtung, Nutzung und Hilfe zu RaspberryMatic (OCCU auf Raspberry Pi)

Moderatoren: jmaus, Co-Administratoren

rucksman007
Beiträge: 82
Registriert: 04.11.2018, 13:17
Hat sich bedankt: 4 Mal

Duty Cycle läuft Amok

Beitrag von rucksman007 » 05.06.2020, 17:15

Seit ein paar Tagen läuft mein Duty Cycle Amok und befindet sich stets knapp unter 100%. Geändert habe ich davor nichts an Programmen o.ä. Sämtliche Heizkörperthermostate zeigen "Gerätekommunikation gestört" bzw. "Gerätekommunikation war gestört". Bei den alten HM-CC-RT-DN ist es immer "war gestört", die Meldung kann ich auch einfach wegklicken. Sie kommt aber wieder, sobald sich in dem Redmatic-Flow irgendwas tut, was auch die Heizkörperthermostate betrifft. Bei den neuen eTRVs ist es noch übler, dort steht permanent "Gerätekommunikation gestört", die Meldung lässt sich auch nicht wegklicken. Bei einigen Thermostaten, die weiter weg sind, würde ich sporadische Probleme verstehen, aber es betrifft auch Thermostate, die sich zB grade mal einen Meter neben der CCU befinden. Wo kann ich denn da ansetzen und Ursachenanalyse betreiben? Wie gesagt: Das Problem habe ich erst seit ein paar Tagen, ohne dass ich irgendetwas verändert hätte. Ein Neustart hat auch nichts gebracht.

Was mir auch auffällt: Wenn ich am Heizkörperthermostat etwas ändere, kommt die Änderung in der CCU in ein oder zwei Sekunden an, obwohl in den Servicemeldungen nach wie vor "Gerätekommunikation gestört" steht. Will ich im GUI etwas ändern, passiert gar nichts. Keine Reaktion nach einem Klick auf irgendein Element.

Xel66
Beiträge: 7102
Registriert: 08.05.2013, 23:33
Wohnort: Nordwürttemberg
Hat sich bedankt: 32 Mal
Danksagung erhalten: 234 Mal

Re: Duty Cycle läuft Amok

Beitrag von Xel66 » 05.06.2020, 18:16

Wahrscheinlich läuft eines Deiner Progamme Amok. Der Fehler wirkt sich vielleicht jetzt erst aus, weil Du vielleicht die Außentemperatur mit verwurstelst hast. Mangels Kenntnis Deiner Programmierung kann man da nur schlecht raten. Dein System läuft wegen massiver Kommunikation in den Duty Cycle. Dass da Kommunikationsstörungen anstehen, ist nachvollziehbar.

Dass Änderungen am Thermostat an der CCU ankommen liegt einfach daran, dass nur die CCU im Duty Cyle festhängt und deswegen dem Thermostat nicht antworten kann. Empfangen kann sie sehr wohl. Auch die nomalen nicht quittierpflichtigen Broadcasts der Thermostate. Es liegt also mit relativ großer Wahrscheinlichkeit an Deiner Programmierung oder Du hast einen Aktor, der die CCU in den Duty Cycle treibt. Hatte ich vor zwei Tagen mal. Da war es ein IP-Aktor, der auf die CCU per Funk eingetrommelt hat. Und der hat noch nicht mal was zu tun, da er einfach nur mit Netzspannung versorgt ist, um keine Servicemeldung zu generieren. Nur ein kurzzeitiges Trennen von der Netzspannung konnte ihn wieder besänftigen. Rausbekommen habei ich das recht schnell mit dem AskSin Analyzer. Den hatte ich mir nur wegen des "Auch-Haben-Wollen" zugelegt und jetzt den wirklich ersten Anwendungsfall gehabt. Kann auch ein Batterieaktor oder -sensor sein, bei dem die Batterien am Ende sind und er sich zum "Babbling Idiot" gewandelt hat und so die CCU vollmüllt.

Gruß Xel66
---------------------------------------------------------------------------------
358 Kanäle in 141 Geräten und 114 CUxD-Kanäle in 24 CUxD-Geräten:
274 Programme, 265 Systemvariablen und 144 Direktverknüpfungen,
RaspberryMatic Version 3.51.6.20200420
Testsystem: CCU3 3.49.17
---------------------------------------------------------------------------------

rucksman007
Beiträge: 82
Registriert: 04.11.2018, 13:17
Hat sich bedankt: 4 Mal

Re: Duty Cycle läuft Amok

Beitrag von rucksman007 » 05.06.2020, 18:53

Danke für Deine Antwort. An der Programmierung hab ich nichts geändert, und der Status der Thermostate ist eigentlich seit Wochen gleich. Im Prinzip läuft da nur ein Flow, der alle 30 Minuten ein paar Zustände abfragt. Da sich an den Einstellungen nichts ändert, sollte auch die Kommunikation auf ein Minimum beschränkt sein, weil ja nichts geändert werden muss.

Batterien waren auch mein erster Anlaufpunkt, aber die sind fast neu. Deiner Antwort nach ("Rausbekommen habei ich das recht schnell mit dem AskSin Analyzer") finde ich über die CCU nicht raus, was das Problem verursacht?

Xel66
Beiträge: 7102
Registriert: 08.05.2013, 23:33
Wohnort: Nordwürttemberg
Hat sich bedankt: 32 Mal
Danksagung erhalten: 234 Mal

Re: Duty Cycle läuft Amok

Beitrag von Xel66 » 05.06.2020, 20:28

rucksman007 hat geschrieben:
05.06.2020, 18:53
... finde ich über die CCU nicht raus, was das Problem verursacht?
Die Möglichkeiten der CCU sind da sehr eingschränkt. Im HM-Manager von hobbyquaker kannst Du Dir das Funkprotokoll ansehen und dort mögliche häufige Kommunikationspartner ausmachen. Danach kannst Du auf die Suche gehen, in welchen Programmen diese verwendet werden. Die WebUI würde Dir noch die Möglickeit bieten, die Zeitstempel der Programmausführungen anzusehen, und dort häufig getriggerte Programme zu identifizieren. Da Du aber auf eine andere Logikengine setzt, kann ich dir da nicht weiterhelfen.

Gruß Xel66
---------------------------------------------------------------------------------
358 Kanäle in 141 Geräten und 114 CUxD-Kanäle in 24 CUxD-Geräten:
274 Programme, 265 Systemvariablen und 144 Direktverknüpfungen,
RaspberryMatic Version 3.51.6.20200420
Testsystem: CCU3 3.49.17
---------------------------------------------------------------------------------

chka
Beiträge: 1900
Registriert: 13.02.2012, 20:23
System: Alternative CCU (RaspberryMatic etc.)
Hat sich bedankt: 43 Mal
Danksagung erhalten: 21 Mal

Re: Duty Cycle läuft Amok

Beitrag von chka » 05.06.2020, 21:00

wenn es keine aktor ist der durch dreht schau dir mal unter Status -> Programme welches Programm ggf zu oft startet.

bei mir hat die tage ein Programm den dc in die höhe getrieben was ich vor Monaten als es noch kalt draußen war angepasst habe.
der kleine Fehler hat alle paar Sekunden in die heitztermostate eine feste Temperatur reingeschrieben diese Aktualisierung war das problem.

nach dem beheben des Problems:
Bildschirmfoto 2020-06-03 um 19.30.24.png
Debmatic - CuL V2 868mHz- CuxDemon - PioTek Tracker - Velux und Somfy Anbindung- io.Broker aufm ESX 6.7
Keine Support PNs Danke!

plotzkella
Beiträge: 91
Registriert: 26.06.2015, 19:56
Hat sich bedankt: 5 Mal
Danksagung erhalten: 3 Mal

Re: Duty Cycle läuft Amok

Beitrag von plotzkella » 05.06.2020, 21:02

Ich hatte vor kurzem ein ähnliches Problem, siehe hier.

Darin kannst Du Dich ganz gut in die Möglichkeiten der konventionellen Fehlersuche einarbeiten - aber das einzige, was wirklich hilft ohne selbst "durchzudrehen" ist ein Asksin-Analyzer. Mittlerweile habe ich dank stan23 einen halbwegs vernünftig am Laufen und erstmalig (nach über 6 Jahren Homematic) einen relativ guten Überblick sowie ein grundlegendes Verständnis meines Funk-Netzwerks.

Aber zurück zum Thema und einer möglichen "Soforthilfe": Deaktiviere Schritt für Schritt Programme und schaue, wie sich der Duty-Cycle entwickelt. ACHTUNG: Nach dem Deaktivieren eine (!) Stunde warten, da der DC wohl stündlich neu berechnet / gebildet wird. Das wusste ich bei der Fehlersuche nicht und das hat bei mir für zusätzlichen Frust gesorgt.

Parallel dazu würde ich alle Sensoren / Aktoren z.B. in 10er-Schritten außer Betrieb nehmen, d.h. Batterien herausnehmen oder vom Stromnetz trennen. Bei mir war es ein Funk-Aktor, der Amok gelaufen ist...

Auch hier wieder eine Stunde abwarten, ob sich der DC reduziert.

Das Durchsehen von Protokollen hat mir jedenfalls nicht weitergeholfen.
Viele Grüße
Thomas

RaspberryMatic 3.51.6.20200420 @ RPi4 (4GB) mit RPI-RF-MOD & RS485 (HM-Wired)
Anbindungen: Viessmann, Resol, Velux, Harmony, Heytech, Sonoff, Shelly, Vorwerk
AddOns: CUxD mit Highcharts, ioBroker, HVL, pdetect, E-Mail, Drucken

Xel66
Beiträge: 7102
Registriert: 08.05.2013, 23:33
Wohnort: Nordwürttemberg
Hat sich bedankt: 32 Mal
Danksagung erhalten: 234 Mal

Re: Duty Cycle läuft Amok

Beitrag von Xel66 » 05.06.2020, 21:07

Er hat keine WebUI-Programme, so wie ich das verstanden habe. er hat irgendwas Redmatic. Damit helfen die Standardtipps zur WebUI nicht. Ist halt so, wenn man unbedingt auf ein anderes Pferd setzen will.

Gruß Xel66
---------------------------------------------------------------------------------
358 Kanäle in 141 Geräten und 114 CUxD-Kanäle in 24 CUxD-Geräten:
274 Programme, 265 Systemvariablen und 144 Direktverknüpfungen,
RaspberryMatic Version 3.51.6.20200420
Testsystem: CCU3 3.49.17
---------------------------------------------------------------------------------

rucksman007
Beiträge: 82
Registriert: 04.11.2018, 13:17
Hat sich bedankt: 4 Mal

Re: Duty Cycle läuft Amok

Beitrag von rucksman007 » 06.06.2020, 20:47

Xel66 hat geschrieben:
05.06.2020, 20:28
Im HM-Manager von hobbyquaker kannst Du Dir das Funkprotokoll ansehen und dort mögliche häufige Kommunikationspartner ausmachen.
Das wer ich mal versuchen.
chka hat geschrieben:
05.06.2020, 21:00
enn es keine aktor ist der durch dreht schau dir mal unter Status -> Programme welches Programm ggf zu oft startet
Der Weg funktioniert für mich leider nicht, da ich meine Programmlogik in Redmatic ausgelagert habe.
plotzkella hat geschrieben:
05.06.2020, 21:02
aber das einzige, was wirklich hilft ohne selbst "durchzudrehen" ist ein Asksin-Analyzer.
Würde ich definitv mal versuchen (auch um was dazuzulernen), aber mich schreckt auf den ersten Blick ab, dass ich da offenbar selber diverse Bauteile zusammenlöten und verschalten muss. Das gehört leider nicht zu meinen Stärken ... Und mit Arduino habe ich noch dazu noch überhaupt keine Erfahrung.
plotzkella hat geschrieben:
05.06.2020, 21:02
Parallel dazu würde ich alle Sensoren / Aktoren z.B. in 10er-Schritten außer Betrieb nehmen, d.h. Batterien herausnehmen oder vom Stromnetz trennen.
Das werde ich jetzt wohl mal machen müssen.
Xel66 hat geschrieben:
05.06.2020, 21:07
Er hat keine WebUI-Programme, so wie ich das verstanden habe.
Korrekt, ich habe mich aus verschiedenen Gründen für Redmatic entschieden. Alles Gute ist halt leider nie beisammen...

Und damits auch schön kompliziert bleibt: Heute ist der Duty Cycle wie aus heiterem Himmel nie über 20 gestiegen und war die meiste Zeit deutlich darunter, und die einzigen Thermostate, die wie üblich rumzicken, sind die alten HM-CC-RT-DN. Zwei davon sind allerdings recht weit von der CCU weg, der dritte aber nicht und nur durch eine Wand von der CCU getrennt. Aber da die meist nur einmal pro Tag irgendein Problem haben, stört mich das jetzt nicht weiter. Allerdings ist die Fehlersuche dadurch auch nicht einfacher geworden - jetzt wo die eTRVs wieder so arbeiten, wie sie sollen....

Xel66
Beiträge: 7102
Registriert: 08.05.2013, 23:33
Wohnort: Nordwürttemberg
Hat sich bedankt: 32 Mal
Danksagung erhalten: 234 Mal

Re: Duty Cycle läuft Amok

Beitrag von Xel66 » 06.06.2020, 22:01

rucksman007 hat geschrieben:
06.06.2020, 20:47
Heute ist der Duty Cycle wie aus heiterem Himmel nie über 20 gestiegen und war die meiste Zeit deutlich darunter...
Tja, heute ist es wieder kühler draußen und vermutlich arbeitet Dein Programm deswegen wieder "normal". Ich würde mal die entsprechenden Flow suchen.

Gruß Xel66
---------------------------------------------------------------------------------
358 Kanäle in 141 Geräten und 114 CUxD-Kanäle in 24 CUxD-Geräten:
274 Programme, 265 Systemvariablen und 144 Direktverknüpfungen,
RaspberryMatic Version 3.51.6.20200420
Testsystem: CCU3 3.49.17
---------------------------------------------------------------------------------

Baxxy
Beiträge: 975
Registriert: 18.12.2018, 15:45
System: Alternative CCU (RaspberryMatic etc.)
Hat sich bedankt: 93 Mal
Danksagung erhalten: 151 Mal

Re: Duty Cycle läuft Amok

Beitrag von Baxxy » 06.06.2020, 23:50

rucksman007 hat geschrieben:
06.06.2020, 20:47
Würde ich definitv mal versuchen (auch um was dazuzulernen), aber mich schreckt auf den ersten Blick ab, dass ich da offenbar selber diverse Bauteile zusammenlöten und verschalten muss. Das gehört leider nicht zu meinen Stärken ... Und mit Arduino habe ich noch dazu noch überhaupt keine Erfahrung.
Schau dir doch mal meine Flash Anleitung an. Das bekommt eigentlich jeder hin. :wink:

Grüße
Baxxy
Grüße
Baxxy

Antworten

Zurück zu „RaspberryMatic“