stop reserviertes Wort oder sonst ein Fehler?

[eiten]

Hallo zusammen,

ich bin gereade daran, ein AttrTemplate für einen zigbee-Rolladenaktor zu schreiben. Jetzt habe ich ein Problem und weiss nicht, ob "stop" ein reserviertes Wort in FHEM ist oder ob ich ein anderes Problem habe. Das Device schaut so aus:

Code Auswählen Erweitern


Internals:
   CFGFN     
   CID        zigbee_OG_Erik_Storen
   DEF        zigbee_OG_Erik_Storen
   DEVICETOPIC zigbee2mqtt/OG_Erik_Storen
   FUUID      602a2f0d-f33f-9f51-efad-85c70555c56dbc97
   IODev      MQTT2SERVER
   LASTInputDev MQTT2SERVER
   MQTT2SERVER_MSGCNT 590
   MQTT2SERVER_TIME 2021-02-16 17:50:20
   MSGCNT     590
   NAME       OG.Erik.Storen
   NR         9382
   STATE      100
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2021-02-16 16:16:39   associatedWith  SYS.zigbee
     2021-02-16 17:50:20   calibration     OFF
     2021-02-16 17:50:20   linkquality     81
     2021-02-16 17:50:20   motor_reversal  OFF
     2021-02-16 17:50:20   moving          STOP
     2021-02-16 17:50:20   position        100
     2021-02-16 17:49:27   state           open
Attributes:
   IODev      MQTT2SERVER
   devStateIcon up:fts_shutter_up:stop down:fts_shutter_down:stop 0:fts_shutter_100:open 10:fts_shutter_90: 20:fts_shutter_80: 30:fts_shutter_70: 40:fts_shutter_60: 50:fts_shutter_50: 60:fts_shutter:40: 70:fts_shutter_30: 80:fts_shutter_20: 90:fts_shutter_10: 100:fts_window_2w:close
   devicetopic zigbee2mqtt/OG_Erik_Storen
   eventMap   ON:on OFF:off STOP:stop UP:up DOWN:down
   genericDeviceType blinds
   getList    calibration:noArg calibration $DEVTOPIC/get {"calibration": ""}
   icon       fts_shutter
   model      zigbee2mqtt_Shutter_Switch
   readingList $DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }
   room       MQTT2_DEVICE
   setList    open:noArg $DEVICETOPIC/set {"state":"OPEN"}
stop:noArg $DEVICETOPIC/set {"state":"STOP"}
close:noArg $DEVICETOPIC/set {"state":"CLOSE"}
position:slider,0,5,100,1 $DEVICETOPIC/set {"position":"$EVTPART1"}
calibration:on,off $DEVICETOPIC/set {"calibration":"$EVTPART1"}
motor_reversal:on,off $DEVICETOPIC/set {"motor_reversal":"$EVTPART1"}
   stateFormat {my $moving = ReadingsVal($name, "moving", "stop"); $moving =~ /stop/i ? int(ReadingsVal($name, "position", "100")/10.0 + 0.5)*10 : $moving}
   webCmd     open:stop:close:position

Auf den Befehl

Code Auswählen Erweitern

set OG.Erik.Storen stop kommt als Antwort

Code Auswählen Erweitern

Unknown argument stop, choose one of open stop close position calibration motor_reversal off-till on-till off-till-overnight intervals blink off-for-timer on-for-timer toggle on-till-overnight attrTemplate. Ersetze ich das stop durch halt, also

Code Auswählen Erweitern

halt:noArg $DEVICETOPIC/set {"state":"STOP"} funktioniert alles wunderbar, ausser:

Het jemand ausserdem ein Ahnung, wieso die setextensions (off-till on-till) etc. hier erscheinen?

Danke und Gruss, Edi

[Beta-User]

"stop" wird auch an ähnlicher Stelle in anderen attrTemplate verwendet, das ist seltsam...
Evtl. spuckt dir da die eventMap rein? (ggf. durch die komplexe Form ersetzen {dev=>...})

Ansonsten kommen bei M2D immer SetExtensions-Befehle mit, indirekt hängt auch attrTemplate als Befehl da dran .

[rudolfkoenig]

Code Auswählen Erweitern

   eventMap   ON:on OFF:off STOP:stop UP:up DOWN:down

Macht aus dem vom Benutzer eingegebenen stop ein STOP, und so ein Befehl gibt es nicht.
Btw, mit "list -r" hat man es als Debugger etwas einfacher, des Problem nachzustellen.

[eiten]

Ah, dank euch Zwei, es war tatsächlich das eventMap.
Erster Versuch, abgeschaut beim Zigbee_Switch (funktioniert dort übrigens auch nicht...):

Code Auswählen Erweitern

attr OG.Erik.Storen eventMap { dev=>{'STOP'=>'stop', 'UP'=>'up', 'DOWN'=>'down', 'OFF'=>'off', 'ON'=>'on'} }
Funktioniert nicht, da nun jeder event, der ein STOP enthält, einfach durch stop ersetzt wird, also "moving: STOPW wird zu "stop".
2. Versuch:

Code Auswählen Erweitern

{ dev=>{'(.*)STOP'=>'$1stop', '(.*)UP'=>'$1up', '(.*)DOWN'=>'$1down', '(.*)ON'=>'$1on', '(.*)OFF'=>'$1off'} }
funktioniert schon besser, nun wird das event "moving: STOP" zu "moving: stop". ABER: das readingsVal zeigt immer noch STOP.

Habt ihr da eine Idee? Ich wollte eigentlich schon gerne das in Kleinbuchstaben, dann ist's kompatibel zum Beispiel zu den Shellies (ok, ausser der Reading-Namen, aber das kann ja dann mit einem jsonMap gefixt werden). Gibt's eigentlich irgendwo ne Übersicht/Standardisierung, welche Readings/sets bei welchen Geräteklassen wie heissen sollten?

