Nach letztem Update zu Open CCU fehlt mir eins von 6 HMW-IO-12-Sw7-DR

[Jany62]

Hallo in die Runde, ich habe vor einigen Tagen das Update auf meine CCU3 (Original) eingespielt. Von der Firmware "RaspberryMatic-3.83.6.20250705-ccu3" zur "OpenCCU-3.83.6.20251025-ccu3". Seit dem ist eines von 6 HMW-IO-12-Sw7-DR Modulen mit unreach gekennzeichnet und entsprechend nicht erreichbar. Die im Modul angelegten Direktverknüpfungen funktionieren. Wurde eine solche betätigt verschwindet erst mal das "unreach" für eine gewisse Zeit und es ist bedienbar über die CCU WebUi
Nach langem suchen und probieren habe ich die letzte Raspberry Firmware installiert und alles ist wie gahabt. Ein erneutes Update zu OpenCCU bringt sofort wieder den Fehler zu Tage.

Hat da ggfs. jemand ähnliche erfahrungen gemacht? Hat jemand eine Idee? Wird das Homematic Wired System nicht mehr unterstützt?
Danke und Gruß R.

[paleluc]

Ich habe ähnliche Erfahrungen mit OpenCCU auf einem Raspi 3B, bei mir sind sogar eine ganze Reihe von HM Wired Geräten betroffen. Bevorzugt tritt das auf, nachdem die CCU neu gestartet wurde. Auch der Effekt, dass das jeweilige Gerät nach Betätigen der Direktverknüpfung wieder funktioniert, ist bei mir derselbe. Die unreach-Markierung bleibt dann zwar sticky erhalten, aber immerhin läuft es dann wieder.

Hinweise, dass HM Wired nicht mehr unterstützt werden soll, finde ich nirgends. Die aktuelle Situation ist jedenfalls ziemlich doof, ich habe nur wenig Lust, nach jedem Restart durchs Haus zu laufen und sämtliche Taster 1x zu betätigen. Ideen fehlen mir leider auch. Vermutlich werde ich wohl auch auf das letzte Raspberry-Release downgraden.

[jens-maus]

Natürlich ist HM-Wired und wird HM-Wired weiterhin supported. Wenn das also ein generelles Problem ist müsstet ihr HM-Wired leidgeplagten euch irgendwie ggf. zusammentun und das Problem genauer unter die Lupe nehmen, denn aktuell haben wir keinen Core-OpenCCU-Entwickler onboard der selbst ein HM-Wired system hat. Selbst habe ich HMIP-Wired und das läuft problemlos. Für die Fehlersuche bräuchten wir aber mehr Details und logfiles mit höherem Debuglevel und dem willen auch am Ball zu bleiben wenn es um hands-on debugging/Analysen geht.

[paleluc]

Da bin ich ja froh, dass HM Wired weiterhin supported wird.
Ich werde heute Abend nochmal in Ruhe die CCU restarten und Logs ziehen.
Bei Analysen mache ich natürlich gerne mit, wo ich helfen kann.
Welche Details (außer den Logs) wären sonst noch hilfreich?

[paleluc]

Ich habe nun einen alten Raspi aus der Schublade gekramt und noch einmal ein komplett frisches OpenCCU aufgesetzt.
Mit diesem habe ich ausschließlich mein HM-Wired-RS485 Gateway verbunden und alle Wired-Geräte angelernt. Alles wird sofort erkannt und lässt sich einwandfrei steuern. Weitere Gateways oder Geräte (BidCos-RF oder Homematic IP) sind nicht angebunden.

Nach einem Restart zeigt sich das auf meiner produktiven CCU bereits beobachtete Verhalten: Beim ersten Versuch, ein Gerät unter "Status und Bedienung" anzuzeigen oder zu steuern geht dieses dauerhaft auf UNREACH.

Ein ausführliches Log habe ich angehängt.

Nach einer Bedienung der Direktverbindung via Taster (im Log um 18:12 Uhr) ist das bediente Gerät wieder erreichbar.

openccu-2026-01-07.log

[jens-maus]

Das ist doch schon ein super Anfang @paleluc. Danke für das Logfile. Ich sehe da schon einige Fehler/Warnungen bzgl. hs485d. Da tauchen so sachen wie das hier auf:

Jan  7 18:10:47 openccu user.err hs485d: LGW_RPL_ANSWER ERROR - request was 53
Jan  7 18:10:47 openccu user.debug hs485d: HS485ControllerLGW::SendMessage(msg): Failed
Jan  7 18:10:47 openccu user.debug hs485d: HS485ControllerLGW::SendMessage(msg): Send failed...retrying
Jan  7 18:10:48 openccu user.err hs485d: LGW_RPL_ANSWER ERROR - request was 53
Jan  7 18:10:48 openccu user.debug hs485d: HS485ControllerLGW::SendMessage(msg): Failed
Jan  7 18:10:48 openccu user.debug hs485d: HS485ControllerLGW::SendMessage(msg): Send failed...retrying
Jan  7 18:10:48 openccu user.debug hs485d: Event: MEQ0515237:0.UNREACH=1
Jan  7 18:10:48 openccu user.debug hs485d: Event: MEQ0515237:0.STICKY_UNREACH=1
Jan  7 18:10:48 openccu user.err hs485d: HS485PhysicalDataInterfaceCommand::GetData SendMessage failed for LEVEL_GET
Jan  7 18:10:48 openccu user.err hs485d: HSSParameter::GetValue() id=WORKING failed getting physical value.
Jan  7 18:10:48 openccu user.debug hs485d: HSSXmlRpcEventDispatcher::Handle send 1 events
Jan  7 18:10:48 openccu user.debug hs485d: HSSXmlRpcEventDispatcher::Handle send 2 events
Jan  7 18:10:48 openccu local0.info ReGaHss: Info: Event="MEQ0515237:0"."UNREACH"=1 [execute():iseXmlRpc.cpp:334]

Was ich allerdings bräuchte waren händische Marker in dem Logfile an welchen Stellen

1. Du versuchst hast manuell ein HMW Aktor zu schalten/bedienen und darauf dann welche Fehlermeldungen/Logausgaben genau folgen.
2. Du den Aktor dann manuell am Gerät bedient hast und welche Fehlermeldungen dann genau folgen
3. Der Aktor dann geht und du dann genau das gleiche machst wie unter Punkt 1 und dann welche Logmeldungen (eben keine Fehlermeldungen mehr) folgen.

Wenn du also dies noch einmal nachstellen könntest und mir dann genau das Logfile so aufgesplittet lieferst kann ich mir dann entsprechend im hs485d Quellcode mal anschauen ob mir da was konkretes auffällt was auf nicht funktionierende Bedienung und die entsprechenden hs485d bezogenen Logausgaben bezogen ist.

[paleluc]

Hallo @jens-maus, ich habe das noch einmal nachgestellt und entsprechende Markierungen im Logfile eingefügt.
openccu-2026-01-07-marked.log

Wenn ich irgendwelche Entwicklungs- oder Debuggingversionen ausprobieren soll, wäre das kein Problem.
Ich habe ja jetzt eine Spiel- und Testumgebung.

[jens-maus]

Danke. Ich sehe gerade das dein Testsystem wohl ein Raspberry Pi 2 Model B Rev 1.1 ist, richtig? Das ist ja dann ein 32bit System. Entspricht das auch deinem produktiven System oder ist das ein anderer Pi? Mich würde vor allem interessieren ob das ggf. mit einem Pi3 vielleicht geht?

[paleluc]

Richtig. Das Testsystem, auf dem ich alles nochmal nachgestellt habe, ist noch 32bit.
Produktiv nutze ich einen Pi 3 B+. Das Problem tritt also sowohl mit 32bit als auch mit 64bit auf.

[jens-maus]

Richtig. Das Testsystem, auf dem ich alles nochmal nachgestellt habe, ist noch 32bit. Produktiv nutze ich einen Pi 3 B+. Das Problem tritt also sowohl mit 32bit als auch mit 64bit auf.

Dann schreib mir mal bitte eine direkte Email damit wir Testversionen austauschen können.

[jens-maus]

Kurze Rückmeldung hier zu diesem Thema: Zusammen mit @paleluc konnte ich jetzt den Fehler im hs485d daemon (der für die HM-Wired Kommunikation zuständig ist) eingrenzen und dort auch beseitigen. Es scheint wohl ein Fehler im hs485d daemon zu sein der durch die Implementierung der 64bit Unterstützung reingewandert ist und wohl das erste mal in der RaspberryMatic 3.83.6.20250705 aufgetreten ist. Konkret passiert es hier wohl seit dieser Version das beim Neuanlernen von HM-Wired Geräten die Geräteinformationen die unter /etc/config/hs485d in *.dev Dateien gespeichert werden invalid sind. Konkret sieht man das dadurch:

In der 3.81.5.20250527 wurden z.B. die folgenden Dinge dort gespeichert:

<device serial="MEQ0515487" type="HMW-LC-Sw2-DR" sysinfo="11000306" address="0x00013B38“>

Und mit der 3.83.6.20250705 (und folgende) wird hier die address leider nicht mehr in hexadezimaler Form gespeichert, sondern falsch als Integerwert dort abgelegt:

<device serial="MEQ0515487" type="HMW-LC-Sw2-DR" sysinfo="11000306" address="0x00080696“>

Wie schon erwähnt konnte ich dank Hilfe von @paleluc das Problem recht schnell eingrenzen und entsprechend dann beseitigen. D.h. mit dem nächsten OpenCCU Release sollte das Problem dann beseitigt sein. Für Betroffene bedeutet dies allerdings, das sie danach die betroffenen Geräte jedoch neu anlernen müssten oder die address-Einträge in den "defekten" *.dev Dateien korrigieren (d.h. die "Integer" werte in hexadezimaler form dort niederlegen).

Und natürlich hier nochmal explizit ein dickes Danke an @paleluc für die Unterstützung und das Testen!

[TobiasSt78]

Hallo Jens,
vielen Dank, dass Du den Fehler schnell eingrenzen konntest und auch schon den "Work-Around" erwähnst.

Ich bin leider mit recht großer Installation (16 Wired Geräte) nun auch betroffen und habe erst jetzt den Beitrag gesehen, also nachdem ich erste 12/7 Komponenten bereits getauscht habe, die Busleitung neu verdrahtet, OpenCCU neu aufgesetzt...

Bei mir fiel erst 1 dann 3 dann 8 und gestern nach einem Reboot gleich 10 Geräte am Stück aus und diese hatten nicht nur Fehlermeldungen sondern nehmen teils auch keine Schaltbefehle mehr an.

Ich muss dringend das Problem zumindest provisorisch lösen, da auch meine Heizung und Lüftung darüber läuft. Die Lichter funktionieren zum Glück dank Direktverknüpfungen noch.

Ich teste gern die neue Beta und würde mich über Tipps freuen, wie ich das Problem bis dahin reduzieren kann. Umrechnen der Codes ist ja kein Problem, nur nach einem Reboot der CCU scheinen immer mehr Probleme dazu zu kommen. Könnte ich die Dateien auch aus einem Backup übernehmen?

Hängt mit diesem Fehler auch die seltsame Darstellung der Direktverknüpfungen zusammen? Teils lassen sich die Direktverknüpfungen nicht mehr löschen, teils sind die Geräte mit nichts verknüpft und ca. 50% aller Beschreibungen sind verschwunden.

Update:
Dank der Fehlerbeschreibung oben konnte ich mein Problem erst einmal lösen:
So bin ich vorgegangen:

1. Programme drucken in pdf (ja, in der zerstörten Version!)
2. Direktverkbüfungen drucken in pdf
3. Firmware downgrade auf: 3.81.5
4. Backup Einspielen vom Juli 2025
5. Programme erneut drucken in pdf
6. Direktverkbüfungen erneut drucken in pdf
7. in den letzten Monaten dazugekommene Geräte erneut anlernen
8. pdfs der Programme vorher zu jetzt (altes Backup) abgleichen und korrigieren
9. Direktverkpüfungen prüfen, kaputte löschen und neu erstellen.

Ergebnis:
ALLE Fehler sind nun weg und alles funktioniert wieder.
Änderungen oder neu Anlernen der Komponenten war nicht nötig.

[paleluc]

Hallo @TobiasSt78,
die seltsame Darstellung der Direktverknüpfungen einschließlich verschwundener Beschreibungen und Fehleranzeigen nach einem Reboot kommt mir bekannt vor. Diesen Effekt konnte ich bei den Versionen, die eine falsche Geräteadresse abgespeichert haben, ebenfalls beobachten.

In der aktuellen Snapshot-Version hat Jens den Fehler bereits behoben. Diese Version habe ich ausgiebig getestet und danach auch direkt auf mein Produktivsystem mit 15 Wired-Aktoren losgelassen.

Wenn Du lieber auf ein stable Release warten möchtest, bist Du aber auch mit der 3.81.5 auf der sicheren Seite.

[steviehs]

Ich hab die OpenCCU 3.85.7.20260124 bei mir installiert, aber hab immer noch den Stand, dass zwei HMW-IO-12-Sw7-DR von fünf "Gerätekommunikation gestört" auf :0 melden. Miteinander sprechen die aber super. Und Programme gehen auch alle.
... OK, ich hatte das oben nicht gelesen, aber die adressen der Meckerdevices waren schon hex. Nun, nach zwei OpenCCU restarts, waren alle devices erkannt....

[jens-maus]

Dann probier mal die quasi "drüberzulernen". D.h. neu in der OpenCCU Anlernen lassen ohne diese dort zu löschen.

[steviehs]

das hatte ich glaub ich am Anfang als erstes probiert, war ja die einfachste Übung :-) Aber hat sich nix getan.
Aber jetzt ist alles grün, warum auch immer :-) Auf jeden Fall vielen vielen Dank für die ganze Arbeit! Ich hab so gar keine Lust, das Wired Zeugse zu ersetzen, vor allem weil der Schaltkasten rappelvoll ist. Das läuft jetzt seit Anno 2008.