attr IODev - wie versteh ich das richtig?

[Otto123]

Ich habe ja versucht die Entwicklung zu verfolgen, manchmal bin ich vielleicht über die Diskussion nur drüber geflogen - aber wie ist es jetzt für das MQTT2_DEVICE?
In der Doku selbst taucht die Beschreibung in der Rubrik: common Attributes auf

... Das Attribut IODev muss nur gesetzt werden, wenn mehr als ein physisches Device fähig ist, Signale von diesem logischen Device zu empfangen.

Ok, find ich verständlich und eindeutig.
Etwas verwirrend finde ich, dass bei der commandref zu MQTT2_DEVICE nicht auf die drei common attributes sondern nur auf die zwei disabled.* verlinkt wird. In der interaktiven Erklärung beim attribute jedoch taucht es auf.

In mqtt2.template wird an mind. 46 Stellen 'IODev' gefunden - im groben drüberschauen wird damit AttrVal(....,'IODev',...) gelesen.
Ich weiß nicht genau seit wann, aber attr IODev wird bei autocreate des MQTT2_Devices nicht mehr erzeugt. Müssen wir jetzt die Templates alle anpassen?

Ich hatte das bei meinen "Devices" als grundlegendes Setup mit drin, das nehme ich jetzt einfach raus - kein Problem - aber generell richtig/zu empfehlen? Es macht es einfacher!

Gruß Otto

[Beta-User]

Teilantwort zu

In mqtt2.template wird an mind. 46 Stellen 'IODev' gefunden - im groben drüberschauen wird damit AttrVal(....,'IODev',...) gelesen.
Ich weiß nicht genau seit wann, aber attr IODev wird bei autocreate des MQTT2_Devices nicht mehr erzeugt. Müssen wir jetzt die Templates alle anpassen?

mqtt2.template setzt in der Regel das IODev nicht als Attribut, es wird aber in einigen Fällen benötigt, damit entsprechende Konfigurations-publishes abgesetzt werden können. Daher wird der Ersatzwert aus dem Internal gelesen, was mAn. eigentlich immer funktionieren sollte. Mit dieser Lösung wird mAn. die "übliche Priorität" gewahrt (User-Vorgabe ist wichtiger als "besseres Wissen" des Moduls).

Daneben ist IODev neuerdings als (weiteres) "spezielles Reading" vom generellen Löschen ausgenommen, um auch da Brüche zu vermeiden.

Seit der Umstellung sind auch keine Berichte mehr hier aufgetaucht, dass etwas nicht funktioniert, von daher scheint der aktuelle Stand an der Stelle ok zu sein.

Ich hatte das bei meinen "Devices" als grundlegendes Setup mit drin, das nehme ich jetzt einfach raus - kein Problem - aber generell richtig/zu empfehlen?

Was externe Dienste im allgemeinen angeht, (die bei "deinen" attrTemplate häufiger zugrunde liegen) sehe ich v.a. da dann eine erhöhte Wahrscheinlichkeit, dass tatsächlich identische Topics von verschiedenen Quellen zusammenkommen können und daher "Verwirrungsgefahr" droht. Würde daraus die Schlussfolgerung ziehen, dass man "irgendwo" (desc/comment?) jeweils klarstellen sollte, dass man als User selbst das Attribut setzen sollte, wenn man mehr wie eine externe Instanz hat und das nicht auf andere Weise "entwirren" kann. Topic-Pfad-Anpassung würde ich vom Bauchgefühl her tendenziell zu diesem Zweck bevorzugen.
Evtl. _könnte_ man dazu RADIO_Options vorsehen?

[rudolfkoenig]

... Das Attribut IODev muss nur gesetzt werden, wenn mehr als ein physisches Device fähig ist, Signale von diesem logischen Device zu empfangen.

Ist etwas komplizierter.

Kurz: das Attribut sollte im Normalfall nicht gesetzt werden.

Lang: beim autocreate wird gemeldet, ueber welchen Kanal die MQTT Daten reingekommen sind, und dieses IODev wird im Reading gespeichert. Das Speichern ist deswegen notwendig, weil sonst beim config Reinlesen einem MQTT2_DEVICE immer das (in der fhem.cfg) zuletzt definierte MQTT2_CLIENT oder MQTT2_SERVER zugewiesen wird. Das Attribut wird benoetigt, wenn diese Zuordnung dem Benutzer nicht mehr passt, z.Bsp. weil mehrere Server zusammengelegt werden.

