DutyCycle-Alarm

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

Moderatoren: jmaus, Co-Administratoren

DidiTheE
Beiträge: 101
Registriert: 19.02.2018, 20:52
Wohnort: Waldshut-Tiengen
Hat sich bedankt: 11 Mal
Danksagung erhalten: 7 Mal

Re: DutyCycle-Alarm

Beitrag von DidiTheE » 07.10.2019, 20:11

LibertyX hat geschrieben:
07.10.2019, 09:25
Die kommen nur, wenn in den Zentralen Einstellungen das RF Logging auf "Alles loggen" steht.
Ok, danke. Habe das jetzt mal eingeschaltet. Was ich bereits sehe ist, dass vor allem die Sensoren (Bewegungsmelder, einige Fensterkontakte, und der Stromzähler HM-ES-TX-WM) übermäßig oft auftauchen.

Mir ist jetzt aber noch unter Einstellungen in der Geräteliste die Spalte RSSI aufgefallen. Dort werden zu jedem Gerät dBm Werte und unterschiedlich farbige Pfeile angezeigt.

Bei einem Gerät (HMIP-PSM) wird zusätzlich in Gelb "DUTYCYCLE" angezeigt (-74 dBm und grüner Pfeil nach unten).
Bei anderen Geräten ist teilweise ein roter Pfeil zu sehen.

> Wo finde ich mehr Infos zur RSSI Spalte?

Ich stecke den HMIP-PSM jetzt testweise mal aus und beobachte, ob sich der DS beruhigt (aktuell wieder bei 44%).
- Raspberry 3B (Charly)
- 121 Geräten mit insgesamt 493 Kanälen, 1 HmIP-HAP als Repeater
- 2 separate Raspberry mit jeweils Historian und ioBroker

LibertyX
Beiträge: 767
Registriert: 10.11.2012, 19:47
System: Alternative CCU (auf Basis OCCU)
Wohnort: RP
Hat sich bedankt: 1 Mal
Danksagung erhalten: 19 Mal

Re: DutyCycle-Alarm

Beitrag von LibertyX » 07.10.2019, 20:20

Dann würde ich mal vermuten, dass bei der HMIP-PSM die Messwerte beim Kanal für die Leistungsmessung so eingestellt sind, dass die Quasi am Dauerfunken ist. Denn wenn da "DUTYCYCLE" steht, heißt das, dass der Duty Cycle des Gerätes überschritten ist.
RaspberryMatic (3.71.12.20231020) @RPI3 | 218 Kanäle in 53 Geräten und 72 CUxD-Kanäle in 8 CUxD-Geräten (2.11) | iobroker.pro - CCU-Historian (3.4.0)

DidiTheE
Beiträge: 101
Registriert: 19.02.2018, 20:52
Wohnort: Waldshut-Tiengen
Hat sich bedankt: 11 Mal
Danksagung erhalten: 7 Mal

Re: DutyCycle-Alarm

Beitrag von DidiTheE » 08.10.2019, 20:31

Das Problem scheint gelöst nachdem ich den HMIP-PSM ausgesteckt habe. DutyCyle ist danach zurück gegangen und seither stabil bei +/-10.
Vielen Dank für eure Tipps.

Noch ein paar Infos zum fraglichen HMIP-PSM:
- Gerät hat die letzte Firmware (2.6.2) geladen
- Gerät war eingeschaltet, Kontrollleuchte hat aber nicht (mehr) geleuchtet
- Verbrauchswerte wurden trotzdem korrekt in einem Diagramm erfasst (Messung Gefriertruhe)
- Taster (mit Kontrollleuchte) hat das Gerät nicht mehr geschaltet
- Fernsteuerung über CCU ging nicht mehr
- Nach Power-Reset (Stecker raus und weder rein) hat alles wieder normal funktioniert (habe den Stecker trotzdem außer Betrieb genommen)
- Raspberry 3B (Charly)
- 121 Geräten mit insgesamt 493 Kanälen, 1 HmIP-HAP als Repeater
- 2 separate Raspberry mit jeweils Historian und ioBroker

krikkit
Beiträge: 15
Registriert: 31.05.2017, 19:19
System: Alternative CCU (auf Basis OCCU)

Re: DutyCycle-Alarm

Beitrag von krikkit » 08.10.2019, 20:40

