ShellyPlus Aktoren (2.Gen) mit MQTT und Node-Red

Shelly Aktoren mag ich sehr. In meinem Haus habe ich ca. 8 “Shelly 1” Schalter (erste Generation = Legacy) verbaut. Das tolle an den Shellies ist, dass man sie ohne Cloud betreiben kann und kein teures Hub dafür braucht, weil sie direkt ins WLAN zuhause eingebunden werden. Ferner kann ich sie mit MQTT ansteuern.

Die neue Generation der Shelly Aktoren hat leider einige Herausforderungen parat, auf die ich hier eingehen möchte.

Alte Shelly Legacy Welt

Bisher habe ich immer mit den sogenannten Legacy Geräten gearbeitet. Wenn man sie einmal ins WLAN integriert hat, ist die Einrichtung über den in den Shellies eingebauten Webserver intuitiv und einfach. Kurzum, Shelly Legacy Produkte können alles, was ich brauche. Im Device eingebautes Skripting, RPC, Key Value Storage und all das brauche ich nicht. Ich will lediglich über meine Node-Red Logik via MQTT einen Schalter bedienen. Insofern ist die neue Shelly Generation ein technologischer Overkill – aber preiswert.

Neue Shelly Plus Welt

Zur Fernsteuerung eines Luftentfeuchters brauche ich einen Steckdosenschalter. Gab es bei Shelly als “Shelly Plug S”. Inzwischen aber nicht mehr. Dafür aber einen “Shelly Plus Plug S“, also zweite Generation.

Anstatt eines ESP8266 Microcontrollers wird ein ESP32 verbaut. Der ist schneller, hat mehr Speicher und bietet somit auch mehr Platz für allerlei zusätzliche Spielereien. Zusätzlich wird auch noch Bluetooth angeboten.

Die mitgelieferte Dokumentation genügt gerade einmal den gesetzlichen Anforderungen. Den Rest muss man sich mehr oder weniger mühsam im Web zusammensuchen.

Integration ins WLAN

Das Teil wie üblich über die iPhone Shelly App zu integrieren, hat irgendwie nicht funktioniert. Als Workaround habe ich mein iPhone (Android oder PC geht natürlich auch) mit dem lokal aufgespannten WLAN des Shelly Plugs verbunden. Dann im Browser die IP Adresse des lokalen Shelly Webservers eingegeben: 192.168.33.1

Es erscheint eine nüchterne Konfigurationsseite und netterweise wird man auch gleich aufgefordert, die WLAN Credentials des Heimnnetzwerks einzugeben.

Beim Plug können sogar zwei verschiedene Netzwerkkonfigurationen eingegeben werden. Vielleicht wegen der Portabilität des Plugs? Keine Ahnung…

Nachdem die Credentials eingegeben und gespeichert wurden, sollte das Shelly Device neu gestartet werden. Hat alles geklappt, kann man  jetzt über das Home Network darauf zugreifen. Die zugewiesene Adresse kann über den Router abgefragt werden.

Shelly Konfiguration

Gegenüber der ziemlich intuitiv zu bedienenden Adminoberfläche der Legacy Geräte, ist die neue Oberfläche ein Rückschritt. Zwar kein Klickibunti dafür eher grau in dunkelgrau und schlecht zu lesen. Jede Menge Menüeinträge mit mehrdimensionaler Navigation – eher unübersichtlich.

Grau in grau, schwer zu lesen und trotz unterschiedlicher Funktionaliäten gleiche Menü-Begrifflichkeiten horizontal wie vertikal

Wichtig ist es, erst einmal einen Firmware Update zu machen. Über Settings auf der linken Seite und dann beim Punkt Firmware. War vorher eine sehr alte Firmware aufgespielt, wird danach das Menü leider noch unübersichtlicher.

Die wesentliche Navigation befindet sich vertikal  auf der linken Seite. Aus irgend welchen Gründen hat man bei Shelly bei der horizontalen Navigation des Home Menüs die gleichen Begriffe verwendet – Settings, Actions, Schedules – die aber ganz andere Funktionen auslösen – sehr verwirrend das.

Über Settings auf der linken Seite, kommen wir zu den Einstellungen. Ich habe folgende Einstellungen vorgenommen um ein möglichst simples Setup zu erhalten:

Network Settings
  • Access Point settings: alle Haken weg
  • Wi-Fi: Einstellungen so lassen. Nur ein WLAN konfiguriert, statische Adresse nur setzen, wenn der Router das nicht selbst festlegen kann, Roaming so lassen.
  • Bluetooth: Haken wegnehmen. Je weniger Zugangsmöglichkeiten, desto weniger Blödsinn machen andere damit.
Connectivity
  • Cloud:Haken wegnehmen
  • MQTT: Siehe Detaillierung unten
  • RPC over UDP: Alles leer lassen
  • Outbound websocket: disable – Haken weglassen
  • Range Extender: Haken weglassen
Device settings
  • Device name: Hier kann man einen menschenlesbaren Namen vergeben, der aber lediglich auf der Admin Oberfläche angezeigt wird.
  • Reboot device: Selbsterklärend
  • Factory reset device: Selbsterklärend
  • Location and time: Nach Belieben Zeitzone, Geolocation und SNTP Server eintragen oder alles so lassen.
  • Authentication: Wer unautorisierten Zugriff vermeiden möchte, kann hier ein Passwort vergeben
  • Firmware: Zumindest einmal ein Update machen. Es besteht auch die Möglichkeit eine Custom Firmware zu installieren (Tasmota o.ä.)
  • User Certificate: Für noch höhere Sicherheitsansprüche kann ein SSL Zertifikat hochgeladen werden.
  • Eco Mode: Wenn alles funktioniert kann der sowieso schon niedrige Stromverbrauch von <1W noch weiter reduziert werden.
  • Debug: Nichts markieren

Detaillierung MQTT

Hier sind etwas mehr Daten einzugeben als bei der Legacy Version:

  • Enable MQTT Network: Ja – logisch!
  • Connection Type: No SSL – Es sei denn ihr habt ein Zertifikat installiert.
  • MQTT Prefix: Sehr schön: Hier können wir ein beliebiges, eindeutiges MQTT Topic  Prefix vorgeben. Bei Legacy fing das Topic immer mit Shellies an. Hier also etwas flexibler; zum Beispiel Keller/Hobbyraum/Entfeuchter
  • Enable MQTT Control: Haken setzen
  • Enable RPC over MQTT: kein Haken – ich fand die Erklärungen zu RPC (Remote Procedure Call) äußerst verwirrend und ich weiß immer noch nicht wofür das gut sein soll
  • RPC status notification: kein Haken
  • Generic status update over MQTT: Haken setzen. Das ist der Rückkanal, der die Ausführung eines Kommandos bestätigt.
  • Server: Hier die IP oder den Netzwerknamen des MQTTbrokers incl. der Portnummer (meist 1883) eintragen
  • Client ID: so lassen
  • MQTTbroker Username und Passwort eintragen

Dann speichern und fertig. Der Schaltaktor ist jetzt so konfiguriert, dass wir ohne größere Umstände mit Node-Red über MQTT darauf zugreifen können. Weitere Einstellungen – vor allem im Menü Home-Settings – selbst ausprobieren.

Da ich kein Informatiker bin und auch keine Installationen im industriellen Maßstab vorhabe, verschiebe ich den Know How Aufbau bzgl. der ganzen neuen Funktionen auf später. Ich will doch nur ein Gerät mit MQTT ein- und ausschalten können.

Ansteuerung mit Node-Red

Die wesentliche Information zu den MQTT Steuer- und Abfrage-Topics befindet sich gut versteckt unter jeder Menge schwer verdaulicher High-End Informatik Doku genau hier: MQTT Control. (Ich weiß wirklich nicht, wozu dieser RPC Kram eigentlich gut sein soll, der gefühlte 95% der Doku ausmacht…)

Sinngemäß steht in dem uns interessierenden Kapitel, dass der Shelly Schalter folgendes Topic abhört (subscribed): <topic_prefix>/command/switch:<ID>

Auf unser Schalter Beispiel bezogen also
Keller/Hobbyraum/Entfeuchter/command/switch:0  Beim Plug, der ja ein einkanaliges Gerät ist, ist die ID immer 0.

Wichtig: Ans Ende kommt kein Schrägstrich hin.

Andere Komponenten (z.B. Thermometer) haben eine andere Komponenbezeichnung als switch.

Als Kommandos verwenden wir on, off oder toggle, die als Payload an den MQTT out Node übergeben werden.

In Node Red sieht ein interaktiver Prozess so aus:

Verwendet werden die Standard MQTT Nodes. Die Inject Nodes und der Debug Node sind nur zum Testen erforderlich.

Der Rückkanal (Status) wird in unserem Beispiel wie folgt abgefragt:
Keller/Hobbyraum/Entfeuchter/status/switch:0

Warum auch immer und anders als bei den Legacy Shellies gibt der Schalter kein einfaches On oder Off zurück sondern einen kompletten Status als JSON String aus dem wir uns die Schalterstellung herausklamüsern müssen. Das geschieht mit einem JSON Node, der aus dem String ein JSON Objekt macht gefolgt von einem Function Node, der den Wert output [true/false] in on/off umwandelt.

Update: den JSON Node braucht man nicht mehr – dieMQTT Ausgabe Einstellung Auto-Erkennung (string oder buffer) ist veraltet (deprecated) und wird ab einer der kommenden Versionen von Node-Red nicht mehr funktionieren. Stattdessen entweder die Auto-Erkennung (parsed JSON-Objekt….) oder Ein analysiertes (parsed) JSON-Objekt auswählen. In beiden Fällen können wir den Output direkt mit einem Function Node auswerten. zum Beispiel so:
onoff=msg.payload.output

Der gesamte Flow (inkl. obigem Update) ist hier als JSON dargestellt:

 

 

 

6 Gedanken zu „ShellyPlus Aktoren (2.Gen) mit MQTT und Node-Red

  1. Normalerweise verwende ich Tasmota basierende Geräte und die Shelly Teile lassen es ja auch zu eine andere — also Tasmota — Firmware zu laden.
    Deiner Beschreibung “Firmware: Zumindest einmal ein Update machen. Es besteht auch die Möglichkeit eine Custom Firmware zu installieren (Tasmota o.ä.)” ist nicht zu entnehmen, ob das OTA geht, jedenfalls hat es bei mir nicht funktioniert. Geht OTA ev. nur für Shelly FW upgrade?
    Gibt es da einen besonderen Trick? OTA wäre besser als über Kabel, denn die neuen Shelly Plus (zB Dimmer2, RGBW2, I4) sind ja wirklich Mini, so auch die PINs für das flashen per Kabel.

    1. Hi Günter,
      welcome back! Bisher hatte ich keinen Anlass die original Shelly FW mit Tasmota o.ä. zu überschreiben. Die neuen Plus Geräte sind aber, was die Benutzerschicht angeht, echt grottig. Vielleicht mache ich das künftig auch mit Tasmota. Jedenfalls gibt es im “Settings” Menü auf der linken Seite den Punkt “Firmware”, der es dir erlaubt, eine Datei hochzuladen. Der Dateidialog verlangt dann eine .zip Datei. Geht auch per Drag&Drop.
      Probiere es mal aus und gib mir Rückmeldung. 😉
      VG
      Chris

      1. Aus deiner Beschreibung habe ich entnommen, dass du aus der Shelly Oberfläche das FW flashen entpfiehlst. Ist ja klar, wenn man die Shelly FW updaten will.
        Als “Tasmoter” hatte ich versucht mit dem Tasmotizer dem Shelly die Tasmota FW zu verpassen. Das funktioniert aber nicht und ist auch für den Shelly Plus I4 beschrieben (https://templates.blakadder.com/shelly_plus_i4.html):
        “WARNING!!! Devices with firmaware v1.10+ cannot be flashed OTA anymore”

        Allerdings könnte es sein, dass es von der Shelly Oberfläche aus geht. Kann das aber im Moment nicht testen .. in Ermangelung der notwendig HW.

        1. “Empfehlen” wäre zuviel gesagt, da ich das noch nie gemacht habe. Mit dem Tasmotizer würdest du wahrscheinlich den Shelly Bootloader überschreiben, den der Shelly braucht, um auf die Füße zu kommen…. Über die eingebaute “Load Firmware” Funktion müsste das funktionieren. Da würde ich aber auch erst einmal bei den Shelly Seiten nachsehen.
          Hier der entsprechende Shelly Screen.
          Und hier ist beschrieben wie man das macht: https://github.com/tasmota/mgos32-to-tasmota32
          VG
          Chris

  2. danke für diese einfach zu verstehende Erklärung und Lösung meines Problems mit einem Shelly4PM und Nodered. Bin mit den rpc auch nicht klar gekommen.

Schreibe einen Kommentar

Ich freue mich über Lob und Kritik.
Falls du Probleme mit der hier vorgestellten Anleitung hast und nicht weiter kommst:
Bitte das Problem oder die Fehlermeldung(en) möglichst genau beschreiben, auch an welcher Stelle (z.B. in welchem Node oder Befehl) und unter welchen Umständen der Fehler auftritt.
Gerne kannst du mir auch ein Mail schreiben. Die Adresse findest du im Impressum.
Ich gebe mir viel Mühe, meinen Lesern weiterzuhelfen. Je konkreter du bist, desto einfacher und schneller kann ich versuchen zu helfen.
Deine E-Mail-Adresse wird nicht veröffentlicht.
"
Erforderliche Felder sind mit * markiert