Rückmeldungen zu Gladys

Konfiguration
1

Hallo,

Aktuell verwende ich als „Smart-Home-System“ eine Kombination aus Diensten (zigbee2mqtt, deconz, node-red) + home-assistant (aber eher wenig).
Um mir einen Eindruck von Gladys zu verschaffen, habe ich eine Testinstanz in einem Container bereitgestellt: Der Installationsprozess war perfekt, die Oberfläche ist sauber und reaktiv.
Die Benutzeroberfläche ist modern und hebt sich von vielen anderen oft spartanischen Smart-Home-Lösungen ab.

Eine Einschränkung, die ich bei Gladys etwas bedauerlich finde, ist die MQTT-Integration. Dass man kein spezifisches Topic (auch nicht zusätzlich zu dem automatisch definierten) direkt auf Ebene des Geräts angeben kann, ist schade. Obwohl es möglich ist, den Empfang einer Nachricht über eine Szene zu verwalten, finde ich, dass dies die Logik „unübersichtlich“ macht, um eine Geräte-Logik beizubehalten.
Meiner Meinung nach würde die Möglichkeit:

  1. ein Topic auf Ebene des Geräts anzugeben,
  2. festzulegen, ob der Inhalt ein JSON oder „Plain Text“ ist,
  3. in den Funktionen das Sub-Topic des Wertes oder den Schlüssel im empfangenen JSON des Geräte-Topics zu spezifizieren,
    viele Szenarien, die node-red erfordern, abdecken.

Zusätzlich würde dies die Integration von Shelly-, Teleinfo- und EnOcean-Geräten in Gladys relativ einfach machen.

Meine zwei Cent

Guten Tag

2

Hallo @Alyafride! :blush:

Willkommen bei Gladys und vielen Dank für dein Feedback! :folded_hands:

Ich höre diesen Punkt sehr oft bei Gladys, aber ich verstehe nicht, wie das funktionieren könnte.

MQTT ist ein Kommunikationsprotokoll (wie HTTP), aber dieses Protokoll definiert kein Nachrichtenformat (jeder kann dort reinschreiben, was er will), es ist auch nicht speziell mit der Hausautomatisierung verbunden.

In Gladys haben wir unser eigenes Topic- und Nachrichtenformat definiert. Jede Marke, die MQTT verwendet, verwendet auch ihr eigenes Format (und das ist normal, wie bei HTTP-APIs, die nicht standardisiert werden sollen).

Also, stellen wir uns vor, wir bieten den Nutzern an, jedem MQTT-Gerät ein benutzerdefiniertes Topic hinzuzufügen.

Wie du sagst, müsste der Nutzer auch das Format der Payloads (Eingabe und Ausgabe) definieren, dann müsste der Nutzer das Format der Werte sowie die Umwandlungsfunktionen definieren.

Beispiel: In Gladys ist eine Lampe „An“ der Wert 1, bei Shelly ist es „true“.

Bei Farben ist es in Gladys ein ganzzahliges Format, bei einigen Herstellern ist es Hexadezimal, bei anderen RGB usw.

Also, alles, was ich gerade beschrieben habe, ist im Grunde Code :joy:

Um das Beispiel von Shelly zu nehmen, wenn man schon die Zuordnungstabelle in Shelly und Gladys erstellt, warum sollte man alle Nutzer zwingen, sie für jedes Gerät einzeln zu erstellen, wenn sie einmal im Gladys-Code erstellt werden könnte und dann für alle funktioniert? Das haben wir zum Beispiel bei Zigbee gemacht.

Oder habe ich etwas nicht verstanden?

Danke auf jeden Fall für dein Feedback!

Aber da ich diesen Punkt von Nutzern, die von HA kommen, relativ oft höre, muss ich etwas nicht verstehen, also bin ich für deine Hilfe dankbar :blush:

3

