Unterschied zwischen 2.27.8.20170410 und 2.27.8.20170413?

[P@rick]

Guten Tag

Ich bin neu hier im Forum und ein RaspberryMatic-Fan seit Januar 2017. Ich forsche nun seit Wochen in diesem Forum und habe auch die Tipps für Anfänger durchgearbeitet.
Die erste installierte Version war 2.25.15.20170114 und schon kurz nach der Inbetriebnahme begann meine Begeisterung. Am meisten gefällt mir die Zuverlässigkeit insgesamt, die ist 100%.
Unterdessen gehören Status-Display, Handsender, Wandsender, IR-Sensoren und alles mögliche an Aktoren zur Familie. HQ WebUI, E-Mail, WebMatic, XML-API und CUx-Daemon nutze ich ebenfalls sowie diverse Scripts (die ich aus diesem Forum übernommen habe).

Kurz vor Ostern habe ich die damals neueste Version 2.27.8.20170410 installiert und mein Backup zurückgeladen - das hat prima funktioniert. Sämtliche Funktionen (Timer usw.) liefen ohne Probleme. Ein erhöhter Wert des Duty Cycle konnte ich ebenfalls feststellen.
Kurz nach dem Umstieg jedoch wurden die Status-Updates meines Displays HM-OU-LED16 unzuverlässig, unter Service-Meldungen häuften sich die Meldungen "Geräte-Kommunikation gestört". Die Status sind jedoch nicht soo wichtig und ich habe Zeitverzögerungen, wie in diesem Forum empfohlen, eingebaut, jedoch mit mässigem Erfolg. Die Zuverlässigkeit war nicht wie vorher, ab und zu blieb eine LED aus (oder ein) und die Meldung "Geräte-Kommunikation gestört" erschienen erneut. Als dann auch noch ein Dimmer HM-LC-Dim1T-DR diesselbe Meldung brachte und nicht mehr zuverlässig dimmte, ging ich wieder zurück auf die Version 2.25.15.20170114 - und alles lief wieder bestens wie seit Beginn. Ich habe während des Versuchs keine Komponenten örtlich verschoben. Erst ganz am Schluss probehalber den Raspberry in die Raummitte gestellt und das HM-OU-LED16 3m davon entfernt aufgestellt - ich konnte keine Abweichung des Verhaltens feststellen.

Nach Ostern habe ich den gleichen Versuch gestartet mit der Version 2.27.8.20170413 (Neuinstallation und Backup zurückladen). Wie schon vorher hat die Inbetriebnahme perfekt geklappt. Nach ein paar Stunden erschienen die "Geräte-Kommunikation gestört"-Meldungen wieder beim HM-OU-LED16 - aber nur noch vereinzelt und weniger oft als beim vorhergehenden Versuch. Jedoch meldete nun ein Schaltaktor HM-LC-Sw2-FM ebenfalls "Geräte-Kommunikation gestört" und nicht wie beim vorhergehenden Versuch der Dimm-Aktor HM-LC-Dim1T-DR.

Was ich mich nun frage:
-Wenn mit einer Version (2.25.15.20170114) keine Meldungen "Geräte-Kommunikation gestört" erscheinen und mit einer neueren Version (2.27.8.20170410, 2.27.8.20170413) jedoch gehäuft - woran liegt das? Ist die Funkkomponente empfindlicher als vorher? An der Installation (örtlich, Benutzung) hat sich nichts geändert.
-War es Zufall, dass die Version 2.27.8.20170410 mehr Meldungen erzeugte als die Version 2.27.8.20170413?

Ich werde weiterhin das Geschehen hier im Forum beobachten und vielleicht kann ich auch einmal einen Beitrag zu einer Problemlösung leisten

Ein angenehmes Wochenende wünsche ich allen,
Patrick

[wuscheltuschel]

Hallo P@rick,

willkommen im Forum und von mir großen Respekt was Du als Anfänger in so kurzer Zeit alles zum laufen bekommen hast!

Kurz nach dem Umstieg jedoch wurden die Status-Updates meines Displays HM-OU-LED16 unzuverlässig, unter Service-Meldungen häuften sich die Meldungen "Geräte-Kommunikation gestört". Die Status sind jedoch nicht soo wichtig und ich habe Zeitverzögerungen, wie in diesem Forum empfohlen, eingebaut, jedoch mit mässigem Erfolg.

Ich bin zwar erst seit der neuesten Raspberrymatic Version mit dabei, kann Deine Beobachtung allerdings bestätigen. Ich hatte heute erneut, ohne zuvor Deinen Beitrag gelesen zu haben, den Gedanken dass mit den 16fach-Status-Displays etwas nicht stimmt.

