MQTT2+Shelly: erste Konfiguration und template-Entwicklung

[stratege-0815]

Falls ich gemeint bin muss ich etwas ausholen...
Sorry für OT
Ich möchte eine Nachtbeleuchtung für eine Treppe realisieren. Vom EG immer an der Treppenwange entlang bis zum 2.OG. Ich habe 2015 bei einer Treppenhaus Sarnierung schon Leerrohre verlegt. Ich komme auf ca. 13 LED insgesamt, immer wieder unterbrochen durch Kabelstrecken (Leerrohre im Boden).
Nun kam tatsächlich von den Kindern der Wunsch nach einem Bewegungsgesteuerten Nachtlicht damit der alternde Hund nicht stolpert. (Kommt tatsächlich vor) Aber auch wenn die Nachtschwärmer nach Hause kommen wäre das kein Nachteil. Ich lese mich in die LED stripe Thematik gerade erst ein. Einzeln gesteuerte LEDs sind ja wohl eine ganz andere Baustelle, ich glaube mit meinen Kabelunterbrechungen kriege ich das auch gar nicht hin. Aber mit RGBW sollten auch ein paar Effekte möglich sein - sanftes Überblenden der Farben wäre wohl ganz brauchbar.

[pula]

Hi,
für so was wäre evtl WS2812b eine super Option, da kann man jede LED einzeln steuern...
Cheers,
Pula

[Hellspawn]

Mal eine andere Frage, vielleicht stehe ich auch einfach nur auf dem Schlauch...
ich versuche auf ein Event zu triggern und zwar eines Shelly 2.5 Langer Tastendruck.. das Event ist:

Code Auswählen Erweitern

MQTT2_DEVICE shelly_KuechenLichtCH2 event: L
das funktioniert auch gut... ABER
das Event erscheint immer wieder im eventmonitor und zwar solange, bis ich einen kurzen Tastendruck mache... dann erscheint

Code Auswählen Erweitern

MQTT2_DEVICE shelly_KuechenLichtCH2 event: S

das Problem was ich habe, ist das mein DOIF immer wieder loslegt obwohl ich keinen langen Klick gemacht habe...

Liegt es an mir, am Doif oder evtl. doch am MQTT2 Template?

Lg
Carsten

[rudolfkoenig]

Vmtl an Dir und DOIF
Ich gehe davon aus, dass dein DOIF nicht richtig konfiguriert ist.
Um es zu reparieren wuerde ich in der DOIF- oder Anfaenger-Abschnitt des Forums ein Thema oeffnen, und die Details (aka list oder list -r) des aktuellen DOIFs schildern, samt den Event-Zeilen aus dem Event-Monitor.

[Beta-User]

...oder an dem Shelly...

Der ESP sendet (vermtl. abhängig von der Konfiguration) auch regelmäßig Statusupdates, obwohl sich nichts geändert hat, das Thema hatten wir schon ein paar Mal, aber bisher hat sich keiner bemüßigt gefühlt mir zu erklären, wie man das einem Shelly (bzw. wie welchem) "austreiben" kann.

Da der Shelly vermutlich Klartext sendet: event-on-change.* und timestamp-on-change.* ansehen und bitte dann eine so konsolidierte Rückmeldung machen, dass ich die Allgemeingültigkeit (bzw. den exakten Gültigkeitsbereich) der betreffenden Einstellungen erkennen kann, bitte dabei berücksichtigen, dass es für Meßwerte Sinn macht, die auch dann zu senden/und ggf. zu loggen, wenn sich nichts geändert hat seit der letzten Messung...

(Gerne können wir das für einen einzelnen Shelly auch mal durchexerzieren, ich bräuchte dann aber bitte a) einen separaten Thread und b) den Verkehr auf der MQTT-Ebene.)

[87insane]

Eigentlich sollte longpush auch ein Reading haben welches auf 1 oder 0 steht....
longpush_0

Kommt aus: shellyXYZ_ID:shellies/shellyXYZ-ID/longpush/(0|1) (Je nachdem wie viele Eingänge er hat).

Bei mir laufen die "longpushes" eigentlich sauber... Ggf. Das Gerät krumm?

[Hellspawn]

ok, mit dem Reading geht es in der Tat...
vielen Dank für die Rückmeldung...

[Beta-User]

...das ändert aber nichts daran, dass der Shelly an anderer Stelle nach meinem Geschmack (viel) zu gesprächig ist und man diese Flut unabhängig von der "anderen Lösung" eindämmen sollte...

[87insane]

Shelly verhält sich fast wie Tasmota (in meinen Augen).
Ich habe überall event-on-change aktiv, da mir das sonst auch zu viel ist. Allerdings dämme ich damit nur die Verarbeitung ein, nicht aber das was der Shelly immer und immer wieder sendet.