Zunächst denke ich nur an den Teil der Datenerfassung und -anzeige, um bestimmte Zustände anzuzeigen (wie viel ich verbrauche, eingeschaltetes Gerät usw.). Für die Befehlsausführung ist es tatsächlich eine andere Hausnummer, um die verschiedenen Datentypen zu verwalten. Persönlich mag ich es, die Daten der Sensoren (Luftqualität, Energie usw.) über MQTT hochzuladen. Für die Befehlsausführung ist es meistens Node-RED oder Home-Assistant.

Typischerweise im Fall von Shelly: Eine Person, die Gladys testen möchte und ein sauberes Dashboard haben möchte, obwohl es etwas mühsam ist, wie derzeit Funktionen unter einem MQTT-Gerät zu definieren, aber indem das Abonnementsthema angegeben wird und somit die Metriken direkt hochgeladen werden.

Um meinen Fall zu veranschaulichen, bei einem CO2-Sensor, der die Information über MQTT hochlädt, musste ich einen Node-RED-Flow erstellen, der nur das Thema des Sensors abonniert, dieses Thema durch das von Gladys erwartete ersetzt und die Nachricht erneut sendet. Das ist etwas schade.

4

Beispiel für ein Shelly EM, eine Person könnte einfach den MQTT-Broker in der Hardware konfigurieren, dieser würde eine Nachricht dieses Typs senden (Achtung nur Gen1, Gen2 in JSON-Form):

image
image203×377 4.47 KB

Ein MQTT-Gerät in Gladys erstellen und eine Funktion für die relevanten Metriken erstellen.

5

Ok, ich verstehe. Danach ist es ein einfacher Fall, wenn es sich nur um numerische Werte handelt (aber das ist vielleicht in den meisten Fällen so).

In deinem Screenshot, sind „power“ und „reactive_power“ JSON-Attribute?

6

Nicht fett ist die Topologie und normal die Wert:
shellies/shellyem-XXXXXXX/emeter/0/total_returned 855.2

Für die Generation 2 und 3 der Shelly-Geräte sind die Nachrichten jedoch in JSON-Format, ich könnte ein Beispiel kommunizieren, falls benötigt.

Ich bin überzeugt, dass dieser relativ einfache Fall einer der häufigsten ist. MQTT ist zwar nicht einfach zu handhaben, wenn es um den Befehlsdurchlauf geht, da es keine Statusrückmeldung gibt, aber für IoT und die Sensorwert-Rückmeldung finde ich es sehr relevant.

7

Okay, in diesem Fall würde ich gerne, dass du einen Feature-Request im Forum erstellst, um die Anfrage zu dokumentieren :slight_smile:

Schau vielleicht vorher, ob es nicht schon eine ähnliche Anfrage gibt

Und wenn du ein bisschen Entwickler bist, Gladys ist Open-Source und jeder Pull-Request ist willkommen :hugs:

8

Okay, ich werde eine Feature-Anfrage finden/verfassen.

Für die Entwicklung bin ich mit Python vertraut und bereits an vielen Projekten beteiligt.

9

hallo @Alyafride

deine Anfrage ähnelt ein wenig dieser Anfrage, wenn ich mich nicht irre und deine Aussagen richtig verstanden habe :wink:.

10

Tatsächlich bin ich auf diesen hier gestoßen, mit dem Unterschied, dass die Idee zunächst einfach darin bestand, das Topic zu definieren, ohne die Daten zu verändern. Grob gesagt, die gleiche Logik beibehalten, aber einfach die Möglichkeit bieten, das Topic zu spezifizieren, um die vom Hersteller vorgegebenen Topics zu nutzen.

Eine sinnvolle Lösung wäre es, meinere Meinung nach, das « Eltern »-Topic auf Ebene des Geräts zu definieren und zu spezifizieren, ob der Inhalt der Nachricht ein JSON oder flache Werte (in Untertopics) ist. Anschließend für jede « Funktionalität » des Geräts den Schlüssel des Wertes zu definieren, also das Untertopic, wenn es sich um flache Daten handelt, und den Schlüssel des Wörterbuchs, wenn es sich um JSON handelt.

11

@cce66 da es sich um dieselbe Anfrage handelt, habe ich deine Anfrage geschlossen, um die andere beizubehalten, die klarer ist / mehr Stimmen hat :slight_smile: