Duty Cycle hoch bei >160HMIP Geräten >1000 Kanäle

[NickHM]

Die HM-OU-LED16 fressen doch auch massig DC, wenn sie gesetzt werden.

Hallo

das 16er LED Teil hatte ich glatt übersehen.
Der Klassiker ... eine LED wird gesetzt, obwohl sie sich schon im gewünschten Zustand befindet. Das gilt es zu vermeiden.

Allerdings hatten wir ja gelesen, dass es keine derartigen Programme gibt, weil es auf der CCU noch gar keine Programme gibt.

[Mathias]

... Hatte den Historian ausgeschaltet, weil ich Fremdsoftware als Ursache ausschließen wollte. ...

Der CCU-Historian funktioniert rein passiv. Er veranlasst weder Geräte noch die CCU dazu irgendetwas zu senden.

Vielleicht hilft noch zur Analyse folgende Funktionalität vom CCU-Historian: Auf der Seite Datenpunktkonfiguration in der Spalte Anz. Einträge werden zwei Werte gezeigt: Die Gesamtanzahl an Einträgen in der Datenbank und die Anzahl an Einträge in den letzten 24 Stunden. Gerade der 2. Eintrag hilft, um häufig sendende Geräte zu finden. (Es sollte natürlich keine Vorverarbeitung für die Datenpunkte aktiv sein, damit auch wirklich die Rohdaten ausgewertet werden.)

Gruß
Mathias

[qwertz]

Hallo zusammen !

Vielen Dank für die weiteren Anregungen. Obwohl das Thema große HM-Classis-Systeme hier im Forum gut beherrscht wird, ist das Thema große HmIP System noch spannendes Neuland und bestimmt ein zunehmendes Problem in der Zukunft.

-CCU-Historian
@Mathias Vielen Dank für den Hinweis. Mit "Anzahl Einträge" des Historians kann man DutyCycle-Fressern wirklich deutlich schneller ausmachen als mit den multimac-Log oder HomematicManager Ereignislog. Wie man das mit den ioBroker macht, habe ich noch nicht raus und da habe ich auch die Sorge dass der ioBroker aktiv pullt.
Werde beim Neuaufsetzen des Systems mit dem Historian gezielt nach Duty-Cycle-Fressern fahnden.

HM-OU-LED16 Statusanzeige Ampek
Die Problematik ist bekannt, aber die LED16 waren im genannten Problem-System noch garnicht aktiv und natürlich auch in keinem Programm. Die Ansteuerung von zwei HM-OU-LED16 in meinem eigenen System läuft über das Sysvar-Skript hier aus dem Forum mit SystemDutyCycle < 15%.
Zumindest könnte ich die HM Classis LED16 notfalls über ein eigenes LanGateway ansteuern und den DutyCycle des Raspi schonen. Werde die LED16 bei Neuaufbau des Problem-Systems zuletzt anlernen und vorher/nachher Vergleich machen.

HmIP-MOD-RC8 Sender
@nicolas-eric: Die RC8-Sender setze ich dezentral ein zum Auslesen von Reed-Kontakte in Fenstern und Türen. Da es Sensoren sind und keine Aktoren, glaube ich nicht, dass die mit einem Burst aufgeweckt werden. Die sollen sich hin und wieder von alleine Melden und eben bei Statusänderung. Oder übersehe ich da was ?

BSM-Messaktor Kanal7
@Familienvater: Vielen Dank für den Tip auch die Watt-grenze hochzunehmen. Werde ich beim Neuaufbau umsetzen. Am liebsten wäre es mir ja, wenn ich mit einer Checkbox, das ganze unnötige Messgedöns ausschalten könnte. SmartHome als Energiesparlösung ist eh nur ein Marketing-Gag.