Was genau stört Dich an der Kommunikation? Ggf. kann ich ja helfen...

Gruß,
87insane

[Reinerlein]

Hallo Beta-User,

mir ist an dem DevStateIcon der Shelly-Templates eine kleine Unschönheit aufgefallen.
Es wird dort oftmals sowas gemacht:

Code Auswählen Erweitern

my $light = ReadingsVal($name,"state","off");;

Damit soll dann der aktuelle Zustand in $light abgelegt werden, um ihn für die spätere Darstellung verwenden zu können.
Die Verwendung von "ReadingsVal" hat aber den unschönen Nebeneffekt, dass das immer live vom Gerätedevice geholt wird. Bei einer Anzeige innerhalb einer LightScene z.B. wird dann in der Szenenübersicht immer der aktuelle Zustand des Geräts dargestellt, und nicht der, den die Szene schalten würde.

Ich habe dieses "$light" bei mir ersetzt duch "$state". Diese Variable wird von FHEMWEB vor dem Perl-Eval des DevStateIcon gesetzt, und enthält im Falle einer Lightscene auch den passenden Wert, der geschaltet werden soll.

Am Beispiel von "shelly1_w_energy_meassuring" (schreibt man übrigens wohl mit einem "s" ):

Code Auswählen Erweitern

{my $onl = ReadingsVal($name,"online","false") eq "false"?"10px-kreis-rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "10px-kreis-gelb" : "10px-kreis-gruen";; my $cons = ReadingsVal($name,"relay_0_power","unknown");; my $total = ReadingsVal($name,"relay_0_kWh","unknown");; my $temp = ReadingsVal($name,"temperature","-100");;"".FW_makeImage($onl)." ".FW_makeImage($state)."
Verbrauch: $cons / Total: $total/ Temp: $temp ° C
"}
Die Definition von $light raus, und direkt $status verwenden.

Bei den anderen dann Analog dazu...

Grüße
Reinerlein

[Beta-User]

@Reinerlein:

Danke für die Rückmeldung, ich bau's bei Gelegenheit um. (Man lernt nie aus...)

Für den Fall, dass jemand diese Fleißarbeit leisten will (und dabei auch den Typo eliminieren mag):
Feel free, ich nehme auch patches oder "normalen Text", dann aber bitte möglichst alles als kompletten Auszug liefern...

[Beta-User]

Shelly verhält sich fast wie Tasmota (in meinen Augen).
Ich habe überall event-on-change aktiv, da mir das sonst auch zu viel ist. Allerdings dämme ich damit nur die Verarbeitung ein, nicht aber das was der Shelly immer und immer wieder sendet.

Was [...] stört Dich an der Kommunikation?

Was mich "ungenau" stört: Das Verhalten von Shelly ist (wie das von Tasmota auch, aber da haben wir auch einigen Aufwand reingesteckt, um die Auswirkungen sinnvoll zu begrenzen...) mMn. nicht 100% "MQTT"-like.

Ich zitiere mal aus der Doku zu 3.1.1 (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html)

MQTT is a Client Server publish/subscribe messaging transport protocol. It is light weight, open, simple, and designed so as to be easy to implement. These characteristics make it ideal for use in many situations, including constrained environments such as for communication in Machine to Machine (M2M) and Internet of Things (IoT) contexts where a small code footprint is required and/or network bandwidth is at a premium.

Immer alles zu senden, ist nicht "light weight", hier hatte ich dazu auch schon mal etwas mehr geschrieben:

[...] Das "Grundproblem" ist m.E. ein anderes: Nach meinem Verständnis ist MQTT ein Protokoll, das mal dafür gemacht war, Zustände ausfallsicher zu übermitteln. Es gibt daher zu jedem Informationspunkt in meiner Gedankenwelt optimalerweise genau eine Information, die in der Auswahl recht beschränkt ist, und irgendwelche Elemente nach dem Muster "0/1/on/off/missing/offline/failure..." haben sollte. Mit JSON weicht man das Prinzip etwas auf, was auch noch solange ok ist, als die Datenpunkte und Werte irgendwie zuordenbar bleiben.

Dinge wie Grafiken (valetudo) oder Konfigurationen (homeassistant-discovery-Meldungen) zu übertragen, sind für mich "abuse", das ist nicht "schlank und schnell" (=MQTT-like=maschinenlesbar), sondern "fett" (Webpage-like=menschenlesbar).

[...]
Vielleicht kurz zum Hintergrund: Mein "gedanklicher Prototyp" für den Einsatz von MQTT ist eine Ölpipeline. Für sowas wurde das afaik mal entwickelt:
Hardwareüberwachung unter Extrembedingungen. Lange Stecken, ständig zu befürchtende Verbindungsabbrüche, widrige externe Umstände wie Hitze/Staub/Kälte/Wasser. Also: Wenig Info, eigentliche Auswertung der Info erfolgt "hinter dem Broker".

Ich hoffe, das ist nachvollziehbar und hilft ggf. auch beim Design (imo) "guter" MQTT-Implementierungen?

Kurzform: Ein optimales MQTT-Device sendet mMn. immer nur genau die Infos, die jemand in einem Kontrollzentrum braucht oder haben will. Das erfordert eigentlich entsprechende Konfigurationsmöglichkeiten auf dem Device selbst, die allerdings afaik teils nicht vorhanden sind (?).
Meine Erwartung, an das, was zu senden wäre, wäre daher in etwa das hier:
- LWT => zeigt an, ob das Gerät überhaupt erwartungsgemäß kommunizieren kann. Sollte JEDES MQTT-Gerät können. Intervall sollte einstellbar sein, per Default eher lang (in einem typischen Hausautomatisierungsumfeld reichen 5-15 Minuten oder so).
- Bestätigungen für erhaltene Anweisungen (schalte Relay xy ein)
- Messwerte wie Temperaturen oder Luftfeuchtigkeit: regelmäßig, Intervall einstellbar, optimalerweise noch mit Schwellenwerten für schnellere Änderungen)
- Basisinfos nur beim Starten (IP-Adresse, firmwareversion usw.)
- sonstige Statusinfos nur auf Anfrage

