MQTT2+Shelly: erste Konfiguration und template-Entwicklung

[draddy]

Frage

Code: [Auswählen]

attr DEVICE getList in_mode:noArg in_mode $\DEVICETOPIC/rpc {"id": 1,"src":"$\DEVICETOPIC", "method": "Switch.GetConfig", "params": {"id": 0}}
hast du bewusst "src" wieder auf DEVICETOPIC geändert und nicht mehr request2shelly? (habe das erstmal nicht geändert)

setList - kleinere fehler korregiert (eine klammer, und am ende muss auf $var nicht auf $EVTPART1 gesetzt werden, weil er sonst versucht "in_mode" auf toggle zu setzen, was aber follow heissen würde und nicht das ist was wir wollen xD.

Code: [Auswählen]

in_mode:toggle,flip,detached {my $val = $EVTPART1 ne 'toggle' ? $EVTPART1 : ReadingsVal($NAME,'in_mode','flip') eq 'flip' ? 'detached':'flip'; qq($DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "$val"}}})}

userReadings Funkioniert auch, auch dann wenn z.B: über WebUI vom Shelly umgestellt wird. demnach, sorry tomlee, ist periodic doch geflogen und auch das SetList mit dem auslösen des get habe ich n icht getestet, weil userreading seinen job macht.

webCmd
muss ich mir noch anschauen - werd die ganze zeit vom telefon gestört 

[Beta-User]

Frage [...] hast du bewusst "src" wieder auf DEVICETOPIC geändert und nicht mehr request2shelly? (habe das erstmal nicht geändert)

Ja, Begründung s.o.. Die rL muss dazu auch an zwei weiteren Stellen angepaßt werden!

(eine klammer, und am ende

Das mit den kleinen Fehlerchen hat sich als gute Methode bewährt, um "Kunden" zum mitdenken zu animieren...

userReadings Funkioniert auch,

Wenn möglich bitte trotzdem die "Verzögerungsvariante" ausprobieren. Hintergrund:
Wer nur von FHEM aus arbeitet, braucht dann das userReading nicht, und es gibt v.a. bei den Modellen mit Energiemessung den Bedarf für weitere userReadings-Einträge => für diese wird alles sehr viel komplizierter...

Ergo: Sowas sollte dann (wie das mit webCmd ggf. auch) im Wiki dokumentiert werden (whodunnit?!? => Freiwillige gesucht!), im attrTemplate selbst würde ich den "inhibit"- setter (so heißt die vergleichbare Funktion im CUL_HM-Sprech) zwar drin lassen, aber eben nicht als besonders hervorgehobes oder wünchenswertes "Standard-Kommando".

Auch das mit dem periodicCmd kann man dokumentieren, allerdings würde ich dazu noch "timestamp-on-change-reading" (und die dafür notwendigen Vorbedingungen) mit aufnehmen.

Alles klar soweit...?

[draddy]

also readingList und getList habe ich umgebaut auf $DEVICETOPIC ... wenn ich den get manuel ausführe - klappt das auch

was nicht geht, ist der get call beim toggle bzw. flip|detached (was am ende ja das gleiche ist) - also der set wird wohl ausgeführt, aber der get nicht, kommt auch in m_sub nix was darauf hindeuten würde, dass der get ausgeführt wurde)

hier nochmal der in_mode teil der setList

Code: [Auswählen]

in_mode:toggle,flip,detached {fhem("sleep 0.2;; get $NAME in_mode"); my $val = $EVTPART1 ne 'toggle' ? $EVTPART1 : ReadingsVal($NAME,'in_mode','flip') ne 'flip' ? 'flip':'detached'; qq($DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "$val"}}})}



MaaAAHHNN
übertreibs doch nicht mit deinen "fehlerchen" einbauen ... nachdem ich den 2. ; hinter sleep 0.2 entfernt habe, wird get getriggert ...   

aber (natürlich?!) bekommt fhem es nicht mit, wenn ich im shelly direkt den in_mode ändere