PSM-Routing
Zum Routing durch OSM habe ich bisher wenig handfestes gelesen. Z.B. Nach wieviel Sendeversuchen wird begonnen zu Routen ? So wie man liest, bauen die PSM untereinander eine Art MESH auf ? Haben die PSM interne Tabellen wie LAN-Router und wissen, wenn sie über welche Route erreichen können ? Oder feuern die jedesmal um sich und gucken, ob sich das gesuchte Gerät meldet.
Bis jetzt habe ich noch Bedenken ohne Not das Routing zu aktivieren und mir die Pest ins System zu holen.

BWM-Helligkeit
Kann man den BWM austreiben auch auf Helligkeitsveränderungen mit Senden zu reagieren ? Ich will von denen nur wissen ob sich was Bewegt. Ich sehe bis jetzt keine Möglichkeit.

Programme
Wirklich keine aktiven Programme im Problem-System ! Nur Basisprogramme für BackUP und Reboot-Trigger/Detektionsprogramme, die kein Sensor oder Aktor beinhalten und manuell in der WebUI getriggert werden.

Fazit:
Ich lerne jetzt alles ab mit Werksreset + lokalem Werksreset und nehme den 1.Raspi vom Strom. Dann lerne ich die Geräte an ein frischen 2.Raspi mit leerem Image mit anderem Funkmodul wieder an. Erstmal nur eine Etage und werde dann eure Hinweise einarbeiten.

Wenns bei einer Etage mit dem DC nach o.g. Optimierung im Rahmen bleibt schaue ich weiter, ob ich wirklich mehrere Raspis brauche.
Ich werde hier berichten.

Besten Dank und Gruß,
Sebastian

[qwertz]

So, nach kompletten Neuaufsetzen mit lerrem Raspi Image und werksreset aller Geräte siehts besser aus.
BewMelder und Co sowie Statusmeldungen angepasst. Messfunktion von BSM ausgeschaltet. Fast alles über Direktverknüpfungen.

Code: Alles auswählen

961 Kanäle in 146 Geräten und 36 CUxD-Kanäle in 5 CUxD-Geräten:
5x HMIP-SWDO, 30x HmIP-BSM, 7x HmIP-SMO-A, 14x HmIP-BDT, 11x HmIP-SWSD, 19x HmIP-SMI55, 9x HmIP-BROLL, 13x HmIP-WTH-2, 8x HmIP-SWD, 4x HM-OU-LED16, 5x HmIP-WRC6, 9x HmIP-SPDR, 3x HmIP-SPI, 1x HmIP-WGC, 1x HmIP-SAM, 3x HmIP-MOD-RC8, 5x CUX28, 3x HMIP-PSM, 1x HM-LC-Sw1PBU-FM

DutyCycle Grundlast bei Abwesenheit ist nun um 20%. Auch mit mehreren LED16 Modulen gehts bei Abwesenheit meist nur bis 70%. Die Ansteuerungsprogramme der LED16 werden ab DC >90 durch Programmbedingung gestoppt, damit der DC nicht voll läuft.

Mit ein wenig Feinschliff und einem sauberen System geht das also.
Danke für die Tipps !

[hjd55]

Da ich ein ähnliches Problem habe die Frage, wie das Problem gelöst hast?
Gruß Hans

[hjd55]

sorrx, ich meine, ob du dauerhaft jetzt keine DC- Probleme mehr hast.
Gruß Hans

[eiGelbGeek]

Abwesenheit meist nur bis 70%

Ich denke mal das es Anwesenheit heissen soll..... ich halte 70% trotzdem noch für schlecht .....

[romeoalfa1975]

Moin.