Neu: die automatische Zuweisung setzt ein Reading, damit der Benutzer nicht mit dem System kaempfen muss.

[Otto123]

Dann müsste man das eigentlich so auslesen?

Code Auswählen Erweitern

AttrVal('DEVICE','IODev',ReadingsVal('DEVICE','IODev',InternalVal('DEVICE','IODev',undef))

[Beta-User]

Na ja, vielleicht...

"Eigentlich" sollte es reichen, nur auf das Internal zu schauen . AssignIoPort() müßte zum Zeitpunkt des Anwendens von attrTemplates immer "durch" sein, von daher sollte das Internal auch immer vorhanden sein, ganz unabhängig davon, ob es jetzt aus Attribut oder Reading befüllt wird - ich war nur nicht so "mutig", mich darauf zu verlassen und/oder zu faul, nachzusehen, ob das Internal auch in den älteren fhem.pl-Varianten vorhanden ist (es soll ja User geben, die ggf. nur die attrTemplate-Files aktualisieren...).

[rudolfkoenig]

Der Haken mit InternalVal/IODev ist, dass man da ein Hash zurueckkriegt:

Code Auswählen Erweitern

fhem> { InternalVal("ks", "IODev", undef) }
HASH(0x5638fad4e800)
fhem> { InternalVal("ks", "IODev", undef)->{NAME} }
m2s
fhem> { InternalVal("ks2", "IODev", undef)->{NAME} }
Can't use an undefined value as a HASH reference at (eval 1412199) line 1.

fhem> { InternalVal("ks2", "IODev", {NAME=>"Undefined"})->{NAME} }
Undefined


War wohl nicht die Kluegste aller Entscheidungen.

[Otto123]

ok in mqtt2.template ist durchgängig die Variante gewählt:
InternalVal('DEVICE', 'IODev', undef)->{NAME}
die müsste dann so geändert werden:

Code Auswählen Erweitern

AttrVal('DEVICE','IODev', ReadingsVal('DEVICE','IODev', InternalVal('DEVICE','IODev', {NAME=>"Undefined"})->{NAME})

Oder man verlässt sich konsequent darauf, dass in InternalVal immer die "Wahrheit" steht!?

Gerade probiert: MQTT2_DEVICE angelegt ohne attr IODev aber mit AttrTemplate -> InternalVal IODev wird gesetzt, alles funktioniert! Kein Reading IODev, kein attr IODev!
Neustart FHEM -> Reading IODev wird angelegt.

[Beta-User]

  da war doch was  ...

mqtt2.template berücksichtigt das, und man muss es eben wissen, dass man keinen Klartextnamen zurückbekommt. Finde es eigentlich aus Developer-Sicht ganz ok, dass man nicht umständlich in $defs nach dem Hash suchen muss, wenn man das IO haben will...

Oder man verlässt sich konsequent darauf, dass in InternalVal immer die "Wahrheit" steht!?

Imo ist das Risiko überschaubar: undef->{NAME} gibt auch undef zurück, der User erhält eine Rückfrage, schlimmstenfalls wird mal eine Hash-Kette erstellt, die sonst nicht exisitieren würde => (sehr kleiner) unnötiger Speicherverbrauch? Rückfrage bedeutet: User ist überfordert oder erkennt, dass irgendwas schräg hängt. Ersteres ist schade, aber kaum zu vermeiden, letzteres hilfreich.

Falls ich doch (mal wieder) was übersehen haben sollte, bitte ich um einen entsprechenden Schubs...

[LuckyDay]

Wenn ich es richtig verstehe

-ich nutze kein statefile-> da immer alt nach Stromausfall
deswegen liegt bei mir in  /tmp/fhem.save

und ich habe mehr wie ein I/O Device z.B. bei MQTT
dann ist es Pflicht das richtige I/O Device per attr zu setzen!?
weil sonst das senden irgendwie per Los entschieden wird? also so wie Linux die USB device bei Neustart behandelt? 

Oder sehe ich das jetzt falsch, oder ändert sich das Verhalten noch mal?

[rudolfkoenig]

Wie kuerzlich irgendwo geschrieben: es ist nicht das Los, sondern die Reihenfolge in der fhem.cfg. Beim Definieren von MQTT2_DEVICE wird das zuletzt definierte MQTT2_CLIENT oder MQTT2_SERVER (oder was halt noch kompatibel ist) zugewiesen. Reading / Attribut ueberschreiben dieses Verhalten.