FHEM -> MQTT -> Loxberry mosquito -> Loxone -> Loxberry mosquito -> fhem

[MichlB]

hallo
ich hab wieder mal ne frage, ich hab mir loxone zugelegt und mit dem loxberry erweitert um mit Fhem zu kommunizieren also konstellation:

FHEM (eigenständiger RPI):
+mit MQTT verbunden auf den MQTTgate am loxberry (xx.xx.xx.161:1883)
+ MQTT-Device subscribed /fhem/cmnd
+MQTT-Generic_Bridge mit outgoing globalPublish fhem/$device/$reading

Loxberry (eigener RPI):
+MQTT Gateway

Loxone Miniserver

also die übertragung von FHEM -> MQTT-Gate (loxberry) -> Loxone funktioniert einwandfrei
Übertragung von Loxone -> MQTT-Gate(loxberry) -> FHEM tut sich gar nix... 0 incoming-count bei der mqtt_generic_bridge....

wo muß ich da jetzt ansetzen??? kann der loxone direkt an FHEM übertragen oder muß am loxberry auch fhem drauf sein???
auf meinen alten FHEM-Pi hab ich die MAX! Thermostate, Somfy-rollo und Mysensors via Maplecun eingebunden...

ich hab die konfig nach dieser anleitung aufgebaut: https://ownsmarthome.de/2020/05/07/loxone-mit-raspberry-pi-mqtt-fhem-aufbohren/

aber ich komm da nicht weiter....
bin für jeden hinweis dankbar...

ps. was ist der unterschied MQTT und MQTT2???

danke

[Beta-User]

Diese Anleitung ist trotz des vermeintlichen updates aus Januar m.E. komplett outdated...V.a. dieses notify ist ein nogo!
Es gibt mind. einen Thread, der sich "richtig" mit MQTT_GENERIC_BRIDGE und loxone befasst, müsste mal suchen...
Edit: der Thread ist sogar unten in den Kam mmentaren verlinkt, oder...?

[MichlB]

danke für die rasche antwort... ich werd mir das mal zu gemüte führen, aber hat jemand schon so eine ähnliche Kombi realisiert also fhem nicht auf dem loxberry und dennoch gesteuert aus loxone?

ich hab mal versucht einen MQTT2_CLIENT auf den mosqitto-gate zu verbinden... immer nur disconnected, bei dem mqtt funkt das einwandfrei...

[Beta-User]

MQTT2_CLIENT kann z.B. auch SSL-verschlüsselte Verbindungen - ein Grund mehr... Ohne genaue Info, was du wie gemacht hast, geht es aber nicht, die Syntax ist nämlich etwas anders.

[Beta-User]

Vielleicht nochmal eine Zusammenfassung, was an der Anleitung mAn. nicht gut ist:

- Module in FHEM:
(Extern) vorgeschlagen sind:
-- MQTT als IO-Modul kann kein SSL, das Passwort scheint im Klartext in der cfg gespeichert zu werden. Es  braucht zusätzliche Perl-Module (aus Debian verfügbar); der Weg über den hostname ist auch ungünstig (kann blockieren)
-- MQTT_DEVICE: (braucht nochmal mehr Perl-Module, diese kommen nur noch via cpan)

Besser wären:
-- MQTT2_CLIENT als IO-Modul

Code Auswählen Erweitern

define lb_mosquitto2 MQTT2_CLIENT <loxberry-IP>:1883
attr lb_mosquitto2 username loxberry
set lb_mosquitto2 password <dein passwort>
attr lb_mosquitto2 subscriptions setByTheProgram
attr lb_mosquitto2 clientOrder MQTT_GENERIC_BRIDGE MQTT2_DEVICE


-- MQTT2_DEVICE: Das kann direkt JSON auspacken (hier nicht relevant) und (wenn man unbedingt will) Perl-Code ausführen. Es ist hier aber UNNÖTIG!

Denn:
-- MQTT_GENERIC_BRIDGE kann direkt die (anders zu notierenden!) Anweisungen aus dem MQTT-Server verarbeiten!

ABER:
attr mqttGeneric "globalPublish" ist ein "no-go" - selbst wenn man das auf bestimmte Räume eingrenzt. Die Attribute in Sende- und Empfangsrichtung können nach der Einrichtung der MQTT_GENERIC_BRIDGE einfach am jeweiligen Gerät gesetzt werden, und zwar so, dass nur gesendet und empfangen wird, was auch GEWOLLT ist -

