KNX-Aktor mit Rückmeldung ansteuern

[jw9]

Hallo,

ich versuche das zweite Beispiel aus dem Wiki-Artikel umzusetzen:

Code: [Auswählen]

define Bewaesserung_Gemuese KNX 2/1/11:dpt1:EinAus 2/2/11:dpt1:Status:listenonly
attr Bewaesserung_Gemuese IODev KNXIF
attr Bewaesserung_Gemuese room Bewässerung
attr Bewaesserung_Gemuese group Bewaesserung_Gemuese
attr Bewaesserung_Gemuese sortby 1
attr Bewaesserung_Gemuese stateFormat Status
attr Bewaesserung_Gemuese devStateIcon off:FS20.off:on on:FS20.on:off
attr Bewaesserung_Gemuese webCmd EinAus
Doch leider wird das Icon nicht angezeigt. Es steht immer nur "Status" an der Stele wo das Icon sein sollte. Hat jemand eine Idee was da falsch sein könnte?

[baerm]

hi,
bin jetzt auch kein Profi. So habe ich die meisten bei mir definiert:

Code: [Auswählen]

defmod Bewaesserung_Gemuese KNX 2/1/11:dpt1:EinAus 2/2/11:dpt1:Status:listenonly
attr Bewaesserung_Gemuese IODev KNXIF
attr Bewaesserung_Gemuese cmdIcon on:rc_GREEN off:rc_RED STS:rc_INFO@yellow
attr Bewaesserung_Gemuese devStateIcon off:FS20.off:on on:FS20.on:off
attr Bewaesserung_Gemuese group Bewaesserung_Gemuese
attr Bewaesserung_Gemuese room Bewässerung
attr Bewaesserung_Gemuese sortby 1
attr Bewaesserung_Gemuese webCmd on:off
lg.

[erwin]

...ich vermute, es gibt kein reading "Status" in deinem Device, deswegen zeigt das DevstateIcon das Wort "Status".
Ursache: es ist bisher keine message von 2/2/11 vom Bus gekommen... evtl schickt der Aktor kein Feedback, oder die GA ist falsch? -> ETS)
Bitte um ein list Bewaesserung_Gemuese
Um das devstateicon zu testen kannst du mal das probieren:

Code: [Auswählen]

setReading Bewaesserung_Gemuese Status on
l.g. erwin

[jw9]

...ich vermute, es gibt kein reading "Status" in deinem Device, deswegen zeigt das DevstateIcon das Wort "Status".

In der Tat gibt es kein Reading "Status". Dafür aber ein Reading "Status-get"

Ursache: es ist bisher keine message von 2/2/11 vom Bus gekommen... evtl schickt der Aktor kein Feedback, oder die GA ist falsch? -> ETS)

Doch, die Message kommt. Wird auch im Eventlog angezeigt. Aber eben nicht als "Status" sondern als "Status-get"

Bitte um ein list Bewaesserung_Gemuese

Habe es allerdings umbenannt in gGemuese, weil ich das mitlerweile funktionierende device nicht mehr zurückändern will:

Code: [Auswählen]

Internals:
   DEF        2/1/11:dpt1:EinAus 2/2/11:dpt1:Status:listenonly
   DEVNAME    Bewaesserung_gGemuese
   FIRSTGADNAME EinAus
   FUUID      62643c72-f33f-4bd1-b377-b59c956ed963e047
   GETSTRING  EinAus:noArg
   IODev      KNXIF
   KNXIF_MSGCNT 5
   KNXIF_RAWMSG C01a01w0220b00
   KNXIF_TIME 2022-04-23 19:53:41
   LASTInputDev KNXIF
   MSGCNT     5
   NAME       Bewaesserung_gGemuese
   NR         72
   SETSTRING  on:noArg off:noArg EinAus:on,off,toggle
   STATE      on
   TYPE       KNX
   model      dpt1
   GADDETAILS:
     EinAus:
       CODE       0210b
       GROUP      2/1/11
       MODEL      dpt1
       NO         1
       OPTION     
       RDNAMEGET  EinAus-get
       RDNAMEPUT  EinAus-put
       RDNAMESET  EinAus-set
       SETLIST    :on,off,toggle
     Status:
       CODE       0220b
       GROUP      2/2/11
       MODEL      dpt1
       NO         2
       OPTION     listenonly
       RDNAMEGET  Status-get
       RDNAMEPUT  Status-put
       RDNAMESET  Status-set
       SETLIST    :on,off,toggle
   GADTABLE:
     0210b      EinAus
     0220b      Status
   Helper:
     DBLOG:
       Status:
         LogDB:
           TIME       1650736677.56088
           VALUE      on
       Status-get:
         LogDB:
           TIME       1650736421.13981
           VALUE      off
       last-sender:
         LogDB:
           TIME       1650736421.13981
           VALUE      1.10.1
       state:
         LogDB:
           TIME       1650736421.13981
           VALUE      off
   READINGS:
     2022-04-23 19:50:42   IODev           KNXIF
     2022-04-23 19:57:57   Status          on
     2022-04-23 19:53:41   Status-get      off
     2022-04-23 19:53:41   last-sender     1.10.1
     2022-04-23 19:53:41   state           off
