Unerwartet hohes Meldungsaufkommen bei Gruppe Wand/Heizungsthermostat

[dk6ii]

Ich habe an einer CCU2 eine Gruppe aus Wandthermostat, zwei Heizungsthermostaten und einem Drehgriffkontakt gebildet. Die CCU2 macht erwartungsgemäß direktverknüpfungen draus. Soweit OK. Es laufen keine Programme, keine Anwesenheitserkennung etc.. Insgesamt ca 50 Geräte im Netz. HF-Störungen messe ich keine, Reichweite sollte auch kein Problem darstellen (wenige Meter)
Bisher war Duty Cycle kein Problem. Allerdings senden die Heizungsthermostate Minute Meldungen - nachzulesen im Log. Das treibt den Duty Cycle immer gegen 99%. Gibt es da Abhilfe?
vy 73

[Xel66]

Allerdings senden die Heizungsthermostate Minute Meldungen - nachzulesen im Log.

Ja, die Thermostate senden im drei-Minuten-Abstand ihre Daten. Macht statistisch bei zwei Thermostaten alle anderthalb Minuten ein Broadcast. Und nein, im Normalfall treibt das den DutyCycle nicht hoch, weil diese Statusdaten nicht quittierpflichtige Broadcasts sind. Hat man allerdings die gesicherte Übertragung aktiviert, kann das aber schon anders aussehen. Eine gesicherte Übertragung ist für den Fall aber hyperliquid. Im Allgemeinen kann man mit der gesicherten Übertragung den DutyCycle hochtreiben, weil da viel Protokolloverhead generiert wird.

Gruß Xel66

[dk6ii]

Hi Xel66, vielen Dank für die Auskunft,
ich habe hier zehn Ventile, von denen jeweils eines oder zwei von einem Wandthermostat gesteuert werden, dazu noch ein Stall voll Fenster- und Drehgriffsensoren und anderes Kleinzeug, das aber nur on-Demand sendet.
Derzeit ist der DC, bezogen auf die Zentrale, schon wieder auf 62%, was theoretisch nicht schlimm wäre. Ich darf nur keine Konfigurationen verschicken. Wie der DC aber auf den Stationen ist, weiß ich eben nicht...
Mir war zuvor nur nicht so klar, weshalb die Ventile periodisch die ganzen Einstellwerte senden, z.B.:

21:55:34 25.08.2018 Heizung EG Vorraum:4
Auto-Modus, kein Fehler, Batteriestatus 3.10V, Ventilposition 0%, Boost-Status 0min, Ist-Temperatur 22.20°C, Soll-Temperatur 21.00°C, Urlaub-Temperatur 5.00°C, Urlaub-Start-Uhrzeit 0minutes, Urlaub-Start-Tag 1day, Urlaub-Start-Monat 1month, Urlaub-Start-Jahr 0year, Urlaub-Ende-Uhrzeit 0minutes, Urlaub-Ende-Tag 1day, Urlaub-Ende-Monat 1month, Urlaub-Ende-Jahr 0year

Ich hatte zwar die Frage an anderer Stelle schon gestellt, aber trotzdem: Kann ich irgendwo nachlesen, wie lange (zeitlich) typische Frames sind?

Viele Grüße
dk6ii

[Xel66]

Auf dem letzten Usertreffen würde das thematisiert. In irgendeinem Vortrag sollte das zu finden sein. Auf alle Fälle spielt sich das im Millisekundenbereich ab. Außer bei Batterieaktoren, die mit einem Wake-up-Burst erst mal aktiviert werden müssen. Habe da was von 130ms im Kopf. Andere Kommunikationen sind viel, viel kürzer.

Gruß Xel66

[Gluehwurm]

Wie schon im anderen Fred
viewtopic.php?f=27&t=35390&p=450842#p450842
erwähnt, ist das periodische Senden der "Gruppen" m.E. nicht das Problem.

Eher mal in diese Richtung schauen
viewtopic.php?f=19&t=44990

... schon wieder auf 62% ...

Was läuft denn auf der CCU bzw. was machst Du?

[dk6ii]

Ich sehe, auch andere haben das Problem wohl auch.
Also CCU2, Firmware 2.35.16, nur ein Programm für das Außenlicht (Astro-Timer auf Hutschienen-Schaltaktor) Läuft seit einem Jahr.
Auf der CCU2 läuft der xml-Daemon, über den ich die CCU2 (lesend) ins Haus einbinde. Von Außen ist die CCU2 nicht erreichbar.
Was in jüngster Zeit dazu gekommen ist, sind drei Wandthermostate, um die Hz-Thermostate per direkter Verknüpfung zu steuern.
Seitdem beobachte ich, dass der DC hochläuft (gemeseen per Skript auf der CCU). Eben gerade auch wieder 99%...

Insgesamt zehn Hz-Thermostate, die meisten laufen autonom mit Zeitsteuerung.

Der Bereich um 868 MHz ist frei, bis auf die Kommunikation der CCU und der Komponenten, zumindest zeigt der Messempfänger keine unbekannten Signale an. Die CCU ist in Gebäudemitte, Entfernung ca 15m bis zu den Sensoren.

vy 73

[dk6ii]

Danke glühwurm! Der letzte Thread hat (vermutlich) in die richtige Richtung gezeigt.

Ein "Schaltaktor für Batteriebetrieb" (HM-LC-Sw1-Ba-PCB), der zwar nicht in Betrieb, jedoch auch nicht abgelernt war...
Ich hatte ihn aus den Augen verloren, da er nicht in der Störungsliste auftauchte. Stromversorgung angeschlossen, nach einer Stunde lag der DC im einstelligen Bereich.

Thema erst einmal geschlossen...

Beste Grüße an alle...

[Xel66]

Wie soll ein nicht in Betrieb befindlicher Aktor für einen so hohen Duty Cycle verantwortlich sein? Ich tippe eher auf ein Programm, welches permanent durch irgendeinen Trigger versucht, den Aktor zu schalten. Da dieses noch ein Batterieaktor ist, fallen dementsprechend auch die dazu notwendigen WakeUpBursts an.

Gruß Xel66

[dk6ii]

Hatte ich auch gedacht,
doch ich habe kein Programm dazu geschrieben. Ich hatte den Aktor zum Testen der spektralen Emissionen auf dem Labortisch und irgendwann einfach die Batterie abgeklemmt. Glühwurm hatte mich auf einen anderen Thread hingewiesen, da war ein ähnliches Verhalten beschrieben. Ob das aber wirklich die Ursache war, kann ich nicht mehr reproduzieren.
Nun die Batterie (Akku) wieder angeklemmt und nach einer Stunde war der DC bei 2% oder so... komplett normal... Und das ist bis heute so.
Ich bin mit der Homematic-Sache eigentlich recht zufrieden.
Wie gesagr, das Spektrum im Gebäude war auch während der Zeit mit hohem DC eigentlich unauffällig. Alle paar Sekunden ein Frame von irgendeinem Sensor oder Aktor hier.
Und seitdem arbeiten die Thermostate/Wandthermostate/Drehgriffsensoren wieder normal, was mir wichtig war.
Ich benutze zwar eine CCU2 aber keine komplizierten Automatisierungen. Die Überwachung des Hauses läuft über das xml-Interface.

Beste Grüße