Ich habe ca. 90 HmIP-Geräte an der CCU3. Davon 14 HmIP-BSM. Im Ruhezustand habe ich einen DC von 10-15%. Damit bin ich sehr zufrieden. Alle paar Wochen/Monate spielt jedoch irgendein HmIP-BSM verrückt und sendet alle 10 Sek. auf Kanal 0 seinen Status (habe von allen den Kanal 0 protokolliert und eine DC-Anzeige gut sichtbar im Wohnzimmer installiert und somit fast immer im Blick). Gestern hatte dieses komische Senden den DC innerhalb von einer Viertelstunde von ca. 20% auf ca. 80% gebracht. Dann hat das Senden von selbst wieder aufgehört und der DC hat sich wieder normalisiert. Manchmal sendet der BSM aber so lange weiter, bis 100% erreicht sind und die CCU3 verweigert dann den Dienst. Spätestens nach 2 Stunden ist aber dann auch dieser Spuk vorbei.

eq3 hatte mir ein ähnliches Verhalten bei den Schaltmesssteckdosen HmIP-PSM bereits bestätigt und ein Softwareupdate für Anfang 2020 in Aussicht gestellt. Ich habe nun ebenfalls ein Mail mit dem Fehlerbild des BSM geschickt und hoffe, dass auch hier etwas bekannt ist und abgestellt wird.

Daher bitte ich Euch: Schreibt nicht nur ins Forum, sondern auch eq3 (falls nicht schon geschehen). Je mehr Nutzer das tun - um so besser.

Gruß
Michael

[Gerti]

Hi!

Das Verhalten mit dem BSM tritt bei mir auf, wenn er seinen zyklischen Status an die Zentrale sendet, aber die Rückmeldung nicht empfängt.
Hatte es bei mir festgestellt, als der am weitesten entfernte BSM sich so verhielt, nachdem ich ein Netzteil in der Steckdose darunter eingesteckt hatte.
Habe es so gelöst, dass ich einen Zwischenstecker als Router gesetzt habe, seither ist der Spuk vorbei.
Habe dazu aber auch ein Ticket bei eQ-3 erstellt und das Verhalten ist auch bestätigt und wohl in Arbeit.

Gruß,
Gerti

[RandyAndy]

Hi

das Thema Duty Cycle war bei mir auch ein riesen Thema. Insb. da ich damit Dachfenster steuere und die sollten bei Regen schon schliessen. Ich dachte zwar vor einiger Zeit die Lösung gefunden zu haben, am Ende war das nicht wirklich stabil und am Ende gab es Phasen in denen der Duty Cycle so bei 30% lag, ein paar Stunden später waren es dann wieder 99%. Ein anlernen von neuen Geräten war immer recht frickelig und benötigte einige Versuche und ein Aufspielen einer neuen Firmware dauerte dann oft 1 - 2 Wochen. Technisch kenne ich inzwischen auch den Grund, ich habe in einem Blockhaus zwangsläufig viel Holz verbaut und dieses Holz dämpft die Strahlung erheblich (deutlich mehr als Ziegel oder eine Gipswand). In der Summe eine für mich wenig zufrieden stellende Situation. Auffallend war, dass bei einem hohen Duty Cycle immer mind. ein Adpater typ. BROLL und/oder BSM nicht erreichbar war. Am Ende habe ich mich entschlossen in den sauren Apfel zu beißen und habe 2 Router (PSM) gekauft und diese so platziert, dass deren dBM-Wert so bei -70 lag und notfalls die Verbindungen über diese geroutet wird. Seit 4 Wochen ist nun das System stabil und der Duty Cycle ist so bei 20% +/- und das ist bei rund 40 - 50 Adaptern zumindest für mich ein akzeptaber Wert. Ich habe auch keine Medungen mehr im Fehlerlog.
Ich habe da natürlich keine allgemeingültige Lösung (außer eben Router einzusetzen und kann nicht garantieren dass diese Lösung für alle gilt) dennoch wollte ich diese Information einfach mal weitergeben. Für mich kommt das als eine Art Schwachstelle im System an, den gesamten Duty Cycle aufzubrauchen bis indirekt die gesetzliche Regelung ein Verbindung unterbricht und dann geht eben gar nichts mehr. Ich hoffe die Information hilft dem ein oder anderen.

Andreas