RaspberryMatic 3.41.11.20181126 – Erfahrungsberichte

[jmaus]

@Jens: Du hast nichts an der Funktion zur Verbindung der LGWs zwischen den beiden Versionen geändert?

Nein, daran wurde nichts verändert, auch meines Wissens nicht von eQ3.

[Depechem]

Code: Alles auswählen

Der WebUI Patch zur Anzeige des Batteriestatus und der Ventilposition für HmIP Geräte erweitert. Für diese HmIP Geräte werden nun jedoch der Batteriestatus unter "Einstellungen -> Geräte" angezeigt, da eine Anzeige unter "Status und Bedienung" nicht möglich ist (#457).

der Batteriestatus kann aber nur von HMiP Geräten angeszeigt werdem- Richtig!? Kann dies für normale HM Geräte bitte auch noch eingebunden werden.

Gruß Thomas

[jmaus]

Code: Alles auswählen

Der WebUI Patch zur Anzeige des Batteriestatus und der Ventilposition für HmIP Geräte erweitert. Für diese HmIP Geräte werden nun jedoch der Batteriestatus unter "Einstellungen -> Geräte" angezeigt, da eine Anzeige unter "Status und Bedienung" nicht möglich ist (#457).

der Batteriestatus kann aber nur von HMiP Geräten angeszeigt werdem- Richtig!? Kann dies für normale HM Geräte bitte auch noch eingebunden werden.

Unter "Einstellungen -> Geräte sollte auch für alte BidCos-RF Geräte der Batteriestatus angezeigt werden (wenn diese den entsprechenden Datenpunkt haben). Wenn für das Geräte dort nichts angezeigt wird gibt es für dieses Gerät auch den Datenpunkt nicht und er kann lediglich bei einer zu niedrigen Batteriespannung ein LOWBAT anzeigen.

[Depechem]

Code: Alles auswählen

Der WebUI Patch zur Anzeige des Batteriestatus und der Ventilposition für HmIP Geräte erweitert. Für diese HmIP Geräte werden nun jedoch der Batteriestatus unter "Einstellungen -> Geräte" angezeigt, da eine Anzeige unter "Status und Bedienung" nicht möglich ist (#457).

der Batteriestatus kann aber nur von HMiP Geräten angeszeigt werdem- Richtig!? Kann dies für normale HM Geräte bitte auch noch eingebunden werden.

Unter "Einstellungen -> Geräte sollte auch für alte BidCos-RF Geräte der Batteriestatus angezeigt werden (wenn diese den entsprechenden Datenpunkt haben). Wenn für das Geräte dort nichts angezeigt wird gibt es für dieses Gerät auch den Datenpunkt nicht und er kann lediglich bei einer zu niedrigen Batteriespannung ein LOWBAT anzeigen.

Nein dort findet man es nicht. Hab es unter Status und Bedienung gefunden unter Geräte ist nix. Siehe Anhang
Ich habe das aktuelle Update von Raspimatic

[Hütte]

Also bei mir wird im Fall einer schwachen Batterie auch ein LOWBAT gemeldet. Aber eben nur dann, wenn der Ladestand zu niedrig ist. Ansonsten wird da gar nichts angezeigt.

[jmaus]

Code: Alles auswählen

Der WebUI Patch zur Anzeige des Batteriestatus und der Ventilposition für HmIP Geräte erweitert. Für diese HmIP Geräte werden nun jedoch der Batteriestatus unter "Einstellungen -> Geräte" angezeigt, da eine Anzeige unter "Status und Bedienung" nicht möglich ist (#457).

der Batteriestatus kann aber nur von HMiP Geräten angeszeigt werdem- Richtig!? Kann dies für normale HM Geräte bitte auch noch eingebunden werden.

Unter "Einstellungen -> Geräte sollte auch für alte BidCos-RF Geräte der Batteriestatus angezeigt werden (wenn diese den entsprechenden Datenpunkt haben). Wenn für das Geräte dort nichts angezeigt wird gibt es für dieses Gerät auch den Datenpunkt nicht und er kann lediglich bei einer zu niedrigen Batteriespannung ein LOWBAT anzeigen.

Nein dort findet man es nicht. Hab es unter Status und Bedienung gefunden unter Geräte ist nix. Siehe Anhang
Ich habe das aktuelle Update von Raspimatic

Das Problem hieran ist, das bei den Heizkörperventilen der Datenpunkt in Kanal 1 liegt und unter einstellungen nur der maintenance kanal 0 abgefragt wird.

[tinus16]

Hallo,
auch bei einem anstehenden Update für die Zusatzsoftware blinkt die LED am Funkmodul blau/grün, ohne Anzeige in der Servicemeldung.

Zusatzsoftware habe ich nicht Installiert auf den Pi3 mit RaspberryMatic.
Ist nur mit den Phillips hue Bridge verknüpft.

Gruß Enrico

Hallo, bei mir blinkte nach dem update die gelbe LED ebenfalls. Irgendwo gefunden, dass diese LED blinkt, wenn keine Verbindung zum Zeitserver besteht. Bei mir stand fritz.box drin, was anscheinen nicht mehr funktioniert. Nachdem ich dort

Code: Alles auswählen

0.de.pool.ntp.org

eingetragen habe, blinkt die LED nicht mehr. Gruß Tinus

[jmaus]

Hallo, bei mir blinkte nach dem update die gelbe LED ebenfalls. Irgendwo gefunden, dass diese LED blinkt, wenn keine Verbindung zum Zeitserver besteht. Bei mir stand fritz.box drin, was anscheinen nicht mehr funktioniert. Nachdem ich dort

Code: Alles auswählen

0.de.pool.ntp.org

eingetragen habe, blinkt die LED nicht mehr. Gruß Tinus

In der Tat gehört da mehr als ein eintrag / ein Zeitserver rein um auf der sicheren Seite zu sein. Deshalb ist der Standardeintrag für den Zeitserver wie folgt:

Code: Alles auswählen

0.de.pool.ntp.org 1.de.pool.ntp.org 2.de.pool.ntp.org 3.de.pool.ntp.org

Und ich würde jedem raten exakt diese Zeichenkette als Zeitserver in den CCU Einstellungen einzutragen.

[Samhain]

Ich hab nur EIN LAN GW aber ähnliche Probleme. Nach Neuinstallation des LAN GW mit der neusten Raspi Homematic Version läuft alles seit ca. 3 Tagen stabil

Hallo zusammen,

nun sind gestern Abend (ca. 23h) wieder die Verbindungen zu meinen zwei LGW abgebrochen. Kurioser Weise wieder ca. 62h nach dem letzten Neustart. Die Beschreibung von den letzten beiden Ausfällen siehe mein Posting vom 09.12.

Das Syslog wird aber nun mit einem anderen Fehler im Sekundentakt vollgeschrieben:

Code: Alles auswählen

Dec 12 08:13:57 homematic-ccu2 user.err rfd: LGWPortWrapper::ReadData(): Receive error
Dec 12 08:13:57 homematic-ccu2 user.err rfd: LGWPortWrapper::ReadData(): Receive error
Dec 12 08:13:57 homematic-ccu2 user.err rfd: LGWPortWrapper::ReadData(): Receive error
Dec 12 08:13:58 homematic-ccu2 user.err rfd: LGWPortWrapper::ReadData(): Receive error
Dec 12 08:13:58 homematic-ccu2 user.err rfd: LGWPortWrapper::ReadData(): Receive error
Dec 12 08:13:58 homematic-ccu2 user.err rfd: LGWPortWrapper::ReadData(): Receive error
Dec 12 08:13:58 homematic-ccu2 user.err rfd: LGWPortWrapper::ReadData(): Receive error
Dec 12 08:13:59 homematic-ccu2 user.err rfd: LGWPortWrapper::ReadData(): Receive error
Dec 12 08:13:59 homematic-ccu2 user.err rfd: LGWPortWrapper::ReadData(): Receive error
Dec 12 08:13:59 homematic-ccu2 user.err rfd: LGWPortWrapper::ReadData(): Receive error
Dec 12 08:13:59 homematic-ccu2 user.err rfd: LGWPortWrapper::ReadData(): Receive error

Heute hatte ich auch die Zeit weitere Tests durchzuführen:
- LGWs sind per Ping zu erreichen
- Netzwerk-Stecker (an LGWs und Zentrale) ziehen und wieder stecken führt zu keiner Verbesserung
- LGWs vom Strom trennen und neustarten führt zu keiner Verbesserung
- HM-Wired-Komponenten funktionieren
- Alles andere funktioniert auch
- Nur der Neustart der Zentrale führt zu dem Ergebnis, dass die LGWs wieder erreichbar sind
- Nach Ziehen und Wiederstecken der Netzwerkstecker an LGWs oder Zentrale wird nun die Verbindung wieder aufgebaut
- Auch ein kurzzeitiges Trennen der Stromverbindung zum Switch (über welchen die Zentrale mit den Gateways verbunden ist) führt nicht zu dem o.g. Fehlerbild
- Um die Gegenprobe zu machen, werde ich nun wieder auf 3.37.8.20181026 zurück gehen, und die nächsten Tage auf einen Fehler warten.

Wenn jemand noch sonst irgendeine Idee hat, bitte melden.
@Jens: Du hast nichts an der Funktion zur Verbindung der LGWs zwischen den beiden Versionen geändert?

Viele Grüße
Patrick

[tloeffel]

Leider sind Diskussionen rund um einen vermeintlich gestiegenen DutyCycle immer sehr mühlselig. Gerade nach einem FirmwareUpdate vermuten meines Erachtens zuviele Nutzer die Ursache im Update der Firmware selbst wenn der DutyCycle danach erhöht oder verändert ist. Alles was ich dazu sagen kann ist, das sich meines Wissens weder an der DutyCycle Berechnung noch an den darunterliegenden Routinen irgendetwas geändert hat seit vielen Firmware-Updates. Weder hat sich die Firmware des Funkmoduls selbst geändert noch die Berechnungsroutinen des selbigen. Und da sich weder in meinen Testumgebungen noch in meiner eigenen produktiven Umgebung etwas geändert hat kann ich das von dir und hin/da auch von anderen beschriebene Verhalten nicht nachvollziehen. Hier hilft nur selbst das RFD und HMIPServer Logfile selbst zu analysieren (nach dem man den Loglevel hochgestellt hat) um rauszufinden warum das Funkmodul anscheinend sich veranlasst fühlt soviele Funkpakete abzusenden das der DC dauerhaft so hoch ist. Am Firmware-Update alleine kann das meiner Meinung nach nicht liegen.

Hallo Jens,

natürlich kann ich Deine Zeilen verstehen. Ich kann es mir aber auch nicht erklären. Fakt ist das ich vor dem Update diese extremen Ausschläge über 80% bis 95% nicht hatte. Es waren dann nur bis max. 75%. Ich habe auch auf Basis von Andi's Vote alle meine Programme überprüft. Es hat aber zu keinen wirklichen Verbesserungen geführt. Nun habe ich meinen LOG hochgeschraubt. Worauf soll ich genau achten. Hast Du da einen Tipp?

@Andi: Meine normalen Werte liegen bei mir mit 162 Funkaktoren bei ca. 25-45%. Aber dann kommen immer diese Berge in Verbindung mit den Gateways, dieses finde ich komisch.

Gruß Thomas