Duty Cycle läuft Amok
Moderatoren: jmaus, Co-Administratoren
-
- Beiträge: 138
- Registriert: 04.11.2018, 13:17
- Hat sich bedankt: 7 Mal
- Danksagung erhalten: 1 Mal
Duty Cycle läuft Amok
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.
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.
-
- Beiträge: 14165
- Registriert: 08.05.2013, 23:33
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Nordwürttemberg
- Hat sich bedankt: 585 Mal
- Danksagung erhalten: 1500 Mal
Re: Duty Cycle läuft Amok
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
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
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
-
- Beiträge: 138
- Registriert: 04.11.2018, 13:17
- Hat sich bedankt: 7 Mal
- Danksagung erhalten: 1 Mal
Re: Duty Cycle läuft Amok
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?
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?
-
- Beiträge: 14165
- Registriert: 08.05.2013, 23:33
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Nordwürttemberg
- Hat sich bedankt: 585 Mal
- Danksagung erhalten: 1500 Mal
Re: Duty Cycle läuft Amok
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.rucksman007 hat geschrieben: ↑05.06.2020, 18:53... finde ich über die CCU nicht raus, was das Problem verursacht?
Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
-
- Beiträge: 2483
- Registriert: 13.02.2012, 20:23
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 302 Mal
- Danksagung erhalten: 116 Mal
Re: Duty Cycle läuft Amok
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:
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:
-
- Beiträge: 102
- Registriert: 26.06.2015, 19:56
- Hat sich bedankt: 6 Mal
- Danksagung erhalten: 4 Mal
Re: Duty Cycle läuft Amok
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.
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.65.6.20220723 @ 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
Thomas
RaspberryMatic 3.65.6.20220723 @ 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
-
- Beiträge: 14165
- Registriert: 08.05.2013, 23:33
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Nordwürttemberg
- Hat sich bedankt: 585 Mal
- Danksagung erhalten: 1500 Mal
Re: Duty Cycle läuft Amok
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
Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
-
- Beiträge: 138
- Registriert: 04.11.2018, 13:17
- Hat sich bedankt: 7 Mal
- Danksagung erhalten: 1 Mal
Re: Duty Cycle läuft Amok
Das wer ich mal versuchen.
Der Weg funktioniert für mich leider nicht, da ich meine Programmlogik in Redmatic ausgelagert habe.
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:02aber das einzige, was wirklich hilft ohne selbst "durchzudrehen" ist ein Asksin-Analyzer.
Das werde ich jetzt wohl mal machen müssen.plotzkella hat geschrieben: ↑05.06.2020, 21:02Parallel dazu würde ich alle Sensoren / Aktoren z.B. in 10er-Schritten außer Betrieb nehmen, d.h. Batterien herausnehmen oder vom Stromnetz trennen.
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....
-
- Beiträge: 14165
- Registriert: 08.05.2013, 23:33
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Nordwürttemberg
- Hat sich bedankt: 585 Mal
- Danksagung erhalten: 1500 Mal
Re: Duty Cycle läuft Amok
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.rucksman007 hat geschrieben: ↑06.06.2020, 20:47Heute ist der Duty Cycle wie aus heiterem Himmel nie über 20 gestiegen und war die meiste Zeit deutlich darunter...
Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch
- Baxxy
- Beiträge: 10827
- Registriert: 18.12.2018, 15:45
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 608 Mal
- Danksagung erhalten: 2225 Mal
Re: Duty Cycle läuft Amok
Schau dir doch mal meine Flash Anleitung an. Das bekommt eigentlich jeder hin.rucksman007 hat geschrieben: ↑06.06.2020, 20:47Wü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.
Grüße
Baxxy
Grüße... Baxxy
- Raspberry Pi 4 als Homematic-Zentrale - Tipps und Informationen
- Analysescript für genutzte Funk-Adressen, Funkmodul-Hardware und Zentralen Hardware
- NANO CUL 868MHz - Stick zum AskSin Analyzer XS umflashen (Anleitung für ArduinoIDE unter Windows)
- Firmware Updates für IP-Aktoren / Sensoren... Info's, Tipps und Sonstiges
- CCU funkt nicht - CarrierSense (CS) Probleme erkennen und lösen