Übrigens: bei meinen Experimenten habe ich festgestellt, dass die setExtensions kommen, sobald im eventMap ein on vorkommt.

Grüsse, Edi

[eiten]

Sorry, ich nochmal, ich habe jetzt ne Lösung, wenn evtl. auch nicht die sauberste: ein lc():

Code Auswählen Erweitern

attr OG.Erik.Storen readingList $DEVICETOPIC:.* { json2nameValue(lc($EVENT),'',$JSONMAP) }
und schon sind alle Readings und Events lowercase... hoffentlich hat das keine Nebeneffekte...
Ein uc bei der setList brauchts wohl nicht, zigbee2mqtt ist auch mit on und off happy.

LG, Edi

[Beta-User]

abgeschaut beim Zigbee_Switch (funktioniert dort übrigens auch nicht...):

...ist mir neu, und ehrlich gesagt wundert es mich, dass sich da bisher keiner beschwert hat (unterstellt, es geht um zigbee2mqtt_plug, zigbee2mqtt_2channel_split und zigbee2mqtt_3channel_split). Diese sind seit Sept. 2020 nicht angefasst (und vermutlich in dem Punkt schon viel länger so)...

Falls da nachweislich Handlungsbedarf besteht, bitte ich um offizielle Rückmeldung in "bugs" oder dem "zigbee2mqtt"-Thread ("läuft", oder so...), damit sich ggf. auch andere dazu äußern können.

Dass eventMap nur "oberflächlich" wirkt, ist bekannt, aber im Moment habe ich noch Skrupel, das "lc()" als großflächigen Problemlöser zu betrachten. Auch das sollte man ggf. dann in dem generellen Thread mal thematisieren...?

[eiten]

Ich habe nachgeschaut, du hast recht, das Event funktioniert, das hatte ich gar nie nachgeschaut. Was aber nicht funktioniert ist, wenn Du das zum Beispiel in einem DOIF verwendest (daher dachte ich, das funktioniert so nicht). Beispiel Tradfri Zwicshenstecker:

Code Auswählen Erweitern


defmod EG.Putzschrank.Router MQTT2_DEVICE zigbee_EG_Putzschrank_Router
attr EG.Putzschrank.Router IODev MQTT2SERVER
attr EG.Putzschrank.Router devicetopic zigbee2mqtt/EG_Putzschrank_Router
attr EG.Putzschrank.Router eventMap { dev=>{ON=>'on',OFF=>'off'} }
attr EG.Putzschrank.Router icon message_socket
attr EG.Putzschrank.Router model zigbee2mqtt_plug
attr EG.Putzschrank.Router readingList $DEVICETOPIC:.* { json2nameValue($EVENT) }\
zigbee2mqtt/EG_Putzschrank_Router/availability:.* availability
attr EG.Putzschrank.Router room MQTT2_DEVICE,Zentrale
attr EG.Putzschrank.Router setList on:noArg $DEVICETOPIC/set {"state":"ON"}\
  off:noArg $DEVICETOPIC/set {"state":"OFF"}\
  toggle:noArg $DEVICETOPIC/set {"state":"TOGGLE"}
attr EG.Putzschrank.Router setStateList on off toggle


Da muss man beim DOIF auf "ON" prüfen:

Code Auswählen Erweitern


defmod test1 DOIF ([EG.Putzschrank.Router:state] eq "ON") (setreading test1 test 1)
attr test1 do always

Im notify aber auf "on":

Code Auswählen Erweitern


defmod test2 notify EG.Putzschrank.Router:on setreading test2 test 1

Ich werde mal schauen, dass ich ein schönes Beispiel dazu kreieren kann und werde das dan wohl am besten in bugs(?) posten, da ja nicht nur zigbee2mqtt betrifft.[/code]

[Beta-User]

Na ja, das mit der Groß-/Kleinschreibung "großflächig" anzugehen, ist vermutlich keine Lösung, mit der viele seitherige User glücklich wären...

Für den Moment würde ich mal behaupten, dass "man" es eben wissen muss, wie das Event (bzw. der Reading-Wert) genau aussieht, und "gut ist". Die Welt ist eben an der Stelle bunt...

Gibt's eigentlich irgendwo ne Übersicht/Standardisierung, welche Readings/sets bei welchen Geräteklassen wie heissen sollten?

Gibt es (noch) nicht, siehe auch https://forum.fhem.de/index.php/topic,117933.0.html. Vorschläge (am besten vollständig ausgearbeitet und unter Berücksichtigung der Historie diverser Module) sind herzlich willkommen .

[eiten]

Danke Beta-User, der andere Thread ist so ziemlich genau das, was ich damit gemeint habe. Bin gerade an nem Yeelight Modul, und da stellte ich mir diese Fragen immer wieder.

[Beta-User]

Falls du dich als "Tester" (oder Developer) registrierst, kannst du dort auch schreiben.

Yeelight klingt nach Licht, und für Licht@MQTT2_DEVICE habe ich bisher folgende Marschroute:
- state => on/off, (wo ohne Klimmzüge möglich: Kleinschreibung)
- Helligkeit => was 0-100 liefert => pct,
                             0-255          => brightness
Rest ist meistens so, wie es halt vom Gerät kommt...

[eiten]

Sorry, hab Dich gerade mit PM zugemüllt. Wo registriere ich mich denn als Tester/Developer? Gefunden, sorry.

Ah, danke für das klar stellen von pct/brightness, das hätte ich gerade falsch gemacht. Wird allerdings nicht MQTT2_DEVICE, die kommunizieren über TCP und UDP.