axo, das userReadings habe ich natürlich rausgeworfen!

hier ein raw dieser version: (und JA, da ist mein devStateIcon ... halt einfach ignorieren , aber um dieses gehts ja aktuell nicht^^)

Code: [Auswählen]

defmod MQTT2_shellyplus1_441793a3b110 MQTT2_DEVICE shellyplus1_441793a3b110
attr MQTT2_shellyplus1_441793a3b110 alias Jens Ceilinglight
attr MQTT2_shellyplus1_441793a3b110 devStateIcon {my $onl = ReadingsVal($name,'online','false') eq 'false'?'10px-kreis-rot':'10px-kreis-gruen';; $onl = FW_makeImage($onl);; \
my $light = ReadingsVal($name,'state','off') eq 'off'?'light_ceiling_off':'light_ceiling@yellow';; $light = FW_makeImage($light);; \
my $lock = ReadingsVal($name,'in_mode','flip') eq 'flip'?'secur_open@green':'secur_locked@red';; $lock = FW_makeImage($lock);;\
my $ip = ReadingsVal($name,'ip','none');; \
my $reb = ReadingsVal($name,'sys_restart_required','false') eq 'true'?'<a href="/fhem?cmd.dummy=set '.$name.' x_reboot&XHR=1"> ... Notwendigen Reboot durchführen</a>':'';; qq\
(<a href="http://$ip" target="_blank">${onl}</a><a href="/fhem?cmd.dummy=set $name toggle&XHR=1">${light}</a>\
<a href="/fhem?cmd.dummy=set $name in_mode toggle&XHR=1">${lock}</a>)}
attr MQTT2_shellyplus1_441793a3b110 devStateStyle style="text-align:right;;;;"
attr MQTT2_shellyplus1_441793a3b110 devicetopic shellyplus1-441793a3b110
attr MQTT2_shellyplus1_441793a3b110 getList in_mode:noArg in_mode $DEVICETOPIC/rpc {"id": 1,"src":"$DEVICETOPIC", "method": "Switch.GetConfig", "params": {"id": 0}}
attr MQTT2_shellyplus1_441793a3b110 icon light_ceiling_light@green
attr MQTT2_shellyplus1_441793a3b110 jsonMap switch_state:state switch_temperature_tC:temperature switch_temperature_tF:0 params_wifi_sta_ip:ip params_switch_0_temperature_tC:temperature params_switch_0_temperature_tF:0 req_result_in_mode:in_mode
attr MQTT2_shellyplus1_441793a3b110 model shellyPlus_1
attr MQTT2_shellyplus1_441793a3b110 readingList $DEVICETOPIC/online:.* online\
  $DEVICETOPIC/events/rpc:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  $DEVICETOPIC/status/mqtt:.* { json2nameValue($EVENT, 'mqtt_', $JSONMAP) }\
  $DEVICETOPIC/status/sys:.* { json2nameValue($EVENT, 'sys_', $JSONMAP) }\
  $DEVICETOPIC/status/switch_0:.* { $EVENT =~ s/"output":true/"state":"on"/g;; $EVENT =~ s/"output":false/"state":"off"/g;; json2nameValue($EVENT, 'switch_', $JSONMAP) }\
  $DEVICETOPIC/status/cloud:.* {}\
  $DEVICETOPIC/rpc:.* { json2nameValue($EVENT, 'req_', $JSONMAP, 'in_mode') }\
  fhem2shelly/rpc:.* {}\

