KNX-Aktor mit Rückmeldung ansteuern

[Beta-User]

Nein, siehe:

OK, dann war die Frage ja vermutlich doch berechtigt:

Warum dann nicht "state" via "get" abfragen?

Tendenziell wäre es m.E. sinnvoll, auch das Wiki dahingehend nochmal durchzusehen und ggf. zwei Beispiele zu machen, eines für "on/off-Aktor" und irgendwas anderes, wo es wirklich um ein _anderes_ Reading geht.

Was die Statusabfrage nach FHEM-Start angeht: CUL_HM macht das afaik bei mehr oder weniger allen Devices automatisch. Wäre vielleicht eine Idee für eine (optionale?) Erweiterung. "Blöd" ist nur, dass dazu eine NotifyFn eingebaut ist, die dann bei allen bis auf einer CUL_HM-Instanz deaktiviert wird, Timer-basiert wäre einfacher (die NotifyFn hat dort aber ihre Berechtigung, weil sehr früh die IO's initialisiert werden müssen).

Bewässerung sieht bei mit devStateIcon-mäßig z.B. so aus (Farbe ist nicht so meins):

Code: [Auswählen]

attr <device> devStateIcon on:sani_sprinkling:off off:sani_water_tap:on

[erwin]

Warum dann nicht "state" via "get" abfragen?

Versteh ich jetzt nicht ganz:
Ohne jedes "spezielle Attribut" zeigt 'state' den Zustand jenes readings, dass als letztes upgedated worden ist. Damit ist FHEM im "normalen Betrieb" immer aktuell.
Wenn man nach einem längeren FHEM Ausfall den realen Zustand in FHEM wiederherstellen will, macht man ein:

get <device> status

(in diesem Beispiel) - damit wird das entsprechende reading 'status' UND state upgedated.

Falls man alle (abfragbaren) KNX-devices updaten will, gibts eine Utility Funktion:

Code: [Auswählen]

KNX_scan() siehe cmdref - Die Funktion sucht alle definierten KNX-Devices zusammen und macht ein 'get ....' auf alle, die potentiell Antworten können. - Es gibt KNX-Aktoren bzw. GA-Addressen (in FHEM mit set-option definiert) die nur msg's empfangen können und nichts Richtung FHEM senden.
..wobei es nicht ideal ist, das im global:INITIALIZED notify ohne Verzögerung auszulösen, weil da unter Umständen das FHEM-KNX-IO-Device seinen initial Protokol Handshake mit dem KNX-Gateway noch nicht fertig hat!

Das wiki muß ich mir nochmals ansehen....

[Beta-User]

Versteh ich jetzt nicht ganz:
[...] damit wird das entsprechende reading 'status' UND state upgedated.

Ah, das war mir mangels näherer Kenntnis des Moduls entgangen... Da hat mich das mit stateFormat aus der Bahn geworfen (das dann aber mAn. insgesamt keinen Sinn macht) .

..wobei es nicht ideal ist, das im global:INITIALIZED notify ohne Verzögerung auszulösen, weil da unter Umständen das FHEM-KNX-IO-Device seinen initial Protokol Handshake mit dem KNX-Gateway noch nicht fertig hat!

Ja, ist bei CUL_HM ähnlich. Da wird die NotifyFn auf "INITIALIZED" auch erst mal nur dazu genutzt, die IO's zu initialisieren, die Statusabfrage kommt dann erst später per Timer (der aus der NotifyFn heraus gesetzt wird), und dann (soweit ich das noch korrekt im Kopf habe) auch nur für Devices, die nicht schon sowieso irgendwas zwischendurch gemeldet hatten. (Die interne Datenverwaltung dazu ist - na ja - nennen wir es nicht ganz trivial...).