Attributes:
   IODev      KNXIF
   devStateIcon off:FS20.off:on on:FS20.on:off
   group      Bewässerung
   room       Bewässerung
   sortby     8
   stateFormat Status
   webCmd     EinAus


Um das devstateicon zu testen kannst du mal das probieren:

Code: [Auswählen]

setReading Bewaesserung_Gemuese Status on

Nach diesem Befehl erscheint das Reading "Status" (wie oben im List zu sehen).

Gibt es irgendwo eine halbwegs verständliche Zusammenfassung zu devStateIcon, eventMap, stateRegex, webCmd, cmdIcon und Konsorten? Je mehr ich die commandref lese um so weniger verstehe ich...

[jw9]

So habe ich die meisten bei mir definiert:

Vielen Dank! Anlehnend an Dein Beispiel habe ich es jetzt auch am Laufen:

Code: [Auswählen]

define di.Autostart DOIF ([global:"INITIALIZED"]) ( get Bewaesserung_Gemuese status )

define Bewaesserung_Gemuese KNX 2/1/11:dpt1:EinAus 2/2/11:dpt1:status:get
attr Bewaesserung_Gemuese IODev KNXIF
attr Bewaesserung_Gemuese alias Gemuese
attr Bewaesserung_Gemuese room Bewässerung
attr Bewaesserung_Gemuese group Bewässerung
attr Bewaesserung_Gemuese sortby 3
attr Bewaesserung_Gemuese cmdIcon on:rc_GREEN off:rc_RED STS:rc_INFO@yellow
attr Bewaesserung_Gemuese devStateIcon on:FS20.on:off off:FS20.off:on
attr Bewaesserung_Gemuese webCmd on:off

define Bewaesserung_Gemuese_sommer   at *5:40:00 { if ((grep {$_==$month}        (5,6,7,8))       && !($mday%1)) { fhem("set Bewaesserung_Gemuese on-for-timer 1800") }}
define Bewaesserung_Gemuese_nebenzeit at *5:40:00 { if ((grep {$_==$month} (2,3,4,5,6,7,8,9)) && !($mday%2)) { fhem("set Bewaeserung_Gemuese on-for-timer 1800") }}

Die letzte verbleibende Unzulänglichkeit wäre ein schönes Symbol für die Bewässerung ;-)

[erwin]

Wenn du als reading 'status' haben willst - statt 'status-get' dann definierst du so:

Code: [Auswählen]

defmod Bewaesserung_Gemuese KNX 2/1/11:dpt1:EinAus 2/2/11:dpt1:status:get:nosuffix
attr  Bewaesserung_Gemuese stateFormat status

[jw9]

Wenn du als reading 'status' haben willst - statt 'status-get' dann definierst du so:

Code: [Auswählen]

defmod Bewaesserung_Gemuese KNX 2/1/11:dpt1:EinAus 2/2/11:dpt1:status:get:nosuffix
attr  Bewaesserung_Gemuese stateFormat status

Wollen tue ich das  nicht wirklich. Das stand halt im Wiki so drin, und so habe ich es übernommen.

Wie ich oben bereits angemerkt hatte, konnte ich keine halbwegs verständliche Beschreib ung dieser Zusammenhänge finden.

