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
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
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
Hi,
Zitat von: blueberry63 am 16 Februar 2017, 11:31:19
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
Otto,
der Satz ging aber noch weiter:
Zitatzunä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.
Zitatattr <IO> dummy 1 wirkt dauerhaft.
...genauso habe ich es gemacht. Sorry, dass ich mich so unklar ausgedrückt habe.
Gruß
Blueberry63
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).
ZitatNach 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. ;D
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
Ihr habt ja recht: ich werde mich am Wochenende etwas intensiver mit dem Thema beschäftigen und Euch mehr "Futter" liefern.
Gruß
Blueberry63
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
Hi Stephan,
er hat doch aber scheinbar ein Problem nach dem neustart :-\
Gruß Otto
Moin Otto,
na ja, mal sehen, was Blueberry am Wochenende an Infos beibringt... ;)
Gruß,
Stephan
Zitat von: budy am 17 Februar 2017, 19:13:53
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.
Zitat von: automatisierer am 17 Februar 2017, 21:48:37
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...
ZitatWo 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:
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:
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
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.
Meiner Meinung nach müsste eine per Dummy deaktivierte Entity ignoriert werden. Ich habe aber keine Ahnung, was das für einen Aufwand bedeutet. Soll ich mein HMLAN2 zuerst einmal nicht löschen, um später beim Testen helfen zu können?
wenn bei einem HMLAN dummy gesetzt ist sollte der state immer "disconnected" sein. Ist das so bei dir?
Zitat von: blueberry63 am 18 Februar 2017, 19:58:02
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:
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:
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
Hab das mal nachgestellt, wenn ich einen meiner IO's auf 'dummy 1' setze, verwendet die vccu automatisch einen anderen IO. Nach einem FHEM Neustart, haben alle Devices einen HMlan oder HMlgw zugewiesen, der 'cond ok' ist und selbst die Devices, die den auf 'dummy 1' gesetzten IO als prefIO zugewiesen haben, haben einen der anderen als currentIO. Das ist doch genau das was passieren soll.
Das bei dir nach einem FHEM Neustart bei einigen Devices wieder der HMLAN2 auftaucht, könnte eventuell daran liegen, dass das irgendwo gespeichert ist - vielleicht solltest du mal 'save' machen bevor du einen Neustart machst.
Zitat von: martinp876 am 19 Februar 2017, 17:13:33
wenn bei einem HMLAN dummy gesetzt ist sollte der state immer "disconnected" sein. Ist das so bei dir?
bei mir ist das so...
bei mir auch
Zitatvielleicht solltest du mal 'save' machen bevor du einen Neustart machst
Das mache ich eigentlich immer vor einem Neustart. Gerade habe ich es nochmal ausprobiert: das gleiche Ergebnis wie sonst auch.
Kann es sein, dass die VCCU das Attribut "IODEV" setzt? Ich bin mir nicht ganz sicher, aber ich meine beobachtet zu haben, dass bei einigen Devices "IODEV" zu HMLAN2 wechselt, auch wenn ich vorher das Attribut gelöscht hatte.
Gruß
Blueberry63