VCCU - listDevice zeigt altes HMLAN

[blueberry63]

Das Thema wurde aus "Anfänger" hierhin verschoben


Hallo,

ich habe bei mir einen von zwei HMLAN durch ein HMUARTGW ersetzt und zunächst das eine HMLAN per "disable" deaktiviert und vom Netz genommen. Nun ist mir aber aufgefallen, dass nach jedem Update und Neustart von FHEM das deaktivierte HMLAN in der VCCU-Geräteliste bei vielen Geräten noch gesetzt ist.

Hat jemand eine Erklärung bzw. kann man das korrigieren?

Gruß
Blueberry63

[budy]

Moin,

na ja, das kommt ein wenig drauf an... die IODev in den einzelnen devices wird normalerweise erst aktualisiert, wenn das Device auch von einem anderen IO ein Funktelegramm empfangen hat.

Lassen sich diese Devices denn steuern? Ein List eines dieser Devices könnte hier auch für Klarheit sorgen.

Gruß,
Stephan

[blueberry63]

Die Devices lassen sich alle einwandfrei schalten. Nach einiger Zeit wird die Liste auch einigermaßen "korrigiert", heißt die CUL-Zuordnung passt zu den RSSI-Werten. Aber nach dem nächsten Neustart stimmt wieder nichts mehr!
Gruß Markus

[Otto123]

Hi,

ich habe bei mir einen von zwei HMLAN durch ein HMUARTGW ersetzt und zunächst das eine HMLAN per "disable" deaktiviert

sorry aber HMLAN kennt kein disable!
set <IO> close wirkt nur bis zum Neustart
attr <IO> dummy 1 wirkt dauerhaft.

Gruß Otto

[Benni]

Otto,

der Satz ging aber noch weiter:

zunächst das eine HMLAN per "disable" deaktiviert und vom Netz genommen.

Vom Netz nehmen (egal welches Kabel gezogen wird) wirkt noch sicherer als dummy

Kann es sein, dass die fraglichen Informationen im statefile gespeichert werden?

Gruß Benni.

[blueberry63]

attr <IO> dummy 1 wirkt dauerhaft.

...genauso habe ich es gemacht. Sorry, dass ich mich so unklar ausgedrückt habe.

Gruß
Blueberry63

[Otto123]

Hallo Benni,

ja Du hast Recht. Aber "disable" gibts nicht, ich weiß nicht was blueberry63 damit meint und was er gemacht hat.
Im Zweifelsfall geht die VCCU nach einem Neustart von einem existierenden HMLAN aus und bekommt erst nach geraumer Zeit mit, dass der nicht richtig mitmachen will (weil ja gar nicht aktiv).

Nach einiger Zeit wird die Liste auch einigermaßen "korrigiert", heißt die CUL-Zuordnung passt zu den RSSI-Werten. Aber nach dem nächsten Neustart stimmt wieder nichts mehr!

Nach der ersten Aussage halte ich diese auch für etwas wage. Leider steht da außer " die Welt ist schlecht" nicht wirklich etwas verwertbares drin. 

Da würde jetzt mal ein list von einem betroffenen Device unmittelbar nach dem Neustart und nach "einiger Zeit" vielmehr Licht in die Glaskugel werfen. 

Gruß Otto

[blueberry63]

Ihr habt ja recht: ich werde mich am Wochenende etwas intensiver mit dem Thema beschäftigen und Euch mehr "Futter" liefern.

Gruß
Blueberry63

[budy]

Fürs erste reicht es ja auch, wenn man den HMLAN auf "close" setzt... am Ende sollte man den aber sicherlich sauber aus FHEM  entfernen.

Gruß,
Stephan

[Otto123]

Hi Stephan,

er hat doch aber scheinbar ein Problem nach dem neustart 

Gruß Otto

[budy]

Moin Otto,

na ja, mal sehen, was Blueberry am Wochenende an Infos beibringt...

Gruß,
Stephan

[automatisierer]

Fürs erste reicht es ja auch, wenn man den HMLAN auf "close" setzt... am Ende sollte man den aber sicherlich sauber aus FHEM  entfernen.

Gruß,
Stephan

Wo ist das Problem? Wenn der als Hardware nicht mehr existent ist, dann ein 'delete HMlan' und das Ding ist weg - wozu noch mit 'close' oder 'dummy' arbeiten? Das kann man machen, wenn man den IO temporär mal nicht nutzen will, aber in diesem Fall soll er ja aus der Installation entfernt werden, also lösch ihn einfach! Anschließend die IOlist der VCCU anpassen und ein 'set VCCU assignIO' danach 'save' und 'shutdown restart'.
Anschließend ist das LOG voll mit Meldungen aller: 'Device XYZ hat nen IODev welches nicht existiert - setzte IOabc als IODev'
Nach dem Neustart nochmal 'save' und dann sollte alles wieder ganz normal laufen.

So lange die HMlan Definition in FHEM besteht und die nicht auf dummy oder closed gesetzt ist, versucht FHEM eine Verbindung aufzubauen - das führt dazu, dass FHEM blockiert wird und das führt wiederum zu disconnects des HMlgw - denn der ist was timeouts angeht um einiges kleinlicher als die alten HMlan's

Falls du preffIO eingetragen hast, kannst du dir die Devices anzeigen lassen, indem du 'list a:IOgrp=vccu:HMlan' (vccu > in Name deiner VCCU und HMlan > in Namen des entfernten HMlan ändern) in die FHEM Befehlszeile eingibst. Dieses attribut wird nicht selbstständig geändert, dass musst du von hand machen.

[budy]

Wo ist das Problem? Wenn der als Hardware nicht mehr existent ist, dann ein 'delete HMlan' und das Ding ist weg - wozu noch mit 'close' oder 'dummy' arbeiten?

Nun ja, das meinte ich mit sauber entfernen...

[blueberry63]

Wo ist das Problem? Wenn der als Hardware nicht mehr existent ist, dann ein 'delete HMlan' und das Ding ist weg - wozu noch mit 'close' oder 'dummy' arbeiten?

Das ist natürlich richtig und das werde ich natürlich kurzfristig umsetzen.

Aber ich habe nun mal "vccu listDevice" vor und nach einem Neustart gemacht und hier ist das Ergebnis:

VORHER:

Code Auswählen Erweitern


devices using vccu
current IO / preferred
  HMLAN1 / --- FensterBadO
  HMLAN1 / --- HZK_BadU
  HMLAN1 / --- Rolladen_WZ_Tuer
  HMLAN1 / --- SCHALTER2fach_GH
  HMLAN1 / --- STRAHLER_CP
  HMUART1 / --- CUL_HM_HM_PBI_4_FM_1CDC04
  HMUART1 / --- CUL_HM_HM_SCI_3_FM_1E4F05
  HMUART1 / --- FensterBadU
  HMUART1 / --- FensterToil
  HMUART1 / --- HZK_AZIMMER
  HMUART1 / --- HZK_BadOL
  HMUART1 / --- HZK_BadOR
  HMUART1 / --- HZK_VRONI
  HMUART1 / --- Haustuer
  HMUART1 / --- Kellertuer
  HMUART1 / --- LichtEssz
  HMUART1 / --- Rolladen_Dachf
  HMUART1 / --- Rolladen_Essz
  HMUART1 / --- Rolladen_Kueche
  HMUART1 / --- Rolladen_WZ_Fenster
  HMUART1 / --- Rolladen_flur
  HMUART1 / --- SENS_THP
  HMUART1 / --- STD_HM1_LE
  HMUART1 / --- TempSensAuss
  HMUART1 / --- Terrassentuer
  HMUART1 / HMUART1 BattSchalter


NACHHER:

Code Auswählen Erweitern


  devices using vccu
current IO / preferred
  HMLAN1 / --- LichtEssz
  HMLAN1 / --- Rolladen_Dachf
  HMLAN1 / --- Rolladen_Essz
  HMLAN1 / --- SCHALTER2fach_GH
  HMLAN1 / HMUART1 BattSchalter
  HMLAN2 / --- CUL_HM_HM_SCI_3_FM_1E4F05
  HMLAN2 / --- FensterBadO
  HMLAN2 / --- FensterToil
  HMLAN2 / --- HZK_AZIMMER
  HMLAN2 / --- HZK_BadOL
  HMLAN2 / --- HZK_BadOR
  HMLAN2 / --- HZK_BadU
  HMLAN2 / --- HZK_VRONI
  HMLAN2 / --- Haustuer
  HMLAN2 / --- Kellertuer
  HMLAN2 / --- SENS_THP
  HMLAN2 / --- Terrassentuer
  HMUART1 / --- CUL_HM_HM_PBI_4_FM_1CDC04
  HMUART1 / --- FensterBadU
  HMUART1 / --- Rolladen_Kueche
  HMUART1 / --- Rolladen_WZ_Fenster
  HMUART1 / --- Rolladen_WZ_Tuer
  HMUART1 / --- Rolladen_flur
  HMUART1 / --- STD_HM1_LE
  HMUART1 / --- STRAHLER_CP
  HMUART1 / --- TempSensAuss


Anm.: HMLAN2 ist das deaktivierte Gerät

Gruß
Blueberry63

[martinp876]

Die vccu prüft offensichtlich nicht alle Möglichkeiten, wie eine Entitäten deaktiviert werden kann. Dummy ist nicht auf der Liste. Wenn du in der vccu ein io einträgst und es dann auf dummy setzt soll was passieren? Loeschen aus der Liste?  Oder nur nicht auswählen? Was bei ignorieren?....
Ich werde einmal nachdenken. Das muss evtl i. Io gepasst werden.