MQTT2+Shelly: erste Konfiguration und template-Entwicklung

[87insane]

Anbei mal die technischen Daten der Shellys. Ich denke diese können bei der Template Entwicklung auch ganz interessant sein. Ggf. als Inspiration...

http://www.anf.de/shelly/modules02.htm

[Udomatic]

Hallo,

ich habe heute meinen dritten Shelly Plug S eingerichtet. MQTT habe ich aktiviert und den FHEM Server hinterlegt, wie bei den anderen beiden auch. Diese wurden auch automatisch in FHEM als MQTT_Device angelegt.

Der neue nun nicht. Jemand eine Idee? Hat sich seit dem Update etwas geändert?

[87insane]

Werksreset und nochmal.
Ggf auch nur n IP dreher oder so.

Gesendet von meinem LG-H850 mit Tapatalk

[Udomatic]

Werksreset und nochmal.
Ggf auch nur n IP dreher oder so.

Werksreset brachte keine Änderung.
Weil ich erstmal keine andere Idee hatte habe ich das Gerät nun per define als Shelly Device angelegt. Ich frage mich gerade warum ich MQTT dann überhaupt benötige, weil Leistungsmessung und Übertragung funktioniert ebenso??

[Bartimaus]

Weil über Mqtt2 auch Stati VOM Gerät übermittelt werden, also wenn Du am Gerät schaltest...

[Udomatic]

Weil über Mqtt2 auch Stati VOM Gerät übermittelt werden, also wenn Du am Gerät schaltest...

Also per WLAN ging das eben auch. Hat nur etwas länger gedauert.

Warum auch immer, ist das Gerät plötzlich als MQTT_Device aufgetaucht. Hat etwa ne Stunde gedauert seit Inbetriebnahme. Bei den ersten beiden Shellys war das vlt. innerhalb einer Minute.

Bin gerade etwas verwirrt...

[87insane]

Ggf. macht da auch mal ein FHEM Server neustart Sinn. Normal melden die Geräte sich direkt am MQTT Server an und werden angelegt. Ich hatte das auch einmal (hab über 30 Shelly). Allerdings war das ein IP dreher (bei mir).

MQTT ist am Ende ja nicht nur für Shelly. Warum du das brauchst? Naja du kannst ja selber wählen wie du deine Hardware ansteuerst. Allerdings bin ich ein absoluter MQTT Freund. Es ist einfach, schnell und zuverlässig. Ich nutze MQTT für so gut wie alles

Was genau bei dir nicht ging, lässt sich nicht so einfach nachvollziehen. Du hattest kein EventMonitor oder LOG mit gesendet. Auch deine FHEM MQTT Einstellungen sind unbekannt. Genau wie die Settings im Shelly. Wie du selber sagtest, es dauert normal nur wenige Sekunden bis ein Gerät erzeugt wird, nachdem man die Daten im Shelly eingegeben hat. Ich würde auch kein MQTT Gerät per define anlegen, wenn es sich selbst erzeugen kann. Meist kann man damit schon sehen, wenn man ggf. mal was falsch gemacht hat.

Naja -> Ende gut, alles gut

PS: Ich selber vergesse das gerne, aber das Template für den 1PM ist auch für den PlugS. Ich nehme lieber das, anstelle des normalen attr Template, des Shelly Plug (ohne S).


EDIT: Nochmal zum Verständnis.... MQTT macht mehr als nur Shelly. Ich weiß nicht wie du dein define genau gemacht hast, da es für Shelly aktuell mehrere Wege gibt. Wir haben das Shelly Modul und MQTT. Auch HTTP würde gehen.

[Udomatic]

Was genau bei dir nicht ging, lässt sich nicht so einfach nachvollziehen. Du hattest kein EventMonitor oder LOG mit gesendet. Auch deine FHEM MQTT Einstellungen sind unbekannt. Genau wie die Settings im Shelly. Wie du selber sagtest, es dauert normal nur wenige Sekunden bis ein Gerät erzeugt wird, nachdem man die Daten im Shelly eingegeben hat. Ich würde auch kein MQTT Gerät per define anlegen, wenn es sich selbst erzeugen kann. Meist kann man damit schon sehen, wenn man ggf. mal was falsch gemacht hat.

