ring-mqtt (auf FHEM mit Broker "MQTT2_SERVER")

[Sascha_F]

Hallo zusammen,

kennt jemand von euch ring-mqtt von tsightler (https://github.com/tsightler/ring-mqtt)?

Super simpel zum laufen zu bekommen, allerdings habe ich ein Problem - und ich weiß nicht, woran es liegt (ring-mqtt / mqttjs / FHEM / MQTT2_SERVER / ...)



Start EDIT:

Gerade eben erst den Hinweis aufs Wiki gesehen:

• tagesaktuelles FHEM
• MQTT2_SERVER
• MQTT2_DEVICE (autocreate)

Internals:
   FUUID      5c508649-f33f-3ff8-b3f3-8dbc7a320090f51f
   FVERSION   98_autocreate.pm:0.216590/2020-04-13
   NAME       autocreate
   NOTIFYDEV  global
   NR         14
   NTFY_ORDER 50-autocreate
   STATE      active
   TYPE       autocreate
Attributes:
   DbLogExclude .*
   filelog    ./log/%NAME-%Y.log
   room       CUL

End EDIT (hoffe, habe jetzt alles relevante mit aufgenommen)



Jedes Mal, wenn ich den rint-mqtt-Service stoppe+starte (oder natürlich einfach restarte), bekomme ich ein neues Topic. Als Beispiel (es ändert sich ausschließlich der rote Teil):

mqttjs_082bc927:homeassistant/...
mqttjs_082bc927:ring/...

mqttjs_b0e8b7fc:homeassistant/...
mqttjs_b0e8b7fc:ring/...

mqttjs_d6da5183:homeassistant/...
mqttjs_d6da5183:ring/...


tsightler hat mir super schnell auf mein Git-Issue geantwortet:

I'm afraid this question should be directed to the FHEM community and is not really related to anything here. The information you are highlighting is not something that is coming from the ring-mqtt script, the ring-mqtt script creates topics starting with homeassistant/ and ring/ while the mqttjs_<random_number> is some type of ID generated by FHEM. You will notice that ring-mqtt generates 100% consistent topics each time using location/device IDs.

Just taking a quick glance at the FHEM docs (I had never even heard of it) it appears that is has some ability to create regex rules to ignore topics or map the id to specific topic levels. Also, I double you need to care about the topics that start with homeassistant/ at all as those are just used to publish discovery messages to home assistant. Unless FHEM supports home assistant style MQTT discovery these would be totally useless. The actual devices are all published in the topic starting with ring/.

Regardless, the issue you are posting about is specific to FHEM and nothing to do with ring-mqtt and I'm not going to be able to help you with that.

Er geht dabei von einem "FHEM-Problem" aus - ich selber hatte bisher nur Shelly, Raspberry Pi, ESP8266 und ESP32 per MQTT angebunden und nie solche Probleme gehabt. Er war sogar so lieb und hat sich kurz die FHEM-Ref angesehen und mich auf die Möglichkeit hingewiesen, ggf. REGEX-Regeln definieren zu können, um Topics zu ignorieren oder die ID zu spezifischen Topic-Leveln zuzuordnen (falls ich das halbwegs korrekt übersetzt habe) - allerdings bin ich auf dem Gebiet leider auch (noch) komplett lost 

Ich hoffe ihr versteht mein Problem - und natürlich auch, dass mir jemand helfen kann    -->  Denn mit jedem Service-Start ein neues Device (und Filelog, welches ich dann löschen muss...) bekomme ich nix vernünftiges aufgebaut...

Vielen Dank im Voraus und viele Grüße
Sascha

[Otto123]

Hallo Sascha,
kommt mir bekannt vor.
Schau Dir mal die Lösung sonos2mqtt im Wiki an. https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Sonos2Mqtt
Du brauchst sicher auch ein Bridge Device. Wenn Du das definiert hast entsteht Dein Ring Device und bleibt
Hier im Thread wird genau diese Problematik am Anfang besprochen https://forum.fhem.de/index.php/topic,111711.0.html

Gruß Otto

[Sascha_F]

Hi Otto,

oha, Danke für Deine schnelle Antwort! (Da war ich gerade noch am editieren  )

Danke für den Hinweis - da schaue ich natürlich gern und sofort rein! 

Viele Grüße
Sascha

[Otto123]

Im meinem Wiki Artikel ist natürlich das Meiste schon im Template verhackstückt. Aber im Thread am Anfang wird eigentlich genau dieses Thema abgearbeitet. Ich hoffe damit kommst Du klar. Sonst lohnt es sich ja fast, dazu mal ein allgemeines HowTo aufzusetzen.

Aber am Anfang vom Wiki Artikel ist das Thema auch gut anhand von zigbee aufgearbeitet.

[Beta-User]

Das mit der random CID steht afaik bei den "typischen Problemen" in den Praxisbeispielen (das darf auch gerne woanders hin).

Ein Howto fände ich gut (wenn es jemand anderes macht), ich würde aber vorschlagen, eines für "Anfänger" zu machen (am Beispiel eines Shelly-pm erläutern, wie die Attribute (allgemeine Readingfn und spezielle für MQTT2_DEVICE) aufeinander aufbauen, und dann ggf. den Bereich für "Fortgeschrittene", wo sowas wie bridgeRegexp erläutert ist.

Da könnte man dann am Ende mal zusammentragen, was es an "speziellen Lösungen" gibt - also alles, wo dann etwas (Auswertung, Vorverarbeitung usw.) mit der payload geschieht... (Da steige ich dann gerne mit ein, vielleicht fällt dann auch noch jemand was nettes zu dem ein, was es schon so gibt .)

[rudolfkoenig]

Zum Hintergrund: mit MQTT2_SERVER verwendet FHEM das vom Client gesendete ID dazu, um unterschiedliche Topics einem Geraet zuzuordnen. Wenn man (wie vmtl. alle anderen Loesungen) keinen integriertern MQTT Server zur Verfuegung hat, dann hat man keinen Zugriff auf das clientId, und man muss die unterschiedlichen Topics entweder manuell, oder mit Hilfskonstrukten ala homematic-topic einem Geraet zuordnen.

Aus mir nicht ganz nachvollziehbaren Grund generieren einige MQTT-Client-Bibliotheken bei jeder Verbindung eine neue clientId, was zu den o.g. Problemen fuehrt. Ob das jetzt ein "FHEM-Problem" oder "client-Bibliothek-Problem" ist, ist Ansichtssache, meiner Ansicht nach gehoert das im Client gefixt, wenigstens optional.

Es gibt mehrere Moeglichkeiten in FHEM das Problem zu loesen, z.Bsp. bei readingsList das automatisch dazugenerierte clientId manuell entfernen, oder mit einem Attribut in MQTT2_SERVER die ID festsetzen.

[Otto123]

Das mit der random CID steht afaik bei den "typischen Problemen" in den Praxisbeispielen (das darf auch gerne woanders hin).

Du meinst den Abschnitt? https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#bridgeRegexp
Den könnte man zumindest zur Erklärung immer mal verlinken.

Was ich über die typische mqtt Broker Welt so lese, spielt da CID überhaupt keine Rolle. Alle sind froh wenn sie sie nicht wissen oder brauchen. Der Broker ist der zentrale Punkt - ringsherum wird geplappert und gelauscht. Die Topics sind die, die für die "draussen" relevant sind. Die CID ist nur für den Broker wichtig damit der nicht durcheinander kommt. Da gibt es auch kein autocreate für automatische Zuhörer. Nein stimmt wahrscheinlich nicht ganz: Es wird von einigen ein spezieller Topic erzeugt (z.B. homeassistant) aus dem macht eine Applikation irgendein spezielles Gerät. Alles andere wird automatisch ignoriert.

Für MQTT2_SERVER gibt es aus meiner Sicht zwei Vorgehensweisen:

• Man legt das Gerät, dass man will, manuell an. Mit entsprechenden Topics in readingList und setList
• Man nimmt das per autocreate erzeugte Gerät und verändert es so, dass in Zukunft kein neues Gerät erzeugt wird. Hat Rudi schon gesagt

MQTT2_SERVER macht nämlich nur so lange neue Geräte wie kein MQTT2_DEVICE zuhört. Für 2. gibt es noch die schöne Sache der Templates.
Für ring-mqtt gibt es da jetzt noch keins. Könnte man als Ergebnis von dem Thread erzeugen. Ring Produkte sind ja auch in FHEM oft im Einsatz.

Gruß Otto

[Beta-User]

Gemeint war eigentlich https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#St.C3.A4ndig_neue_Devices.3F

Das mit dem clientId-Attribut am SERVER war mir bisher auch entgangen, muß ich da aaO in den Praxisbeispielen mal noch einarbeiten; ich finde das aber eher eine nicht ganz so empfehlenswerte Variante, sowas macht eigentlich dann auch wieder nur Sinn iVm. einem General-bridgeRegexp-Gerät, das man dann bei Bedarf erweitert. Das erfordert aber genau dasselbe Verständnis der Gesamtzusammenhänge wie das Löschen der CID aus den readingList-Attributen...

[Otto123]

@Beta-User Vielleicht sollte man den Abschnitt (Mein Link ff. also auch Deiner) in einen eigenen Artikel MQTT2_SERVER auslagern? Den gibt es noch nicht dazu die Ergebnisse aus den Beiträgen von Rudi. Damit man das mal zusammen hat

Noch zum Thema von Sascha:
am Ende entsteht wahrscheinlich hier auch eine Dreierkombination:
MQTT2_SERVER
MQTT2_DEVICE als Bridge
MQTT2_DEVICEs als Ring Geräte

Die Bridge muss man konfigurieren damit die Ring Geräte erzeugt werden. Am Anfang und bei nur einem Ring Gerät ist nicht unbedingt eine Bridge nötig. Besser ist es sicher sie von Anfang an zu haben.

[Beta-User]

Muß ich mal drüber nachdenken. bridgeRegexp und das Verhalten von autocreate sind mMn. aber eigentlich Themen, die zu M2_DEVICE gehören und nicht zu M2_SERVER (M2_CLIENT verhält "sich" bei eingeschaltetem autocreate eigentlich auch nicht substantiell anders als M2_SERVER, man muß da eben nur selbst dafür sorgen, dass man eine "gute CID" zur Orientierung hat=vernünftige bridgeRegex-Ausdrücke).

Einen Artikel zu M2_SERVER hatte ich bisher v.a. deswegen nicht angelegt, weil ich keinen besonderen Bedarf dafür gesehen hatte, aber zwischenzeitlich gibt es gibt es wohl schon ein paar Kleinigkeiten, die man da reinpacken könnte (und den ansonsten als Verweisungsartikel gestalten).

Es gibt übrigens auch einen Thread zur Artikelstruktur@MQTT, vielleicht würde es Sinn machen, den wieder zu reaktivieren und dann auch die Frage aufzugreifen, was wie in Praxisbeispiele bleiben soll und was nicht (Das Milight-Thema könnte man z.B. auch noch ausgliedern, und Tasmota wäre dem Gefühl nach einen "upgrade" wert).

EDIT: Was die Struktur bei dieser Ring-Geschichte angeht, dürfte übrigens das zutreffen, was Otto geschrieben hatte. Es wäre ggf. mal zielführend, das Ding eine Weile laufen zu lassen und dann mal eine komplette RAW-Definition hier zu zeigen, dann können wir besser unterstützen?

(In dem Sonos-Thread ist ziemlich viel "neben" den Hauptthemen erörtert; vielleicht besser mal den ems-esp-Thread suchen, das ist nach meiner Erinnerung hier etwas "prototyischer" und leichter nachzuvollziehen (allerdings auf englisch); sonst den zigbee2tasmota-Thread, wobei da die JSON-Struktur "speziell" ist).

[Sascha_F]

Hallo zusammen,

zuerst möchte ich mich noch einmal bei euch allen bedanken! 

Leider ist es aufgrund Arbeit und anderer Dinge im Haus bei mir bisher liegengeblieben (man muss sich ja auch Zeit dafür nehmen, damit es ordentlich werden kann...).

Sobald ich wieder etwas mehr Luft habe, werde ich mich wieder ins Vergnügen stürzen --> der nächste Urlaub ist jetzt nicht mehr sooo lange entfernt und die Reisepläne haben sich in nicht-Reisepläne geändert 

Danach gibt's natürlich ein Update!

Viele Grüße
Sascha

[Sascha_F]

Hallo zusammen,

sorry, für die lange Zeit bis zur Rückmeldung - leider ist es bei mir untergegangen

Zum Überbrücken hatte ich einen Weg über IFTTT eingerichtet und MQTT aus den Augen verloren --> naja, in der aktuellen Zeit klingelt es ja auch nicht so oft.....

Da ich meine gesamte Netzwerk-Infrastruktur aber gerade auf UniFi umgestellt habe, holt es mich wieder ein     UniFi-Protect ist über Homebridge angeschlossen und MQTT aktiviert. Dort wird mqttjs verwendet und Überraschung: 1x bis 2x am Tag wird ein neues MQTT2-DEVICE angelegt. Irgendwie Karma, glaube ich :-D

Viele Grüße
Sascha

[Beta-User]

Hallo zusammen,

sorry, für die lange Zeit bis zur Rückmeldung - leider ist es bei mir untergegangen

Zum Überbrücken hatte ich einen Weg über IFTTT eingerichtet und MQTT aus den Augen verloren --> naja, in der aktuellen Zeit klingelt es ja auch nicht so oft.....

Da ich meine gesamte Netzwerk-Infrastruktur aber gerade auf UniFi umgestellt habe, holt es mich wieder ein     UniFi-Protect ist über Homebridge angeschlossen und MQTT aktiviert. Dort wird mqttjs verwendet und Überraschung: 1x bis 2x am Tag wird ein neues MQTT2-DEVICE angelegt. Irgendwie Karma, glaube ich :-D

Viele Grüße
Sascha

Falls da eine Frage versteckt sein soll: https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#St.C3.A4ndig_neue_Devices.3F
(das Grundproblem scheint _auch_ zu sein, dass der PAHO-Dienst entsprechend oft neu gestartet wird. Warum das passiert, solltest du klären, klingt nach einem bug. Ist aber _kein_ FHEM-Thema...!)

[Sascha_F]

Hi! Wenn jemand eine Antwort parat hat, würde ich mich darüber natürlich nicht ärgern --> es sollte aber nur die längst überfällige Rückmeldung von mir sein. Das Problem selbst liegt nicht in FHEM, das ist mir klar - in FHEM kann ja nur verarbeitet werden, was vorne reinkommt.

Ich versuche mich gerade etwas hinsichtlich ClientID, 2. Broker-Instanz, etc. zu beschäftigen, um das für mich "in den Griff zu bekommen". Das hatte ich damals wohl entweder übersehen oder nicht richtig verstanden. Danke Dir aber natürlich trotzdem für den Link ins Wiki!

Viele Grüße ++ schönes WE
Sascha

[Otto123]

Einfach hier:

Code Auswählen Erweitern

// Initiate the connection to MQTT broker
function initMqtt() {
    const mqtt = mqttApi.connect({
        host:CONFIG.host,
        port:CONFIG.port,
        username: CONFIG.mqtt_user,
        password: CONFIG.mqtt_pass
    });
    return mqtt
}die Clientid dazu packen?
https://www.eclipse.org/paho/files/jsdoc/Paho.MQTT.Client.html