Hallo zusammen
ich habe festgestellt, dass wen der HM-MOD-Re-8 offline ist und angesprochen wird, der Duty-Cycle durch die Decke geht. Natürlich ist der HM-MOD-Re-8 ein Auslaufmodell, aber er ist sicherlich noch bei vielen Lesern im Einsatz, bei mir sind es 3.
Wie beschrieben ist das Spannende, dass wenn der HM-MOD-Re-8 OFFLINE ist, aber angesprochen wird, der Duty-Cycle der CCU durch die Decke geht. Die aktuelle Firmware 1.4 kann hier nichts dafür, denn das Gerät ist ja offline. Es muss also auf der zentralenseite ein problem sein.
Wer z.B. in die Ferien reist und vorher mit dem HM-MOD-Re-8 und einer Batteriespeisung ein Projekt umsetzt hat, kann aus der Ferne einen Absturz erleben, welcher (Fernzugang vorausgesetzt) nur mit dem Löschen des Moduls behoben werden kann.
Ich verwende die aktuelle Version der RasperryMatic.
Gruss aus der Schweiz
HM-MOD-Re-8 und der Duty Cycle der CCU
Moderator: Co-Administratoren
-
- Beiträge: 249
- Registriert: 03.01.2014, 09:07
- Hat sich bedankt: 67 Mal
- Danksagung erhalten: 3 Mal
HM-MOD-Re-8 und der Duty Cycle der CCU
Insgesammt 4 Anlagen. Hauptsystem mit 1271 Kanäle in 200 Geräten und 5977 Datenpunkte, verwaltet mit Charly auf einem Asus-Thinkerboard "S", natürlich mit RaspberryMatic. HM, HMIP und Wired im Einsatz.
-
- Beiträge: 5526
- Registriert: 30.05.2019, 11:37
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Chemnitz
- Hat sich bedankt: 119 Mal
- Danksagung erhalten: 758 Mal
Re: HM-MOD-Re-8 und der Duty Cycle der CCU
Ich sehe darin ein ganz normales Verhalten. Wird ein nicht erreichbares Gerät angesprochen, wird die Message einige Male wiederholt. Wenn das für alle Kanäle erfolgt, ist der DC-Anstieg kein Wunder. Wie sollte das anders gehen?
Wird das Gerät über Programme angesprochen? Wie häufig?
Da könnte man ja eine Abfrage auf Kommunikationsstörung einbauen und dann keine Ausgaben mehr zulassen. Auch könnte man stündlich eine solche Ausgabe mal erlauben, falls die Kommunikation wieder funktioniert. Zudem solltest du überprüfen, ob nicht unnötig viele, vielleicht auch überflüssige Ausgaben getätigt werden. Wir wissen nicht, wie du den Re ansteuerst, kennen auch ein evtl. Programm nicht.
Wird das Gerät über Programme angesprochen? Wie häufig?
Da könnte man ja eine Abfrage auf Kommunikationsstörung einbauen und dann keine Ausgaben mehr zulassen. Auch könnte man stündlich eine solche Ausgabe mal erlauben, falls die Kommunikation wieder funktioniert. Zudem solltest du überprüfen, ob nicht unnötig viele, vielleicht auch überflüssige Ausgaben getätigt werden. Wir wissen nicht, wie du den Re ansteuerst, kennen auch ein evtl. Programm nicht.
-
- Beiträge: 249
- Registriert: 03.01.2014, 09:07
- Hat sich bedankt: 67 Mal
- Danksagung erhalten: 3 Mal
Re: HM-MOD-Re-8 und der Duty Cycle der CCU
Das Spannende an meinem Phänomen ist die Tatsache, dass eine Auslösung an einem Gerät die komplette HM-Installation zum erliegen bringen kann. Dabei ist es ein Aktor mit möglichem Batteriebetrieb, die Ursache kann also eine kränkelnde Batterie sein.
Die Anzahl Versuche, welche die Zentrale zum Erreichen des Aktors unternimmt, kann bekanntlich nicht eingestellt werden. Auch nach einem DC-Alarm ist das Problem nicht gelöst.
Die Anzahl Versuche, welche die Zentrale zum Erreichen des Aktors unternimmt, kann bekanntlich nicht eingestellt werden. Auch nach einem DC-Alarm ist das Problem nicht gelöst.
Insgesammt 4 Anlagen. Hauptsystem mit 1271 Kanäle in 200 Geräten und 5977 Datenpunkte, verwaltet mit Charly auf einem Asus-Thinkerboard "S", natürlich mit RaspberryMatic. HM, HMIP und Wired im Einsatz.
-
- Beiträge: 14244
- Registriert: 08.05.2013, 23:33
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Nordwürttemberg
- Hat sich bedankt: 597 Mal
- Danksagung erhalten: 1520 Mal
Re: HM-MOD-Re-8 und der Duty Cycle der CCU
Das siehst Du etwas einseitig. Der Befehl wird durch die CCU gemäß der Einstellungen (max 10x) wiederholt. Wenn dieses in unendlichen Versuchen endet, ist der Anwender mit seiner Programmierung (bei Aktualisierung eines anderen Wertes, oder durch zyklische Scriptläufe) die eigentliche Ursache. Es ist dann eben nicht eine Auslösung. Das System unterliegt nun mal betimmten funktechnischen Auflagen und hält diese ein. Und 36 Sekunden Funkzeit pro Stunde und Gerät ist auch bei Funktelegrammen im Bruchteil einer Sekunde nicht gerade wirklich viel. Dass es aber ausreicht, beweisen die vielen Installationen, bei denen es reibungslos läuft.
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: 249
- Registriert: 03.01.2014, 09:07
- Hat sich bedankt: 67 Mal
- Danksagung erhalten: 3 Mal
Re: HM-MOD-Re-8 und der Duty Cycle der CCU
Gleichfalls.
Das Problem tritt auch auf, wenn gar keine Programme auf das Gerät programmiert sind, sondern nur eine Handauslösung erfolgt. Sogar ein Neustart der Zentrale bringt keine "Erleichterung". Dieses Phänomen habe ich unabhängig in zwei Projekten festgestellt und habe deshalb auf die Alternative HmIP-MOD-OC8 umsteigen müssen.
Insgesammt 4 Anlagen. Hauptsystem mit 1271 Kanäle in 200 Geräten und 5977 Datenpunkte, verwaltet mit Charly auf einem Asus-Thinkerboard "S", natürlich mit RaspberryMatic. HM, HMIP und Wired im Einsatz.
-
- Beiträge: 14244
- Registriert: 08.05.2013, 23:33
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Nordwürttemberg
- Hat sich bedankt: 597 Mal
- Danksagung erhalten: 1520 Mal
Re: HM-MOD-Re-8 und der Duty Cycle der CCU
Dann stimmt bei Dir an anderers Stelle was gewaltig nicht, denn der DC wird bei einem Reboot der Zentrale mit Neuinitialisierung des Funkmoduls definitv zurückgesetzt. Der Status DC ist flüchtig gespeichert. Das Deaktivieren von Programmen und ein nachfolgender Reboot war bisher immer der Königsweg, um aus der DC-Falle herauszukommen.
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
- gnom
- Beiträge: 332
- Registriert: 23.06.2022, 05:33
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Brühl
- Hat sich bedankt: 27 Mal
- Danksagung erhalten: 56 Mal
Re: HM-MOD-Re-8 und der Duty Cycle der CCU
bin etwas verwirrt, erst heißt es
Hast Du mal die Kanäle auf protokolliert gestellt?
Ich habe 2 von den Dingern und solche DC effekte noch nicht gesehen - nur die "normalen", wenn man diese Teile öfter anspricht.
dannWie beschrieben ist das Spannende, dass wenn der HM-MOD-Re-8 OFFLINE ist, aber angesprochen wird, der Duty-Cycle der CCU durch die Decke geht
Kommt das jetzt wenn off-line, on-line oder beides?Das Spannende an meinem Phänomen ist die Tatsache, dass eine Auslösung an einem Gerät die komplette HM-Installation zum erliegen bringen kann.
Hast Du mal die Kanäle auf protokolliert gestellt?
Ich habe 2 von den Dingern und solche DC effekte noch nicht gesehen - nur die "normalen", wenn man diese Teile öfter anspricht.
Gruss, Chris
don't fear dying, fear not living (Marc Aurel)
strebst Du nach Respekt, handle selber danach (unbekannt)
2 Systeme:
- Home: Debmatic & IOBroker unter Debian 12 auf Laptop, HM-IP, Asksin++ (HB-+Innogy Devices), Zigbee, Tasmota/Shelly
- WE-Shed: Debmatic & IOBroker unter Debian 11 auf Laptop, HM classic, Asksin++ (HB-+Innogy Devices), RF, Tasmota/Shelly
don't fear dying, fear not living (Marc Aurel)
strebst Du nach Respekt, handle selber danach (unbekannt)
2 Systeme:
- Home: Debmatic & IOBroker unter Debian 12 auf Laptop, HM-IP, Asksin++ (HB-+Innogy Devices), Zigbee, Tasmota/Shelly
- WE-Shed: Debmatic & IOBroker unter Debian 11 auf Laptop, HM classic, Asksin++ (HB-+Innogy Devices), RF, Tasmota/Shelly