Naja -> Ende gut, alles gut

PS: Ich selber vergesse das gerne, aber das Template für den 1PM ist auch für den PlugS. Ich nehme lieber das, anstelle des normalen attr Template, des Shelly Plug (ohne S).


EDIT: Nochmal zum Verständnis.... MQTT macht mehr als nur Shelly. Ich weiß nicht wie du dein define genau gemacht hast, da es für Shelly aktuell mehrere Wege gibt. Wir haben das Shelly Modul und MQTT. Auch HTTP würde gehen.

Ich hatte den Event Monitor leider nicht mitlaufen und konnte deshalb nichts genaueres hier posten. Trotzdem Danke!

Das define habe ich auf Basis des Shelly Moduls angelegt: define <name> Shelly <IP Shelly>
Habe es jetzt aber gelöscht, weil ich nicht zweimal das gleiche Device in FHEM möchte.

[87insane]

Dann hast du ja alles hin bekommen... Weiter so und viel Spaß damit

[sledge]

Eine generelle Frage bei den ganzen devStateIcon-Vorschlägen: Ich denke, das möchte jeder gerne ein bisschen anders haben - insofern finde ich den Transfer in die Templates nicht so ganz glücklich.

Sollte man diese Vorschläge samt Bildmaterial nicht eher in einem entsprechenden Wiki-Artikel sammeln und das ausgelieferte Template diesbezüglich "schlicht" halten? Just an idea.

Meine Version des devStateIcon zB ist folgende:

Code Auswählen Erweitern

{
  my $online=ReadingsVal($name,"online","false");
  my $fw=ReadingsVal($name,"new_fw","false");
  my $power=ReadingsVal($name, "state","off");
  if($online eq "false")
  {
       return ".*:message_socket_disabled\@red";
  }
  elsif($fw eq "true")
  {
       return ".*:message_socket_unknown\@orange";
  }
  else
  {
       if($power eq "on")
       {
           return ".*:message_socket_on2\@green";
       }
       else
       {
           return ".*:message_socket_off2\@grey";
       }
   }
}

Und @Beta-User bzgl. des Announce: Es ist in der Tat so, dass die Shelly seit einer der letzten Firmware-Updates recht sparsam sind mit den ersten Informationen - das "online" Reading zB kommt erst nach langer Zeit - dann verwirrt auch das ausgelieferte devStateIcon, da es auf "rot" steht, obwohl der Shelly klar ansteuerbar ist.

Vermutlich reicht ein

Code Auswählen Erweitern

set DEVICE x_mqtt_com announce am Ende der jeweiligen Templates, um die Shelly hier zu einer entsprechenden Antwort anzuregen.

[87insane]

Zum zweiten Teil: announce reicht hier. Ist aber schon seit Anbeginn der shellys. Also hast du recht damit.

Zum ersten Teil: sehe es mittlerweile wie Beta-User. Das ist ne Inspiration. Also ein einheitliches aber inspirierendes Template für alle...
Aber deine Idee macht natürlich auch Sinn. Ggf sollten alle Ideen in einem Wiki landen. So hätte man direkt verschiedene Varianten. Allerdings wären das bis hier her dann drei verschiedene. Die meisten nutzen es wohl, wie es ist. Hatte auch gedacht es müssten viele verschiedene sein. Aber so groß ist der Andrang bisher nicht. Du hast geschrieben, dass dein devstateicon "einfacher" ist. Denke das ist genau so schlimm für einen normalen User wie das aktuelle :-P musste auch drei mal lesen.

Hier kurz Edit: du hast nicht "einfacher" geschrieben, ich hatte es nur falsch im Kopf. Sitze am handy und kann beim tippen, leider nicht nochmal nach lesen.

Die Wiki Idee würde ich soweit es mir möglich ist, unterstützen!

Gesendet von meinem LG-H850 mit Tapatalk

[sledge]

Zum zweiten Teil: announce reicht hier. Ist aber schon seit Anbeginn der shellys.

[....]
Du hast geschrieben, dass dein devstateicon "einfacher" ist. Denke das ist genau so schlimm für einen normalen User wie das aktuelle :-P musste auch drei mal lesen.

Die Wiki Idee würde ich soweit es mir möglich ist, unterstützen!

Einfacher - ja, True. Im Sinne von: Nur ein Icon. Keine Zusammengebauten Icons mit <...> usw Und als Anfang finde ich das FHEM-spezifische Lampen-Icon übrigens gar nicht so schlecht.

Und was die Wiki-Seite angeht: Klar. Ist die Überlegung, ob man die vorhandene Seite erweitert. Ich check' das mal ab.

[87insane]

Die zusammen gebauten Icons bieten alles. Kleiner machen ist ja meist einfacher als größer. Ist aber natürlich Geschmacks Sache.

Ich persönlich denke, das Wiki ist der richtige weg.
War schon ein Kampf das so hin zu bekommen und so kann man direkt sehen was alles so geht. Auch die Abhängigkeiten waren zu anfang höchst interessant.

Bin aber generell für alles offen und gespannt wohin die reise geht.

Gesendet von meinem LG-H850 mit Tapatalk

[Beta-User]

Eine generelle Frage bei den ganzen devStateIcon-Vorschlägen: Ich denke, das möchte jeder gerne ein bisschen anders haben - insofern finde ich den Transfer in die Templates nicht so ganz glücklich.

Hmm, eventuell wäre es eine Überlegung, die templates so zu ändern, dass zumindest bei vorhandenen devStateIcon-Attributen das bleibt, was da ist.

Nach meinem Eindruck waren die meisten bisher ganz froh mit dem, was ausgeliefert wurde, aber wenn es deutliche Nachfrage nach "weniger" gibt, mache ich auch das, mir letztlich egal...

(Mein Ziel bei der Mitarbeit an den attrTemplate-files war es übrigens u.A. _auch_, zu zeigen, was alles möglich ist, und da hat sich einiges bewegt, so dass es letztlich heute eher eine Frage der Praktikabilität ist, wo man was unterbringt...
Es sollte halt einheitlich sein, so dass die, die den Standard nutzen, nicht dauernd nacharbeiten müssen.

Sollte man diese Vorschläge samt Bildmaterial nicht eher in einem entsprechenden Wiki-Artikel sammeln und das ausgelieferte Template diesbezüglich "schlicht" halten? Just an idea.

Gerne dürft ihr den Artikel erweitern (paßt am ehesten doch direkt zu devStateIcon, oder?).

Würde nur dazu tendieren, vorneweg die Grundzüge mit _wenigen_ Beispielen zu erläutern und dann "hinten" weitere konkrete Beispiele zu nennen, wobei ausdrücklich erwähnt sei, dass die in der Einleitung vorhandenen Beispiele "verbesserungsfähig" sind...

Wäre super, wenn sich da jemand kümmern könnte/möchte!

Vermutlich reicht ein

Code Auswählen Erweitern

set DEVICE x_mqtt_com announce am Ende der jeweiligen Templates, um die Shelly hier zu einer entsprechenden Antwort anzuregen.

Schau ich mir an, guter Vorschlag! (nur evtl. etwas Aufwand)

[87insane]

x_mqtt_com gibt es zum Zeitpunkt des Templates ja nicht wirklich. Erst ganz am ende und da könnte es zu schnell rein laufen...(oder?).

Reicht doch dann einfach ein announce gegen alles zu pushen oder wie bei den tasmota's zb
set IO_DEV publish announce

Gesendet von meinem LG-H850 mit Tapatalk