MQTT2+Shelly: erste Konfiguration und template-Entwicklung

[Beta-User]

Hey - Was genau ist in deinem "Test" anders?
Ich nutze bei allen Shelly event-on-change .* (als Minimum).

.* ist schlicht und ergreifend mMn. zu pauschal, das ist in dem Beispiel sehr viel ausdifferenzierter, auch was timestamps angeht. Vielleicht hast du ja einen pm-Shelly irgendwo rumfliegen und kannst mal einen etwas kritischer beobachtenden Blick auf das ganze Device im Betrieb (auch bei lokalen Schaltungen am Taster usw.) werfen, wenn die von mir vorgeschlagenen Attribute gesetzt sind? Das Zusammenspiel ergibt sich besser, wenn man das "in Aktion" erlebt...

.* werde ich jedenfalls bis auf weiteres nicht einfach so in attrTemplate-Form gießen.

[87insane]

Ne neeeeee.. Sagte ja auch als Minimum. Je nachdem was das Ding in der Wand auch am Ende machen soll.

Ja, teste ich. Am Ende ist es aber sehr Personen bezogen. Waschmaschine ist am Ende was anderes als ein Licht oder aber ggf. als Raumzähler... usw

EDIT: Aber zum testen wollte ich nur die Veränderungen wissen. Würde das dann einfach anpassen. Wollte eben nicht selber comparen

[87insane]

Hab den Test seit gestern Abend in meinem Waschmaschine Shelly.... Mal sehen was kommt.

[Hellspawn]

Hallo Ihr, ich noch mal...

ich habe hier einen Shelly-DW2, der verhält sich auch brav wie er soll... wenn ich allerdings das DW Template auswählen erscheint:

Code Auswählen Erweitern

Unknown command shellies/announce:.*, try help.

ich glaube da ist ein Fehler im Template...

Gruß
Carsten

[Beta-User]

Danke für den Hinweis, da fehlt ein Zeilenumbruch (\) in Zeile 2351.

Update folgt.

Was mich zu dem allgemeinen announce-Pfad noch interessieren würde: Ist der eigentlich (noch) notwendig?
Hintergrund der Frage: würde eher dazu tendieren, das "shelly_announces" etwas mehr in den Vordergrund zu rücken bzw. ggf. im Hintergrund dafür sorgen, dass das als separates Device (einmalig) angelegt wird, um alle diese zentralen Infos zu abonnieren? Die "announce"-Infos kommen ja über zwei Pfade an, wenn man dem attrTemplate Glauben schenkt, und sind daher ggf. einfach doppelt bzw. werden auch doppelt ausgewertet... (man könnte den Pfad auch drin lassen, aber dann die Daten nicht auswerten; das erscheint mir als "Nebenaktion" sinnvoller, als die regex drüberlaufen zu lassen, das erzeugt ggf. nur unnötige Systemlast).

(Nach Analyse des MQTT-Verkehrs gebildete) Rückmeldungen wären nett...

[JJ_Pamoux]

Ich habe jetzt eine Shelly 1 an meine Sommer Garagensteuerung angeschlossen und auch ein Template erstellt.

Für mich passt das so, aber da gibt es bestimmt etwas zu verbessern.

Code Auswählen Erweitern


name:shelly1_garage
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;Shelly1 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
order:A_10
attr DEVICE setList\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on\
  x_update:noArg shellies/DEVNAME/command update_fw\
  x_mqttcom shellies/DEVNAME/command $EVTPART1
attr DEVICE webCmd :on
attr DEVICE readingList \
  shellies/DEVNAME/relay/0:.* state\
  shellies/DEVNAME/relay/0:.* relay0\
  shellies/DEVNAME/input/0:.* input0\
  shellies/DEVNAME/online:.* online\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }\
  shellies/announce:.* { $EVENT =~ m,..id...DEVNAME...mac.*, ? json2nameValue($EVENT) : return }
attr DEVICE cmdIcon on:fts_garage_door_up_down_stop
attr DEVICE devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $status = ReadingsVal($name,"input0","0") eq "0" ? "100" : "10";; 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 on&XHR=1\">".FW_makeImage("fts_garage_door_".$status)."</a></div>" }
deletereading -q DEVICE (?!associatedWith).*
set DEVICE x_mqttcom announce
set DEVICE attrTemplate speechcontrol_type_switch
attr DEVICE model shelly1_garage


Was mich noch stört, wenn ich z.B. das Shelly 2.5 Roller-Template (shelly25_roller_invert_0) verwende, dann erhalte ich nach einem Klick auf die Bezeichnung des Devices den "Vorschlag" set mit dem pct-Slider zu nutzen.
Bei meinem Template wird mir stattdessen "vorgeschlagen" das attrTemplate zu setzen (was ich ja glaube schon mit dem Template gesetzt zu haben).
Wie kann ich denn vorgeben, dass einfach set DEVICE on vorgeschlagen wird? Auf die Schnelle habe ich da im Template nichts gesehen.

[Beta-User]

Vorab mal willkommen im Forum!

Danke auch für den template-Vorschlag, von dem ich allerdings noch nicht so recht verstanden habe, was der "Trick" sein soll, den du damit als Beispiel zeigen willst. Oder funktioniert was an dem Basistemplate nicht?

