VCCU und AES

[Benni]

Guten Morgen allerseits!

Also ich habe die Logzeile nicht deaktiviert, sondern um den Namen des Device erweitert, dem ein neuer IO zugewiesen werden soll.

Nachdem ich die Geräte identifizieren konnte, war das Problem und damit die  Lösung auch schnell gefunden:
Ich hatte noch 3 HM-Devices, denen im Attibut IODev ein HMUART3 zugewiesen war.
Diesen gibt es aber seit gestern nicht mehr in meiner Installation.
Sprich er wurde durch die TCP232-Variante ersetzt und das HMUART3-Device in FHEM aus aus der IOList der vccu entfernt und auf dummy=1 gesetzt.

Ich habe also für diese 3 Devices in IOGrp meine vccu eingetragen (so wie es sich gehört!) und seither ist Ruhe!
Warum dort im IODev noch ein HMUART direkt eingetragen war kann ich nicht sagen, ich "fahre" eigentlich schon seit Ewigkeiten mit einer vccu.

Tipp.: Wenn die Log-Meldung von Haus aus etwas ausführlicher gewesen wäre, wäre ich mit dem Ding gar nicht erst hier aufgeschlagen

Vielen Dank für den Schubs in den Code
und einen entspannten Sonntag wünsche ich!

gb#

Edit:
Inzwischen habe ich auch verstanden, warum die (preferred) IO-Zuweisung nicht funktioniert hat:
fhem_setIoDev (aufgerufen in AssignIoPort) macht keine IODev-Zuweisung, wenn ein IO über das Attribut IODev bereits festgelegt ist.
CUL_HM wollte aber unbedingt ein neues IO mittels AssignIOPort zuweisen, weil das bisher im Reading IODev eingetragene nicht mehr als IO verfügbar war und hat im Anschluss festgestellt, die Zuweisung schlug, warum auch immer fehl, weil im Reading IODev immer noch der alte IO drin steht.

Edit2:
Möglicherweise habe ich im ersten Edit noch irgendwo Reading und Internal durcheinander geworfen.
Es ist aber auch echt verwirrend, dass es IODev in allen 3 Bereichen (Attribute, Reading und Internal) gibt.

[frank]

moin benni,

Ich hatte noch 3 HM-Devices, denen im Attibut IODev ein HMUART3 zugewiesen war.

gab es dort kein attr IOgrp?
gab es attr IOgrp dort noch nie? oder ist es durch ein update abhanden gekommen?
immer nur attr IODev alleine?

beide attribute sind verboten, dieser fall sollte gar nicht mehr vorkommen können.
ansonsten frage ich mich gerade, ob ein mischbetrieb, mit und ohne vccu, überhaupt vorgesehen ist?


edit:

Diesen gibt es aber seit gestern nicht mehr in meiner Installation.
Sprich er wurde durch die TCP232-Variante ersetzt und das HMUART3-Device in FHEM aus aus der IOList der vccu entfernt und auf dummy=1 gesetzt.

für AssignIoPort ist dummy=1 kein kriterium zum ausschluss, für cul_hm aber schon.

Ich habe also für diese 3 Devices in IOGrp meine vccu eingetragen (so wie es sich gehört!) und seither ist Ruhe!

ich meine: stationäre devices sollten besser immer mindestens ein prefered io bekommen.

[Benni]

Moin frank,

moin benni,
gab es dort kein attr IOgrp?

Nö, nur IODev!

gab es attr IOgrp dort noch nie? oder ist es durch ein update abhanden gekommen?
immer nur attr IODev alleine?

Das kann ich dir beim besten Willen nicht zuverlässig beantworten.
Aber wie gesagt, arbeite ich schon seit Ewigkeiten mit einer vccu und lerne meine Devices generell auch nur über diese an. Die 3 betroffenen Devices sind eher jüngeren Datums also definitiv schon unter der vccu angelernt worden.

beide attribute sind verboten, dieser fall sollte gar nicht mehr vorkommen können.
ansonsten frage ich mich gerade, ob ein mischbetrieb, mit und ohne vccu, überhaupt vorgesehen ist?

Du meinst beide Attribute gleichzeitig sind verboten. IOgrp als einzelnes Attribut brauche ich ja für die vccu-Zuweisung. Bei den 3 o.g. Devices wurde das IODev-Attribut beim setzen von IOgrp auch korrekt gelöscht!

edit: für AssignIoPort ist dummy=1 kein kriterium zum ausschluss, für cul_hm aber schon.
ich meine: stationäre devices sollten besser immer mindestens ein prefered io bekommen.

Die prefered-Zuweisung für die stationären Devices über IOgrp nehme ich erst in ein paar Tagen vor, wenn ich für die beiden neuen IOs aussagefähige rssi-Werte habe.

gb#