Verdoppeltder "Idle DutyCycle" mit 3.75.6.20240319 gegenüber 3.73.9.20240130

[Baxxy13]

Describe the issue you are experiencing

Mein Hauptsystem im aktuell ungenutzten Ferienhaus zeigt einen quasi verdoppelten "Idle DytyCycle" nach Update auf die 3.75.6.20240319.
Das lässt sich reproduzieren indem ich zwischen der Vorversion und der aktuellen Version wechsele.
Die Betriebsbedingungen im Haus sind absolut identisch, es ist unbewohnt und wird aktuell nicht beheizt.

Describe the behavior you expected

Keine Verdoppelung des DutyCycle durch Installation der aktuellen Version.

Steps to reproduce the issue

1. das kann man vermutlich nur mit identischen Setup reproduzieren
2. ich werde unten detaillierte Infos liefern

...

What is the version this bug report is based on?

3.75.6.20240319

Which base platform are you running?

ova (Open Virtual Infrastructure, AMD64/x86_64)

Which HomeMatic/homematicIP radio module are you using?

RPI-RF-MOD

Anything in the logs that might be useful for us?

-

Additional information

Duty Cycle Verlauf:

Setup:
5 HmIP-Heizgruppen als 2-Punkt-Regelung

• 3x je 1x WTH-2 (2.8.10), 1x FSM (1.24.6), 1x SWDO-I (1.18.10)
• 1x WTH-2 (2.8.10), 2x FSM (1.24.6), 1x SWDO-I (1.18.10)
• 1x STH (2.8.10), 1x FSM (1.24.6), 1x SWDO-I (1.18.10)

Als Hinweis:
In dieser Konstellation senden die Thermostate ~alle 3min wohl eine "Multicast-Nachricht".
(der Analyzer zeigt diese als "HmIP Multicast All Devices - except CCU")
Diese "Multicast-Nachricht" ist wohl für andere Geräte, aber nicht für die Zentrale.

Verhalten mit 3.73.9.20240130:

Die "Multicast-Nachrichten" sind im ~3min Raster zu sehen, die Zentrale reagiert darauf nicht.
(von unten nach oben "lesen")

Verhalten mit 3.75.6.20240319:

Die "Multicast-Nachrichten" sind im ~3min Raster zu sehen, die Zentrale reagiert darauf indem sie auch eine "Multicast-Nachrichten" aussendet, also quasi antwortet. Wichtig ist hier der Zeitstempel, erst sendet das WTH-2 und direkt darauf die Zentrale. (von unten nach oben "lesen")

Analyse und Auswertung:
Das Verhalten hängt mit dem verwendeten HmIP-Server zusammen, ist also eher ein Upstream-Issue.

• durch Rückkehr zur Vorversion oder auch durch Nutzung des vorherigen HmIP-Servers implementiert in die aktuelle Version ist das Verhalten wieder "normal", also der DC pegelt sich wieder im einstelligen Bereich ein. Beides sind keine guten Optionen.
• entferne ich die IP-Schaltaktoren aus den HmIP-Heizgruppen stellen die Thermostate diese 3min "Multicast-Nachrichten" ein und mein DC pegelt sich auf normalem Level ein. Keine Option da die IP-Heizgruppen somit keinerlei Funktion mehr haben.

Die Frage die sich mir stellt:

• ist das jetzt ein Bug oder Feature das die Zentrale nun auf "Multicast-Nachrichten" reagiert/antwortet

Wenn das jetzt so korrekt ist dann finde ich ~15% "Idle DutyCycle" für mein recht kleines System doch recht viel.

meine Bitte:

Es wäre gut wenn du mal deine Kontakte bei eQ-3 auf das Thema aufmerksam machen könntest.
Das auf einer vanilla CCU3 nachzustellen erfordert doch einiges an Aufwand, das würde ich nur im Notfall auf mich nehmen wollen.
Entweder es war vorher "falsch", dann muss ich damit leben, oder es ist was buggy und eQ-3 sollte das fixen.
Letzteres wäre mir lieber. 😉

Zusammengefasst:

Seit 3.75.6.20240319 funkt die Zentrale an die Multicastadresse, jedes mal nachdem ein IP-Wandthermostat (welches mindestens einen IP-Schaltaktor als DV hat) eine "Multicast-Nachrichten" ausgesendet hat.
Das war mit 3.73.9.20240130 definitiv nicht der Fall.
Da die IP-Thermostate ihre "Multicast-Nachrichten" im ~3min Raster aussenden und die Zentrale jedes mal "antwortet" kommen bei meinen 5 IP-Heizgruppen summa summarum 100 zusätzliche Nachrichten/h dazu die es so vorher nicht gab.
Diese mache ich für die Verdoppelung meines DutyCycle verantworlich.

Laut Analyzer werden "Multicast-Nachrichten" anderer IP-Geräte nicht durch die Zentrale "beantwortet", es scheint also als wären nur die IP-Thermostate betroffen.

Keiner möchte durch ein Zentralenupdate verdoppelten DC, wäre gut wenn eQ-3 sich das mal anschaut.

[friedpa]

@Baxxy13: kann das irgendwie mit #2667 zusammenhängen? Da habe ich auch so ein Problem mit dem DC geschildert

[Baxxy13]

Nein, das sind 2 verschiedene Dinge.
Mein Problem hier betrifft ausschließlich HmIP und tritt erst seit der 3.75.6.20240319 auf.
Dein Problem betrifft laut Screenshots nur HM und ist schon länger vorhanden.

[Baxxy13]

Also noch tiefergehender Analyse steht fest das im HmIP-Server das "Repeating" von solchen "Multicast-Nachrichten" vom Typ HEATING_CONTROLLER_MODE aktiviert wurde. Damit wiederholt / repeated nun die Zentrale jede der 3 minütigen "Multicast-Nachrichten" meiner 5 IP-Wandthermostate was zur deutlich sichtbaren Erhöhung meines DC führt.

Schade das sowas mal wieder nicht im Changelog stand, das hätte einiges an Tests und Sucherei erspart.

Grundsätzlich ist das also eher ein Feature statt Bug.
Als Feature gesehen ist das in Installationen in denen IP-Thermostat und IP-Schaltaktor räumlich weit voneinander entfernt sind eigentlich gar nicht so schlecht.
Bei mir sind aber Aktor und Thermostat jeweils max. 2-3m voneinander entfernt, die Zentrale hingegen hat zu allen Aktoren einen größeren Abstand und damit ist es unsinnig das die Zentrale die Nachrichten der Thermostate wiederholt.

Und nun zu eQ-3:
Es wäre gut wenn man das "Repeating" in den Einstellungen des Funkmoduls (RPI-RF-MOD / HmIP-RFUSB) deaktivieren könnte, also ähnlich wie bei HAP's (als LAN-ROUTER) oder auch HmIP-PSM.

So sieht das jetzt mit der Vorversion aus, wo die "Multicast-Nachrichten" noch nicht durch die Zentrale repeated werden.
Der "Bewohnt-DC" ist deutlich unter dem "Idle-DC" der 3.75.6.20240319.