attr MQTT2_shellyplus1_441793a3b110 room Favs,Jens,MQTT2_DEVICE
attr MQTT2_shellyplus1_441793a3b110 setList toggle:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Toggle","params": {"id":0}}\
  off:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false}}\
  on:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":true}}\
  on-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":true,"toggle_after":$EVTPART1}}\
  off-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false,"toggle_after":$EVTPART1}}\
 in_mode:toggle,flip,detached {fhem("sleep 0.2;; get $NAME in_mode");; my $val = $EVTPART1 ne 'toggle' ? $EVTPART1 : ReadingsVal($NAME,'in_mode','flip') ne 'flip' ? 'flip':'detached';; qq($DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "$val"}}})}\
  x_update:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Shelly.Update","params": {"stage":"stable"}}\
  x_reboot:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Shelly.Reboot"}\
  x_eco:true,false $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Sys.SetConfig","params": {"config": {"device": {"eco_mode": $EVTPART1}}}}
attr MQTT2_shellyplus1_441793a3b110 setStateList on off toggle on-for-timer off-for-timer
attr MQTT2_shellyplus1_441793a3b110 webCmd :
den setState part am ende habe ich mal weg gelassen ...


BUG: ist mir gerade aufgefallen:
wenn ich im detached mode bin, und am echten Schalter welcher am Shelly ist, schalte, passiert der lampe nichts, wohl aber ändert sich "state" auf "true" und damit spring die das devStateIcon auf "AN" (weil der state nicht mehr off ist) und bleibt solange, bis ich über FHEM ein / ausschalte ... hier wird also irgendein reading "falsch" an state weiter geleitet

dieses event erhalte ich in m_sub (EIN und AUS schalten)

Code: [Auswählen]


shellyplus1-441793a3b110/events/rpc {"src":"shellyplus1-441793a3b110","dst":"shellyplus1-441793a3b110/events","method":"NotifyStatus","params":{"ts":1646396730.00,"input:0":{"id":0,"state":true}}}
shellyplus1-441793a3b110/status/input:0 {"id":0,"state":true}
shellyplus1-441793a3b110/events/rpc {"src":"shellyplus1-441793a3b110","dst":"shellyplus1-441793a3b110/events","method":"NotifyStatus","params":{"ts":1646396735.85,"input:0":{"id":0,"state":false}}}
shellyplus1-441793a3b110/status/input:0 {"id":0,"state":false}

denke, das ist bis her nicht aufgefallen, da im "normal" mode ja beim betätigen des schalters, auch irgendwas am Licht passiert und es vermutlich dann sofort wieder überschrieben wird durch den status der lampe ...

[draddy]

quick&dirty

Code: [Auswählen]

webCmd  in_mode


setzt einfach ein Dropdown Menü mit flip detached toggle und funzt auch - Anzeige (wenn nicht ausgeklappt) war beim kurztest auch immer sauber der Aktuelle Status (also, flip oder detached)

Optik etc. möge bitte jemand machen, welcher webCmd nutzen mag aktuell keinen kopf und lust mich in WidgetOverride etc. rein zu arbeiten, da ich für mich persönlich überall wo ich kann auf webCmd verzichte ^^

[draddy]

von mir aus auch mit webCmdLabel

Code: [Auswählen]

Button Mode


[Beta-User]

Optik etc. möge bitte jemand machen,

Och komm, lass den monk vollends raus ...

Was die Zahl der Strichpunkte angeht: hatte extra geschrieben, dass ich nicht sicher bin .

Zum "bug": Da müßte eigentlich was zusätzliches in der rL aufgetaucht sein. Da bitte die Langform von j2nv() einbauen und einen "input_"-Präfix setzen. Dann sollte Tastendruck und Relay getrennt als Reading zu erkennen sein.

[draddy]

AACHHTUNG AM BAHNSTEIG xD

ok 1 nachm anderen
tatsache, neuer rL Eintrag (hab wohl vorhin kein F5 gedrückt und hatte das gar nicht gesehen als mir der bug aufgefallen ist ...

Code: [Auswählen]

shellyplus1_441793a3b110:shellyplus1-441793a3b110/status/input_0:.* { json2nameValue($EVENT) }
aber was ich da jetzt wie wo zu ändern habe? .. shellyplus1..... gegen $$DEVICETOPIC tauschen vermutlich - aber j2n lang form? - den ausdruck von status/switch_0 rein kopieren ?

also sowas?

Code: [Auswählen]

$DEVICETOPIC/status/input_0:.* { $EVENT =~ s/"output":true/"state":"on"/g; $EVENT =~ s/"output":false/"state":"off"/g; json2nameValue($EVENT, 'switch_', $JSONMAP) }

von wegen strichpunkte ... ja, aber trotzdem musst ja nicht übertreiben mit deinen fehlerchen : P

webCmd ... job done! ganz einfach, wer mehr will, feel free - works as designed hat gestern mal jemand gesagt xD

[draddy]

andere frage ... kann man die zeile der setList irgendwo "brechen"? ich brauch fast beide Monitore damit ich nicht immer nach links und rechts schieben muss 

[draddy]

Code: [Auswählen]

$DEVICETOPIC/status/input_0:.* { $EVENT =~ s/"output":true/"state":"on"/g; $EVENT =~ s/"output":false/"state":"off"/g; json2nameValue($EVENT, 'input_', $JSONMAP) }

also, kein neuer eintrag in rL mehr, wenn detached und schalter wird geschaltet bleibt state icon unverändert.
im flip modus wirds licht an und aus geschaltet und auch das state icon schaltet um.

sollte, so hoffe ich, also passen.

alkutelles raw

Code: [Auswählen]

defmod MQTT2_shellyplus1_441793a3b110 MQTT2_DEVICE shellyplus1_441793a3b110
attr MQTT2_shellyplus1_441793a3b110 alias Jens Ceilinglight
attr MQTT2_shellyplus1_441793a3b110 devStateIcon {my $onl = ReadingsVal($name,'online','false') eq 'false'?'10px-kreis-rot':'10px-kreis-gruen';; $onl = FW_makeImage($onl);; \
my $light = ReadingsVal($name,'state','off') eq 'off'?'light_ceiling_off':'light_ceiling@yellow';; $light = FW_makeImage($light);; \
my $lock = ReadingsVal($name,'in_mode','flip') eq 'flip'?'secur_open@green':'secur_locked@red';; $lock = FW_makeImage($lock);;\
my $ip = ReadingsVal($name,'ip','none');; \
my $reb = ReadingsVal($name,'sys_restart_required','false') eq 'true'?'<a href="/fhem?cmd.dummy=set '.$name.' x_reboot&XHR=1"> ... Notwendigen Reboot durchführen</a>':'';; qq\
(<a href="http://$ip" target="_blank">${onl}</a><a href="/fhem?cmd.dummy=set $name toggle&XHR=1">${light}</a>\
<a href="/fhem?cmd.dummy=set $name in_mode toggle&XHR=1">${lock}</a>)}
attr MQTT2_shellyplus1_441793a3b110 devStateStyle style="text-align:right;;;;"
attr MQTT2_shellyplus1_441793a3b110 devicetopic shellyplus1-441793a3b110
attr MQTT2_shellyplus1_441793a3b110 getList in_mode:noArg in_mode $DEVICETOPIC/rpc {"id": 1,"src":"$DEVICETOPIC", "method": "Switch.GetConfig", "params": {"id": 0}}
attr MQTT2_shellyplus1_441793a3b110 icon light_ceiling_light@green
attr MQTT2_shellyplus1_441793a3b110 jsonMap switch_state:state switch_temperature_tC:temperature switch_temperature_tF:0 params_wifi_sta_ip:ip params_switch_0_temperature_tC:temperature params_switch_0_temperature_tF:0 req_result_in_mode:in_mode
attr MQTT2_shellyplus1_441793a3b110 model shellyPlus_1
attr MQTT2_shellyplus1_441793a3b110 readingList $DEVICETOPIC/online:.* online\
  $DEVICETOPIC/events/rpc:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  $DEVICETOPIC/status/mqtt:.* { json2nameValue($EVENT, 'mqtt_', $JSONMAP) }\
  $DEVICETOPIC/status/sys:.* { json2nameValue($EVENT, 'sys_', $JSONMAP) }\
  $DEVICETOPIC/status/switch_0:.* { $EVENT =~ s/"output":true/"state":"on"/g;; $EVENT =~ s/"output":false/"state":"off"/g;; json2nameValue($EVENT, 'switch_', $JSONMAP) }\
  $DEVICETOPIC/status/input_0:.* { $EVENT =~ s/"output":true/"state":"on"/g;; $EVENT =~ s/"output":false/"state":"off"/g;; json2nameValue($EVENT, 'input_', $JSONMAP) }\
  $DEVICETOPIC/status/cloud:.* {}\
  $DEVICETOPIC/rpc:.* { json2nameValue($EVENT, 'req_', $JSONMAP, 'in_mode') }\
  fhem2shelly/rpc:.* {}\
\

attr MQTT2_shellyplus1_441793a3b110 room Favs,Jens,MQTT2_DEVICE
attr MQTT2_shellyplus1_441793a3b110 setList toggle:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Toggle","params": {"id":0}}\
  off:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false}}\
  on:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":true}}\
  on-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":true,"toggle_after":$EVTPART1}}\
  off-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false,"toggle_after":$EVTPART1}}\
  in_mode:toggle,flip,detached {fhem("sleep 0.2;; get $NAME in_mode");; my $val = $EVTPART1 ne 'toggle' ? $EVTPART1 : ReadingsVal($NAME,'in_mode','flip') ne 'flip' ? 'flip':'detached';; qq($DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "$val"}}})}\
  x_update:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Shelly.Update","params": {"stage":"stable"}}\
  x_reboot:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Shelly.Reboot"}\
  x_eco:true,false $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Sys.SetConfig","params": {"config": {"device": {"eco_mode": $EVTPART1}}}}
