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:
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 set OG.Erik.Storen stop kommt als Antwort 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 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
"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 ;) .
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.
Ah, dank euch Zwei, es war tatsächlich das eventMap.
Erster Versuch, abgeschaut beim Zigbee_Switch (funktioniert dort übrigens auch nicht...):
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:
{ 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
Sorry, ich nochmal, ich habe jetzt ne Lösung, wenn evtl. auch nicht die sauberste: ein lc():
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
Zitat von: eiten am 17 Februar 2021, 09:28:37
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...?
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:
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:
defmod test1 DOIF ([EG.Putzschrank.Router:state] eq "ON") (setreading test1 test 1)
attr test1 do always
Im notify aber auf "on":
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]
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...
Zitat von: eiten am 17 Februar 2021, 09:28:37
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 ;) .
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.
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...
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.