Shelly Farbring mit MQTT ändern

There are 7 replies in this Thread which has previously been viewed 299 times. The latest Post (April 2, 2024 at 10:31 PM) was by CLohn.

  • Hallo zusammen,

    ich möchte gerne den Leuchtring von meinem Plus Plug S V2 per MQTT ändern.

    Den Shelly mit MQTT ein/aus schalten klappt über folgenden Befehl:

    Topic:

    PlusPlugSLED-Oben/command/switch:0

    Value on oder off

    Die Farbe des Leuchtrings kann ich über ein Http request ändern:

    sendHttpGetRequest("http://192.168.2.175/rpc/PLUGS_UI.S…22:%7B%22rgb%22:[100,0,0],%22brightness%22:100%7D,%22off%22:%7B%22rgb%22:[100,100,0],%22brightness%22:100%7D%7D,%22power%22:%7B%22brightness%22:100%7D%7D,%22night_mode%22:%7B%22enable%22:true,%22brightness%22:10,%22active_between%22:[%2222:00%22,%2206:00%22]%7D%7D,%22controls%22:%7B%22switch:0%22:%7B%22in_mode%22:%22detached%22%7D%7D%7D")

    Wie finde ich nun das entsprechende Topic (RBG) ? Es müsste irgendwie so aussehen:

    PlusPlugSLED-Oben/command/switch:0/rgb


    Mit Hilfe vom folgenden Aufruf bekomme ich die Struktur angezeigt

    192.168.2.175/rpc/PLUGS_UI.GetConfig


    {

    "leds": {

    "mode": "switch",

    "colors": {

    "switch:0": {

    "on": {

    "rgb": [

    100,

    0,

    0

    ],

    "brightness": 100

    },

    "off": {

    "rgb": [

    100,

    100,

    0

    ],

    "brightness": 100

    }

    },

    "power": {

    "brightness": 100

    }

    },

    "night_mode": {

    "enable": true,

    "brightness": 10,

    "active_between": [

    "22:00",

    "06:00"

    ]

    }

    },

    "controls": {

    "switch:0": {

    "in_mode": "detached"

    }

    }

    }

  • Per Skript wurde solches oder ähnliches bereits implementiert.

    Wenn du skripten nicht abgeneigt bist, kannst du darin einen eigenen Subscriber mit selbst gewählten Topic registrieren und alles, was du möchtest in dessen callback Funktion implementieren - grenzenlos. ;)

    Btw, "switch:0" ist reserviert für das Schalten des Ausgangsrelais. Ich würde mich wundern, wenn diese Component auch für die farbigen LED gelten täte.

    So übersichtlich kann die Antwort auf die HTTP Request dargestellt werden. ;)

    Ich brauche so etwas nicht, vermute aber, dass ein config Parameter erforderlich ist, dessen Wert ein Objekt (JSON Format) sein muss.

    In diesem Objekt können dann alle Teile, ich nenne solche "Komponenten" - nicht mit Component verwechseln, aufgeführt werden, die eingestellt werden sollen.

    Was du in der MQTT message/payload unterbringen kannst, hängt von deinem Frontend ab.

    Edit:

    Nach meiner bisherigen Erfahrung ist die Firmware eigene MQTT Kommunikation gewöhnungsbedürftig, weil sie, anders als im MQTT Standard, eine Peer to Peer Kommuniktion über den Broker nachbildet. Ich nutze solches per Node-RED, es bleibt trotzdem wenig vertraut.

    An Cloud-/Szenen-Benutzer (insbesondere für Regelungen): Was erwartest du, wenn Internet oder Cloud sabotiert werden? Nicht nur dafür meine kleine Skripteinführung  8)

    Die einzig existierende Konstante ist der Wandel. Oft liegt die größte Schwierigkeit darin, das Anliegen des Klienten zu verstehen.

    Edited 4 times, last by eiche (March 28, 2024 at 12:57 AM).

  • In der Doku habe ich schon nachgeschaut, leider finde ich nichts.

    Alleine das Schalten der Komponente mit:

    ShellyName/command/switch:0

    Value on oder off

    wird dort nicht erwähnt.

    Gibt es irgendwie die Möglichkeit, die command befehle vom shelly herauszufinden?

    Oder wo stehen diese in der Doku?

    Hier ist mein Auszug vom MQTT Explorer, was meine Shelly senden:

    Shelly.png

    Vielen Dank für die Infos

  • Dazu ein vermutlich hilfreicher Link: RPC channels - MQTT

    Dort entnehme ich folgendes.

    Als Beispiel-Topic: shellyplus1-c4dd57877294/rpc

    Als Beispiel-Payload: {"id":123, "src":"user_1", "method":"Switch.Set", "params":{"id":0,"on":true}}

    Das zu deinem Shelly passende Topic kannst du ableiten, indem du dir dessen MAC-Adresse kopierst und statt der Beispiel MAC-Adresse einbaust. Das für dich geeignete Topic sollte somit wie folgt lauten: "shellyplusplugs-<MAC-Adresse>/rpc"

    Nun zur Payload.

    Die Komponenten id und src dienen ausschließlich der Peer to Peer Kommunikation per in der Firmware verankerten MQTT Kommunikation. Damit kannst du experimentieren.

    Beide erscheinen in der Antwort-Payload, womit selektiert werden kann. In der Antwort erscheint aber src unter dst (destination), weil der Shelly die Antwort an die Quelle des Auftrags zurücksenden will. Dafür verwendet die Firmware den empfangenen src Wert (in der Antwort als dst Wert) im Topic: <src Wert>/rpc. Selbstverständlich kann ein anderer Subscriber eine solche Nachricht trotzdem empfangen. In der Shelly-Antwort ist der src Wert der eindeutige Name des Shelly mit dessen MAC-Adresse und das Topic enthält den Namen der auslösenden Quelle.

    Auf diese Weise sind die Quelle der Nachricht an den Shelly und die Quelle der Antwort bekannt. Damit lässt sich eine Peer to Peer Kommunikation nachbilden, ähnlich einer HTTP Request mit einer darauf folgenden HTTP Response. Vermutlich ist die HTTP Kommunikation das "Vorbild" für diese Art der MQTT Kommunikation.

    Die Komponenten method und params sollten eindeutig und leicht zu verstehen sein. Ich erläutere trotzdem für den Fall, dass du mit dem JSON Format nicht sehr vertraut sein solltest.

    Der method Wert muss ein Methodenname sein, welcher dem Shelly zur Verfügung steht, hier "Switch.Set". Diese Methode setzt einen Ausgang auf einen Zustand, welcher per params Wert definiert ist.

    Der params Wert ist ein kleines Objekt mit den Komponenten id und on. {"id":0, "on":true} definiert, dass der Ausgang 0 eingeschaltet werden soll.

    Alle Methoden, die in einem Shelly der Generation 2+ zur Verfügung stehen, kannst du abfragen mit 'http://<IP Adresse>/rpc/shelly.listmethods' .

    Die Methodennamen sind case insensitiv, d.h. Groß-/Kleinschreibung spielt keine Rolle.

    Wichtig: Sowohl die Struktur des params Objekts als auch dessen Komponentennamen hängen von der genutzten Methode ab.

    Mit diesen Informationen solltest du nun in der Lage sein, dich eigenständig durchzuärgern. ;)

    Ich kann dich gerne bei Gelegenheit ein wenig unterstützen, falls du bei einem konkreten Vorhaben nicht weiterkommen solltest.

    ShellyName/command/switch:0

    Dies nehme ich zum Anlass, kurz konkret darauf einzugehen.

    Topic: shellyplusplugs-<MAC-Adresse>/rpc

    Payload: {"id":<von dir gewählt>, "src":<Name für deine Quelle>,"method":"Switch.Set", "params":{"id":0, "on":true}} zum einschalten des Ausgangs 0 - die Component Id muss auch dann angegeben werden, wenn es nur eine solche Component gibt. Auf Grund dieser MQTT Nachricht an den Shelly, wird der Shelly

    1. seinen Ausgang einschalten
    2. eine MQTT Antwort senden mit dem Topic <Name für deine Quelle>/rpc

    Somit solltest du einen MQTT Subscriber mit diesem Topic nutzen können, um die Antwort des Shelly zu analysieren, bspw. im MQTT Explorer. Ich nutze dafür am liebsten Node-RED Flows.

    Noch ein wenig konkreter:

    Du lässt eine MQTT Nachricht senden mit dem Topic 'shellyplusplugs-xxxxxxxxxxxx/rpc' und der Payload '{"id":"schalte_ein","src":"smartcenter","method":"Switch.Set","params":{"id":0,"on":true}}'
    Dann antwortet der Shelly mit dem Topic 'smartcenter/rpc' und der Payload: '{"id":"schalte_ein","src":"shellyplusplugs-xxxxxxxxxxxx","dst":"smartcenter","result":{"was_on":false}}', wenn der Ausgang vorher ausgeschaltet war. War dieser bereits eingeschaltet, lautet der letzte Teil "result":{"was_on":true}.

    Ich bevorzuge selbst gewählte Topics, will an dieser Stelle aber nicht noch mehr notieren. Da ich nicht der ersten Shelly Generation nachtrauere, weiß ich derzeit nicht, ob hier deren Topics und Payloads nutzbar sind. Ich empfehle die Verwendung einer solchen, nur teilweise vorhandenen Rückwärtskompatibilität eindeutig nicht.

    An Cloud-/Szenen-Benutzer (insbesondere für Regelungen): Was erwartest du, wenn Internet oder Cloud sabotiert werden? Nicht nur dafür meine kleine Skripteinführung  8)

    Die einzig existierende Konstante ist der Wandel. Oft liegt die größte Schwierigkeit darin, das Anliegen des Klienten zu verstehen.

    Edited 17 times, last by eiche (March 28, 2024 at 9:18 PM).

  • This threads contains 3 more posts that have been hidden for guests, please register yourself or log-in to continue reading.