attr MQTT2_shellyplus1_441793a3b110 setStateList on off toggle on-for-timer off-for-timer
attr MQTT2_shellyplus1_441793a3b110 webCmd :
devStateIcon müsstest halt dein Original wieder rein fummeln

[Beta-User]

webCmd ... job done! ganz einfach, wer mehr will, feel free - works as designed hat gestern mal jemand gesagt xD

..so wird kein echter monk aus dir...

Etwas mehr Ehrgeiz bitte! Du wolltest doch was lernen, oder? (und ich auch, hab das nämlich auch noch nie in der Form genutzt )

Betr. das status-Ding war es gar nicht so kompliziert gemeint:

Code: [Auswählen]

$DEVICETOPIC/status/input_0:.* { json2nameValue($EVENT, 'input_', $JSONMAP) }
Da es ggf. ja "nur" darum geht, Tastendrücke gesondert auswerten zu können, ist es nicht ganz so wichtig, ob der Event "vollendet" ist, on/off sind v.a. bei schaltbaren Zuständen wichtig. "Blöd" war da ohne den "prefix" nur, dass ausgerechnet "state" als Keyword in dem JSON-Blob enthalten war...
Vermutlich geht deine Version auch "irgendwie", ich habe aber nicht geprüft, ob dann überhaupt ein Taster-Event kommt. Der wäre schon wünschenswert .

andere frage ... kann man die zeile der setList irgendwo "brechen"?

No. Beste Technik ist rauskopieren, einen "richtigen" Editor benutzen und nach Bearbeitung wieder reinkopieren...

[draddy]

..so wird kein echter monk aus dir...

Etwas mehr Ehrgeiz bitte! Du wolltest doch was lernen, oder? (und ich auch, hab das nämlich auch noch nie in der Form genutzt )

wer sagt das ich ein Fliesenfugen überspringender, alles berührender aber vor Menschen angsthabender Monk werden will?
und über meine Lernkurve der letzten 2 Wochen kann ich mich nicht beklagen, danke für deine Fürsorge 

Betr. das status-Ding war es gar nicht so kompliziert gemeint:

Code: [Auswählen]