die anleitung bezüglich duty cycle hat mir schon mal geholfen, problem ist jetzt das ich fast nur hm-ip componenten hab und wenn ich mir das log so anseh, ich nicht ganz versteh wie ich da des jeweilige HM-IP gerät identifizieren kann...

hier nur mal ein ausschnitt:

Code: Alles auswählen

Oct  8 20:24:20 raspi2 user.debug rfd: HSSXmlRpcEventDispatcher::Handle send completed
Oct  8 20:24:20 raspi2 user.debug multimac: C> @1157151: #99 HMIP CMD=06  03
Oct  8 20:24:20 raspi2 user.debug multimac: A<: #58 HMIP CMD=06  03
Oct  8 20:24:25 raspi2 user.debug multimac: C> @1161736: #2 HMIP CMD=07  3A 10 00 8E 90 03 DC B5 48 AA 05 64 49 F1 2D 5D F0 56 85 C2 00 80 00 00 00 E6 06 00 00
Oct  8 20:24:25 raspi2 user.debug multimac: A<: #90 HMIP CMD=07  3A 10 00 8E 90 03 DC B5 48 AA 05 64 49 F1 2D 5D F0 56 85 C2 00 80 00 00 00 E6 06 00 00
Oct  8 20:24:25 raspi2 user.debug multimac: A>: #59 HMIP CMD=03  00 10 00 8E 00 00 00 90 03 DC 02 C2 00
Oct  8 20:24:25 raspi2 user.debug multimac: MacController::OnDownstreamFrame(#59 HMIP CMD=03  00 10 00 8E 00 00 00 90 03 DC 02 C2 00)
Oct  8 20:24:25 raspi2 user.debug multimac: C<: #100 HMIP CMD=03  00 10 00 8E 00 00 00 90 03 DC 02 C2 00
Oct  8 20:24:25 raspi2 user.debug multimac: C< @1161742: bin:FD 00 10 02 64 03 00 10 00 8E 00 00 00 90 03 DC 02 C2 00 74 AE
Oct  8 20:24:25 raspi2 user.debug multimac: C> @1162491: #100 HMIP CMD=06  03
Oct  8 20:24:25 raspi2 user.debug multimac: A<: #59 HMIP CMD=06  03
Oct  8 20:24:25 raspi2 user.debug multimac: C> @1162574: #3 HMIP CMD=07  3A 10 00 8E 32 7A 37 B5 48 AA 05 5C D9 4F 74 EA D7 0F 85 0A 00 80 00 00 00 FA 06 00 00
Oct  8 20:24:25 raspi2 user.debug multimac: A<: #91 HMIP CMD=07  3A 10 00 8E 32 7A 37 B5 48 AA 05 5C D9 4F 74 EA D7 0F 85 0A 00 80 00 00 00 FA 06 00 00
Oct  8 20:24:25 raspi2 user.debug multimac: A>: #60 HMIP CMD=03  00 10 00 8E 00 00 00 32 7A 37 02 0A 00
Oct  8 20:24:25 raspi2 user.debug multimac: MacController::OnDownstreamFrame(#60 HMIP CMD=03  00 10 00 8E 00 00 00 32 7A 37 02 0A 00)
Oct  8 20:24:25 raspi2 user.debug multimac: C<: #101 HMIP CMD=03  00 10 00 8E 00 00 00 32 7A 37 02 0A 00
Oct  8 20:24:25 raspi2 user.debug multimac: C< @1162590: bin:FD 00 10 02 65 03 00 10 00 8E 00 00 00 32 7A 37 02 0A 00 BC 1B
Oct  8 20:24:26 raspi2 user.debug multimac: C> @1163075: #101 HMIP CMD=06  03
Oct  8 20:24:26 raspi2 user.debug multimac: A<: #60 HMIP CMD=06  03
Oct  8 20:24:27 raspi2 user.debug multimac: C> @1163919: #4 HMIP CMD=07  3D 10 00 8E 74 B4 92 B5 48 AA 05 64 C4 6B EE 81 1F 6C 85 39 00 80 00 00 01 04 06 00 00
Oct  8 20:24:27 raspi2 user.debug multimac: A<: #92 HMIP CMD=07  3D 10 00 8E 74 B4 92 B5 48 AA 05 64 C4 6B EE 81 1F 6C 85 39 00 80 00 00 01 04 06 00 00
Oct  8 20:24:27 raspi2 user.debug multimac: A>: #61 HMIP CMD=03  00 10 00 8E 00 00 00 74 B4 92 02 39 00
Oct  8 20:24:27 raspi2 user.debug multimac: MacController::OnDownstreamFrame(#61 HMIP CMD=03  00 10 00 8E 00 00 00 74 B4 92 02 39 00)
Oct  8 20:24:27 raspi2 user.debug multimac: C<: #102 HMIP CMD=03  00 10 00 8E 00 00 00 74 B4 92 02 39 00
Oct  8 20:24:27 raspi2 user.debug multimac: C< @1163927: bin:FD 00 10 02 66 03 00 10 00 8E 00 00 00 74 B4 92 02 39 00 E1 B3
Oct  8 20:24:27 raspi2 user.debug multimac: C> @1164439: #102 HMIP CMD=06  03
Oct  8 20:24:27 raspi2 user.debug multimac: A<: #61 HMIP CMD=06  03
Oct  8 20:24:28 raspi2 user.debug multimac: C<: #103 TRX GetDutyCycle
Oct  8 20:24:28 raspi2 user.debug multimac: C< @1165671: bin:FD 00 03 01 67 03 CA 1B
Oct  8 20:24:29 raspi2 user.debug multimac: C> @1165773: #103 TRX Response Ack 2E
wäre für sachdienliche hinweise sehr dankbar...

Hütte
Beiträge: 746
Registriert: 08.02.2017, 11:08
Hat sich bedankt: 32 Mal
Danksagung erhalten: 75 Mal

Re: DutyCycle-Alarm

Beitrag von Hütte » 08.10.2019, 20:58

DidiTheE hat geschrieben:
08.10.2019, 20:31
Das Problem scheint gelöst nachdem ich den HMIP-PSM ausgesteckt habe. DutyCyle ist danach zurück gegangen und seither stabil bei +/-10.
Vielen Dank für eure Tipps.

Noch ein paar Infos zum fraglichen HMIP-PSM:
- Gerät hat die letzte Firmware (2.6.2) geladen
- Gerät war eingeschaltet, Kontrollleuchte hat aber nicht (mehr) geleuchtet
- Verbrauchswerte wurden trotzdem korrekt in einem Diagramm erfasst (Messung Gefriertruhe)
- Taster (mit Kontrollleuchte) hat das Gerät nicht mehr geschaltet
- Fernsteuerung über CCU ging nicht mehr
- Nach Power-Reset (Stecker raus und weder rein) hat alles wieder normal funktioniert (habe den Stecker trotzdem außer Betrieb genommen)
Dann poste doch mal die Einstellungen in der Gerätekonfiguration für den HMIP-PSM. Mit Sicherheit sind da ein paar Einstellungen, die bewirken, dass die Steckdose viel zu oft Daten überträgt. Denn jede Sendung von der Steckdose muss von der Zentrale quittiert werden. Und wenn da schon alleine zu viele Datenpakete von der Steckdose gesendet werden, dann kommt auch die Zentrale an ihre Grenzen. Schließlich darf sie insgesamt auch nur 36 Sekunden pro Stunde senden. Hast du eventuell noch weitere HMIP-PSM im Einsatz? Dann vergleich doch mal die Gerätekonfigurationen.

Bei Parametern wie aktuelle Netzspannung oder Netzfrequenz ist es nicht wirklich wichtig, eine Änderung von 0,1 Volt jedes Mal an die Zentrale zu melden. Denn diese kleinen Schwankungen treten dauernd auf, ohne dass ein Verbraucher davon irgendwie beeinflußt wird.

DidiTheE
Beiträge: 101
Registriert: 19.02.2018, 20:52
Wohnort: Waldshut-Tiengen
Hat sich bedankt: 11 Mal
Danksagung erhalten: 7 Mal

Re: DutyCycle-Alarm

Beitrag von DidiTheE » 09.10.2019, 20:18

Vermutlich hast du recht. Der Mindestsendeabstand für den Messwertkanal war auf 3 Sekunden gestellt.
Ich habe das jetzt mal auf 1 Minute erhöht und beobachte wieder.

Danke,
Dietmar
- Raspberry 3B (Charly)
- 121 Geräten mit insgesamt 493 Kanälen, 1 HmIP-HAP als Repeater
- 2 separate Raspberry mit jeweils Historian und ioBroker

Antworten

Zurück zu „RaspberryMatic“