Shelly Farbring mit MQTT ändern

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.

{
    "leds": {
        "mode": "off",
        "colors": {
            "switch:0": {
                "on": {
                    "rgb": [
                        0,
                        100,
                        0
                    ],
                    "brightness": 100
                },
                "off": {
                    "rgb": [
                        100,
                        0,
                        0
                    ],
                    "brightness": 100
                }
            },
            "power": {
                "brightness": 100
            }
        },
        "night_mode": {
            "enable": false,
            "brightness": 100,
            "active_between": []
        }
    },
    "controls": {
        "switch:0": {
            "in_mode": "momentary"
        }
    }
}

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.

Hast du schon in der Dokumentation nachgesehen und damit experimentiert?

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.

Zitat von CLohn

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.