Und zwar darf ich regelmäßig, geschätzt 1-2 mal täglich, bei allen dreien die Störungsmeldungen weg klicken.
Eine ist im gleichen Raum wie der Raspberry, eine im Raum daneben und die dritte ein Stockwerk höher. Das Problem tritt unabhängig von der Location auf.

edit: allerdings habe ich mit der CCU2 gerade das gleiche Problem mit einem Status-Display gehabt. Vielleicht ist das ein generelles Problem der aktuellen HM-Firmware.

Jedoch meldete nun ein Schaltaktor HM-LC-Sw2-FM ebenfalls "Geräte-Kommunikation gestört"

Meine Schaltaktoren melden keine Störungen. Allerdings habe ich die 1-fach Variante.
Weiß nicht ob das einen Unterschied macht.

[JRiemann]

Wenn die Ansteuerung der Statusdisplays unsauber programmiert ist verbrennt das sehr schnell viel DC. Die Dinger sind bei falscher Anwendung extrem Funkintensiv. Wenn dann auch noch 3 Stück verbaut sind die wahrscheinlich auch noch zeitgleich identische Daten erhalten wundert es nicht das der DC explodiert und Kommunikationsprobleme mit Servicemeldungen auftreten.

Nur mal so als Tip zur Fehlersuche...

[wuscheltuschel]

öhm, ja, Danke für die Information

Inzwischen kann ich mir vorstellen wie es ist Diät zu machen, da zählen die Leute doch auch jede Kalorie von jedem Bissen den sie zu sich nehmen.
Beim Hobby Homematic hat EQ3 jetzt den DutyCycle scharf aktiviert.

die wahrscheinlich auch noch zeitgleich identische Daten erhalten

ein paar Sekunden Verzögerung habe ich eingebaut aber die sollen schon zeitnah leuchten nachdem eine Bewegung registriert wurde und nicht erst x Sekunden später.
überlege gerade, Leuchte Nr. X wird bei allen 3 zeitgleich geschaltet, stimmt.

[jmaus]

[...]
Nach Ostern habe ich den gleichen Versuch gestartet mit der Version 2.27.8.20170413 (Neuinstallation und Backup zurückladen). Wie schon vorher hat die Inbetriebnahme perfekt geklappt. Nach ein paar Stunden erschienen die "Geräte-Kommunikation gestört"-Meldungen wieder beim HM-OU-LED16 - aber nur noch vereinzelt und weniger oft als beim vorhergehenden Versuch. Jedoch meldete nun ein Schaltaktor HM-LC-Sw2-FM ebenfalls "Geräte-Kommunikation gestört" und nicht wie beim vorhergehenden Versuch der Dimm-Aktor HM-LC-Dim1T-DR.

Was ich mich nun frage:
-Wenn mit einer Version (2.25.15.20170114) keine Meldungen "Geräte-Kommunikation gestört" erscheinen und mit einer neueren Version (2.27.8.20170410, 2.27.8.20170413) jedoch gehäuft - woran liegt das? Ist die Funkkomponente empfindlicher als vorher? An der Installation (örtlich, Benutzung) hat sich nichts geändert.
-War es Zufall, dass die Version 2.27.8.20170410 mehr Meldungen erzeugte als die Version 2.27.8.20170413?

Deine Fragen kann ich dir recht schnell und hoffentlich auch ausreichend klar beantworten. Im Grunde hast du Eingehens ja schon selbst den Grund deiner Kommunikationsstörungen benannt, nämlich das unterschiedliche Verhalten in der Berechnung des DutyCycle zwischen der Version 2.25.15.20170114 und späteren Versionen. Bei der 2.25.15.20170114 version war es einfach so, dass diese mit einer Funkmodul-Firmware daher kommt (2.2.1) die nicht nur vor allem noch einige HmIP bezogene Bugs besitzt sondern auch die Berechnung des DutyCycle in dieser Version falsch war - was dazu führte das der DutyCycle um ein vielfaches zu niedrig berechnet und folgerichtig auch so ausgewertet wurde. Mit der Version 2.27.7.20170316 und neuer hat sich das einfach dadurch geändert das diese Version mit aktuelleren Funkmodul-Firmware Versionen (2.7.0+) daherkommt die unter anderem auch den DutyCycle-Bug behebt und damit Normkonform berechnet. Deine bemerkten Kommunikationsprobleme kommen also einfach daher, dass mit den neueren Versionen die Funkmodul-Firmware einfach recht schnell an die 100% DutyCycle kommt und dann einfach für eine gewisse Zeit (mitunter 1-2 Std) nicht mehr funken darf um innerhalb der vorgeschriebenen Norm zu bleiben. Wie jedoch bereits von anderen benannt muss man eben (wie auch mit einer CCU2 mit gleichem CCU Firmware stand) nun sehr genau aufpassen was man so programmiert in der CCU und welche HomeMatic Hardware man wie einsetzt und das man sicherstellt das so wenig wie möglich Funkverkehr über das Funkmodul entsteht da es mit neueren 2.27.7+ Versionen eben einfach nun "enger" wird als vorher. Und ja, es war purer Zufall das du mit der 2.27.8.20170410 mehr Meldungen hattest als mit der 2.27.8.20170413.

[JRiemann]

ein paar Sekunden Verzögerung habe ich eingebaut aber die sollen schon zeitnah leuchten nachdem eine Bewegung registriert wurde und nicht erst x Sekunden später.
überlege gerade, Leuchte Nr. X wird bei allen 3 zeitgleich geschaltet, stimmt.

Zeitgleich ist an jeder Stelle eine große Fehlerquelle!
Und das zeitnahe und häufige anfunken von mehreren Geräten frisst viel DC.
Bei falscher Anwendung (sehr häufige Statusänderungen ans Display senden) reicht ein Display um den DC zu sprengen.

[wuscheltuschel]

Zeitgleich ist an jeder Stelle eine große Fehlerquelle!
Und das zeitnahe und häufige anfunken von mehreren Geräten frisst viel DC.
Bei falscher Anwendung (sehr häufige Statusänderungen ans Display senden) reicht ein Display um den DC zu sprengen.

Ach ja, mein MP3-Gong wird ja auch noch angesprochen. Und den zweiten wollte ich wegen der langsamen CCU2 nicht mehr programmieren, liegt seit 4 Monaten in der Ecke.
Deswegen Raspberrymatic.
Die Statusänderung wird einmal bei Bewegung (auf jedem Device) angezeigt.
Muss zeitgleich sein, Du hast keine Ahnung wie schnell die Igel und andere Viecher bei uns im Garten unterwegs sind... tagsüber die Vögel lösen auch aus soweit ich das mitbekommen habe?
wenn ich da erst 10 Sekunden warte und dann kucke sind die längst ganz wo anders.

edit:

Deine bemerkten Kommunikationsprobleme kommen also einfach daher, dass mit den neueren Versionen die Funkmodul-Firmware einfach recht schnell an die 100% DutyCycle kommt und dann einfach für eine gewisse Zeit (mitunter 1-2 Std) nicht mehr funken darf um innerhalb der vorgeschriebenen Norm zu bleiben.

Ich habe ja dieses Alchi-Script am laufen und auf 100% bin ich eigentlich nie. Denke ich zumindest. Die Variable lasse ich auf der Startseite anzeigen.
Solange die 100% erreicht sind dürfte doch auch die 16fach-Status-Anzeige kein Kommunikations-Problem haben?

[JRiemann]

Die Verzögerungen sind nur wichtig um zu verhindern das Funkpakete sich gegenseitig behindern.
Problematischer ist das häufige anfunken von Geräten. Dein DC muss doch ständig weit oben sein...
Alles was dauerhaft sehr deutlich über 50% liegt halte ich für bedenklich. Es besteht dringender Handlungsbedarf.

[wuscheltuschel]

Wechsel von CCU2 auf Raspberry. (nach Rollo-Firmware-Update)

Dutycycle beim Start und auch jetzt ist unter 50%

Trotzdem kurzzeitig nach dem Start meldet 16-fache LED 1 und 16-fache LED 3 (letzere 5 Minuten später) Gerätekommunikation gestört.

Wenn es am DutyCycle liegt, dürfte das Problem meiner Meinung nach nur bei 100% auftauchen?

Und der Raspberry denkt immer noch meine Rollos wären auf der alten Firmware.
Gibt es dafür eine unkomplizierte Lösung?

[Familienvater]

Hi,

das Problem bei dem Statusdisplay ist, das ggf. die ansteuernden Programme schlecht sind, und z.B. zwar bei erkannter Bewegung eine LED auf Rot setzen, was durchaus legitim ist, aber bei JEDER nicht erkannten Bewegung (ggf. alle 240 Sekunden) die LED jedesmal auf grün setzen, obwohl die LED nicht grüner werden kann (bzw. auch eine rote LED kann nicht roter werden).
Das der Befehl "zeitgleich" an 3 Anzeigen geht, führt ggf. durch die untergehenden Quittungen zu Kommunikationsstörungen auf CCU-Seite (das Display zeigt ggf. alles richtig an), und fehlende Quittungen veranlassen die CCU evtl. zum wiederholten Senden des gewünschten Zustands, und alles in allem frißt DC.

Wenn ich Jens richtig verstehe, ist bei Raspberrymatic erst mit Version 2.25.x die "funktionierende" DC-Überwachung reingekommen, die bei der CCU2 Firmware schon seit den HmIP-fähigen Firmware-Versionen ab 2.17.x (?) entahlten ist (was damals bei den CCU2-Benutzern zu einem Aufschrei geführt hatte).

Der Familienvater