MQTT2-Anfänger: Ignorieren von publishs

[pula]

Hi!

Da das alte mqtt-modul (zumindest bei mir) nicht mehr mit neueren mosquitto-versionen tut, bleibt mir nichts anderes übrig, als mich mit mqtt2 auseinanderzusetzen.
Obwohl ich mich seit Jahren mit mqtt beschäftige und auch schon etliche (python) Skripte und Arduino/ESP Sketches dazu geschrieben habe, tue ich mich mit dem Konzept von mqtt2 in fhem ein wenig schwer. Ich denke, das ist einfach zu komplex, um es intuitiv auf Anhieb zu erfassen.
Trotzdem vielen Dank an die hier sehr aktiven Entwickler.

Eins vorweg: ich betreibe zwei fhem-Instanzen, die per MQTT_GENERIC_BRIDGE verbunden sind (weil einige Module leider immer wieder lags verursachen, was auf der Haupt-Instanz dem WAF nicht sehr förderlich ist). Außerdem feuern alle möglichen Devices (zb tasmota, selbstprogrammierte Arduinos und ESPs, diverse Skripte) Richtung mosquitto und lauschen auch darauf. Historisch gewachsen also. Die jeweiligen mqtt-Geräte sind in fhem mit mqtt derzeit als einzelne devices abgebildet.

Ich hab nun mal in beiden fhem-Instanzen einen mqtt2-client Richtung mosquitto angelegt und die generic_bridges damit verbunden. Das ging einfach

Jetzt versuche ich, mich an das Thema einzelne devices heranzutasten. Ich lasse hier mal die templates aussen vor, weil ich aus vielen Gründen bei den meisten devices, die hier abgedeckt wären verschiedene Dinge (wie zb die topic-Pfade) verändert habe.
Was ich gerne erreichen würde, ist mit mqtt2 quasi den gleichen Zustand zu erreichen wie zuvor mit mqtt (no na ned).

Im client habe ich autocreate auf complex stehen und es wird auch brav ein mqtt2_device names MQTT2_fheminfra angelegt (fheminfra ist die clientId vom client). So weit so gut. Ich konnte jetzt die ersten mqtt2_devices anlegen, die auch schon auf publishs reagieren.

So, nach dem langen Gelabere jetzt meine Frage:
Da auf der fhem-Instanz eine MQTT_GENERIC_BRIDGE läuft, die einige devices publishen, kommen diese natürlich wieder in dem mqtt2_device an.
Sieht dann in der readingList zb so aus:

Code Auswählen Erweitern

fheminfra:fhem2/verowz/volume:.* volume
fheminfra:fhem2/verowz/mute:.* mute
fheminfra:fhem2/verowz/version:.* version
fheminfra:fhem2/verowz/name:.* name

Wobei hier fhem2 das Zauberwort ist, weil das die topic-base von der generic bridge ist.
Gibt es eine Möglichkeit, derartige publishs in dem mqtt2_device MQTT2_fheminfra zu ignorieren? Wie?
Danke im voraus für die Geduld und cheers,
Pula

[Beta-User]

Also:

1. Setze autocreate auf simple! Nur so entsprechen die Readingnamen nach json2nameValue() denen, die expandJSON erzeugt... Du kannst bei den attrTemplates dann nachsehen, ob für bestimmte Devices eventuell doch die erweiterte json2nameValue()-Syntax Sinn machen könnte (ohne es jeweils anzuwenden), und es dann manuell nachpflegen.

2. Setze die entsprechenden ignoreRegexp-Ausdrücke beim IO (MQTT2_CLIENT).
Das ist noch recht neu und es gibt noch nicht so viele Beispiele, aber das ist eine "normale" regex, Bausteine wären in MQTT2_IO_ignoreRegexp_basic und dem nächsten zu finden.

