Mal wieder: attr HMLAN dummy x

topfi · 26 Januar 2021, 22:27:48

Nachdem ich eine Woche lang meine HMLANs über Kreuz getauscht und den Fehler gesucht habe, möchte ich Euch meine Erkenntnisse nicht vorenthalten. Ich habe hier:

*VCCU mit 3 IOs (HMLAN1, HMLAN2,HMUART)
*HMLAN1 und HMUART sind immer in Betrieb, HMLAN2 funktioniert als "Backup" und ist im Normalfall stromlos und mit

Code Auswählen

attr HMLAN2 dummy 1 stillgelegt.

*HMLAN2 wird mit einer Intertechno-Dose bei Bedarf zugeschaltet. Dabei soll das Attribut dummy gelöscht werden. Das ist aber gar nicht so simpel, wie gedacht:

1. Versuch

Code Auswählen

attr HMLAN2 dummy 0
schaltet zwar vermeintlich den HMLAN2 zu, der sendet aber nicht. Das ist nicht neu, dieses Verhalten kann man hier im Forum an einigen Stellen nachlesen. Meine ganze Homematic-Installation war mitunter in diesem Zustand nicht mehr bedienbar, auch nicht durch die anderen IOs.

2. Versuch

Code Auswählen

deleteattr HMLAN2 dummy
Das macht erstmal, was es soll. Mit einem

Code Auswählen

notify Steckdose_HMLAN2 on deleteattr HMLAN2 dummy schien erstmal alles zu funktionieren.

Das habe ich natürlich längst alles wieder vergessen.

Nun brauche ich aber seit einiger Zeit vorübergehend alle drei IOs gleichzeitig und fand plötzlich regelmäßig den HMLAN2 im Zustand "disconnected" vor, ohne dass ein Event generiert worden wäre oder das im Log gestanden hätte. Er war auch nicht einfach "closed", das hätte auch im Log gestanden. Und die Zeit, die beim reading "state disconnected" stand, war immer die aktuelle Uhrzeit beim Nachschauen, was die Fehlersuche sehr erschwert hat. Ich habe das zunächst aufs Netzwerk geschoben und munter getauscht: die Geräte, die Netzteile, die IP-Adressen. Das Problem blieb immer beim HMLAN2, das war schon mystisch.

Heute habe ich den Grund gefunden. Der Befehl

Code Auswählen

deleteattr HMLAN2 dummy versetzt den Adapter in diesen merkwürdigen Zustand, wenn das Attribut dummy vorher gar nicht gesetzt war. Weil Intertechno-Dosen keine Rückmeldung geben, setze ich die nachts immer auf ihren letzten regulären Zustand. Dabei wurde natürlich auch jedesmal überflüssigerweise das dummy-Attribut vom HMLAN2 gelöscht, obwohl der ja bereits aktiv war, mit beschriebenem Ergebnis.

Ich werde nun als Workaround das attr dummy nur löschen, wenn es vorher auch gesetzt war und vielleicht ein reopen hinterherschicken.

Vielleicht hilft die Erkenntnis ja mal jemandem, Zeit zu sparen. Merke: Das Attribut dummy ist bei HM-IOs ein zartes Pflänzchen.

frank · 27 Januar 2021, 07:09:07

wozu der ganze aufwand?
warum lässt du hmlan2 nicht einfach "online"?

topfi · 27 Januar 2021, 14:29:34

Der dritte IO war ursprünglich als Backup gedacht, zum gegebenenfalls Zuschalten bei Abwesenheit. Normalerweise genügen zwei IOs, der dritte stört nur, was man u.a. bei Fernbedienungen an zeitweisem Rotlicht oder an attack-Einträgen im Log gesehen hat.

Nun ist aber neuerdings zusätzlich noch ein Wintergarten (viel Eisen drumherum) zu versorgen mit Winmatic und Jalousieaktoren und die verlieren gern mal den Kontakt. Mit denen bin ich noch in der Experimentierphase, dabei habe ich das Verhalten bemerkt.

frank · 27 Januar 2021, 14:59:47

Zitatder dritte stört nur, was man u.a. bei Fernbedienungen an zeitweisem Rotlicht oder an attack-Einträgen im Log gesehen hat.

attack meldungen dürften gar nicht kommen.
da muss bei dir etwas falsch eingestellt sein.

ich würde eher diese probleme lösen, als deinen konstrukt nutzen.

haben wirklich alle devices sowohl attr IODev als auch attr IOgrp?

Code Auswählen

list TYPE=CUL_HM:FILTER=DEF=...... a:IODev a:IOgrp

topfi · 28 Januar 2021, 13:35:09

IOgrp ist natürlich überall auf vccu gesetzt (auch bei der vccu selbst nach einem Hinweis von Otto hier im Forum) und bei manchen Aktoren, die nah am IO sind, auf vccu:HMLAN1 oder 2. IODev setzt FHEM selbst auf das zuletzt (oder bei Definition?!) benutzte, das definiere ich nicht extra.

Ich habe eigentlich gar kein Problem damit, ich hätte das genauer schreiben sollen: zugeschaltet wird der dritte IO nur zum Experimentieren. Mir ging es hier um das Verhalten des HMLAN beim Setzen und Löschen des dummy-Attributs. Man erwartet doch nicht, dass der HMLAN in den disconnect geht, ohne ein Event zu generieren und ohne Logeintrag. Ich habe dadurch auch gelernt, dass es nicht sauber ist, ein Attribut zu löschen, ohne dass es gesetzt war. Nun frage ich das immer vorher ab.

Damu · 30 Januar 2021, 08:36:54

ZitatIOgrp ist natürlich überall auf vccu gesetzt (auch bei der vccu selbst nach einem Hinweis von Otto hier im Forum) und bei manchen Aktoren, die nah am IO sind, auf vccu:HMLAN1 oder 2. IODev setzt FHEM selbst auf das zuletzt (oder bei Definition?!) benutzte, das definiere ich nicht extra.

Auf den HM-LAN's hab ich das nicht gesetzt.
Auf der vccu hab ich es auf vccu gesetzt.

Ich würde alle HM-LAN immer online lassen, das sollte keine Probleme machen.
Haben doch alle so.
Denke das der Fehler woanders liegt.

ZitatIch habe dadurch auch gelernt, dass es nicht sauber ist, ein Attribut zu löschen, ohne dass es gesetzt war.

Verstehe ich nicht.
Was nicht gesetzt ist kann doch nicht gelöscht werden?

topfi · 31 Januar 2021, 23:06:26

Oh je, bitte nicht alle verwirren.

Natürlich haben die HMLANs kein IOGrp Attribut. Gibt es doch gar nicht, wozu auch. Die vccu schon, und das hat auch eine Bewandtnis, siehe hier:
https://forum.fhem.de/index.php?topic=88621.0

Es gibt hier keinen Fehler und ich habe Gründe, zu Testzwecken manchmal einen HMLAN abzuschalten.
Natürlich kann ich einen Löschbefehl schicken, obwohl nichts gesetzt war. Im besten Fall passiert nichts oder es gibt eine Fehlermeldung. Hier passiert aber etwas anderes, worauf ich hinweisen wollte.

Ob Sinn oder Unsinn, mitunter steckt aus Versehen irgendwo so ein vergessener deleteattr Befehl. Dann wundert man sich über das Verhalten der HMLANs und sucht den Grund und mitunter mehr als ein paar Stunden herum.