Hoher Duty Cycle nach Stromausfall und keine Erklärung gefunden

HMIP lokale Installation

Moderator: Co-Administratoren

Matsch
Beiträge: 5359
Registriert: 30.05.2019, 11:37
System: Alternative CCU (auf Basis OCCU)
Wohnort: Chemnitz
Hat sich bedankt: 113 Mal
Danksagung erhalten: 722 Mal

Re: Hoher Duty Cycle nach Stromausfall und keine Erklärung gefunden

Beitrag von Matsch » 17.09.2021, 12:31

Aquaplex hat geschrieben:
17.09.2021, 12:23
Ist dieses Rückmelden der CCU auf ein Telegramm eines Aktors normal? Auch wenn keine Ansteuerung oder Messwertübertragung erfolgt bzw. erfolgen sollte?
Ja natürlich, die Kommunikation ist ja bidirektional. Und wenn keine Antort oder NotACK kommt, dann wiederholt der Sender die Sendung noch bis zu 3mal.

D.h. ist die CCU etwas schwerhörig (Empfang gestört), dann senden viele Geräte Ihre Datenpakete bis zu 4mal - mit den Auswirkungen auf den DC.

Aquaplex
Beiträge: 300
Registriert: 16.11.2011, 18:16
System: CCU und Access Point
Hat sich bedankt: 26 Mal
Danksagung erhalten: 8 Mal

Re: Hoher Duty Cycle nach Stromausfall und keine Erklärung gefunden

Beitrag von Aquaplex » 17.09.2021, 12:38

Matsch hat geschrieben:
17.09.2021, 12:31
Ja natürlich, die Kommunikation ist ja bidirektional. Und wenn keine Antort oder NotACK kommt, dann wiederholt der Sender die Sendung noch bis zu 3mal.
Dieses Ping Pong findet immer nur 1x statt, aber von verschiedenen Aktoren, auch wenn diese nicht bedient werden
HmIP auf Pi3B+ mit RaspberryMatic und neuem Funk-Modul sowie 3 HAPs / Etwa 150 IP-Geräte

Aquaplex
Beiträge: 300
Registriert: 16.11.2011, 18:16
System: CCU und Access Point
Hat sich bedankt: 26 Mal
Danksagung erhalten: 8 Mal

Re: Hoher Duty Cycle nach Stromausfall und keine Erklärung gefunden

Beitrag von Aquaplex » 17.09.2021, 12:39

jmaus hat geschrieben:
17.09.2021, 12:30
Doch genau die meinte ich. Auch DV auf interne Gerätetasten bzw. virtuellen CCU Tastern können dafür sorgen das dadurch der DC steigt. Die solltest du also auch noch deaktivieren bzw. temporär löschen, etc. um zu überprüfen das deshalb nicht irgendwie unnötiger funktraffic passiert.
OK, das prüfe ich mal...
jmaus hat geschrieben:
17.09.2021, 12:30
Kommt natürlich drauf an. Natürlich melden Aktoren/Geräte sich in regelmäßigen Abstanden mit Statusmeldungen bei der CCU und diese quittiert dann durch ein eigenes Funktelegram diese Statusmeldung. Folglich steigt auch deshalb der DC mitunter an. Überprüfe also mal die Geräteeinstellungen für die Zeitabstände der Statusmeldungen dieses Gerätes oder setz diesen Wert neu im Aktor. Vielleicht hilft das ja schon bereits. Und du könntest ja auch in der WebUI z.B. die Protokollierung der Telegramme die von diesem Gerät kommen einmal aktivieren und dann solltest du sehen in welchen Abständen das Gerät was genau an die CCU übermittelt und wie regelmäßig.
In einem anderen Thread hier im Forum habe ich gelesen, dass diese Statusmeldungen reine Broadcasts sind und nix mit dem DC der CCU zu tun haben?
HmIP auf Pi3B+ mit RaspberryMatic und neuem Funk-Modul sowie 3 HAPs / Etwa 150 IP-Geräte