3. Es ist m.E. zu empfehlen, dass du dich mit dem Thema bridgeRegexp auseinandersetzt. MAn. geht das am einfachsten auf Basis des templates MQTT2_CLIENT_general_bridge, Beschreibung dazu ist im Wiki zu CLIENT zu finden. In deiner bridge für fhem1 sähe da z.B. einer der Einträge dann so aus (unterstellt, du willst das Device dort überhaupt haben):

Code Auswählen Erweitern

fhem1[/]([^/]+)[/].*:.* "$1"\
4. Generell: Wirf die CID-Angaben jeweils aus der readingList, also in deinem (nicht erwünschten, habe ich schon verstanden, brauche aber ein Beispiel) Device:

Code Auswählen Erweitern

fhem2/verowz/volume:.* volume
fhem2/verowz/mute:.* mute
fhem2/verowz/version:.* version
fhem2/verowz/name:.* name

Allg.: Was findest du am "Konzept von MQTT2" schwierig? Dass man nicht (fast) alles von Hand machen _muß_? Oder dass es diese seltsamen Einheitsdevices mit komischen Readingnamen gibt, wenn man den CLIENT-Weg geht und dann "autocrate complex" verwendet?
Man muß halt einmal verstehen, was ignoreRegex und bridgeRegex machen, dann ist es m.E. deutlich flexibler (und v.a. iVm JSON leichtgewichtiger) als die seitherige MQTT-Implementierung.

[rudolfkoenig]

Man kann "attr MQTT2_DEVICE autocreate 0" setzen, dann werden hier keine neuen Readings angelegt, aber wenn MQTT2_CLIENT autocreate simple oder complex gesetzt hat, dann geht MQTT2_GENERIC_BRIDGE leer aus, weil MQTT2_DEVICE sich zustaendig fuehlt.

Fuer Fortgeschrittene: ich meine aus dem Code zu erkennen, dass wenn bridgeRegexp als clientId 0 oder "" zurueckliefert, MQTT2_GENERIC_BRIDGE benachrichtigt wird, auch mit gesetzten MQTT2_CLIENT autocreate.

[Beta-User]

@pula:
Um aus der Antwort von Rudi richtig Kapital schlagen zu können, solltest du etwas detaillierter schildern, wo welche Daten von bzw. über MQTT_GENERAL_BRIDGE gesendet und empfangen werden.

@Rudi:
Was bei MQTT_GENERAL_BRIDGE "unschön" ist, ist der Umstand, dass im Hintergrund immer auch 00_MQTT.pm geladen wird, was seinerseits (ich meine nur genau) ein cpan-Modul voraussetzt. Vielleicht gibt es einen Weg, das bei Verwendung von MQTT2-IO's zu umgehen? (Diese "lose" Verbindung von mehreren FHEM-Instanzen via MQTT ist nach meinem Eindruck ziemlich verbreitet, und wenn du jetzt schon aktiv Werbung  machst, auf MQTT2-IO's umzustellen, sollten wir möglichst diesen Zopf auch noch abschneiden...).

Das mit der "leeren" CID ist eine super Sache, ich hoffe, das klappt wie von dir aus dem Code abgelesen!

[rudolfkoenig]

Vielleicht gibt es einen Weg, das bei Verwendung von MQTT2-IO's zu umgehen?

Das geht sicher, der MAINTAINER muss es nur wollen bzw. fuer den Umbau Zeit haben

[Beta-User]

Das geht sicher, der MAINTAINER muss es nur wollen bzw. fuer den Umbau Zeit haben

Wenn ich nicht mit einiger Sicherheit davon ausgehen würde, dass der MAINTAINER sehr wenig Zeit hat, hätte ich das nicht in der Form an "den bekanntermaßen falschen" adressiert... Erfahrungsgemäß ist dort die Bereitschaft da, das möglichst zu allen IO-Varianten kompatibel zu haben, das dürfte also nicht das Problem sein, falls "jemand" einen Patch erstellen _wollte_. (Könnte man ggf. vorher erfragen, das wäre eher nicht das Problem; ich selbst traue mir das mit dem Umbau grade nicht zu).