$DEVICETOPIC/status/input_0:.* { json2nameValue($EVENT, 'input_', $JSONMAP) }
Da es ggf. ja "nur" darum geht, Tastendrücke gesondert auswerten zu können, ist es nicht ganz so wichtig, ob der Event "vollendet" ist, on/off sind v.a. bei schaltbaren Zuständen wichtig. "Blöd" war da ohne den "prefix" nur, dass ausgerechnet "state" als Keyword in dem JSON-Blob enthalten war...
Vermutlich geht deine Version auch "irgendwie", ich habe aber nicht geprüft, ob dann überhaupt ein Taster-Event kommt. Der wäre schon wünschenswert .

denke das sollte reichen, das wird gesetzt bei tasten druck
input_state  false  2022-03-04 15:18:15
werde aber auf deine version umbauen, wenn da kein Kommentar mehr dazu kommt, passt es

No. Beste Technik ist rauskopieren, einen "richtigen" Editor benutzen und nach Bearbeitung wieder reinkopieren...

gibt es ernsthaft leute, die ohne externen editor arbeiten? also für kleinigkeiten, ok, aber allein sowas wie besagte zeile ... im notepad++ z.B. seh ich zumindest schnell ob alle klammern beendet werden etc. pp ... ^^



Template:
d.h. du übernimmst das so ins Template, dass der in_mode schaltbar ist und den aktuellen status kurz checkt mit dem get? (muss ja nicht aktiv raus getragen werden mit schaltern, ist eco mode oder sowas ja auch nicht)

brauchst du in dem zuge noch was von meiner seite?

Wiki Doku:
ehm, öhh? ich muss weg xD ... nein, kann nicht ganz folgen was du da wo genau dokumentieren wolltest? das webCmd ist ja quasi pillepalle, indem moment wo webCmd auf einen multischalter gesetzt wird, bekommst ja diese auswahl, wenn du jetzt ins webCmd einfach x_eco einträgst, sollte auch ein dropdown mit true und false kommen.

jedenfalls nochmal danke, auch an tomlee, auch wenn seine "befürchtung" wohl doch wahr geworden ist.
aber besonders die Zusammenarbeit mit dir beta hat gut geklappt und spass gemacht

[Beta-User]

wer sagt das ich ein Fliesenfugen überspringender, alles berührender aber vor Menschen angsthabender Monk werden will?

...für Risiken und Nebenwirkungen von FHEM fragen Sie eine beliebige Person ihres Vertrauens ...

gibt es ernsthaft leute, die ohne externen editor arbeiten? also für kleinigkeiten, ok, aber allein sowas wie besagte zeile ... im notepad++ z.B. seh ich zumindest schnell ob alle klammern beendet werden etc. pp ... ^^

Dein Suchwort ist "codemirror" .

d.h. du übernimmst das so ins Template, dass der in_mode schaltbar ist und den aktuellen status kurz checkt mit dem get?

Das wäre der Plan.

Wiki Doku:

Na ja, das mit dem automatischen get ist eine Lösung von mehreren, und ich will das auch nicht "überall" einbauen. Prinzipiell ist einiges an den 2. Gen.-Geräten "speziell", und von daher wäre es wahrscheinlich sinnvoll, für u.A. eben sowas in separaten Wiki-Artikel betr. Shelly-2.Gen-@MQTT2 zu packen, damit man künftig nicht gefühlte 10000 Seiten Forumsbeiträge (mit Fehlversuchen usw.) durchforsten muss...

(Ich warte jetzt nur noch darauf, dass hier spätestens morgen jemand mit einem 4-er Shelly 2. Gen. aufschlägt, der wissen will, wie man das im Doppel-Rollladenmodus hinbekommt ...)

hat gut geklappt und spass gemacht

Dank zurück!

(Auch der Stil ist hoffentlich so, dass eventuelle Nachleser etwas "Spaß" dabei haben, sich diese m.E. insgesamt nicht ganz trivialen Sachen zu erlesen...)

[draddy]

