CCU Gerätekommunikation gestört – Fehlersuche (Teil 1)

Fehlersuche CCU3

Ein häufig auftretende Fehlermeldung einer CCU3 ist der Fehler "Gerätekommunikation gestört". Anhand eines Beispiels zeige ich, wie ich diese Fehlermeldung untersucht und schließlich eine Ursache identifizieren konnte. Da ich bisher von diesen Fehlern im großen Stil verschont geblieben bin habe ich mich komplett neu mit dieser Fehlersuche auf einem Smarthome System mit einer CCU3 und openHAB 2.5 Kombination eingearbeitet. Die Erfahrungen sowie die Erarbeitung einer gewissen Systematiik teile ich hiermit gerne. Dabei kann ich hier nur einige Möglichkeiten aufführen, da es eine Vielzahl ergänzender Vorgehensweisen und Tests gibt.

Aufgabenstellung

Seit einigen Wochen erhielt ich immer mehr Fehlermeldungen von verschiedenen Aktoren "Gerätekommunikation gestört". Manche dieser Servicemeldungen verschwanden wieder nach kurzer Zeit automatisch. Nach verschiedenen Neustarts der CCU meldeten sich aber immer wieder neue Aktoren mit dieser Fehlermeldung, während andere Aktoren nach einem Neustart die vorher gemeldete Kommunikationsstörung nicht mehr aufführten. Da ich viele der Aktoren auch in Programm z.B. über openHAB anspreche hatten einige dieser Meldungen durchaus unangenehme Auswirkungen. So bleiebn z.B. nur die Rolladenaktoren oben oder unten, die gerade keine Kommunikationsstörung hatten. Da der Fehler schleichend aufgetreten war, gab es keine konkreten Vermutungen, woher dieser kommen konnte.

Systematische Vorgehensweise

Insgesamt empfehle ich die Suche nach Fehlern, die sich nicht so genau eingrenzen lassen nach folgender Vorgehensweise durchzugehen:

  • Suche nach Softwarefehlern
  • Suche nach Hardwarefehlern
  • Suche nach Fehlern in der Verbindung zu weiteren Softwarepaketen wie openHAB, IOBroker, etc.

Dabei hängt die Reihenfolge von den erhaltenen Fehlern und natürlich von euren Vermutungen ab.

Je schneller man aber bemerkt, dass ein Fehler vorliegt (d.h. ab und zu mal in die Servicemeldungen schauen), umso besser könnt Ihr eingrenzen, was Ihr vorher möglicherweise verändert habt. Ein erster Ansatz ist daher immer, die Veränderungen zurückzunehmen, die erkennbar zwischen dem Zustand "funktioniert" und "funktioniert nicht mehr" durchgeführt wurden. In meinem Fall war das aber Theorie, da ich beide Zustände nicht mehr klar voneinander abgrenzen konnte.

Bei allen durchgeführten Tests ist es aber wichtig, möglichst viele Daten zu sammeln, auszuwerten und daraus wieder einen Rückschluss für die weitere Vorgehensweise zu ziehen.

Da ich vorher viele Anpassungen in der CCU vorgenommen hatte habe ich vermutet, dass es sich um Softwarefehler handeln könnte, die evtl. sogar in openHAB vorliegen könnten.

Softwarefehler finden

Hier bin ich sehr klassich vorgegangen und habe die folgenden Punkte alle geprüft und ggfs. durchgeführt:

  • Sofern es Firmware-Updates für Eure Geräte gibt, installiert diese zuerst auf den angebundenen Geräten.
  • Spielt immer die aktuelle Softwareversion der CCU3 ein, sofern Ihr das noch nicht gemacht habt.
  • Wenn Ihr Zusatzsoftware installiert habt, dann spielt hierzu die aktuellen Softwareversionen ein.
  • Wenn Ihr kürzlich Zusatzsoftware installiert habt dann deinstalliert diese und prüft anschließend das Verhalten
  • Hilft das alles nicht, dann startet die CCU3 im abgesicherten Modus. In diesem wird keine Zusatzsoftware geladen.
  • Für den Fall, dass dann der Fehler immer noch auftritt kann auch ein Softwareproblem mit der CCU3 Firmware nicht ausgeschlossen werden. In diesem Fall habe ich ausprobiert, ob die vorige Firmwareversion den Fehler nicht mehr erzeugt. Auch hier empfehle ich das Ganze einmal mit Zusatzsoftware oder ohne Zusatzsoftware zu testen.

Da ich openHAB nutze, habe ich dieses System nun heruntergefahren um auszuschließen, dass durch openHAB Anfragen an die CCU initiiert werden, die z.B. die Kommunikation der CCU überlasten würden. In meinem Fall blieben die Fehlermeldungen auch ohen Betrieb von openHAB bestehen, so dass ich meine Untersuchung weiter auf die CCU fokussiert und openHAB für die weiteren Tests ausgeschaltet gelassen habe.

Sofern Ihr die obigen Firmware und Zusatzsoftwareprüfung durchgeführt habt besteht noch die Möglichkeit, dass es sich um Fehler in Programmen oder auch Systemvariablenauf der CCU handelt.

  • Verwendet bei der Deklaration von Systemvaraiablen keine deutschen Umlaute oder Leerzeichen. Ja, ich weiß, wir sind schon in der Neuzeit, aber ein großer Teil der Software basiert halt auf der angloamerikanischen Sprache. Und sobald eine Übersetzung ins Spiel kommt, können Fehler passieren.
  • Das gleiche gilt für Programmnamen oder Programmcode. Ich behaupte nicht, dass dies nur so funktioniert, aber es schließt häufig auftretende Fehler einfach schneller aus. D.h. wenn Ihr hier Umlaute oder Leerzeichen verwendet ändert dies und schaut Euch an, wie das System anschließend im Normalbetrieb reagiert.
  • Einfluss auf den Duty Cycle der CCU und damit auch Verbinungsprobleme kann die häufige Anfrage von Kanälen sein. Ihr solltet auf jeden Fall mal die selbstgebauten Programme prüfen um festzustellen, ob beispielsweise die Funktion .Status() verwendet und aufgerufen wird, um Werte von Geräten abzufragen. Diese Funktion verursacht nämlich jedesmal eine direkte Ansprahce des Gerätes. Sofern Ihr keine "Echtzeitdaten" benötigt empfehel ich hier stattdessen die Funktion .Value() zu verwenden, die immer den zuletzt in der CCU gespeicherten Wert ausgibt. Damit umgeht Ihr eine unnötige Abfrage des Gerätes.

Alle diese Punkte habe ich geprüft und keine Verbesserung des Systemverhaltens feststellen können. Im nächsten Teil werde ich meine Erfahrungen mit der Suche nach Hardwarefehlern teilen.