Xel66
Beiträge: 14085
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 580 Mal
Danksagung erhalten: 1492 Mal

Re: Hoher Duty Cycle nach Stromausfall und keine Erklärung gefunden

Beitrag von Xel66 » 17.09.2021, 15:17

Aquaplex hat geschrieben:
17.09.2021, 11:45
Aber trotzdem muss sie doch mehr senden als ein einzelnes Gerät. So wie es auch im geposteten Screenshot bei verdrahtet.info zu sehen ist.
Auch wenn Du es nicht glauben magst, muss die CCU nur senden, wenn sie den Aktoren aufgrund eines Programmlaufes etwas mitzuteilen hat. Man kann eben auch Programme so anlegen, dass sie nicht unnütz in der Gegend rumposaunen, indem man z.B. nur Befehle raussendet, wenn ein Aktor nicht den gewünschten Status hat. Nebenbei gibt es aber noch viele Fallstricke in der Programmierung, bei denen sich Trigger wie "bei Aktualisierung" verhalten, obwohl "bei Änderung" ausgewählt ist (z.B. in komplexeren Programmen mit mehreren Triggern oder des gleiche Triggers mit mehreren Status). Da meine CCU dauerhaft einen einstelligen Duty Cycle hat und nur bei umfangreichen Aktionen mal die 25% überschreitet, kann ich mit meiner Art, Programme anzulegen, nicht so falsch liegen. Und ich betreibe Hausautomation(!) und keine Fernsteuerung.

Bei mir läuft fast alles automatisch ab (Rollladensteuerung mit Beschattungs- und Lüftungsfunktion, Heizungssteuerung mit schichtplanabhängiger Sollwertvorgabe und Berücksichtigung von Außentemperaturen, Lichtsteuerung in Abhängigkeit der Anwesenheit und Bewegung im Haus und noch vieles mehr). Ein richtiger Duty Cycle-Treiber ist meine Art, die Keymatic anzusteuern. Das aber eben nur, weil ich hier viel Wert auf Sicherheit lege und sie teils doppelt ansteuere. So bekommt sie beim Verlassen des Hauses und geöffneter Tür erst mal einen Befehl für entriegelt, damit ich zwischenzeitliche mögliche Handbedienungen neutralisiere, und danach wird abgeschlossen, wenn die Tür zugezogen wurde. Hier kann ich in Verbindung mit Heizungsansteuerungen im Winterhalbjahr und der Aktivierung der Einbruchsmeldefunktion schon mal meine interne Warnschwelle von 25% reißen. Und die Anzahl meiner Geräte und Programme steht ja in der Signatur. Allerdings ist der überwiegende Anteil klassisches Homematic.
Aquaplex hat geschrieben:
17.09.2021, 12:39
In einem anderen Thread hier im Forum habe ich gelesen, dass diese Statusmeldungen reine Broadcasts sind und nix mit dem DC der CCU zu tun haben?
Dann hast Du nicht richtig gelesen. Zyklisch übermittelte Statusmeldungen werden größtenteils als Broadcasts ausgesendet. Wechselt ein Status, ist das natürlich eine bidirektionale Kommunikation. Temperaturen von Thermosensoren und Thermostaten werden auch als Wettertelegramm gebroadcastet, Entscheidungswerte eines Thermostats sind quittierpflichtig uswusf. Ein Gefühl für den Anteil von Broadcast-Informationen bekommt man, wenn man mal die tabellarische Aufstellung der Telegramme im Analyzer anschaut. Derzeit sind die meisten meiner Telegramme mit BCAST getagt. Da im Moment auch nichts los ist, ist das auch korrekt so. Und an meinem angehängte Screeshot (ja, er ist absichtlich unscharf) sieht man in der letzten Spalte den Anteil der grün getagten Broadcasts. Der Ausschnitt umfasst einen Zeitbereich von ca. 45 Minuten.

Gruß Xel66
Dateianhänge
Screenshot AskSinAnalyzer.jpg
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

MichaelN
Beiträge: 9562
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 696 Mal
Danksagung erhalten: 1608 Mal

Re: Hoher Duty Cycle nach Stromausfall und keine Erklärung gefunden

Beitrag von MichaelN » 18.09.2021, 17:23

Aus Neugier habe ich das mal bei meinem System ein paar Stunden protokollieren lassen, mit filgdnem Ergebnis. Die CCu beansprucht ~ doppelt soviel wie jeweils das gesprächigste Gerät. Also immer noch deutlich weniger als beim TO. Interessanterweise habe ich hierbei gemerkt, das sich noch eine CCU in der Nähe befinden muss.
Unbenannt.JPG
LG, Michael.

Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.

Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++

Xel66
Beiträge: 14085
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 580 Mal
Danksagung erhalten: 1492 Mal

Re: Hoher Duty Cycle nach Stromausfall und keine Erklärung gefunden

Beitrag von Xel66 » 18.09.2021, 21:05

MichaelN hat geschrieben:
18.09.2021, 17:23
Interessanterweise habe ich hierbei gemerkt, das sich noch eine CCU in der Nähe befinden muss.
Kann an der Art der Programmierung liegen, aber auch an den verbauten Geräte selbst. Was hast Du für einen Duty Cycle? Ich habe zwar auch eine zweite CCU(2) in Betrieb und sehe diese auch. Die Darstellung unterscheidet sich aber nicht wesentlich von der meiner Wetterstation und der Alarmanlage des Nachbarn, die alle das gleiche Frequenzband nutzen. Da der Analyzer die Kommunikation nicht detektieren kann (wie bei HmIP auch), tagt er diese Ereignisse als IP-Kommunikation, nur eben ohne Gerätenamen. Sie werden durch eine sechstellige alphanumerische Kennung dargestellt.

Solche Geräte können natürlich auch Einfluss auf den Duty Cycle der CCU haben, obwohl alle angemeldeten Geräte mit gutem Schätzwert ... ähhh RSSI dargestellt werden. Behindern diese gleichstarken Signale die Kommunikation, kann die CCU gezwungen werden, ihre Befehle vielfach zu wiederholen, bis der eigentliche Adressat sie bestätigt.

Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

MichaelN
Beiträge: 9562
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 696 Mal
Danksagung erhalten: 1608 Mal

Re: Hoher Duty Cycle nach Stromausfall und keine Erklärung gefunden

Beitrag von MichaelN » 18.09.2021, 21:09

DC ist meist unter 5%
Könnte natürlich auch Wetterstation oder Temperatur Sensor sein, die hier rum stehen. Hätte aber nicht gedacht das sowas als HM Kommunikation angezeigt wird.
LG, Michael.

Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.

Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++

Xel66
Beiträge: 14085
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 580 Mal
Danksagung erhalten: 1492 Mal

Re: Hoher Duty Cycle nach Stromausfall und keine Erklärung gefunden

Beitrag von Xel66 » 18.09.2021, 22:57

MichaelN hat geschrieben:
18.09.2021, 21:09
Hätte aber nicht gedacht das sowas als HM Kommunikation angezeigt wird.
Ja, wird es. Das sind bei mir in obigem Screenshot die roten kurzen Texte. Da stehen nur die sechsstelligen alphanumerischen Kennungen drin. Es gibt drei verschiedene Empfangskennungen (CCU2, Wetterstation und Alarmanlagenzentrale des Nachbarn) und diverse Sendekennungen von den verteilten Sensoren (und einem an die CCU2 angelernten IP-Aktor).

Ich habe noch eine andere autarke Wetterstation mit nur einem Außensensor, der laut Aufdruck auch die gleiche Frequenz nutzt. Den sehe ich allerdings nicht im Analyzer. Vielleicht fährt er ein ganz anderes Kommunikationsprotokoll. Der Grund, warum der Analyzer die anderen Geräte sieht, liegt wahrscheinlich an der ähnlichen Adressierung wie HM(IP). Der Payload scheint aber nicht dekodierbar (zumindest nicht mit Bordmitteln). Brauche ich aber auch nicht, da die Inneneinheit der Wetterstation per WLAN/LAN die Daten aufbereitet im Weatherunderground-Format in Systemvariablen der CCU schreibt. Eine sehr stabile Lösung ohne Gebastele und noch dazu mit mehr Daten und viel günstiger als die HM-Wetterstation.

Auch ein CUL, der für die wenigen FS20-Weihnachtsdeko-Aktoren noch vorhanden ist, sieht die anderen Kommunikationen nicht. Ist wohl auch eine Protokollangelegenheit. Tiefer analysiert habe ich das nicht, weil ich keine Probleme damit habe. Im Wasserfalldiagramm meiner App für einen SDR-Stick sieht aber ständige Kommunikationen von wenigen Millisekunden im betreffenden Frequenzband, so dass es mich wundert, dass ich ganz wenig mit Kommunikationsstörungen zu tun habe (so 1-2 "war gestört" pro Woche) und mein Duty Cycle so stabil gering ist.

Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

Aquaplex
Beiträge: 300
Registriert: 16.11.2011, 18:16
System: CCU und Access Point
Hat sich bedankt: 26 Mal
Danksagung erhalten: 8 Mal

Re: Hoher Duty Cycle nach Stromausfall und keine Erklärung gefunden

Beitrag von Aquaplex » 20.09.2021, 09:38

Xel66 hat geschrieben:
17.09.2021, 15:17
Zyklisch übermittelte Statusmeldungen werden größtenteils als Broadcasts ausgesendet. Wechselt ein Status, ist das natürlich eine bidirektionale Kommunikation. Temperaturen von Thermosensoren und Thermostaten werden auch als Wettertelegramm gebroadcastet, Entscheidungswerte eines Thermostats sind quittierpflichtig uswusf. Ein Gefühl für den Anteil von Broadcast-Informationen bekommt man, wenn man mal die tabellarische Aufstellung der Telegramme im Analyzer anschaut. Derzeit sind die meisten meiner Telegramme mit BCAST getagt. Da im Moment auch nichts los ist, ist das auch korrekt so.
Erst mal Respekt für den dauerhaft niedrigen DC. Da ich den Analyzer erst seit dem "Problem" nutze, kann ich den Anteil meiner CCU - wie vorher "normal" war - leider nicht als Referenz heranziehen. Auf jeden Fall ist mein DC sicher zwangsläufig etwas höher, da ich ausschließlich IP-Geräte verwende, die ja durch die standardmäßig verschlüsselte Kommunikation mehr Traffic erzeugen.

Den Hinweis oben habe ich verstanden. Es ist aber wirklich auffällig, dass bei mir recht häufig dieses "Ping Pong" (Meldung vom Gerät an CCU und die meldet etwas zurück) stattfindet. Und da sind überwiegend Geräte dabei, die definitiv nicht ständig einen Messwert übertragen müssten (z.B. Lichtaktoren, Dimmaktoren, Schaltsteckdosen ohne Messfunktion usw.). Warum erfolgt dieser Austausch, wenn nichts geschaltet oder gemessen wird? Hier im Haus ist gerade nichts los. Screenshot im Anhang und der ist gerade typisch :cry:
Dateianhänge
Bsp.JPG
Bsp.JPG (16.28 KiB) 272 mal betrachtet
Zuletzt geändert von Aquaplex am 20.09.2021, 10:52, insgesamt 1-mal geändert.
HmIP auf Pi3B+ mit RaspberryMatic und neuem Funk-Modul sowie 3 HAPs / Etwa 150 IP-Geräte

Matsch
Beiträge: 5359
Registriert: 30.05.2019, 11:37
System: Alternative CCU (auf Basis OCCU)
Wohnort: Chemnitz
Hat sich bedankt: 113 Mal
Danksagung erhalten: 722 Mal

Re: Hoher Duty Cycle nach Stromausfall und keine Erklärung gefunden

Beitrag von Matsch » 20.09.2021, 10:47

HmIP-Geräte tauschen m.E. aller ca. 1,5 h ihren Status aus.

Antworten

Zurück zu „HomeMatic IP mit CCU“