[erwin]

Wie ich oben bereits angemerkt hatte, konnte ich keine halbwegs verständliche Beschreib ung dieser Zusammenhänge finden.

mit

Code: [Auswählen]

help KNX kommst du unmittelbar zur cmdref -  da sind alle KNX-spezifischen Dinge beschrieben, bzw. gibts dort auch Links zu den allgemeinen Attributen.
Das KNX-Wiki kennst du ja bereits....
Falls du eine spezifische Frage/Problem hast,  kann ich dich gerne unterstützen.
l.g. erwin
PS: der Sinn von stateFormat status: Nur die Werte vom reading status werden ins Internal STATE kopiert, und damit relevant fürs devStateIcon.
Ohne stateFormat kommen auch die werte vom reading EinAus in state und damit (automatisch) ins Internal STATE....

Edit: Fehler korrigiert: StateFormat - danke Beta_User!
@Beta-User: reading 'status' ist ein frei wählbarer Name in diesem Kontext - wird in der def bestimmt - und ja, Groß/Kleinschreibung ist relevant!
Es geht darum ein: 'set <device> on' nicht ins STATE zu kopieren - sondern nur das Feedback vom Aktor (hier als reading 'status' definiert) nach STATE zu kopieren.

[Beta-User]

Interessehalber: Ist "status" (oder "Status") nicht identisch mit "state"? Warum dann nicht "state" via "get" abfragen?

Neben der Doppelung der Info ist v.a. auch "state" in FHEM ja allgemein etwas besonders in der Handhabung (was z.B. die automatische Übernahme nach STATE angeht, wenn stateFormat nicht gesetzt ist). stateFormat schreibt aber _nicht_ das Reading "state", das scheint ein Mißverständnis zu sein!

Für das Icon: sani_sprinkling ist zwischenzeitlich soweit geschrumpft, dass man das verwenden kann...

[Beta-User]

Betr. den edit: Wenn nur ein "Übergangszustand" in "state" soll, sollte das Modul mAn. genau das ermöglichen, also "set_on" nach state und z.B. ein automatischer Timer hinterher, der checkt, ob der Aktor das mitbekommen hat....
Und: das gehört imo nach state, nicht (!) nach STATE!

[jw9]

Für das Icon: sani_sprinkling ist zwischenzeitlich soweit geschrumpft, dass man das verwenden kann...

Ja, da gibt es auch noch das sprinkler_icon und sani_irrigation (gefällt mir am besten).

Aber alle drei taugen nur für "active". Für "inactive" sind leider keine passenden icons zu finden.

Die anderen Beiträge muss ich mir in Ruhe nochmal antun...

[erwin]

@Beta-User:
evtl. hab ich falsch formuliert, weil ich mich nur auf die Logik von devstateIcon fokussiert habe....

1) Das KNX-Modul schreibt niemals nach Internal STATE, das macht ausschließlich fhem.pl - wenn nicht durch stateFormat,... was anderes angegeben ist.
2) jede KNX-msg auf eine in der definition gefundene GA-Adresse erzeugt ein entsprechendes reading - Der reading name wird in der def bestimmt.
3) Jeder reading-Value wird auch nach reading state kopiert, ausser es wird durch KNX-Modul spezifische Attribute modifiziert/blockiert. (kommt in diesem Bsp. nicht vor)
Das zweite GA (2/2/11) in jw9's Beispiel ist die Rückmeldung vom Aktor. Der Aktor kann allerdings nicht nur von FHEM geschaltet werden (via GA 2/1/11), sondern z.b. auch von einem Wandtaster.

Es geht also nicht um einen Übergangszustand, sondern darum, dass im Internal STATE immer der aktuelle Status vom Aktor steht. - deswegen stateFormat auf das reading 'status'.
Für Übergangszustände hab ich ein Bsp. im Wiki. (verzögerte Rückmeldung)

@jw9: versuch mal:

Code: [Auswählen]

devStateIcon on:sprinkler_icon@red:off off:sprinkler_icon@green:on

[Beta-User]

Hmm, dann scheint das von der Ablauf-Logik her in etwa so zu sein wie bei ZWave, da kann auch "ewig" z.B. irgendeine Konfigurationsanweisung in "state" stehen bleiben (oder MQTT2_DEVICE ohne ergänzende Konfiguration). Soweit verstanden.

