MQTT2+Shelly: erste Konfiguration und template-Entwicklung

[Beta-User]

Gemeint ist wohl das:

1. Wenn ich den Shelly vom Stromnetz trenne, verschwindet er aus dem WLAN und die Ampel zeigt richtigerweise "ROT". Wenn ich allerdings in diesem stromlosen Zustand "on" oder "off" schalte, dann wechselt das Lampensymbol sein Aussehen und es sieht so aus, als würde der Shelly schalten (kann er natürlich nicht, weil er keinen Strom hat). Das ist bei anderen Aktoren, die nur empfangen und nicht senden können, auch der Fall, aber der Shelly kann mehr, oder?

Kann nur raten: Es erscheint ein Lampensymbol mit rotem Fragezeichen darin?
Wenn ja: Works as designed => das zeigt an, dass es zwar einen Schaltbefehl gab, dieser aber nicht bei der Hardware angekommen ist...
Ansonsten hätte ich gerne ausnahmsweise (!) einen Screenshot.

@Gundermann:
Bis dato sehe ich keine Veranlassung, statt des "on"-Symbols irgendwas anderes zu verwenden.
Vielleicht liest du mal in der commandref den Eintrag zu iconPath bei FHEMWEB, mMn. kann man das, was du möchtest, besser erreichen durch ein eigenes Verzeichnis mit eigenen Dateien namens "on.xyz" usw., das mit der höchsten Prio durchsucht werden soll. Das wirkt dann nämlich systemweit, ohne dass man irgendwelche Änderungen an einzelnen Devices vornehmen müßte...
(Ziemlich genau aus diesem Grund dränge ich hier immer mal wieder darauf, dass bitte Standardsymbole und diese in der Regel ohne Farbe zu verwenden sind...!)

Vielleicht noch eine persönliche Anmerkung zur Tonlage: Eventuell hat du etwas Zeit und kannst den hier verlinkten Artikel mal in Ruhe durchlesen: https://forum.fhem.de/index.php/topic,13092.msg105687.html#msg105687

[Gundermann]

@ Beta-User

Vielleicht noch eine persönliche Anmerkung zur Tonlage: Eventuell hat du etwas Zeit und kannst den hier verlinkten Artikel mal in Ruhe durchlesen

Gelesen und viel darüber gelernt, wie Hacker ticken. Danke

[Gundermann]

@ Beta-User

Kann nur raten: Es erscheint ein Lampensymbol mit rotem Fragezeichen darin?

Genau soetwas dachte ich mir. Das wäre dann - neben der roten Ampel - ein Hinweis, dass es ein Problem gibt (z.B. keinen Strom, also Schaltbefehl nicht angekommen). Die Lampensymbole sind aber immer die gleichen, nämlich die Standardsymbole, ob mit oder ohne Strom am Shelly, kein rotes Fragezeichen.

Und so sieht es unter "RAW definition" aus (die Attirbute "devStateIcon", "readingList" und "setList" sind aus dem attrTemplate "shelly1"):

Code Auswählen Erweitern

defmod 233_Reserve_MQTT2_shelly1_2C79A6 MQTT2_DEVICE shelly1_2C79A6
attr 233_Reserve_MQTT2_shelly1_2C79A6 IODev MQTT2_FHEM_Server
attr 233_Reserve_MQTT2_shelly1_2C79A6 devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";;;; my $light = ReadingsVal($name,"state","off");;;; my $show = '<a href="';;;;$show .= $onl eq "gelb" ? "/fhem?cmd.dummy=set $name x_update&XHR=1\">" : "http://".ReadingsVal($name,"ip","none").' "target="_blank">';;;;$show .= FW_makeImage("10px-kreis-".$onl)."</a>";;;; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a></div>" }
attr 233_Reserve_MQTT2_shelly1_2C79A6 event-on-change-reading .*
attr 233_Reserve_MQTT2_shelly1_2C79A6 model shelly1
attr 233_Reserve_MQTT2_shelly1_2C79A6 readingList shellies/shelly1-2C79A6/relay/0:.* state\
  shellies/shelly1-2C79A6/relay/0:.* relay0\
  shellies/shelly1-2C79A6/input/0:.* input0\
  shellies/shelly1-2C79A6/online:.* online\
  shellies/shelly1-2C79A6/announce:.* { json2nameValue($EVENT) }\
  shellies/announce:.* { $EVENT =~ m,..id...shelly1-2C79A6...mac.*, ? json2nameValue($EVENT) : undef }
attr 233_Reserve_MQTT2_shelly1_2C79A6 room MQTT2_DEVICE
attr 233_Reserve_MQTT2_shelly1_2C79A6 setList off:noArg shellies/shelly1-2C79A6/relay/0/command off\
  on:noArg shellies/shelly1-2C79A6/relay/0/command on\
  x_update:noArg shellies/shelly1-2C79A6/command update_fw\
  x_mqttcom shellies/shelly1-2C79A6/command $EVTPART1

setstate 233_Reserve_MQTT2_shelly1_2C79A6 off
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:16:16 fw_ver 20200122-090220/v1.5.9@4b657c90
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:16:16 id shelly1-2C79A6
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:16:16 ip 192.168.188.233
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:16:16 mac 3C71BF2C79A6
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:16:16 new_fw false
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:16:16 online true
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:16:35 relay0 on
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:16:51 state off


Grüße von Gundermann

[Beta-User]

Hmm,

das sollte vermutlich zu lösen sein mit einem setStateList-Attribut (on off toggle), das scheint auch bei einigen anderen Device-Typen noch zu fehlen (wundert mich, dass das bisher noch keinem aufgefallen ist, und freut mich, weil Rudi erst nicht so überzeugt war, dass man "sowas" braucht bzw. es jemand außer mir haben will)...

(Ein RAW, das zum "Zeitpunkt des Problems" "geschossen" worden wäre, wäre vermutlich noch aufschlußreicher gewesen, hier schien aber alles ok zu sein, das Device war jedenfalls online).

Grüße

[Gundermann]

Hallo Beta-User,

Code Auswählen Erweitern

(Ein RAW, das zum "Zeitpunkt des Problems" "geschossen" worden wäre, wäre vermutlich noch aufschlußreicher gewesen, hier schien aber alles ok zu sein, das Device war jedenfalls online).

... liefere ich hiermit nach:

Code Auswählen Erweitern

defmod 233_Reserve_MQTT2_shelly1_2C79A6 MQTT2_DEVICE shelly1_2C79A6
attr 233_Reserve_MQTT2_shelly1_2C79A6 IODev MQTT2_FHEM_Server
attr 233_Reserve_MQTT2_shelly1_2C79A6 devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";;;; my $light = ReadingsVal($name,"state","off");;;; my $show = '<a href="';;;;$show .= $onl eq "gelb" ? "/fhem?cmd.dummy=set $name x_update&XHR=1\">" : "http://".ReadingsVal($name,"ip","none").' "target="_blank">';;;;$show .= FW_makeImage("10px-kreis-".$onl)."</a>";;;; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a></div>" }
attr 233_Reserve_MQTT2_shelly1_2C79A6 event-on-change-reading .*
attr 233_Reserve_MQTT2_shelly1_2C79A6 model shelly1
attr 233_Reserve_MQTT2_shelly1_2C79A6 readingList shellies/shelly1-2C79A6/relay/0:.* state\
  shellies/shelly1-2C79A6/relay/0:.* relay0\
  shellies/shelly1-2C79A6/input/0:.* input0\
  shellies/shelly1-2C79A6/online:.* online\
  shellies/shelly1-2C79A6/announce:.* { json2nameValue($EVENT) }\
  shellies/announce:.* { $EVENT =~ m,..id...shelly1-2C79A6...mac.*, ? json2nameValue($EVENT) : undef }
attr 233_Reserve_MQTT2_shelly1_2C79A6 room MQTT2_DEVICE
attr 233_Reserve_MQTT2_shelly1_2C79A6 setList off:noArg shellies/shelly1-2C79A6/relay/0/command off\
  on:noArg shellies/shelly1-2C79A6/relay/0/command on\
  x_update:noArg shellies/shelly1-2C79A6/command update_fw\
  x_mqttcom shellies/shelly1-2C79A6/command $EVTPART1

setstate 233_Reserve_MQTT2_shelly1_2C79A6 on
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:45:06 fw_ver 20200122-090220/v1.5.9@4b657c90
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:45:06 id shelly1-2C79A6
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:45:08 input0 1
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:45:06 ip 192.168.188.233
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:45:06 mac 3C71BF2C79A6
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:45:06 new_fw false
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:46:48 online false
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:45:18 relay0 off
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 15:47:45 state on

Grüße von Gundermann

[Beta-User]

...wie vermutet...

Aber nachdem ich schon über dein Problem nachgedacht hatte und einen Test bzw. einen Lösungsansatz vorgeschlagen, würde mich eigentlich das Ergebnis des Tests mehr interessieren  ...

[Gundermann]

@ Beta-User

Ich nehme an, du beziehest dich jetzt auf deinen Vorschlag

... liest du mal in der commandref den Eintrag zu iconPath bei FHEMWEB, mMn. kann man das, was du möchtest, besser erreichen durch ein eigenes Verzeichnis mit eigenen Dateien namens "on.xyz" usw., das mit der höchsten Prio durchsucht werden soll. Das wirkt dann nämlich systemweit, ohne dass man irgendwelche Änderungen an einzelnen Devices vornehmen müßte...

Ja, ich bin sicher, dass es so funktionieren würde, weil es ja eigentlich auch schon so ist. Aber das ist nicht mein Ziel. Dann gäbe es zwar andere, aber trotzdem immer wieder gleiche Symbole. Wenn ein Aktor eine Lampe ein- und ausgeschaltet, sind eine gelbe Glühbirne für "on" und eine transparente für "off" bestimmt geeignete und intuitive Symbole. Wenn ich aber mit dem Aktor das Ladegerät meines fliegenden Teppichs ansteuere, dann eben nicht. Deshalb finde ich es für meine Anwendungen angemessener (und mache mir auch gerne die Mühe), die einzelnen Devices anzupassen und weiß dank der helfenden Köpfe in diesem Forum nun auch wie das geht.

Danke und Grüße von Gundermann

[Beta-User]

Ich nehme an, du beziehest dich jetzt auf deinen Vorschlag

No. Auf diesen:

setStateList-Attribut (on off toggle)

Aber das ist nicht mein Ziel. [...]

Ok, leuchtet ein, ich habe nur keine Idee, wie man das am einfachsten vermitteln kann. Geht nur über Einarbeiten in den recht "knackigen" Perl-Code, oder eben, indem man dann die vereinfachte Variante nutzt (ggf. iVm. mit der "Multiline"-stateFormat-Lösung für die Anzeige mehrerer Symbole), die aber dann nicht einfach so auf externe Webseiten (das Web-Interface des ESP) verlinkt. Das war hier aber mehrheitlich gewünscht (Siehe ca. Beiträge 300-500 in diesem Thread und ein paar andere Stellen...), sonst gäbe es jetzt fast überall die einfache Variante und die komplexe nur als "Demo"...

(Meiner persönlichen Ansicht nach könnte man das update-Thema bequem mit dem Zentraldevice "abfrühstücken" und Funkprobleme (LWT) über einen Eventhandler/eine Readingsgroup, die nur "Problematische Devices" anzeigt ... mitteilen/visualisieren.)

[ripperle]

Wollte gerade mein shelly2.5 in fhem rein holen aber ich sehe das passende template nicht?

Wie wird dass shelly2.5 als korrektes MQTT2_DEVICE angelegt? sehe nur shelly1 als template? 

Gruß

[Beta-User]

Siehe https://wiki.fhem.de/wiki/AttrTemplate#Warum_finde_ich_das_Template_xyz_nicht.3F

Wenn du da nicht die passende Info findest: Bitte ein list von dem von autocreate angelegten Device... (Oder: wie hast du das MQTT2_DEVICE erstellt?).

[ripperle]

Ja das ich es mit autocreate erstellen kann bzw. muss habe ich in der Zwischenzeit auch raus gefunden...

Also ich muss sagen diese template geschichte beim mqtt2 sollte dringend mal vernünftig dokumentiert werden. Man findet nur gestreut teilsrichtige oder aktuelle Infos...

Wie man das shelly 2.5 ohne autocreate anlegen kann, konnte ich immernoch nicht rausfinden...

P.S.
Und zum Thema autocreate. Ich benutze diese Funktion sehr ungern da oft sehr merkwürdige Dinge passieren, so auch gestern beim anlegen des shelly2.5.
Nachdem autocreate das device angelegt hatte habe ich noch ein shelly 1 eingebunden. Es wurde dann im shelly2.5 auf einemal die readings vom shelly1 eingetragen... Habe ich dann händisch wieder raus gelöscht und schnell Autocreate aus gemacht...

[87insane]

Hey u guten Abend,

alles was du geschrieben hast spricht dafür, dass du dich DRINGEND in die fhem Basic einlesen solltest.

Nur als Beispiel... Geräte die via mqtt 2 Server in fhem eingebunden werden und via autocreate rein laufen - bekommen einen Namen. Sollte der doppelt sein, hast du eben Namen doppelt vergeben. Das kann fhem oder ein anderes System nicht wissen. Dementsprechend laufen verschiedene hardware Geräte in fhem in nur ein software Gerät.

Was die Doku angeht, kannst du gerne helfen
An sich ist es aber einfach und außer bei speziellen Dingen, würde ich es auch nur so machen:
- Autocreate an
- Gerät rein laufen lassen
- in das neue Gerät rein klicken, set attr Template xxx
- fertig oder ggf minimal anpassen

Das geht natürlich auf verschiedenen wegen aber nur mal einer als Beispiel.

Gesendet von meinem LM-G810 mit Tapatalk

[Beta-User]

@ripperle
Du kannst es gerne besser dokumentieren...

Und wenn du weißt, was du tust, geht auch alles ohne autocreate, auch die gefilterten attrTemplate kann man anwenden, muß dann aber halt wissen, wie der topictree aufgebaut ist bzw. aufgebaut werden muß, um dann die Rückfragen passend zu beantworten. Oder man erstellt ein "rudimentäres" Device, das für die attrTemplate-Erkennung ausreichend ist, in der Regel reicht ein bestimmter readingList-Eintrag (LWT@tasmota, IRGENDEINEN Eintrag, der mit "shellies/" beginnt für die shelly-Geräte). Ist auch nicht schwer, nur eben nicht separat dokumentiert...

(Grummel, das Gemotze finde ich irgendwie ungerecht . Ist schon klar, dass "besser" immer geht, aber zum einen tut autocreate meist, was es soll, jedenfalls, wenn man es "richtig" macht und wenigstens versucht zu verstehen, was da abläuft. Und zum anderen ist die Doku zumindest so, dass gefühlt 80-90% der User positiv überrascht sind, wie intuitiv das alles eigentlich geht.

Wer Verbesserungsvorschläge hat oder direkt verbessern kann und will, ist herzlich willkommen, aber nur Motzen ist ... (such dir was aus!)).
Schönen Abend noch...

[marvin78]

Alles gut. Es funktioniert wie es soll. Doku ist prima und mehr als ausreichend. Wer damit nicht zurecht kommt, fällt eben hinten runter. Kann man verschmerzen.

[87insane]

Das sollte nicht die Botschaft sein!

Vielmehr hilft zu lesen oder sachlich zu fragen. Hatte auch Schmerzen mit dem Gemecker. Wichtig ist eben das man zumindest basics kennt. Du fährst dein Auto ja auch nicht ohne zu wissen wo dir bremse ist (übertrieben aber sollte es verdeutlichen).

Du hast es hin bekommen, sagtest du... Vielleicht hilft dein Lösungsweg einem anderen, der mal das Problem hat. Mich würde sie interessieren..

Gesendet von meinem LM-G810 mit Tapatalk