...für Risiken und Nebenwirkungen von FHEM fragen Sie eine beliebige Person ihres Vertrauens ...

ich hab doch schon die Packungsbeilage gefuttert 

Dein Suchwort ist "codemirror" .

muss ich mir, irgendwann, mal anschauen, für meine zwecke reicht seit jahren der notepad++ ... mit dem hab ich seinerzeit schon java gelernt (bin ich froh das ich damit nix mehr am hut hab) für das bissl hoppy coden / scripten reicht der notepad++ mir 

Na ja, das mit dem automatischen get ist eine Lösung von mehreren, und ich will das auch nicht "überall" einbauen. Prinzipiell ist einiges an den 2. Gen.-Geräten "speziell", und von daher wäre es wahrscheinlich sinnvoll, für u.A. eben sowas in separaten Wiki-Artikel betr. Shelly-2.Gen-@MQTT2 zu packen, damit man künftig nicht gefühlte 10000 Seiten Forumsbeiträge (mit Fehlversuchen usw.) durchforsten muss...

nun, das get bleibt ja und das periodic ist ja jetzt raus, dies ist ja scheinbar eh mqtt "typisches" Boardmittel in fhem oder?  oder wolltest du das automatische abfragen nach dem setzen von set in_mode wieder rauskanten? das würde ich, aufgrund fehlender  verwertbarer Rückmeldung, halt drin lassen. (meine Meinung)
Gibt es das Gen2 Wiki schon? PM einfach wenn du entschieden hast was drin bleibt und was nicht, dann schauen wir das wir WIKI entsprechend sinnig befüllen mit tipps

(Ich warte jetzt nur noch darauf, dass hier spätestens morgen jemand mit einem 4-er Shelly 2. Gen. aufschlägt, der wissen will, wie man das im Doppel-Rollladenmodus hinbekommt

ja, für normales 2er oder 4 relay denke ich ehr problemlos. man muss eben sinnvoll ergänzen alla in_mode_1 ... id:2 .. aber Rollladenmodus bin ich raus, meine Rollos haben noch Seilzug
habe halt ausser dem Plus 1 aktuell nur nen 2.5 hier (und eben plugs / bulbs) - und der ist (gsd) Gen1 xD also, Tester vor treten

(Auch der Stil ist hoffentlich so, dass eventuelle Nachleser etwas "Spaß" dabei haben, sich diese m.E. insgesamt nicht ganz trivialen Sachen zu erlesen...)

ja, bissl show haben wir schon gemacht 

[Beta-User]

muss ich mir, irgendwann, mal anschauen, für meine zwecke

Es verbirgt sich kein übermäßig großes Geheimnis hinter dem Schlagwort, aber die Zielrichtung ist eine andere .

Gibt es das Gen2 Wiki schon?

Nein. Es gibt einen "Sammel-Wiki"-Artikel für "Praxisbeispiele", in den ich ursprünglich mal "alles mögliche" reingepackt hatte. Da war z.B. auch mal zigbee2mqtt drin, was zwischenzeitlich ausgelagert ist. So ähnlich würde ich das auch vorschlagen, habe aber noch keine konkreteren Vorstellungen, wie das im Detail aussehen kann. Kann vorläufig auch gerne einfach ein separater Abschnitt in den "Praxisbeispielen" werden, analog zu dem "on-for-timer"-Thema bei Tasmota (das ist auch so ein "Großthema", bei dem der Hauptartikel irgendwann vor der MQTT2-Zeit entstanden ist).

Das Format ist etwas speziell, am einfachsten den Quelltext der Wiki-Seite anzeigen lassen und in dem Stil. (Wer notepad++ bedienen kann bekommt das hin... )

[draddy]

Das Format ist etwas speziell, am einfachsten den Quelltext der Wiki-Seite anzeigen lassen und in dem Stil. (Wer notepad++ bedienen kann bekommt das hin... )

ich kann mich im wiki nicht mal anmelden! so schauts aus, NÜX KANNA 

fahr jetzt essen, bis später mal