Aber warum "muss" die Rückmeldung vom Aktor nach "status" (oder einem anderen beliebigen Reading-Namen)? Gibt es einen "harten" Hinderungsgrund, das nicht nach "state" zu schreiben? Gerade bei einer Schaltanweisung "von woanders her" (z.B. einem Taster) wäre mir da Konsistenz wichtig!

Anders gesagt:
1. "STATE" wäre mir "zu volatil", da dem Zugriff des Users unterworfen. Für einen "on/off"-Aktor sollte im Reading "state" nach meinem Geschmack immer der Relay-Zustand abgebildet werden. Doppelungen derselben Info sollte man vermeiden.

STATE (stateFormat) und devStateIcon sind reine Darstellungsoptionen.

2. Wenn man "andere Readings" hat, die man manipulieren kann, sollte das auch via Modul durch entsprechende Konfigurationen abbildbar sein (das scheint aber der Fall zu sein), ähnlich wie MQTT2_DEVICE das mit "setStateList" macht (in "state" landet dann nur, was in dieser Liste steht, der Rest geht mit dem "set_"-Prefix in die entsprechenden Reading-Werte, z.B. "brightness"), bei Rückmeldung vom Aktor wird dann der von dort gemeldete Wert in das Reading geschrieben.

[Beta-User]

Nachtrag noch...

Wenn ich sowas sehe:

Code: [Auswählen]

   READINGS:
     2022-04-23 19:57:57   Status          on
     2022-04-23 19:53:41   state           off


stellt sich die Frage, ob es zwei Relays (oder allgemeiner: schaltbare Elemente) gibt. Wenn nein, stimmt was in der Konfiguration nicht, weil eine der beiden Angaben dann "falsch" sein muss...
(Oder zumindest irgendeiner Interpretation bedarf, die hier aber auch nicht für stateFormat vorgeschlagen war, damit zumindest STATE "stimmt").

[erwin]

Gibt es einen "harten" Hinderungsgrund, das nicht nach "state" zu schreiben

Nein, siehe:

3) Jeder reading-Value wird auch nach reading state kopiert

Die Ausnahmen treffen nur bei komplexen devices zu, die mittels KNX-spezifischen Attributen gesteuert werden. Ein simples Beispiel: ein Windspeed-Aktor sendet Werte in m/sec - die kommen genau so ins reading windspeed - im state wird mittels Attribute auf km/h umgerechnet...

Code: [Auswählen]

attr <device> stateCmd {sprintf("%.1f",(ReadingsNum($name,'windspeed',0) * 3.6))}Ich bevorzuge aber als Einheit für Windgeschwindigkeit: kn 
Das Problem wird dann virulent, wenn der Aktor z.b. zusätzlich zu on|off auch solche Werte wie Spannung/Strom/Leistung/%,.... liefert, dann muss man sehr genau steuern, welche Werte man in STATE (bzw via stateFormat) haben will - um ein vernüftiges devStateIcon darzustellen (oder auch mehrere....) und gleichzeitg in state einen konsistenten Wert, z.b. fürs logging....

   READINGS:
     2022-04-23 19:57:57   Status          on
     2022-04-23 19:53:41   state           off

Mit diesen Timestamps wäre was falsch, wenn allerdings 'state' eine späteren Timestamp als Status hat, könnte das von einem anderen reading stammen....und man könnte nicht mehr sagen ob richtig oder falsch.
PS: Das reading Status in jw9's def stammt vermutlich von dem Versuch: 'setreading <device> Status on', zu dem ich ihm geraten habe um das devStateIcon zu testen...(3. Beitrag)

Im Prinzip ist die Logik ähnlich zu MQTT2_DEVICE:
dort wird mittels Attr die Zuordnung Topic->readingName gemacht,
bei KNX mittels def GA-Addresse->readingName gemappt (optional mehrfach). - und jede KNX-msg auf eine definierte GA-Addresse erzeugt/updated ein entsprechendes reading
Die Logik was/wann  in STATE kommt, ist völlig standard FHEM, inkl. der FHEMWEB Attribute!