das notify ist ABSOLUTES nogo! Damit kann jeder, der Zugriff auf den MQTT-Server hat beliebige Befehle an FHEM schicken (einschließlich: lösche alles, formatiere die Festplatte, lege 10.000 Devices an, ...)
Sätze wie

ohne bei jedem FHEM Gerät ein subscribe auf ein bestimmtes Topic zu erstellen. Das erspart viel Arbeit und Zeit.

sind einfach eine unglaubliche Vereinfachung, die Anfänger in die völlig falsche Richtung schicken.

"retain" führt auch immer wieder zu "lustigen" Ergebnissen...

Hier also nochmal, wie es "richtig" geht:

Code Auswählen Erweitern

define mqttGeneric MQTT_GENERIC_BRIDGE loxb
attr mqttGeneric IODev lb_mosquitto2
attr mqttGeneric globalDefaults sub:base=fhem/set pub:base=fhem


Hier noch die Einstellungen zum Ein- und Ausschalten eines HUEDevice (hier bewußt auf "state" begrenzt)

Code Auswählen Erweitern

attr Licht_Essen loxbPublish state:topic={"$base/$device"} state:expression={if($value=~/dim.*/){$value="on"}else{$value}}
attr Licht_Essen loxbSubscribe state:stopic={"$base/$device"}


Der MQTT-Befehl wäre dann:

Code Auswählen Erweitern

fhem/set/Licht_Essen on

Kann nicht erkennen, dass es soooo viel mehr Arbeit ist, für die paar Devices, die man von wo aus auch immer steuern will, diese zwei Attribute zu setzen - und zwar gleich so, dass sie zu "standardisierten" Ergebnissen auf der Empfängerseite (logxberry) führen...
(Es gibt dazu auch die Möglichkeit, das ganze in attrTemplate-Form zu gießen, denn die Struktur ist jeweils für einen bestimmten Device-TYPE gleich...!)

Nachträge noch:
- Das mit den "subscriptions" bzw. "clientOrder" bei MQTT_GENERIC_BRIDGE ist etwas vielschichtiger als oben dargestellt, "setByTheProgram" in Verbindung mit MQTT2_DEVICE in clientOrder ist nicht allzu sinnig (das dürfte aber trotzdem für die MQTT_GENERIC_BRIDGE funktionieren!)

- Wenn man die Standardisierung so macht wie vorgeschlagen, sind die MQTT-Attribute nicht nur für loxone verwendbar, sondern von allen möglichen anderen Gegenstellen aus...

- In dieser Anleitung steht: "virtueller Ausgang angelegt", danach taucht irgendwas mit "udp" auf. Das klingt zumindest auf den ersten Blick danach, als könnte jeder Netzwerkteilnehmer auf diesem Weg (anonym?!?) irgendwelche Befehle auf den MQTT-Server schicken und damit jegliche weitere Sicherungsmaßnahmen konterkarieren... Dann ist das ein Grund mehr für die These, dass das notify "nogo" ist!

EDIT: Formatierung war kaputt...

[MichlB]

vielen dank für die ausführlichen infos, ich werde das mal versuchen irgendwie zu verstehen und entsprechend umzusetzen...

nachtrag:
ich habs mal so 1:1 versucht umzusetzen, weil ich's noch nicht ganz durchschaut hab - bei mir dauert das immer etwas... aber es klappt nicht, im loxberry mqtt-gateway-plugin kommt nix an

Code Auswählen Erweitern

define lb_mosquitto2 MQTT2_CLIENT 10.66.1.161:1883
setuuid lb_mosquitto2 62518454-f33f-2c3b-efdf-687d69a5e8e58a29
attr lb_mosquitto2 clientOrder MQTT_GENERIC_BRIDGE MQTT2_DEVICE
attr lb_mosquitto2 room MQTT2
attr lb_mosquitto2 subscriptions setByTheProgram
attr lb_mosquitto2 username loxberry
define mqttGeneric MQTT_GENERIC_BRIDGE loxb
setuuid mqttGeneric 6251851f-f33f-2c3b-e305-a1c917e47128c012
attr mqttGeneric globalDefaults sub:base=fhem/set pub:base=fhem
attr mqttGeneric room MQTT2


und beim device hab ich dann:

Code Auswählen Erweitern


define WW9 GPIO4 28-011564e9c4ff
setuuid WW9 5d17622e-f33f-2c3b-00b3-2dff8d571300f39f
attr WW9 alias EGFBHVL
attr WW9 event-min-interval 1800
attr WW9 event-on-change-reading temperature:0.2
attr WW9 group Fühler
attr WW9 loxbPublish state:topic={"$base/$device"} state:expression={"$value"}
attr WW9 model DS18B20
attr WW9 pollingInterval 60
attr WW9 room 20_EG-FBH,OWire
attr WW9 stateFormat {sprintf("%.2f",ReadingsVal("WW9","temperature",0))."°C / " .ReadingsTimestamp("WW9","temperature","")}
attr WW9 verbose 0




lg
und vielen dank... sorry für meine quälerei



und nochmals für die ganz doofen....
ich brauche für das mqtt2 nicht zwingend einen eigenen server (der client übernimmt das mit?!)
aber die bridge brauch ich, die sammelt meine daten und schickt die quasi raus - richtig? und empfangen bwz zum steuern brauch ich das mqtt2-device?

[Beta-User]

Das Ding liefert vermutlich "temperature", dann solltest du auch das publishen, und nicht " state".
Würde da noch den Reading-Namen in den Topic packen, und expression ist hier nicht nötig => löschen.
Und bitte list oder raw-Def, keine cfg-Auszüge!

[MichlB]

also wenn ich dich richtig verstehe müsste ich hier

Code Auswählen Erweitern

defmod WW9 GPIO4 28-011564e9c4ff
attr WW9 alias EGFBHVL
attr WW9 event-min-interval 1800
attr WW9 event-on-change-reading temperature:0.2
attr WW9 group Fühler
attr WW9 loxbForward all
attr WW9 loxbPublish state:topic={"$base/$device"} state:expression={"$value"}
attr WW9 model DS18B20
attr WW9 pollingInterval 60
attr WW9 room 20_EG-FBH,OWire
attr WW9 stateFormat {sprintf("%.2f",ReadingsVal("WW9","temperature",0))."°C / " .ReadingsTimestamp("WW9","temperature","")}
attr WW9 verbose 0

setstate WW9 33.81°C / 2022-04-09 15:54:20
setstate WW9 2022-04-09 15:23:35 failures 0
setstate WW9 2022-04-09 15:54:20 state T: 33.812
setstate WW9 2022-04-09 15:54:20 temperature 33.812

beim

Code Auswählen Erweitern

attr WW9 loxbPublish state:topic={"$base/$device"} state:expression={"$value"}
das 2. state durch temperature ersetzen oder??


aber dennoch sollte ich ja eigentlich schon irgendwas sehen... weil auch bei der MQTT-GENERIC-Bridge  is unter outgoing-count 0

Code Auswählen Erweitern

defmod mqttGeneric MQTT_GENERIC_BRIDGE loxb
attr mqttGeneric globalDefaults sub:base=fhem/set pub:base=fhem
attr mqttGeneric room MQTT2

setstate mqttGeneric 2022-04-09 15:23:43 IODev lb_mosquitto2
setstate mqttGeneric 2022-04-09 15:15:15 attrTemplateVersion 20211208_MQTT
setstate mqttGeneric 2022-04-09 15:52:13 device-count 2
setstate mqttGeneric 2022-04-09 15:23:42 incoming-count 0
setstate mqttGeneric 2022-04-09 15:23:42 outgoing-count 0
setstate mqttGeneric 2022-04-09 15:23:43 transmission-state IO device initialized (mqtt2)
setstate mqttGeneric 2022-04-09 15:23:42 updated-reading-count 0
setstate mqttGeneric 2022-04-09 15:23:42 updated-set-count 0



und auf meinem anderen rpi wo ich nach der "bösen" anleitung gemacht hab, da läuft die zahl der outgoing nur so hoch... und die seh ich auch am mqtt-gateway am loxberry, die neue mqtt2 (is ein anderer pi) tauchen gar nirgends auf...

[Beta-User]

Nein, das erste umbenennen, das zweite löschen...

[Beta-User]

Und die Edits sind verwirrend...

[MichlB]

ha! danke für die info, hab jetzt a bissi rumgebastelt und wenn ich

Code Auswählen Erweitern

temperature:topic={"$base/$device/$reading"}

verwende, dann kommt das im MQTTGate und auch loxone entsprechen fhem_WW9_temperature an..

perfekt, vielen dank!

[MichlB]

wenn ein device mehrere readings hätte, zb. Battery, temperature, humidity, müsst ich dann für jedes eine zeile anlegen oder wäre dann quasi die readings davor zb.

Code Auswählen Erweitern


battery:temperature:topic={"$base/$device/$reading"}



habs hinbekommen... danke.
jetzt kommt das steuern drann...

[Beta-User]

ha! danke für die info, hab jetzt a bissi rumgebastelt [...] kommt das im MQTTGate und auch loxone entsprechen fhem_WW9_temperature an..

perfekt, vielen dank!

Gerne!
Freut mich, wenn der Groschen gefallen ist, was das Versenden von Daten aus FHEM heraus betrifft.

habs hinbekommen... danke.

Auch wenn es in der commandref steht, wie es geht: Die Lösung dazu zu posten, hätte evtl. Rückfragen von künftigen Nachmachern verhindert...

jetzt kommt das steuern drann...

Ein (in Richtung FHEM->Loxone komplizierteres) Beispiel hatte ich ja bereits gepostet.

Sonstige Hinweise:

nochmal: Es wird  zum Schteuern von "normalen FHEM-Geräten"  weder notify noch MQTT_DEVICE bzw. MQTT2_DEVICE benötigt (!). Das kann die MQTT_GENERIC_BRIDGE direkt übernehmen.
Es wird dann aber eine andere Topic/Payload-Struktur benötigt, als die externe Anleitung das vorsieht.

auf meinem anderen rpi wo ich nach der "bösen" anleitung gemacht hab, da läuft die zahl der outgoing nur so hoch...

Für mich ist die hohe Zahl an "outgoing count" ein klarer Beleg dafür, dass es keine gute Idee ist, pauschal "alles" zu versenden. Auch an deinem "GPIO-Testgerät" wären ja mehrere Datenpunkte versendet worden, obwohl du eigentlich nur die Temperatur haben wolltest. Das war/ist "nur" konkret deswegen nicht aufgefallen, weil du die Events mit "event-on-change-reading" auf genau dieses eine Reading reduziert hattest. Es ist aber erfahrungsgemäß die große Ausnahme, dass jemand das so macht...

Es wäre ggf. eine gute Sache, wenn du (evtl. dann auch zur Übernahme ins Wiki) ein paar screenshots liefern könntest, wenn das ganze dann läuft- ähnlich wie die in dieser externen Anleitung, aber eben "the original MQTT_GENERIC_BRIGE way"...

[MichlB]

hallo Beta-user

ja die übergaben funktionieren perfekt - von FHEM per MQTT2 in den Loxone, bei der Steuerung von Loxone -> FHEM harperts noch, die Screenshots folgen natürlich... das ist das mindeste was ich tun kann...

zur steuerung selbst hab ich ne frage, du schreibst von der MQTT_GENERIC_BRIDGE steuert... aber dann muß ich dem Device eine Subscription zuweisen... oder?
so was auf die art nehm ich an:

Code Auswählen Erweitern

defmod HPTest dummy
attr HPTest loxbPublish state:topic={"$base/$device/$reading"}
attr HPTest loxbSubscribe state:topic={"fhem/set $reading"}
attr HPTest room MQTT2
attr HPTest webCmd on:off


oder muß beim subscribe direkt das device statt $Devide dort stehen?

[Beta-User]

dummy verwirren nur.

Hier noch die Einstellungen zum Ein- und Ausschalten eines HUEDevice (hier bewußt auf "state" begrenzt)

Code Auswählen Erweitern

attr Licht_Essen loxbPublish state:topic={"$base/$device"} state:expression={if($value=~/dim.*/){$value="on"}else{$value}}
attr Licht_Essen loxbSubscribe state:stopic={"$base/$device"}


Der MQTT-Befehl wäre dann:

Code Auswählen Erweitern

fhem/set/Licht_Essen on