[pula]

Erstmal vielen Dank für die EXTREM raschen Antworten.
Für mich als MQTT2-Laien natürlich verwirrend. Ich hatte nicht damit gerechnet, daß durch das autocreate die MQTT_generic_bridge beeinträchtigt wird. Habs aber getestet und in meiner config hat dann tatsächlich ein Test nicht funktioniert. Autocreate aus und tut wieder.

Um ein wenig detaillierter auf meine Situation einzugehen:
Die Idee hinter der zweiten fhem-Instanz (und damit dem Einsatz von MQTT_GENERIC_BRIDGE) ist die, daß es einige Module gibt (vor allem homeconnect), die fhem manchmal extrem blockieren. Die Situation ist nicht einfach, weil der Entwickler das natürlich auch (wie alle anderen) als Hobby betreibt und eine Bereinigung ist nicht in Sicht. Leider sind meine Kenntnisse von Homeconnect die eines reinen Anwenders.
Da ich aber schon die zweite fhem-Instanz am Laufen habe, hab ich auch noch (vorerst) ein kodi-device angelegt, das entsprechend mit einem Dummy auf dem "Haupt-fhem" kommuniziert. Ich wurde erst vor kurzem darauf gestossen, das per MQTT_GENERIC_BRIDGE zu machen, daher sind erst zwei devices hier aktiv (die, die am meisten "Schmerzen" bereiten).

Weil aus der Haupt-Instanz heraus aber die devices auch gesteuert werden sollen (zb Kanal in kodi wechseln oder Geschirrspüler einschalten), sollte die zweite fhem-Instanz auch in der Lage sein, mittels mqtt_generic_bridge publishs entgegenzunehmen.
Ich bin mir jetzt nicht sicher, welche Informationen du brauchst, daher hier die lists der zweiten fhem-Instanz (das ist die, wo die "echten" devices sind):

Code Auswählen Erweitern

define verowz KODI 192.168.1.180 tcp user password
attr verowz mqttBridgeDefaults base={"$base/$device"}
attr verowz mqttBridgePublish *:topic={"$base/$reading"}
attr verowz mqttBridgeSubscribe *:stopic={"fhem/$device/cmds/$reading"}
attr verowz stateFormat label - currentTitle - playStatus - time/totaltime
attr verowz updateInterval 60
attr verowz userReadings channels, art

(in globalDefaults habe ich hier base=fhem2)

und

define SN658X06TE HomeConnect hcconn SIEMENS-SN658X06TE-12A40E08D248
attr SN658X06TE alias Geschirrspüler
attr SN658X06TE icon scene_dishwasher
attr SN658X06TE mqttBridgeDefaults base={"$base/$device"}
attr SN658X06TE mqttBridgePublish *:topic={"$base/$reading"}
attr SN658X06TE mqttBridgeSubscribe *:topic={"fhem/Geschirrspueler/$reading"}
attr SN658X06TE verbose 5
attr SN658X06TE webCmd BSH.Common.Root.SelectedProgram:startProgram:stopProgram


Im "Haupt-fhem" sehen die dummies so aus:

Code Auswählen Erweitern


define verowz dummy
attr verowz icon Tv-icon
attr verowz mqttBridgeDefaults base={"fhem2/$device"}
attr verowz mqttBridgePublish msg|openchannelid|stop:topic={"fhem/$device/cmds/$reading"}
attr verowz mqttBridgeSubscribe *:topic={"$base/$reading"}
attr verowz room WZ
attr verowz stateFormat label - currentTitle - playStatus - time/totaltime
attr verowz userReadings channels, art, msg, openchannelid, stop

und

define SN658X06TE dummy
attr SN658X06TE alias Geschirrspüler
attr SN658X06TE icon scene_dishwasher
attr SN658X06TE mqttBridgeDefaults base={"fhem2/$device"}
attr SN658X06TE mqttBridgePublish *:topic={"fhem/Geschirrspueler/$reading"}
attr SN658X06TE mqttBridgeSubscribe *:topic={"$base/$reading"}
attr SN658X06TE room Kueche,MQTT
attr SN658X06TE setList BSH.Common.Setting.PowerState:BSH.Common.EnumType.PowerState.Off,BSH.Common.EnumType.PowerState.On BSH.Common.Root.SelectedProgram:Intensiv70,Auto2,Eco50,NightWash,Kurz60,Glas40,Quick45,MachineCare
attr SN658X06TE userReadings state, BSH.Common.Status.DoorState, BSH.Common.Status.OperationState, BSH.Common.Status.RemoteControlActive, BSH.Common.Status.RemoteControlStartAllowed,BSH.Common.Root.SelectedProgram,BSH.Common.Setting.PowerState
attr SN658X06TE webCmd BSH.Common.Root.SelectedProgram:startProgram:stopProgram
(wobei ich die setstates unterschlagen habe, weil meiner Meinung nach nicht relevant).

Schön wäre es aus meiner (NICHT-fhem-Entwickler) Sicht, wenn es eine Möglichkeit gäbe, dass MQTT2 hier alles von einer MQTT_GENERIC_BRIDGE unangetastet lässt - oder zumindest nicht blockiert. Noch schönerer (!) wäre es, wenn man die Dinge, die so eine Bridge betreffen (meinem Verständnis kann das pro fhem-Instanz eh nur eine sein?) beim autocreate ausgeblendet/ignoriert werden könnten.

Ich hoffe, ich konnte mich so halbwegs verständlich machen. Danke auf jeden Fall für den Hinweis, dass die Bridge hier "blockiert" wird - hätte sonst ein Problem mit der Frau bekommen, weil der Geschirrspüler sich nicht eingeschaltet hätte

Leider kann ich auch keinen Mischbetrieb mqtt/mqtt2 fahren - sobald ich mosquitto upgrade, tut mqtt nicht mehr. Eigentlich war ich mit der Einfachheit der mqtt-Lösung recht zufrieden. mqtt2 ist sicher bei weitem mächtiger, aber das wirkt sich hier leider sehr auf die Einarbeitungs-Kurve aus....

Danke nochmal und cheers,
Pula

[Beta-User]

Hmm, mal auf die Schnelle ein paar Anmerkungen:

- Das Zusammenspiel mit der MQTT_GENERIC_BRIDGE ist an sich nicht einfach, da sind wir vermutlich (fast) alle noch am lernen...
- Das mit dem Auslagern von potentiell blockierenden Modulen ist sicher eine gute Idee;
- Tendenziell würde ich im Haupt-FHEM auf MQTT_GENERIC_BRIDGE+Dummy verzichten und das rein über MQTT2_DEVICE abbilden. Wenn du autocreate abstellst, sollte aber alles funktionieren wie vorher auch, nur das IO ist dann eben getauscht, oder?
- Es kann in einer Installation durchaus mehrere MQTT_GENERIC_BRIDGE's geben, was aber (mAn.) nur dann Sinn macht, wenn man mit mehreren Servern (aka Brokern) arbeitet.

Was die Vorstellung angeht, dass man bei mehreren möglichen Client-Modulen jeweils "voneinander weiß", gab es dazu - soweit ich mich entsinne gerade in der Kombination von MQTT_GENERIC_BRIDGE und MQTT2_DEVICE - längere Diskussionen und Überlegungen, wie man das (überhaupt) hinbekommt; von daher scheint es mir so zu sein, dass wir da mit der Situation "as is" leben müssen und ggf. die Doku dazu entsprechend verbessern. Da ich selbst aber nur kurz an MQTT_GENERIC_BRIDGE rumgetestet habe und derzeit keinen Anwendungsfall habe, fühle ich mich dazu im Moment auch nicht berufen - falls du aber konkrete (einleuchtende) Vorschläge hast, übertrage ich das gerne ins Wiki...

