Externe Integration - Shelly

Hallo zusammen :waving_hand:

Nach viel Zeit, die ich mit Shelly-Payloads verbracht habe, stelle ich euch eine externe Shelly-Integration für Gladys in Version 1.0.0 vor.

:package: Repository: GitHub - Terdious/gladys-shelly · GitHub
:open_book: Dokumentation: Französisch · Englisch


In zwei Worten

Relais, Steckdosen und Energiemesser von Shelly, zuerst lokal, ohne Konto und ohne Cloud. Eine typische Installation erfordert ein vollständig leeres Konfigurationsformular: Sie installieren, starten einen Scan und fügen Ihre Geräte hinzu.


Steuern Sie Ihre Shelly bereits über eine Brücke?

Pierre-Gilles hat gerade seine Position zu diesem Thema veröffentlicht — Erfahrungsbericht: Warum ich nun externe Integrationen empfehle — und ich teile sie voll und ganz.

Wenn Ihre Shelly heute über eine Zwischenschicht laufen, können Sie sie hierher umstellen. Was Sie konkret gewinnen: Sie müssen nichts mehr zwischen Gladys und Ihren Geräten warten, und vor allem 100 % von dem, was die Hardware kann, ohne einen Standard zu durchlaufen, der es zuerst ausdrücken muss. Ein Pro 3EM kommt mit seinen 24 Funktionen — die drei Phasen getrennt, Wirk- und Scheinleistung, Spannung, Stromstärke, Neutralstrom und die acht Energiezähler für verbrauchte und eingespeiste Energie.

Einziger Hinweis: Entfernen Sie sie vor der alten Brücke, bevor Sie sie hier hinzufügen, sonst sehen Sie jedes Shelly doppelt.


Was sie kann

Lokal und in Echtzeit. Die Integration spricht das RPC Gen2+-Protokoll direkt mit Ihren Geräten, über eine WebSocket, die das Gerät selbst versorgt: Ein Relais, das am Wandschalter umgeschaltet wird, meldet sich in etwa einer Sekunde zurück, nicht bei der nächsten Abfrage.

Alle Generationen. Gen2 und neuer (Plus, Pro, Mini, Gen3, Gen4) und Gen1 (Shelly 1, 1PM, 2.5, Plug S, EM, 3EM). Die Gen1 sprechen eine völlig unterschiedliche API — REST statt JSON-RPC, Basic statt Digest — aber sie sind auf dasselbe Modell normalisiert: Ein 3EM Gen1 bietet genau die gleichen 24 Funktionen wie ein Pro 3EM Gen2.

Drei Transportwege, vom besten bis zur letzten Möglichkeit: lokal → MQTT → Cloud. Jeder hat seinen Zweck:

  • Lokal ist der nominale Weg;
  • MQTT (optional) ist die zuverlässigste Methode, um eine große Installation zu finden. Das mDNS wird in kurzen Multicast-Bursts angekündigt, die leicht zu verpassen sind: Bei mir kam dieselbe Anlage mal mit 19, mal mit 27 Geräten zurück, wobei einige systematisch fehlten. Ein Shelly, das auf Ihren Broker veröffentlicht, kündigt sich ständig an — es wird entdeckt, meldet sich in Echtzeit und bleibt steuerbar, auch wenn es lokal nicht erreichbar ist;
  • Shelly Cloud (optional) übernimmt, wenn ein Gerät weder lokal noch über MQTT erreichbar ist.

Gladys zeigt den tatsächlich verwendeten Transport, Gerät für Gerät, mit dem abgestuften Badge und dem Grund, wenn es nicht der nominale Weg ist.

Das Gerätemodell wird abgeleitet, nicht hart codiert. Die Funktionen stammen von den Komponenten, die das Gerät tatsächlich in Shelly.GetStatus angibt, nie aus einer Modelltabelle. Ein Pro 1 erhält ein Ein-/Ausschalten, ein Pro 1PM erhält zusätzlich die Messtechnik — und ein Shelly, das nach diesem Code herauskommt, funktioniert trotzdem, solange es den dokumentierten Wortschatz spricht.

Abgedeckte Komponenten: switch, em, emdata, em1, em1data, pm1, temperature, humidity, devicepower.


Echtzeit und warum sie einstellbar ist

Gladys akzeptiert 300 Zustände pro Minute pro Integration. Ein einzelnes Pro 3EM sendet etwa eine Aktualisierung pro Sekunde auf ~25 Messungen: Alles so zu übertragen würde ~900 Zustände/Minute machen, dreimal das Limit.

Die Werte werden daher auf zwei Kanäle aufgeteilt:

  • ein Echtzeitkanal (5 s standardmäßig, einstellbar von 1 s bis 30 s), der alle Momentanleistungen — insgesamt, pro Phase, pro Relais — und alle Ein-/Aus-Zustände trägt;
  • der Rest (Spannungen, Ströme, Scheinleistungen, Energiezähler, Temperaturen) folgt dem Auffrischungsintervall, aber geliefert aus dem frischsten geschobenen Wert, ohne HTTP-Hin- und Rückweg.

Der Punkt, auf den ich Wert lege: Ihre Einstellung ist ein Mindestwert, keine Garantie. Die Kosten des Kanals hängen vom Park ab, nicht von der Einstellung — ein Wert, der sich nie ändert, kostet nichts. Die Integration misst also, was sie tatsächlich veröffentlicht und verlängert ihr eigenes Intervall, wenn der Park zu groß wird, und schreibt es in die Protokolle, um dann von selbst zurückzukehren. Ein Zustand, der von Gladys abgelehnt wird, wäre unsichtbar; ein verlangsamter Kanal nicht.

Und jede Minute sagt eine Zeile genau, wo Sie stehen:

Real-time lane: 178 state(s) published in the last minute (every 5s, from
5 WebSocket and 15 MQTT device(s)); 243/300 states/min of the Gladys budget used

Installation

In Gladys: Integrationen → Integration installieren → Shelly → Installieren, dann Entdeckung → Scannen.

Es gibt nichts auszufüllen für eine 100 % lokale Installation. Die Felder (zusätzliche Adressen, Gerätepasswort, MQTT-Broker, Cloud-Schlüssel) dienen nur, wenn Ihre Installation sie benötigt, und jedes wird direkt im Formular erklärt.

(Bild 4: die Konfigurationsseite, leeres Formular)

Erfordert Gladys ≥ 4.83.0. Wenn ein Gerät im Scan nicht gefunden wird, erklärt die Dokumentation, worauf zu achten ist — und MQTT zu konfigurieren ist fast immer die Antwort auf eine große Installation.


Getestet auf

Meine Installation: 19 Shelly, 10 x Pro 3EM, 1 x Pro 4PM, 2 x Pro 3, 1 x Plus 2PM, 2 x Plus Plug S und 3 x 3EM Gen1. Lokal, MQTT und beides gemischt.


Danke @pierre-gilles :folded_hands:

Dabei bin ich auf eine Grenze des Kerns gestoßen: publishDiscoveredDevices() erhielt einen PayloadTooLargeError bei mehr als einem Dutzend Geräten mit vielen Funktionen (ein Pro 3EM = 24 Funktionen ≈ 8,4 Ko). Pierre-Gilles hat das sehr schnell auf Kernseite korrigiert (PR #2732). Bis alle auf dem neuesten Stand sind, veröffentlicht die Integration den größten akzeptablen Teilmenge und protokolliert namentlich, was ausgeschlossen wurde, anstatt den Scan leise zu verlieren.


Die Zukunft

Noch nicht unterstützt, mangels Material zur Validierung: Rollläden (cover), variable Beleuchtung (light) und Eingänge (input). Der Code ist bereit, sie aufzunehmen, mir fehlen die Geräte: Wenn Sie welche haben und eine :dev-Bild testen möchten, sagen Sie es mir, ich bereite es Ihnen gerne vor — das ist der beste Weg, damit es schnell kommt.

Die Shelly BLU werden ebenfalls nicht unterstützt: Sie sprechen Bluetooth, und die Integration macht kein BLE.

Die Roadmap ist offen: Roadmap — Shelly external integration · Issue #1 · Terdious/gladys-shelly · GitHub

Fehler, Feedback, Payloads exotischer Geräte: Die Issues sind weit offen. Und wenn Sie testen, sagen Sie mir, wie es läuft — vor allem an Modellen, die ich nicht habe, und vor allem an Modellen, die ich nicht habe :slightly_smiling_face:

Bravo!! Super Integration

@McFlyPartages Du bist doch nicht schlecht in Shelly, oder? Das wird dir gefallen :slight_smile: