Duty Cycle nach 2.25.15 - meine Erfahrung & Lösung

[reklovf]

Hmm - ich kenne mich mit Unix Skripts schon ein bisschen aus (ist allerdings auch schon eine Weile her, so kurz nach der Lochkarten Ära ... nichtsdestotrotz fände ich ein Toolset das einem die Skripterei/Auswertung zum duty cycle einfacher macht schon ganz charmant.
"Alle die zu doooof sind das mit Logs und Skripts hinzubekommen haben's nicht verdient"- ist imho zu kurz gesprungen - es gibt ja auch für andere Bereiche ganz intelligente Tools ...

Anbei mal meine Lastverteilung - ich habe die Aktoren so eingestellt dass sie möglicht "gleichmäßig" Infos produzieren - von daher passt die Grafik einheitlich mit meiner Erwartungshaltung zusammen.
Festzustellen ist auch dass der Sprung von 2.25.xx auf 2.29.xx rechnerisch den Funkverkehr bei mir verdreifacht hat.

BTW: Meine Erkenntnis - und deshalb hatte ich ja auch den Thread eröffnet - ist, dass die Direktverknüpfung von Funk-Komponenten bei mir den zentralen duty cycle massiv nach oben getrieben hat .. das hat mich wirklich viel Zeit gekostet das zu lokalisieren .. vielleicht liegt das nur an meiner Config - aber im Sinne einer Community wollt ich das einfach mal weitergeben, vielleicht hilft's ja auch bei anderen.

[schneidy76]

Jetzt muss ich mich aber auch mal auskotzen. HM ist doch keine Bastlerlösung! Welches System bitteschön hat es soweit gebracht? Welches System können wir kostenlos über eine kostenlose Plattform beliebig konfigurieren? Welches System bietet eine Rückmeldung der Status? Hat so viele Unterstützung in Foren und kostet ein Bruchteil von KNX? Und ist darüber hinaus auch noch weitestgehend Plattform unabhängig durch ioBroker etc? Ich bin froh über HM, Eq3, Jens, Hobbyquacker und alle die, die hier zusammen immer eine Lösung für noch so individuelle Fragen haben.
Also sage ich mal Danke und bin froh das es alles das hier gibt!
Vg Torsten

[dieterdorn]

Anbei mal meine Lastverteilung - ich habe die Aktoren so eingestellt dass sie möglicht "gleichmäßig" Infos produzieren - von daher passt die Grafik einheitlich mit meiner Erwartungshaltung zusammen.
Festzustellen ist auch dass der Sprung von 2.25.xx auf 2.29.xx rechnerisch den Funkverkehr bei mir verdreifacht hat.

Man kann nicht erkennen, welchen Faktor die Zeitachse hat, aber da scheint mir meine Grafik doch recht weniger "dicht" zu sein - sprich: mein DC ist im Mittel wohl deutlich geringer (bei allerdings auch "nur" 70 Geräten), aber dafür habe ich eben diese Peaks. Ohne diese sähe ich bei mir gar keinen Grund, irgendetwas ergründen zu wollen.
Mal eine Frage: Hast Du (oder jemand anderes) zufällig die LED-Anzeige (16-fach)? Die nutzte ich zur Anzeige des Status von 11 Türen und Fenstern. Jedes Öffnen setzt die dazugehörige LED auf "rot", jedes Schließen auf "grün". Dabei kommt es wohl relativ oft (so ca. 5-6 mal am Tag) zu Kommunikationsstörungen. Der RSSI-Wert der LED-Anzeige ist 43 - viel besser geht nicht!. Mit der CCU2 hatte ich vielleicht 3 Störungen - pro Woche! ich hatte schon mal den Verdacht geäußert, dass das möglicherweise mit der schnelleren Abarbeitung der Programme auf dem Raspi zusammen hängen könnte, da das Funkmodul viel schneller hintereinander angesprochen wird als mit der CCU2. Und damit kommt es zu viel mehr Kollisionen, da z.B. die Quittung gerade vom Gerät gesendet wird, während bereits der nächste Befehl ans nächste Gerät gesendet wird. Ich kann mir vorstellen, dass so etwas von der Software nicht abgefangen wird. Dazu gab es auch wohl bislang nie einen Grund. Ich bin jedenfalls davon überzeugt, dass meine Kommunikationsstörungen alle nichts mit irgendwelchen Reichweite- bzw. Antennenproblemen zu tun haben, sondern immer mit Kollisionen im Funkverkehr.
Ich bin mir noch nicht sicher, ob das alleine meine Peaks erklärt, aber irgendwie hat das wohl eine Auswirkung auf den DC. Ich bin halt noch auf der Suche nach der Ursache, und Verständnis, wie da was vom System gehandhabt wird, ist bei einer Ursachenforschung immer hilfreich.

Gruß

[Familienvater]

Hi,

ich habe auch eine LED16, allerdings ist die im Winter eher weniger funklastig, im Sommer lasse ich da je nach Füllgrad des Pufferspeichers der Solarthermie bis zu 4 LEDs im 30 Sek. Takt blinken, das kostet definitv Dutycycle.

Aber wenn Du glaubst, das es Kollisionen sind, dann setze doch einfach die LED16 mit 2 Sek. Verzögerung, da sollte nichts mehr vom TFK in der Luft sein.

Und auch an dieser Stelle kann man ggf. im rfd-Syslog schauen, dort sind Zeitstempel in Millisekunden-Auflösung (wenn man weiß, wo man suchen muss), da könnte man auch sehen, wie hoch die Latenz durch Zentralenprogramme etc. ist, und ob die "dramatisch" von einer CCU2 zu einer RaspiMatic abweicht.

Bei mir gibt es seit der Umstellung auf piVCCU gefühlt nicht mehr oder weniger Kommunikationsprobleme, nur der "Nordwand-Fühler" hat ein Witterungs-Problem und setzt dann gerne mal aus, das hat er aber auch schon letztes Jahr mit der CCU2 gehabt.

Der Familienvater

[dieterdorn]

Hi,

Aber wenn Du glaubst, das es Kollisionen sind, dann setze doch einfach die LED16 mit 2 Sek. Verzögerung, da sollte nichts mehr vom TFK in der Luft sein.

Hi,

erstmal Danke für Deine Antwort(en).

Habe ich bereits: generell 0 Sekunden bei Tür auf, 2 Sekunden bei Tür zu (bei Fenstern habe ich das Problem nicht). Wenn der zeitliche Abstand bis zur nächsten Tür (oder Fenster) gewahrt bleibt, gibt es auch nur selten Störungen. Problem tritt oft auf, wenn unsere Katzen gefüttert werden: Tür Terrasse auf (nach draußen) und sofort wieder zu, dann Tür Garage auf und u.U. ebenfalls sofort wieder zu. Dazwischen liegen nur 4 Meter und je nachdem, ob man noch den Müll mit rausgenommen hat o.ä. auch nur wenige Sekunden. Genauso beim reinkommen. Garage auf und zu, Terrassentür auf und zu. Ich könnte das lösen, indem ich den jeweiligen Status erst deutlich später zur LED-Anzeige schicke. Aber 1. das war mit der CCU2 nicht so, 2. ich will es verstehen oder ergründen, ob nicht ich irgendwo den Fehler mache oder das System mit solchen Fällen einfach nur "unschön" umgeht. Viele Dinge sind einfacher, wenn man die Fehler und Schwächen kennt. Ich will ja letztlich ein im Prinzip gutes System sicherer, zuverlässiger und stabiler bekommen. Und zumindest die Fehler, die ich selbst reingebracht habe finden und beseitigen.

Und auch an dieser Stelle kann man ggf. im rfd-Syslog schauen, dort sind Zeitstempel in Millisekunden-Auflösung (wenn man weiß, wo man suchen muss), da könnte man auch sehen, wie hoch die Latenz durch Zentralenprogramme etc. ist, und ob die "dramatisch" von einer CCU2 zu einer RaspiMatic abweicht.

Das muss ich mal versuchen. Bisher logge ich nur Fehler. Aktuell steht da:

Jan 6 17:39:38 homematic-raspi local0.err ReGaHss: Error: IseXmlRpc::CallXmlrpcMethod: execute result isFault; method =setValue Params = {"KEQxxxxxxx:2","LED_STATUS",2} result= [faultCode:-1,faultString:"Failure"] [iseXmlRpc.cpp:2605]
Jan 6 17:39:38 homematic-raspi local0.err ReGaHss: Error: IseXmlRpc::CallSetValue: CallXmlrpcMethod failed [iseXmlRpc.cpp:1502]
Jan 6 17:39:38 homematic-raspi local0.err ReGaHss: Error: IseHssDP::WriteValue: CallSetValue failed; address = KEQxxxxxxx:2 [iseDOMdpHSS.cpp:77]

Aber da muss ich mich noch etwas mehr mit befassen und die Protokollstufe raufsetzen.

Gruß