[pula]

Allg.: Was findest du am "Konzept von MQTT2" schwierig? Dass man nicht (fast) alles von Hand machen _muß_? Oder dass es diese seltsamen Einheitsdevices mit komischen Readingnamen gibt, wenn man den CLIENT-Weg geht und dann "autocrate complex" verwendet?
Man muß halt einmal verstehen, was ignoreRegex und bridgeRegex machen, dann ist es m.E. deutlich flexibler (und v.a. iVm JSON leichtgewichtiger) als die seitherige MQTT-Implementierung.

Ich kann den Finger noch nicht auf das Konzept legen - will sagen, ich habe noch nicht so ganz verstanden, wie die Dinge hier genau zusammenhängen. Ich habe versucht, in Forum und Wiki viel zu lesen, aber so ganz verstehe ich das alles noch nicht.
Ich meine, beim alten mqtt hat man einmal die Verbindung zum Broker konfiguriert und dann einfach topics subscribed oder gepublisht.

Das mqtt2-Konzept ist für mich hier noch nicht ganz greifbar. Ich bin mir sicher, daß das viel mächtiger ist, aber ich verstehe es halt noch nicht.
Vielleicht habe ich an den falschen Stellen gelesen. Es gibt auch einen Thread für die Umstellung von mqtt auf mqtt2 - ich habe das Thema aber nicht von Anfang an verfolgt und in diesem Thread tauchen für mich mehr Fragezeichen auf als ich zuvor hatte.
Möglicherweise fehlt (mir) nur ein einfaches "Kochbuch". Nach dem Motto: Lege einen client an stelle autocreate auf simple, lege ein device an. Schau in dem device, was in der readingList auftaucht und bau daraus deine eigenen devices. (das ist zumindest für mich mit meinem momentanen Wissensstand der Leitfaden).
Möglicherweise hab ich hier aber eh immer noch was nicht verstanden.
Was das Ganze dann (für mich als mqtt2-Anfänger) noch schwieriger macht, sind die templates. Sie sind sicher mächtig. Aber bridge-templates, device-templates wth?? Bahnhof.... Schön, daß es das gibt. Aber ich bin noch ein wenig überfordert.
Wenn ich das Ganze hier verstanden habe, werde ich mal einen thread mit so einem Kochbuch starten. Vielleicht beteiligen sich ja auch andere dort und korrigieren/ergänzen mein Geschreibe.
Momentan muß ich das Thema mqtt2-devices eh auf Eis legen, so lange die bridge dadurch blockiert wird. Ohne autocreate wird es ein wenig mühsam, sich die readings zusammenzubasteln. Das ist sehr praktisch, dass die richtigen readings hier gleich angezeigt werden!!! Aber meine bridge ist produktiv, von daher für mich vorrangig....

Jedenfalls nochmal vielen Dank für die "neuen" Module und Eure Geduld bei der Beantwortung solcher einfachen Fragen....
Cheers,
Pula

[pula]

- Das Zusammenspiel mit der MQTT_GENERIC_BRIDGE ist an sich nicht einfach, da sind wir vermutlich (fast) alle noch am lernen...
- Tendenziell würde ich im Haupt-FHEM auf MQTT_GENERIC_BRIDGE+Dummy verzichten und das rein über MQTT2_DEVICE abbilden. Wenn du autocreate abstellst, sollte aber alles funktionieren wie vorher auch, nur das IO ist dann eben getauscht, oder?
- Es kann in einer Installation durchaus mehrere MQTT_GENERIC_BRIDGE's geben, was aber (mAn.) nur dann Sinn macht, wenn man mit mehreren Servern (aka Brokern) arbeitet.

Das Problem bei MQTT2_DEVICE und kodi ist hier mMn, daß das kodi-modul Unmengen von channels als Readings anlegt (bei mir über 1000) - da ist die Bridge schon sehr bequem, weil man sich als user nicht mehr drum kümmern muß, daß alles synchron ist. Das macht das Modul.
Stimmt, wenn man mehrere Broker verwendet, könnten auch mehrere Bridges gebraucht werden. Ich unterstelle aber mal, daß das ein sehr exotischer Fall wäre.
Nur so als Gedanke, ohne den Code zu kennen:
Wäre es schwierig, im MQTT2_CLIENT ein attribut (zb) ignoreAutocreate einzubauen? Wenn das gesetzt ist (befüllt zb mit der entsprechenden mqtt-base von der bridge, in meinem Fall also fhem2) würde alles, was unterhalb dieser base ist, von autocreate so behandelt, als wenn autocreate auf "no" wäre (hier funktioniert dann die bridge ja). Als reiner User würde mir das als relativ einfache Lösung erscheinen, damit sich die Dinger nicht in die Quere kommen?
Cheers,
Pula

[Beta-User]

Na ja, wenn man mal das Grundprinzip des Datenaustauschs verstanden hat, gibt es eigentlich keine wirklichen Unterschiede zwischen
MQTT2_DEVICE + MQTT2-IO und MQTT_DEVICE + (00_)MQTT(.pm) (IO).

Wenn man - wie empfohlen - mit MQTT2_SERVER in das Thema einsteigt, und dann noch "standardkonforme" Geräte wie Shelly's uä. hat, ist es (auch gerade wg. der attrTemplates) easy, das bestätigen jedenfalls viele neue User. MQTT2_SERVER kann anhand der CID der Gegenstelle schon erkennen, was wie zusammengehört, bei MQTT2_CLIENT muß man das eben weiter "von Hand" machen, oder eben verstehen, was bridgeRegexp bewirkt (nämlich das Sortieren anhand der Topic-Struktur).

Du hast halt das "Problem", dass du 1. mit einer "exotischen" Konstruktion einsteigen willst und die auch in Form von dummy+MQTT_GENERC_BRIDGE weiter behalten willst und 2. keine standardkonforme Geräte auf der Gegenseite (das "ausgelagerte FHEM") hast, sondern eine Art "selbstgestricktes Multi-Device". Da muß man sich so oder so selbst drum kümmern, das irgendwie dann wieder auseinanderzuklabüsern. Ist aber auch nicht schwieriger als das bisher war, nur heißen halt die Attribute anders und sind intern etwas anders gestrickt.

Das Problem bei MQTT2_DEVICE und kodi ist hier mMn, daß das kodi-modul hier Unmengen von channels als Readings anlegt (bei mir über 1000) - da ist die Bridge schon sehr bequem, weil man sich hier als user nicht mehr drum kümmern muß, daß hier alles synchron ist. Das macht das Modul.

Sendeseitig ist das klar, empfangsseitig wäre das mit einer passenden bridgeRegexp auch mit "nur" MQTT2_DEVICE zu lösen.

Stimmt, wenn man mehrere Broker verwendet, könnten auch mehrere Bridges gebraucht werden. Ich unterstelle aber mal, daß das ein sehr exotischer Fall wäre.

Weiß nicht. Ist vermutlich eher was für Power-User, aber einfach mal unterstellt, du willst Daten von deiner Wetterstation z.B. zu Wunderground publishen (?). Dann brauchst du dahin eben eine eigene Verbindung und die Wahl zwischen einem "notify-Direkt-publish" über das IO oder einer eigenen Bridge.
Oder du willst nur bestimmte Dinge über irgendein MQTT-basiertes Frontend visualisieren oder bedienen lassen. oder oder oder. Da ist man schnell...

Nur so als Gedanke, ohne den Code zu kennen:
Wäre es schwierig, im MQTT2_CLIENT ein attribut (zb) ignoreAutocreate [...]

Genau darauf läuft der Vorschlag von Rudi raus, via bridgeRegexp eine CID "0" oder "" zu erzeugen . Nur eben ohne spezielles weiteres Attribut... Wenn also weiter dummy+MQTT_GENERIC_BRIDGE die Lösung sein soll, wäre das z.B. so eine Zeile:

Code Auswählen Erweitern

fhem1[/]([^/]+)[/].*:.* ""\

[rudolfkoenig]

@Beta-User: soweit ich sehe, hat jemand schon ueber eine optionale MQTT Verwendung Gedanken gemacht, man muss "nur" MQTT::parseParams ersetzen (mit main::parseParams?). Ich kenne aber die Feinheiten der MQTT Parameter nicht ausreichend, und ich will das jetzt auch nicht aneignen.

@pula: du kannst MQTT2_CLIENT auch ohne autocreate betreiben, dann hast du keine Probleme mit MQTT_GENERIC_BRIDGE, und es ist genauso dumm/einfach wie MQTT.

Zum "MQTT2-Konzept":

- MQTT2* ist fuer Anfaenger gedacht, wo moeglichst viel "von selbst" laeuft. Best-Case: MQTT2_SERVER definieren, MQTT-Geraete werden samt Readings in FHEM automatisch angelegt, fuer die Befehle setzt man attrTemplate, fertig.

- gestartet wurde mit MQTT2_SERVER, der im Normalfall (Anbindung von MQTT2-Geraeten) viel besser fuer autocreate geeignet ist. MQTT2_CLIEnt kam nachher, damit die "eingefleischten" mosquitto Benutzer auch was vom autocreate und attrTempate haben. MQTT2_GENERIC_BRIDGE kam zum Schluss.

- man kann bei MQTT2 auf die ganze "Magie" (autocreate device und reading, autoparsing von JSON, attrTemplate, etc) verzichten, dann ist MQTT2 vergleichbar mit MQTT. Wenn man von MQTT kommt, sollte alles beim Alten bleiben: man definiert MQTT2_CLIENT und jedes MQTT2_DEVICE einzeln und komplett, mit setList und readingList.

Wäre es schwierig, im MQTT2_CLIENT ein attribut (zb) ignoreAutocreate einzubauen?

MQTT2_CLIENT untersucht keine Topics, das macht MQTT2_DEVICE, und da ist fuer die Verteilung bridgeRegexp zustaendig.
Wie ich es vorhin schrieb (was offensichtlich ueberlesen wurde), kann man da mit 0 oder "" was Vergleichbares erreichen.

[pula]

@rudolfkoenig:

Wie ich es vorhin schrieb (was offensichtlich ueberlesen wurde), kann man da mit 0 oder "" was Vergleichbares erreichen.

Gelesen hab ich das sehr wohl. Aber nicht verstanden

@Beta-User:

Genau darauf läuft der Vorschlag von Rudi raus, via bridgeRegexp eine CID "0" oder "" zu erzeugen . Nur eben ohne spezielles weiteres Attribut... Wenn also weiter dummy+MQTT_GENERIC_BRIDGE die Lösung sein soll, wäre das z.B. so eine Zeile fhem1[/]([^/]+)[/].*:.* ""\

Wäre das dann für dieses neue Feld gedacht?

Naja, für Anfänger, die auch nur "default"-Geräte verwenden kann das sicher sehr praktisch sein. Aber ich habe eben viele selbst gestrickte Dinge herumlaufen, da passt das dann nicht so ganz.
Ich bin aber eh kein fhem-Anfänger mehr (glaube ich) - und ein user (in diesem Fall ich) sollte auch bereit sein, sich in neue Themen einzuarbeiten, wenn ihr Euch schon die Mühe macht und so viele Dinge entwickelt und supportet!
Und auf mein "geliebtes" mosquitto verzichten möchte ich auch nicht mehr. Ich beginne langsam, dank Eurer geduldigen Erklärungen, so einiges zu verstehen. Auto-Parsen von JSON ist zb ein absolutes Killer-Feature. Spart viel Arbeit
Nochmal danke. Bin schon gespannt, wie das weitergeht.
Cheers,
Pula

