FHEM Forum

nachdem Homematic nun EOL ist - und teuer - und die IP version auch teuer und mächtig indirekt bin ich bei shelly und Tasmota vermeintlich fündig geworden. Ich versuche nun diese beiden in deren generischen Versionen über MQTT2 in die bestehende Installation einzubinden. Die bestehende Beschreibubg ist sehr mächtig - ich hatte jedoch einige Probleme (auch weil ich nur sehr selten weiter arbeite...) das ganze mit Hand und Fuss einzubauen - und habe es immer noch nicht. Ertstes wirkliches Objekt ist ein  Shelly 2 kanal schalter (eigentlich einfach).
Anforderungen der Implementierung sind (für mich auf der Hand liegend):
- einfache Handhabung der Installation (keine endlos langen Attribute!)
- performantes System - ich rechne leicht mit 30+ devices und 100+ entities in fhem.
- automatische Systemprüfung - sind alle devices erreichbar
- nahtlose Einbindung in das bestehende System - beinhaltet, dass alle Readingnamen denen üblichen konventionen entsprechen
- Kanal Entities - zumindest möglich. Ein System funktioniert nur so generisch

Dass mir die Attribute zu lang sind, somit schlecht überprüfbar und ausserdem die Webdarstellung torpedeiren  - nun ja - werde ich ändern.
Performance-wise: die CID muss der Schlüssel zur Prüfung und erstellung der Readings sein. Das ist aktuell ein suchen über sämtliche regexp - passt mit meinen Performance-regeln nicht zusammen.
Die Erstellung der ReadingsList regeln ist für meine Lesart komplex - da die Namen der einzelnen Elements nicht klar erklärt ist - ich habe es am Ende durch endlose Experimente geprüft.
Schlüssel zur Erstellung der Readings ist "json2nameValue". zum Ersten fehlt hier eine "ordentliche" Dokumentation (und wie immer - im Forum nachlesen ist für Anwendung, ersetzt nie eine Dokumentation). wie wann und wo die postitiv und negativ filter eingesetzt werden, welche Optionen von anderen abhängig sind,... am Besten den Code nachlesen. Wie die jsonmap aussehen muss - keine Beispiele.
json2nameValue nutzt als Trenner der hierarchiestufen "_". Das ist m.E. maxinal ungeschickt, da dies typisch auch in den Namen vorkommt. In den endgültigen Readigns will ich natürlich nur "temperatur" stehen haben - und nicht die dem device eigene MQTT Hierarchie. Leider kann ich die Stufen nachträglich nicht mehr identifizieren, also nach "_" splitten - zumindest nicht sauber.
Logisch (für mich) - ich will die gemeldeten Datenpunkte verarbeiten (zustand des Ausgangs), egal über welche Methode er eingeholt wurde. Ich muss die Stufen also auflösen können.
Anhand der Stufen muss ich erkennen können, welcher Kanal sich gemeldet hat.
Am Ende muss ich die Kanalangabe, den Readingnamen und den Value in FHEM-Momenklatur übersetzen. Also ein
...switch_1_...output true
in
<channel1>level on
sowie dupliziert - da fhem dies bspw bei dimmern auch als state und pct benötigt - sowie der korrekten entity zugewiesen.
==> es ist (für mich) nicht hinnehmbar, dass MQTT im Frontend (readings) sich von anderen unterscheidet
==> die einfachen Methoden, dies zu übersetzen, entites zuzuweisen und auch die Values anzupassen habe ich nicht gefunden.
==> eine performante Lösung für das auflösen der Events in Readings - ohne exzesives regexp gesuche - suche ich ebenfalls

wie geht ihr damit um? Bin ich allein und bin ich auf den Holzweg?
ggf. werde ich wieder einmal den Code frisieren müssen

Warum nicht im richtige Forumbereich "MQTT" diskutieren?

Als ich mit mqtt angefangen habe, war mein erster Schritt, mich von dem ganzen Attribut-Gedöns, das man versucht, per template aufzuzwingen, verabschiedet habe. Die devices habe ich so angelegt, wie ich es mir vorgestellt habe.

Wenn ich einmal ein device eines bestimmten Typs erstellt habe, verwende ich dieses als Vorlage, falls weitere Geräte des gleiche Typs dazukommen. Im devicetopic muss ich dann nur die eindeutige ID ändern, und schon läuft das neue device.

Die ClientID spielt bei mir überhaupt keine Rolle. Sie ist nirgends definiert.

Als mqtt Server verwende ich mosquitto (auf einer Lightsail Instanz bei Amazon) und nanomq (hier im lokalen Netzwerk in einem proxmox container).
Diese Trennung mache ich deshalb, weil ich alle JsonMOD und HTTPMOD devices, die externe Quellen abfragen, auf Amazon ausgelagert habe und die ermittelten Werte dann per mqtt übertragen werden.
Die ganzen lokalen Shellies etc. brauchen aber keine Internetverbindung. Diese arbeiten komplett über den lokalen nanomq server.

Ist ja alles nett, und wer MQTT liebt, soll es auch nutzen. Aber versuch doch einfach mal (und bei ca. 30 Devices geht das problemlos...) das generische Shelly-Modul.

LG

pah

Zitat von: Prof. Dr. Peter Henning am 26 Juli 2026, 13:14:12Ist ja alles nett, und wer MQTT liebt, soll es auch nutzen. Aber versuch doch einfach mal (und bei ca. 30 Devices geht das problemlos...) das generische Shelly-Modul.

es gibt weitere MQTT - wie ich schon sagte bspw Tasmote (generisch,also nocht sonos). Die (meine) Idee ist, nicht x unterschiedliche Protokolle zu prüfen, lernen, anpassen. Shelly ist nur ein Beispiel - ESP32 und derivate ist für generische Ansätze in sonderfällen maximal flexiben. Eine spezial-Shelly Lösung ist daher endlich - und einarbeiten müssste ich mich auch noch. Ich sprach von 30+ devices - wenn man einmal anfängt geht es hier erst los!

ZitatDie ClientID spielt bei mir überhaupt keine Rolle. Sie ist nirgends definiert.

die CID wird in MQTT quasi immer einbezogen - und steht in der ReadingList an erster Stelle, vor dem ":". Ausserdem erscheint sie im define - oder was soll da rein?
Diesen Teil sehe ich einmal so (korrigieren mich)
define devicename CID
attr devicename readinglist CID:<topic>:<value> <action>
eigentlich hätte ich mir genau so die Definition des Attributs vorgestellt. Allerdings ist die CID in der Definition nicht vorgeschrieben. Daher werden bei jeder FHEM entity auch alle CIDs zugelassen.
Die CID ist prädestiniert um als Adresse zu fungieren (sagt ja der Name schon).
Wenn ich keine sinnvolle Alternative finde werde ich es genau so - und stringent - implementieren:

• im Define steht die CID
• Für Kanäle einer CID überlege ich noch. Der 2-fach switch hat eigentlich 4 Kanäle, frei programmierbar: 2 mal out und 2 mal in
• Readings werden auf die CID gefiltert - die wird in der message immer geliefert - bietet sich nicht nur an, das ist sicher die Idee von MQTT
• Readings der Kanäle brauchen einen diskriminator - definier ich mir noch
• Auswertung der Readings (readinglist-pendant) wird über die Adresse/ID (bei MQTT also CID) der/den entities zugewiesen
• Templates muss es auch geben hier bietet es sich an, wie bei CUL_HM (und sicher auch anderen) ein "model" zu definieren (Attribut) worüber das template ausgewählt wird
• da es wie immer keine weiteren interessenten gibt ist es nicht (wie bei CUL_HM) notwendig, user-templates zuzulassen. Wäre aber kein Problem, ist schon erprobt.
• ich werde nicht umhin kommen, eine subroutine zu schreiben, welche die Auswertung durchführt
• Giganto-Attribute mit unendlikch code sind keine Option - nicht übersichtlich, nicht wartbar, nicht managebar.

Noch einmal, es ins rechte Licht zu rücken -  vielen Dank für MQTT2 und auch json2nameval. Ist prima - aber ist für meine Ansprüche nicht ausreichend.
Eine Lösung mit auslagerungen - auch nach Amazon - lehne ich (bis jetzt) strikt ab.