Was mich konkret stört? Hier hatte ich versucht zu schreiben, was ich konkret haben will:

Da der Shelly vermutlich Klartext sendet: event-on-change.* und timestamp-on-change.* ansehen und bitte dann eine so konsolidierte Rückmeldung machen, dass ich die Allgemeingültigkeit (bzw. den exakten Gültigkeitsbereich) der betreffenden Einstellungen erkennen kann, bitte dabei berücksichtigen, dass es für Meßwerte Sinn macht, die auch dann zu senden/und ggf. zu loggen, wenn sich nichts geändert hat seit der letzten Messung...

Hier hatte ich mal eine auf die Schnelle zusammengeklöppelte Basis gepostet:

Bin nicht sicher, ob wir es da mit einem Fall von Rationalisierung zu tun haben .
Wie dem auch sei: Wer bisher kein MQTT(2) nutzt, hat mit deinem Modul eine sehr gute Alternative, wer sowieso MQTT(2) nutzt, wird seine Gründe haben und die "Einheitlichkeit" (*lach...*) schätzen.

Aber:
Man könnte es auch als verpaßte Gelegenheit auffassen, den Usern den "richtigen Umgang" (falls es sowas überhaupt gibt...) mit den event-on.* und timestamp.*-Attributen zu vermitteln . Macht hier ja durchaus Sinn, da die Shelly ja (@MQTT) dankenswerterweise "Klartext" (und nicht JSON) sprechen. Oder dem Hersteller ein etwas differenzierteres Sendeverhalten vorzuschlagen, wenn man einen guten Draht hat und sowas auch sachlich differenziert vermitteln kann.

Wie dem auch sei, hier mal ein vorläufiges Zwischenergebnis@MQTT2 als Diskussionsgrundlage:

Code Auswählen Erweitern

defmod Muster_Shelly1pm MQTT2_DEVICE shelly1pm_123456789012
attr Muster_Shelly1pm IODev MQTT2_FHEM_Server
attr Muster_Shelly1pm comment To get appropriate loadState values: Change the default limit "100" in readingList to your needs.
attr Muster_Shelly1pm devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false"?"10px-kreis-rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "10px-kreis-gelb" : "10px-kreis-gruen";;;; my $light = ReadingsVal($name,"state","off");;;; my $cons = ReadingsVal($name,"relay_0_power","unknown");;;; my $total = ReadingsVal($name,"relay_0_kWh","unknown");;;; my $temp = ReadingsVal($name,"temperature","-100");;;;"<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage($onl)."</a> <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a><div>Verbrauch: $cons / Total: $total/ Temp: $temp °C</div>"}
attr Muster_Shelly1pm event-on-change-reading state,temperature:0.2,online,loadState,overtemperature,Verbrauch_Total_kWh,relay_0_.*,relay0,input0
attr Muster_Shelly1pm event-on-update-reading stat[ERT].*
attr Muster_Shelly1pm model shelly1_w_energy_meassuring
attr Muster_Shelly1pm readingList shellies/shelly1pm-123456789012/relay/0:.* state\
  shellies/shelly1pm-123456789012/relay/0:.* relay0\
  shellies/shelly1pm-123456789012/input/0:.* input0\
  shellies/shelly1pm-123456789012/online:.* online\
  shellies/announce:.* { $EVENT =~ m,..id...shelly1pm-123456789012...mac.*, ? json2nameValue($EVENT) : return }\
  shellies/shelly1pm-123456789012/announce:.* { json2nameValue($EVENT) }\
  shellies/shelly1pm-123456789012/relay/0/power:.* relay_0_power\
  shellies/shelly1pm-123456789012/relay/0/power:.* { my $compare = $EVTPART0 < 100 ? "off":"on";; ReadingsVal($NAME,"loadState","off") ne $compare ? { 'loadState' => $compare } : return }\
  shellies/shelly1pm-123456789012/temperature:.* temperature\
  shellies/shelly1pm-123456789012/overtemperature:.* overtemperature\
  shellies/shelly1pm-123456789012/relay/0/energy:.* relay_0_energy\
  shellies/shelly1pm-123456789012/relay/0/energy:.* {'relay_0_kWh' => sprintf("%.2f",$EVENT/60/1000)}\
  shellies/shelly1pm-123456789012/longpush/0:.* longpush_0\
  shellies/shelly1pm-123456789012/temperature_f:.* {}\
  shellies/shelly1pm-123456789012/input_event/0:.* { json2nameValue($EVENT) }