[Beta-User]

@Rudi: Ich schau mir das mal an, die paar parseParams sollten sich bei entsprechendem IO (oder immer?) auch mit dem "normalen" erschlagen lassen. Verstehe ich das richtig, dass du die anderen imports/exports (send_publish send_subscribe send_unsubscribe client_attr client_subscribe_topic client_unsubscribe_topic topic_to_regexp) schon kurz auf Relevanz durchgesehen hattest?
(Interessant, dass da trotz Import noch der Package-Präfix drin ist. Eigentlich müßte es ohne gehen (wenn, wird als 5. Parameter sowieso undef übergeben), und man könnte das Laden bzw. den Import gleich vom IO-Typ abhängig machen...)

@pula:
Das wäre für ein bridgeRegexp-Gerät des TYPE MQTT2_DEVICE. Wie ganz am Anfang geschrieben: Wenn man CLIENT nutzen will, sollte man ein solches Device haben, ebenso wie ein explizites "Sammeldevice" für alles, was man nicht sortiert bekommt. Ist halt eine "unerwünschte Nebenwirkung" aus der Nutzung von Client...

Und es geht bei JSON noch deutlich weiter wie nur das bißchen auspacken: z.B. mit jsonMap kann man andere Readingnamen generieren, und sendeseitig kann man auch mMn. viel einfacher JSON zusammenbasteln. Das JSON-Handling war damals für mich auch DER Grund, meine eigenen Versuche mit der Erweiterung der "alten" Module direkt einzustellen (siehe den "war ... für Sidoh-Bridge"-Thread).

[pula]

@pula:
Das wäre für ein bridgeRegexp-Gerät des TYPE MQTT2_DEVICE. Wie ganz am Anfang geschrieben: Wenn man CLIENT nutzen will, sollte man ein solches Device haben, ebenso wie ein explizites "Sammeldevice" für alles, was man nicht sortiert bekommt. Ist halt eine "unerwünschte Nebenwirkung" aus der Nutzung von Client...

Jetzt bin ich doch wieder ausgestiegen.
Ich hoffe, daß ich nicht langsam nervig werde, aber möglicherweise gehts anderen wie mir. Daher frage ich doch noch mal.

Wie genau ist das Zusammenspiel/der Unterschied zwischen dem bridgeRegexp-Gerät und dem Sammeldevice? Ich dachte, das wäre das gleiche device?

Zitat aus dem Wiki (MQTT2 Praxisbeispiele):

Das Attribut bridgeRegexp kann dazu genutzt werden, um neue, bisher unbekannte Topic-Strukturen im Rahmen des autocreate-Vorgangs anders zu strukturieren.

In der commandref steht dazu:

Used to automatically redirect some types of topics to different MQTT2_DEVICE instances.

Was ich so verstehe, daß diese bridgeRegexp die ankommenden publishs dann weiterverteilt (im Betrieb, nicht für autocreate).
Da ich kein device mit bridgeRegexp habe und ein einfaches MQTT2_DEVICE trotzdem publishes empfängt, vermute ich, daß das für den Betrieb nicht nötig ist, sondern nur für autocreate, oder?
Das list von diesem einfachen device (zum Testen angelegt):

Code Auswählen Erweitern

define vpn MQTT2_DEVICE vpn
attr vpn IODev mqtt2
attr vpn readingList fheminfra:vpn/connected:.* connected
attr vpn room MQTT2_DEVICE
attr vpn stateFormat connected
setstate vpn 1
setstate vpn 2020-06-19 13:08:02 connected 1
(Ist wirklich einfach, hier wird nur von einem Skript regelmässig geprüft, ob auf einer bestimmten virtuellen Maschine ein Internet-Zugriff per vpn erfolgt oder direkt über den Provider).
Cheers,
Pula