Status Rücklesen Dummy

[Beta-User]

Habe nur mitbekommen, dass es immer wieder Anfragen bzgl. fhem<->Loxone gibt...

Das war auch meine Wahrnehmung, daher auch der ziemlich dicke "Pflock" mit dem statement, dass das nach "blindem Gewurschtel" aussieht...

Aber: besser richtig bzw. vernünftig machen!
Allerdings muss das ather entscheiden...

Genau. Mein statement war auch als Angebot gedacht, das irgendwie sinnvoller aufzugleisen...

Zu Loxone kann ich wenig sagen, aber eigentlich sollte sich das auch eher verhalten wie ein "normales" MQTT-Gerät (und nicht FHEM-Kommandos übermitteln), und für FHEM2FHEM auf dem MQTT(2)-Weg gibt es schon einige Beispiele...
Ich bin in der Ecke aber auch nicht der Experte.

Wir werden es erleben...

[ather]

Ganz grundsätzlich aber: Selbstredend _kann_ man den kompletten set-Befehl an FHEM auch via MQTT übermitteln, aber damit umgeht man eben auch die "mach daraus keine Endlos-Schleife"-Mechanismen, die z.B. MQTT_GENERIC_BRIDGE mit mqttForward bietet.

wie meinst du das? Wenn ich den Statusbefehl Loxone>FHEM via MQTT übermittle, gibt es keine Dauerschleife mehr? Wieso dass? Mqtt leitet das ganze ja auch wieder an den LichtB Dummy weiter und ein event wird wieder ausgeführt? Oder sehe ich das falsch?

Die ganze Sache müßte eigentlich einfacher aufgebaut werden können, indem man für
- originär in Loxone vorhandene Datenpunkte (oder "Geräte") statt eines dummy je ein MQTT2_DEVICE verwendet, das ganze auf einem separaten Topic-Tree und mit einer bridgeRegexp für das automatisierte Erstellen der Geräte;
- alle "nativen FHEM"-Geräte mit MQTT_GENERIC_BRIDGE nach Loxone bringt, und dazu halt den Aufwand treibt, die betreffenden subscriptions sauber zu setzen. Sonst bekämpft man halt nur die Nebenwirkungen...

Ich würde es sehr gerne sauber und einfacherer aufbauen, aber leider habe ich dazu zu wenig Wissen in Sachen MQTT, BridgeRegexp und co. und benötige daher noch Unterstützung.

Genau. Mein statement war auch als Angebot gedacht, das irgendwie sinnvoller aufzugleisen...

Dein Angebot nehme ich gerne an.

Zu Loxone kann ich wenig sagen, aber eigentlich sollte sich das auch eher verhalten wie ein "normales" MQTT-Gerät

Wie genau verhält sich denn so ein MQTT-Gerät?  Bin da zwar auch kein Profi, aber bei Loxone kann ich denke ich schon mehr Auskunt geben.
Loxone ist hier das zentrale Smarthomesystem, das ich mit fhem erweitern möchte um Gewisse Sachen ,wie Sileno,Google Home usw., zu integrieren.
ich habe bereits den Sileno Roboter erfolgreich mit Hilfe des Gardena_device integriert und habe dabei das oben gepostete notify verwendet.



Gruß
Ather

[Beta-User]

Dein Angebot nehme ich gerne an.

OK, dann beginnen wir mal bei den Grundlagen...

Das "Grundproblem" mit der potentiellen Dauerschleife ist allen "richtigen" MQTT-Implementierungen bekannt. Das "forward" von Schaltanweisungen an ein MQTT-Gerät wird daher in der Regel lokal unterbunden.

Gegen diese Grundregel verstößt du "doppelt", wenn du so eine Konstuktion baust:

Mqtt leitet das ganze ja auch wieder an den LichtB Dummy weiter

Denn: dummy ist KEIN MQTT-Gerät und hat daher keine Ahnung, an wen es ggf. die eingehende Info NICHT weitergeben darf. Daher steht auch in der commandref zu MQTT_GENERIC_BRIDGE speziell zu dummy:

This attribute defines what happens when one and the same reading is both subscribed and posted. Possible values: 'all' and 'none'.
If 'none' is selected, than messages received via MQTT will not be published from the same device.
The setting 'all' does the opposite, so that the forwarding is possible.
If this attribute is missing, the default setting for all device types except 'dummy' is 'all' (so that actuators can receive commands and send their changes in the same time) and for dummies 'none' is used. This was chosen because dummies are often used as a kind of GUI switch element. In this case, 'all' might cause an endless loop of messages.

MQTT_GENERIC_BRIDGE kann das aber nur dann unterbinden, wenn es "ahnen kann", dass die Anweisung über MQTT kam, was auf dem "notify-Weg" nicht ohne weiteres klappt...

Ich würde es sehr gerne sauber und einfacherer aufbauen, aber leider habe ich dazu zu wenig Wissen in Sachen MQTT, BridgeRegexp und co. und benötige daher noch Unterstützung.

Auch, wenn jetzt manche Dinge schon (via diesem notify) "irgendwie" funktionieren, wäre meine Empfehlung, das ganze nochmal sauber aufzugleisen. Dabei sei angemerkt, dass man von "sauber" sehr unterschiedliche Vorstellungen haben kann. Andere MQTT-Experten nutzen "dummy", um "fremde" Devices in FHEM zu "repräsentieren" (u.A. hexenmeister, von dem MQTT_GENERIC_BRIDGE stammt!), ich würde pauschal empfehlen, im MQTT-Umfeld komplett auf dummy zu verzichten und diesen Teil mit MQTT2_DEVICE zu machen.

Dazu mußt du erst mal verinnerlicht haben, dass es zwei sehr unterschiedliche Implementierungen für MQTT-Dinge in FHEM gibt, nämlich die ältere Generation MQTT/MQTT_DEVICE/MQTT_BRIDGE und die neuere Generation mit MQTT2_SERVER oder MQTT2_CLIENT und MQTT2_DEVICE. MQTT_GENERIC_BRIDGE hat eine Sonderstellung und "kann" mit allen Interface-Modulen, siehe auch https://wiki.fhem.de/wiki/MQTT#Installation_in_FHEM.

Für's erste würde ich mal empfehlen, ein MQTT2_CLIENT-Interface für den Mosquitto einzurichten und den auf "autocreate simple" zu stellen. Dann bekommst du ein "Sammeldevice", in dem praktisch sämtlicher Inhalt irgendwie zu finden sein sollte, den der mosquitto "kennt".

Diese Inhalte müssen wir dann sortieren - einen Teil verwerfen, einen Teil als Anweisungen nutzen, einen Teil an MQTT_GENERIC_BRIDGE weitergeben, usw..... Als Startpunkt für diesen Teil wäre m.E. mal ein Blick auf https://wiki.fhem.de/wiki/MQTT2_CLIENT zu empfehlen. Je nach deiner vorhandenen Topic-Struktur könnte dann gleich ignoreRegexp und bridgeRegexp gesetzt werden.

Vermutlich wird das erst mal verwirrend sein, aber einen besseren Weg kann ich grade noch nicht anbieten. Ggf. würde es Sinn machen, du würdest dein "Sammeldevice" dann mal (ggf. auszugsweise) als RAW hier einstellen (https://wiki.fhem.de/wiki/Import_von_Code_Snippets).

[ather]

Also ich habe jetzt MQTT2_Client (Mein Loxoberry mit dem MQTT Gateway) und ein MQTT2_Device (GoogleHome) angelegt.

Auf meinem Raspi läuft dieser MQTT Gateway.
https://www.loxwiki.eu/display/LOXBERRY/MQTT+Gateway

die Raw definition kann ich dann später reinstellen.

Ist es so korrekt, dass ich hier den Raspi mit MQTT Gateway als Client angelegt habe?

[Beta-User]

Ist es so korrekt, dass ich hier den Raspi mit MQTT Gateway als Client angelegt habe?

Vermutlich. Wobei sich die Beschreibung auf der verlinkten Seite bei loxwiki irgendwie komisch liest. Wenn du MQTT nur dazu nutzt, um mit FHEM zu sprechen, wäre es ggf. einfacher, MQTT2_SERVER als Broker zu wählen und den Mosquitto zu deaktivieren.
Vorteil: FHEM kann sehr viel einfacher zwischen den internen und externen MQTT-Infos unterscheiden.

und ein MQTT2_Device (GoogleHome) angelegt.

Das verstehe ich nicht. Spricht dieses "GoogleHome" nativ MQTT? Ich vermute: nein. Dann ist bitte der Weg für dieses Device über MQTT_GENERIC_BRIDGE.

MQTT2_DEVICE nimmst du nur für die Geräte, die "nur" außerhalb von FHEM existieren und erst via MQTT in FHEM leben sollen (also insbesondere alles, was direkt über den Loxone-Server läuft und irgendwie nach FHEM soll, falls es sowas gibt).

[MadMax-FHEM]

Ich denke auch, dass das bzgl. GoogleHome unnötig ist!

Wenn ich das jetzt richtig verstanden habe ist der Plan: für "Geräte" in Loxone "gespiegelte" Devices in fhem per MQTT zu haben, oder?

Wenn dem so ist, dann geht eine gassistant-Integration eher durch setzen der entsprechenden Attribute beim jeweils angelegten "Spiegel-Device" (MQTT) in fhem...
...also statt deinem bislang verwendeten "dummy-Dingens"...

Klarer Vorteil: wenn von Google was kommt ist das direkt beim Device (und somit auch in Loxone!?) und andersrum...

EDIT: wenn ich Quatsch erzähle einfach sagen, dann bin ich (sofort) ruhig...

Gruß, Joachim

[Beta-User]

Vielleicht nochmal zur Erläuterung, was ich mit

Wenn du MQTT nur dazu nutzt, um mit FHEM zu sprechen, [...]

meine: In dem https://www.loxwiki.eu/display/LOXBERRY/MQTT+Gateway#MQTTGateway-Kommunikationsdiagramm sind rechts diverse "nativ MQTT sprechende Geräte" abgebildet.

Wenn dort "rechts" nur FHEM steht, ist es einfacher mit MQTT2_SERVER, steht da vieles andere, das bereits zu deiner vollen Zufriedenheit in Loxone eingebunden ist, ist vermutlich mosquitto die bessere Wahl.

Das gilt allerdings nur, sofern es einfach ist, deine anderen MQTT-Geräte in Loxone einzubinden. Ist das nicht der Fall (z.B., weil FHEM via attrTemplate ziemlich viele "spezielle Devices" ganz gut in den Griff bekommt ), ist es evtl. einfacher, eine "doppelte MQTT-Anbindung" für das Device zu installieren und die erst mal via MQTT2_SERVER, MQTT2_DEVICE und attrTemplate nach FHEM zu bringen und dann den Teil, den du eigentlich in Loxone haben willst dann über MQTT_GENERIC_BRIDGE zu realisieren. (EDIT: das mit "doppelt" ist vermutlich in den meisten Fällen zu kompliziert; in der Regel wird es reichen, einfach an beiden Enden ein "Device" zu haben, das für das Gerät steht und die Daten direkt vom Broker zu verwenden).

"Leider" gibt es viele Wege, das macht es teilweise verwirrend. Es wäre ggf. einfacher, konkret was zu sagen, wenn wir in etwa ein Bild hätten, wie die gesamte Landschaft denn eigentlich grob aussieht...

Aus dieser Beschreibung

Ich habe bei mir Loxone als Hauptsystem laufen und Fhem auf einem Raspi als Erweiterung. Hier habe ich mit dem Modul gassitant Google Home integriert und kann Lampen auch per Sprache schalten (Dummy Modul) über MQtt.

hätte ich jetzt folgendes entnommen: Du brauchst für jedes "Ding", das du mit Sprachsteuerung (bzw. -Abfrage) versehen willst, ein entsprechendes "Device" in FHEM, das dann passende Sprachsteuerungsattribute bekommt.
Wenn das die Mehrzahl deiner Geräte ist, könnte man FHEM als eine Art "hardware abstraction layer" ausgestalten und sollte dann auch möglichst alles in FHEM haben. Spräche auch für native MQTT-Geräte dafür, die mit Prio in FHEM zu verwalten => MQTT2_SERVER.
Die Ausnahme wären dann nur Geräte, die "in Loxone" nativ sind... (kann man das verstehen...?!?)

[ather]

Hallo Zusammen,

wenn wir in etwa ein Bild hätten, wie die gesamte Landschaft denn eigentlich grob aussieht...

Was genau meinst du mit Landschaft? Wie kann ich Sie dir besser beschreiben?

Wenn dort "rechts" nur FHEM steht, ist es einfacher mit MQTT2_SERVER, steht da vieles andere, das bereits zu deiner vollen Zufriedenheit in Loxone eingebunden ist, ist vermutlich mosquitto die bessere Wahl.

Ja tatsächlich steht dort rechts bei mir nur FHEM. Andere Systeme sind bis jetzt auch nicht geplant.
Über Fhem sollen andere Geräte, wie GardenaSmart, Google usw. in Loxone eingebunden werden.

Habe auch bemerkt,dass ich bereits eine MQTT_GENERIC_BRIDGE hatte die eben Daten übermittelt. Bis jetzt nur die von Gardena.
Raw

defmod mqttGeneric MQTT_GENERIC_BRIDGE MQTT2
attr mqttGeneric IODev lb_mosquitto
attr mqttGeneric globalDefaults sub:qos=2 pub:qos=0 retain=1
attr mqttGeneric globalPublish *:topic={"fhem/$device/$reading"}
attr mqttGeneric room MQTT2

setstate mqttGeneric 2020-10-28 14:57:40 device-count 0
setstate mqttGeneric 2020-10-28 14:57:40 incoming-count 0
setstate mqttGeneric 2020-10-28 15:17:10 outgoing-count 68877
setstate mqttGeneric 2020-10-28 15:17:10 transmission-state outgoing publish sent
setstate mqttGeneric 2020-10-28 14:57:40 updated-reading-count 0
setstate mqttGeneric 2020-10-28 14:57:40 updated-set-count 0

lb_mosquitto ist ebenfalls angelegt:

defmod lb_mosquitto MQTT loxberry:1883

setstate lb_mosquitto opened
setstate lb_mosquitto 2020-10-28 15:17:43 connection active
setstate lb_mosquitto 2020-10-20 13:39:18 state opened

Das gilt allerdings nur, sofern es einfach ist, deine anderen MQTT-Geräte in Loxone einzubinden. Ist das nicht der Fall (z.B., weil FHEM via attrTemplate ziemlich viele "spezielle Devices" ganz gut in den Griff bekommt ), ist es evtl. einfacher, eine "doppelte MQTT-Anbindung" für das Device zu installieren und die erst mal via MQTT2_SERVER, MQTT2_DEVICE und attrTemplate nach FHEM zu bringen und dann den Teil, den du eigentlich in Loxone haben willst dann über MQTT_GENERIC_BRIDGE zu realisieren. (EDIT: das mit "doppelt" ist vermutlich in den meisten Fällen zu kompliziert; in der Regel wird es reichen, einfach an beiden Enden ein "Device" zu haben, das für das Gerät steht und die Daten direkt vom Broker zu verwenden).

Bis jetzt habe ich keine Geräte mit MQTT. Aber ja wenn ich etwas dazu nehme würde ich es evtl über Loxberry Plugin oder über fhem in Loxone einbinden um den Miniserver von Loxone zu entlasten.

hätte ich jetzt folgendes entnommen: Du brauchst für jedes "Ding", das du mit Sprachsteuerung (bzw. -Abfrage) versehen willst, ein entsprechendes "Device" in FHEM, das dann passende Sprachsteuerungsattribute bekommt.
Wenn das die Mehrzahl deiner Geräte ist, könnte man FHEM als eine Art "hardware abstraction layer" ausgestalten und sollte dann auch möglichst alles in FHEM haben. Spräche auch für native MQTT-Geräte dafür, die mit Prio in FHEM zu verwalten => MQTT2_SERVER.

Genau so habe ich es verstanden. pro Gerät muss ich ein Device bilden und es mit einem Namen versehen. Sobald ich es in den Raum GoogleHome einfüge, erstellt das Modul gasisstant automatisch ein Gerät in Google home und lässt sich per Sprache schalten. Funktioniert auch ganz gut.

Wie mache ich jetzt weiter? Bin im Moment etwas ratlos?
Soll ich jetzt das MQTT2_device GoogleHome wieder entfernen? und MQTT_Server erstellen für die Lampe z.B?

Gruß
Ather

[Beta-User]

Hallo Zusammen,
Was genau meinst du mit Landschaft? Wie kann ich Sie dir besser beschreiben?

In etwa das, was auf dem Schaubild zu sehen ist. Das sollte erst mal reichen.

Ja tatsächlich steht dort rechts bei mir nur FHEM. Andere Systeme sind bis jetzt auch nicht geplant.
Über Fhem sollen andere Geräte, wie GardenaSmart, Google usw. in Loxone eingebunden werden.

Du wirst um eine gewisse Einarbeitung in FHEM nicht rumkommen. M.E. gibt es einen prinzipiellen Unterschied zwischen GardenaSmart und Google (damit ist gassistant gemeint, nehme ich an): GardenaSmart dient der Einbindung von Hardware, gassistant ist eigentlich eine Art "input"-Device, das (btw.: wie die MQTT_GENERIC_BRIDGE) "quer" über alle anderen Devices eine zusätzliche Funktionalität einzieht.

Soll ich jetzt das MQTT2_device GoogleHome wieder entfernen?

MAn. braucht gassistant keine Entsprechung in der MQTT-Welt; wie gesagt: das ist eine andere Ebene.

und MQTT_Server erstellen für die Lampe z.B?

Auch MQTT2_SERVER ist eine Art Querschnittsdevice. Da du keine weiteren Geräte hast, die MQTT sprechen, würde ich erst mal vorschlagen, beim setup mit mosquitto zu bleiben; darum können wir uns ggf. am Ende nochmal kümmern, wenn alles andere klappt...

Wie mache ich jetzt weiter?

Mein Vorschlag:

Wir gliedern das in 3-4 Teile:
Teil A - Vorbereitung
Teil B - Loxone-Hardware-Elemente nach FHEM bringen (für Sprachsteuerung)
Teil C - FHEM-Hardware-Elemente nach Loxone bringen (für GUI?)
Teil D - Nachbereitung (optional)

Erst mal zu
Teil A - Vorbereitung
Zumindest ich, vermutlich aber auch du werden uns leichter tun, wenn wir das ganze mit MQTT2_.*-Modulen umsetzen. Daher werden wir als erstes lb_mosquitto rauswerfen und mit einem MQTT2_CLIENT als IO-Modul zum mosquitto hin arbeiten. Folgende Befehle sind dazu abzusetzen:

Code Auswählen Erweitern

list -r TYPE=MQTT_DEVICE
Bitte den output (falls es welchen gibt) rauskopieren und wegspeichern.

Dann

Code Auswählen Erweitern


delete lb_mosquitto
delete TYPE=MQTT_DEVICE

define defmod lb_mosquitto MQTT2_CLIENT loxberry:1883
attr lb_mosquitto room MQTT2

Was passiert dabei: Der TYPE des Interfaces wird geändert, und um Problemen vorzubeugen, werfen wir MQTT_DEVICE-Type Geräte auch gleich raus. Da MQTT_GENERIC_BRIDGE mit beidem "kann", sollte die eigentlich erst mal weiter funktionieren (in Senderichtung=aus FHEM heraus sowieso).

Dann schauen wir mal, was der mosquitto so an Daten parat hält:

Code Auswählen Erweitern

attr lb_mosquitto autocreate simple
Das kann dazu führen, dass die MQTT_GENERIC_BRIDGE (MGB) erst mal nicht mehr (empfangsseitig) funktioniert.

Wir können das dann wieder reparieren, aber dazu müssen wir die Infos, die über die MGB gehen sollen von denen trennen, die als "natives MQTT2_DEVICE" leben sollen.
Anders gesagt: Du brauchst getrennte Topic-Pfade für die Kommunikation von und zur MGB und für die Hardware, die direkt an dem Loxberry hängt und dann "nur" über FHEM mit Sprachsteuerung versehen werden soll.

Damit wären wir bei
Teil B - Loxone-Hardware-Elemente nach FHEM bringen (für Sprachsteuerung)
Da ist mir aber nicht so richtig klar, wie z.B. der "Rollladen" von links auf der Zeichnung "ver-MQTT't" wird.
Von daher wäre der betreffende Auszug aus dem durch "autocreate simple" erzeugten Gerät interessant. Du bekommst das in FHEM mit

Code Auswählen Erweitern

list -r TYPE=MQTT2_DEVICE
(Bitte kritisch durchsehen, ob da vertrauliche Infos drin sind und ggf. nur auszugsweise posten. Wenn wir das haben, können wir dann versuchen, diesen Teil fertigzustellen, bevor wir den nächsten Schritt machen. Wir können den aber auch vorziehen, wenn dir das lieber ist.

[ather]

Ok habe ich so gemacht.

hier die Lsit bzw. Auzug:

Code Auswählen Erweitern

define MQTT2_lb_mosquitto MQTT2_DEVICE lb_mosquitto
attr MQTT2_lb_mosquitto IODev lb_mosquitto
attr MQTT2_lb_mosquitto readingList lb_mosquitto:loxberry/mqttgateway/status:.* status\
lb_mosquitto:loxberry/mqttgateway/keepaliveepoch:.* keepaliveepoch\
lb_mosquitto:fhem/n_SYS_MQTT_cmnd/state:.* state\
lb_mosquitto:fhem/Gardena_Bridge/token:.* token\
lb_mosquitto:fhem/Gardena_Bridge/state:.* state\
lb_mosquitto:fhem/Gardena_Bridge/lastRequestState:.* lastRequestState\
lb_mosquitto:fhem/Gardena_Bridge/name:.* name\
lb_mosquitto:fhem/Gardena_Bridge/authorized_user_ids:.* authorized_user_ids\
lb_mosquitto:fhem/Gardena_Bridge/devices:.* devices\
lb_mosquitto:fhem/Gardena_Bridge/longitude:.* longitude\
lb_mosquitto:fhem/Gardena_Bridge/gateway_time_zone_offset:.* gateway_time_zone_offset\
lb_mosquitto:fhem/Gardena_Bridge/gateway_time_zone:.* gateway_time_zone\
lb_mosquitto:fhem/Gardena_Bridge/address:.* address\
lb_mosquitto:fhem/Gardena_Bridge/city:.* city\
.
.
.lb_mosquitto:fhem/SILENO/state:.* state\
lb_mosquitto:fhem/SILENO/mower_type-base_software_up_to_date:.* mower_type-base_software_up_to_date\
lb_mosquitto:fhem/SILENO/mower_type-mmi_version:.* mower_type-mmi_version\
lb_mosquitto:fhem/SILENO/mower_type-mainboard_version:.* mower_type-mainboard_version\
lb_mosquitto:fhem/SILENO/mower_type-device_type:.* mower_type-device_type\
lb_mosquitto:fhem/SILENO/mower_type-device_variant:.* mower_type-device_variant\
.
.
.
.lb_mosquitto:fhem/SYS_MQTT/cmnd:.* cmnd\
lb_mosquitto:fhem/Google/gassistantFHEM\xxx\xxxxxURL:.* gassistantFHEM.loginURL\
lb_mosquitto:fhem/Google/gassistant-fhem:.* gassistant-fhem\
lb_mosquitto:fhem/Google/gassistant-fhem-version:.* gassistant-fhem-version\
lb_mosquitto:fhem/Google/gassistant-fhem-lastServerError:.* gassistant-fhem-lastServerError\
lb_mosquitto:fhem/Google/gassistant-fhem-connection:.* gassistant-fhem-connection\
lb_mosquitto:fhem/Google/gassistant-fhem-lasterror:.* gassistant-fhem-lasterror\
.
..
.
lb_mosquitto:fhem/RolloWz/state:.* state\
lb_mosquitto:fhem/RolloB/command:.* command\
lb_mosquitto:fhem/RolloB/desired_pct:.* desired_pct\
lb_mosquitto:fhem/RolloB/last_drive:.* last_drive\
lb_mosquitto:fhem/RolloB/state:.* state\
lb_mosquitto:fhem/RolloB/drive-type:.* drive-type\
lb_mosquitto:fhem/RolloB/pct:.* pct\
lb_mosquitto:fhem/FileLog_SILENO/state:.* state\
lb_mosquitto:fhem/loxberrymqtt2/state:.* state.
.
.

setstate MQTT2_lb_mosquitto DISCONNECTED
.
.
setstate MQTT2_lb_mosquitto 2020-10-29 13:19:36 mower_type-base_software_up_to_date 1
setstate MQTT2_lb_mosquitto 2020-10-29 13:19:36 mower_type-device_type 13
setstate MQTT2_lb_mosquitto 2020-10-29 13:19:36 mower_type-device_variant 1
setstate MQTT2_lb_mosquitto 2020-10-29 13:19:36 mower_type-mainboard_version 10.35
.
.
.
.


Wahrscheinlich werden hier noch die ganzen readings von der ehemahligen installation angezeigt.

Jetzt habe ich ein MQTT2_client "lb_mosquitto" (opened) und ein MQTT2_Device "MQTT2_lb_mosquitto" (disconnected) der automatisch angelegt wurde.

Im "MQTT2_lb_mosquitto" sehe ich jetzt alle aktuellen readings unter readingList, obwohl da steht disconnected.

Ist das so Corrrect?

wie gehts jetzt weiter?

[Beta-User]

OK, dann versuchen wir das mal auszusortieren...

Wenn ich das richtig deute, schubst FHEM alle Readings usw. nach MQTT. Das sollte m.E. selektiver erfolgen (also eigentlich nicht via "globalPublish", sondern via mqttDefaults in der MGB und dann Einzelanweisungen an jedem Device) bzw. wenn, dann in jedem Fall auch auf einem dezidierten Unterpfad geschehen. Daher nur unter Vorbehalt:

Code Auswählen Erweitern

attr mqttGeneric globalPublish *:topic={"fhem/MGB/out/readings/$device/$reading"}
Besser wäre sowas wie:

Code Auswählen Erweitern

attr mqttGeneric globalDefaults base=fhem/MGB/
(bin aber auch bei den Details zu MGB nicht durch, es gibt hier irgendwo einen Thread mit "Beispielen" zu diesem Modul).

Damit die nicht wieder in FHEM ankommen, beschränken wir die subscription des CLIENT:

Code Auswählen Erweitern

attr lb_mosquitto ignoreRegexp fhem/MGB/out
Danach solltest du eigentlich erst mal alles löschen, was mosquitto so an gespeicherten Messages hatte; vermutlich geht das am einfachsten, wenn du die DB löschst, wie hier vorgeschlagen: https://stackoverflow.com/questions/36729300/how-to-clear-all-retained-mqtt-messages-from-mosquitto#comment76794971_36729560. Sollte man aber nur machen, wenn sonst nichts wichtiges drauf war...

Kurz zur angedachten Topic-Struktur:

Code Auswählen Erweitern

fhem/MGB/out => alle Readings, die von FHEM über die MGB an den Broker übermittelt werden
fhem/MGB/in   => alle Anweisungen, die FHEM über die MGB erhalten und auswerten soll
loxberry/out  => alle Anweisungen, die von MQTT2_DEVICE-Geräten in FHEM empfangen werden sollen
loxberry/in    => alle Anweisungen, die FHEM (über MQTT2_DEVICE-Geräte) an Loxone senden soll;

Die letzten beiden Pfade gelten für die Dinge, die in Loxone "schon immer" exisitert haben und nicht mit FHEM zusammenhängen, die ersten beiden für alles, was in FHEM an _steuerbarer Hardware_ (oder an Messdatenerfassung) vorhanden ist und von Loxone aus erkannt und gesteuert werden soll. Wie du unschwer erkennen kannst, wird derzeit sehr viel mehr an mosquitto übertragen, als du eigentlich brauchst...
Falls du schon irgendwas von Loxone aus in Richtung MQTT angepaßt hattest, solltest du die Pfade dann auch entsprechend anpassen.

Danach kannst du die RAW-Definition von MQTT2_lb_mosquitto erst mal wegsichern und dann dieses Device in FHEM wieder löschen.
Nach einem Neustart des Mosquitto müßte dann wieder ein (deutlich kleineres) MQTT2_DEVICE mit diesem Namen erscheinen.

Den "notify-Pfad" würde ich erst mal hintanstellen, wie gesagt, ich meine, dass man den eigentlich besser nicht verwenden sollte, aber an der Stelle der Nachweis, dass das auch via MQTT2_DEVICE geht - dieses eine Device ersetzt dann die Kombination von MQTT_DEVICE und notify (allerdings ohne Log, aber das könnte man auch noch anflanschen...):

Code Auswählen Erweitern

define MQTT2_Notify_replacement MQTT2_DEVICE n_replacement
fhem/SYS_MQTT/cmnd:.*  { fhem($EVENT) }
Das ganze ist aber ein einziges Sicherheitsloch (der Broker muss zumindest von Loxone her ohne TLS oä. auskommen, weil das plugin das nicht kann!), daher sollte man das - genau wie das globale publish von FHEM aus - SEIN LASSEN...

Danach müssen wir uns wieder um das "MQTT2_lb_mosquitto" kümmern:
- zum einen speicherst du die neue (RAW-)Konfiguration erst mal wieder weg und wendest dann das attrTemplate "MQTT2_CLIENT_general_bridge" an.
- Die damit erzeugte bridgeRegexp erweiterst du um eine Zeile:

Code Auswählen Erweitern

attr MQTT2_lb_mosquitto bridgeRegexp [...]
[\b]fhem/MGB/in.*:.* ""

Das sollte dazu führen, dass alle über "fhem/MGB/in" eingehenden Messages an die MQTT_GENERIC_BRIDGE auch bei eingeschaltetem autocreate weitergegeben werden.

Jetzt kümmern wir uns noch um den Eingangspfad von den Loxone-Devices und erweitern die bridgeRegexp um eine weitere Zeile - hier mal angenommen, der Name des Geräts in Loxone steht hinter dem "out" als ein Element des Topic-Pfades:

Code Auswählen Erweitern

attr MQTT2_lb_mosquitto bridgeRegexp [...]
[\b]loxberry/out/([^/]+).*:.* "lb_$1"

Das sollte bewirken, dass alles, was über diesen Pfad an Infos kommt dann auch an demselben MQTT2_DEVICE in FHEM ankommt. Die Namensgebung ist dann erst mal MQTT2_lb_<nameInLoxone>.

Damit haben wir folgendes Gesamtbild für die einzelnen Topics von oben (von FHEM aus gesehen):

Code Auswählen Erweitern

fhem/MGB/out => werden von der ignoreRegexp am IO verworfen
fhem/MGB/in   => werden an die MGB weitergeleitet. Die Weiterverarbeitung in FHEM setzt jetzt voraus, dass am eigentlichen Zieldevice eine Auswertung definiert wird;
loxberry/out  => füllt je Unter-Topic-Pfad ein MQTT2_DEVICE in FHEM.
loxberry/in    => verwenden wir für die setList-Attribute an den betreffenden Devices. (Kommt noch).


Ist damit in etwa nachvollziehbar, wie das am Ende aussehen soll?

[ather]

bei mqttGeneric habe ich bereits folgende Attribute:

globalDefaults
sub:qos=2 pub:qos=0 retain=1

globalPublish
*:topic={"fhem/$device/$reading"}

soll ich die jetzt löschen? und deine neu anlegen?

verstehe ich es richtig?

[Beta-User]

Kommt drauf an, für welchen Weg du dich entscheidest. Wenn du weg willst von dem "globalPublish", kannst du die global defaults einfach um die "base"-Angbae erweitern.
"retain" kann aber auch (v.a. allerdings von der eingehenden Seite her) komische Nebenwirkungen haben, wenn FHEM oder der Broker neu gestartet werden... (Ist mehr ein Punkt, den man im Hinterkopf behalten sollte).

[ather]

Danach solltest du eigentlich erst mal alles löschen, was mosquitto so an gespeicherten Messages hatte; vermutlich geht das am einfachsten, wenn du die DB löschst, wie hier vorgeschlagen: https://stackoverflow.com/questions/36729300/how-to-clear-all-retained-mqtt-messages-from-mosquitto#comment76794971_36729560. Sollte man aber nur machen, wenn sonst nichts wichtiges drauf war...

Das habe ich noch net ganz gecheckt bzw. so verstanden:
- über putty als root anmelden am raspi
- Dann folgendes eingenben:
#!/bin/sh
echo "cleaning " $1 " :: usage: cleanmqtt <192.168.178.XX:1833>"
mosquitto_sub -h $1 -t "#" -v | while read line; do mosquitto_pub -h $1 -t "${line% *}" -r -n; done

ist das so korekt?

[Beta-User]

Das habe ich noch net ganz gecheckt bzw. so verstanden:
- über putty als root anmelden am raspi

Win 10 sollte ssh auch nativ können... (k.A., ich habe einen Linux-Rechner für sowas)

- Dann folgendes eingenben:

...ehrlich gesagt: k.A....
Ich habe das nur kurz über die SuFu meiner Wahl gefunden und hätte eher die "Datenbank löschen"-Variante darüber genommen.

Aber wenn du sowieso mit allem ganz am Anfang stehst, stellt sich mir die Frage, ob es nicht einfacher wäre, gleich den Schritt zum MQTT2_SERVER zu gehen...

Das hieße: mosquitto deinstallieren (falls es ein Debian-Derivat ist, sollte das mit "sudo apt-get remove mosquitto" funktionieren), MQTT2_SERVER in FHEM definieren ("define m2server MQTT2_SERVER 1883 global") und dann in dem Loxone-Ding eben die IP des FHEM-Servers als Broker angeben und den MQTT2_CLIENT wieder löschen+IODev der MGB auf den m2server legen...