attr Muster_Shelly1pm room Steuerung->Test
attr Muster_Shelly1pm setList relay0:on,off,toggle shellies/shelly1pm-123456789012/relay/0/command $EVTPART1\
  off:noArg shellies/shelly1pm-123456789012/relay/0/command off\
  on:noArg shellies/shelly1pm-123456789012/relay/0/command on\
  x_update:noArg shellies/shelly1pm-123456789012/command update_fw\
  x_mqttcom shellies/shelly1pm-123456789012/command $EVTPART1
attr Muster_Shelly1pm setStateList on off
attr Muster_Shelly1pm timestamp-on-change-reading state,online,loadState,overtemperature
attr Muster_Shelly1pm userReadings relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum("$name","relay_0_energy",0)}, Verbrauch_Total_kWh:relay_0_kWh:.* monotonic {ReadingsNum("$name","relay_0_kWh",0)}
attr Muster_Shelly1pm webCmd :

Vielleicht mag das ja jemand testen, verfeinern und ggf. so (generisch) notieren, dass man es auch für andere Shellies verwenden kann...?

[87insane]

Eine Konsole hat man zwar nicht aber man kann den Intervall umstellen (meine ich jetzt aus dem Kopf).

Beim Lesen des zu testenden, sehe ich alte Bekannte😅
Glaube wir haben bei tasmota schon viel gesprochen darüber... Naja egal... Wenn ich an den pc kann/darf, teste ich.

[Beta-User]

Das ist seit eben (hoffentlich) durchgängig raus (auch bei Tasmota), und den Typo habe ich auch gefixt.

Code Auswählen Erweitern

my $light = ReadingsVal($name,"state","off");;

[87insane]

Was mich "ungenau" stört: Das Verhalten von Shelly ist (wie das von Tasmota auch, aber da haben wir auch einigen Aufwand reingesteckt, um die Auswirkungen sinnvoll zu begrenzen...) mMn. nicht 100% "MQTT"-like.

Ich zitiere mal aus der Doku zu 3.1.1 (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html)

Immer alles zu senden, ist nicht "light weight", hier hatte ich dazu auch schon mal etwas mehr geschrieben:Kurzform: Ein optimales MQTT-Device sendet mMn. immer nur genau die Infos, die jemand in einem Kontrollzentrum braucht oder haben will. Das erfordert eigentlich entsprechende Konfigurationsmöglichkeiten auf dem Device selbst, die allerdings afaik teils nicht vorhanden sind (?).
Meine Erwartung, an das, was zu senden wäre, wäre daher in etwa das hier:
- LWT => zeigt an, ob das Gerät überhaupt erwartungsgemäß kommunizieren kann. Sollte JEDES MQTT-Gerät können. Intervall sollte einstellbar sein, per Default eher lang (in einem typischen Hausautomatisierungsumfeld reichen 5-15 Minuten oder so).
- Bestätigungen für erhaltene Anweisungen (schalte Relay xy ein)
- Messwerte wie Temperaturen oder Luftfeuchtigkeit: regelmäßig, Intervall einstellbar, optimalerweise noch mit Schwellenwerten für schnellere Änderungen)
- Basisinfos nur beim Starten (IP-Adresse, firmwareversion usw.)
- sonstige Statusinfos nur auf Anfrage

Was mich konkret stört? Hier hatte ich versucht zu schreiben, was ich konkret haben will:

Hier hatte ich mal eine auf die Schnelle zusammengeklöppelte Basis gepostet:Vielleicht mag das ja jemand testen, verfeinern und ggf. so (generisch) notieren, dass man es auch für andere Shellies verwenden kann...?

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