Was die Frage angeht, wie ein Device aussieht (sowas wie webCmd, cmdIcon etc. allgemein), und wie die ganzen Attribute sinnvollerweise nacheinander aufeinander aufbauend zu setzen sind, würde ich das lieber an einem "einfachen" Device (idealerweise einem shelly mit Power-Messung) mal exemplarisch im Wiki zeigen (ähnlich wie "Device Overwiew anpassen"), bisher hat dazu aber noch keiner effektiv einen Vorschlag geliefert... (in diese Richtung verstehe ich das mit dem Roller-shelly?).

(Da das ein Garagentoröffner ist: du hast vermutlich das Teil im Tasterbetrieb und auch noch was auf dem Gerät konfiguriert, damit es nach einem "on" gleich wieder aus geht, oder?)

[JJ_Pamoux]

Hallo!

Danke für die schnelle Rückmeldung. Wieso "Trick"?
Ich habe einen Shelly 1 genutzt, dieser zeigt mir gleichzeitig (detached Switch) an, in welchem Status das Garagentor ist und ich kann es schalten (und ja, richtig vermutet, es schaltet nach 0,2 Sekunden wieder auf off).

Die Statusanzeige funktioniert, das Auf/Ab/Stop-Fahren funktioniert (habe dafür ein Icon modifiziert, bin mir nicht sicher, ob man das dann veröffentlichen darf), nur leider bekommt man beim Klick auf das Device halt immer den Vorschlag man solle ein Template setzen, statt den einfach "set on". Das wäre mir halt lieber, da man dann mit dem Smartphone nicht direkt das Template verstellt.

Habe dies hier beschrieben (letzter Post):
https://forum.creationx.de/forum/index.php?thread/2159-garagentor-sommer-torantrieb-s-9080-pro/

[87insane]

@beta-user: hab deinen Vorschlag nun lange getestet und bisher nur für die waschmaschine (bei mir running) in event-on-change reading hinzugefügt. Ansonsten reagiert eben kein notify oder sonst was. Aber sonst gut.

Teste weiter und melde mich.

Ps: running ist es bei mir. Glaube du/die Templates haben dafür loadstate.

[lewej]

Hallo zusammen,

Ich stell mal hier die Frage rein, weil ich keinen anderen passen thread gefunden habe. Shelly schreibt ja ins topic /shellies/ID/online{true/false} rein. Das ganze passiert beim boot oder man triggert ein update.

Wenn man nichts macht, bleibt dort true stehen, obwohl man den shellie stromlos gemacht hat, ein Update kann dann halt nicht erfolgen. Im setting Teil vom shelly gibt es einen keep alive, der scheint inputs und relay  Topics upzudaten, was irgendwie nicht das ware ist.

Wie könnte man den online Status als heartbeat umsetzen, evtl. stand der eine oder andere vor dem gleichen Problem?

[87insane]

Vermutlich OT (so wie die Frage)...

MQTT hat IMMER einen Keep-Alive auf den online Status. MQTT sendet beim ersten Verbinden zum Server direkt die Info wie lange er als online gelten soll, wenn er sich nicht mehr meldet (also aus ist).
(https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament/)

In deinem Shelly ist das die eingestellte Zeit unter: Internet & Security -> ADVANCED - DEVELOPER SETTINGS -> Keep-Alive (Standard ist 60 Sekunden).
Also wenn Shelly offline, dann wird FHEM das nach 60 signalisieren.

[rudolfkoenig]

MQTT hat IMMER einen Keep-Alive auf den online Status.

Nicht immer, aber ueblicherweise. Beim LWT ist das genauso.
Weiterhin muss der Server nach 1.5-mal Keep-Alive Time Alarm schlagen, hier also nach 90 Sekunden.
Siehe http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc385349238

[lewej]

Hallo zusammen,

shelly hat bei einigen devices ein neues Topic eingeführt. Die senden jetzt nach shellies/DEVICNAME/info Infos zu WLan und noch anderen Einstellungen.
Hat das jemand schon eingebunden?

Mit diesem subscribe geht es nicht:
shellies/DEVICENAME/info:.* { json2nameValue($EVENT) }

Gruß

[87insane]

Hallo zusammen,

shelly hat bei einigen devices ein neues Topic eingeführt. Die senden jetzt nach shellies/DEVICNAME/info Infos zu WLan und noch anderen Einstellungen.
Hat das jemand schon eingebunden?

Mit diesem subscribe geht es nicht:
shellies/DEVICENAME/info:.* { json2nameValue($EVENT) }

Gruß

Bei mir geht wie es rein kommt....

Code Auswählen Erweitern

shellies/shelly1pm-12345/info:.* { json2nameValue($EVENT) }

Beispiel: wifi_sta_connected
true
2020-10-06 12:40:37
wifi_sta_ip
192.168.20.51
2020-10-06 12:40:37
wifi_sta_rssi
-54
2020-10-06 12:40:37
wifi_sta_ssid
KA-nG-WLan_2.4Ghz
2020-10-06 12:40:37

[rallye]

Guten Abend in die Runde !
Ich hab mir mal ein paar Shellys (1er-Modell) zugelegt und einen verbaut. Ich bin nun nicht sicher welche Methode der Anbindung zu FHEM ich verwenden soll... HTTP oder MQTT ? Gibt's irgendwo eine "Abhandlung" über die Vor- und Nachteile der beiden Anbindungen ? Am Ende des Tages möchte ich so ca. 15+ Shellys verbauen (die sind so schön klein und passen überall hinein). Danke