Befehle von MQTT an Velux KLF200 Modul ausführen

Begonnen von pade84, 18 Juli 2021, 11:05:36

Vorheriges Thema - Nächstes Thema

pade84

Hallo,

ich habe ein Loxone Smart Home mit einem Loxberry laufen. Auf dem Loxberry läuft FHEM und ich habe dort das Velux KLF200 Modul eingebunden. Die Verbindung zum KLF200 steht und ich kann mit der FHEM App auch die Dachfenster bedienen. Nun habe ich ein Problem mit der MQTT-Verbindung, die auf dem Loxberry läuft.

Die Werte von FHEM kommen im MQTT Broker an (also Stati-Änderungen, usw.). Allerdings passiert nichts, wenn ich über Loxone Befehle ausführe. Im MQTT kommen diese Befehle an, aber in FHEM scheinen diese nicht bearbeitet zu werden (die Logs der Geräte zeigen keine Änderung an und das Dachfenster rührt sich auch nicht).

Ich habe es nach folgender Anleitung gemacht:

FHEM --> MQTT: https://www.loxwiki.eu/display/LOXBERRY/MQTT+Gateway+-+Alle+FHEM-Readings+weitergeben
MQTT --> FHEM: [url]]
https://www.loxwiki.eu/display/LOXBERRY/MQTT+Gateway+-+Alle+FHEM-Readings+weitergeben
MQTT --> FHEM: //https://www.loxwiki.eu/pages/viewpage.action?pageId=70353530

Anbei noch Screenshots von FHEM.

Wisst ihr wo mein Fehler liegt?

Danke schon mal für den Support.

VG Philipp

rudolfkoenig

Ich kann zwar nicht direkt helfen, ich moechte aber Wissen, warum Du fuer diese Verbindung das MQTT FHEM Modul verwendest?
Z.Bsp. Empfehlung einer Webseite, naheliegende Benennung des Moduls, etc.

Hintergrund der Frage ist, dass die neuere MQTT2 Modulfamilie eine fuer Anfaenger einfachere Anbindung bietet.
Es muss aber Gruende geben, warum man trotzdem zum alten Modul greift.

pade84

#2
Das wurde so im Loxforum (https://www.loxwiki.eu/display/LOX/Velux+KLF200+einbinden) so empfohlen. Der MQTT-Broker läuft nicht unter FHEM, sondern auf einem Raspberry Pi. Also FHEM soll nur die Werte vom KLF200 Modul an MQTT übertragen (funktioniert) bzw. vom MQTT (extern) empfangen und ausführen.

Beta-User

#3
Grusel, da wird im Mai 2021 immer noch das "pauschale notify" beworben...

Loxone hatten wir schon ein paar Mal, _ein möglicher_ Einstieg in eine sichere und aktuelle Lösung ist vielleicht https://forum.fhem.de/index.php/topic,109192.msg1095845.html#msg1095845
Edit: oder vielleicht auch die Zusammenstellung hier: https://forum.fhem.de/index.php/topic,117987.msg1124158.html#msg1124158
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

pade84

Hallo zusammen,

jetzt muss ich meinen alten Tread neu starten, da meine SD-Karte von Raspberry Pi defekt ist und ich leider keine Sicherung mehr hatte.

Ich habe den Loxberry neu aufgesetzt, MQTT eingerichtet (funktioniert, da andere Daten über den MQTT-Broker vom Loxberry Daten an den Miniserver schicken) und FHEM eingerichtet. Mit der FHEM habe ich Zugriff und kann auch die Velux-Dachfenster über FHEM --> Velux KLF200 steuern. Nur funktioniert das leider nicht aus Loxone heraus.

Meine Vermutung ist, dass die MQTT-Befehle innerhalb FHEM nicht an das KLF200 Modul weitergeschickt werden (mqttGeneric wird auch mit ??? angezeigt). Ich weiß, dass man es über MQTT nicht machen sollte und stattdessen MQTT2 nutzen sollte. Allerdings habe ich mich bisher mit der Thematik nicht auseinander gesetzt und würde es gerne - aus Zeitgründen - einfach nur zum laufen bekommen wollen. Anbei ein paar Screenshots.

Kann mir jemand helfen wie ich die Nachrichten an Velux/KLF200 weitergeroutet bekomme?

Danke & Grüße

Philipp

Beta-User

#5
Zitat von: pade84 am 13 April 2025, 13:30:25Anbei ein paar Screenshots.
Verwende bitte "copy for forum" oder RAW-Definitionen, dann kann man einfacher Verbesserungsvorschläge machen.

Zitat von: pade84 am 13 April 2025, 13:30:25Ich weiß, dass man es über MQTT nicht machen sollte und stattdessen MQTT2 nutzen sollte.
Wenn du als IODev "MQTT" ans Laufen gebracht hast, ist das schon ok. Die Empfehlung wäre trotzdem, MQTT2_CLIENT zu verwenden (und "clientOrder" und "subscriptions" entsprechend anzupassen), dann brauchst du dich künftig nicht mehr um externe Perl-Module zu kümmern ;) .

MQTT_GENERIC_BRIDGE ist imo trotzdem das richtige Tool für dein Anliegen, aber - neben einem generellen Verständnisthema - gibt es im Detail "room for improvement".

Zitat von: pade84 am 13 April 2025, 13:30:25Meine Vermutung ist, dass die MQTT-Befehle innerhalb FHEM nicht an das KLF200 Modul weitergeschickt werden
Woran meinst du zu erkennen, dass überhaupt MQTT-Befehle an FHEM gesendet worden sein sollen? incoming-count steht auf "0" ;) .

Damit FHEM (bzw. das MQTT-Modul) sich bei deinem mosquitto subscribed, mußt du an den einzelnen Rollladen-Devices auch "mqttSubscribe" setzen ;) .

Vorher würde ich aber die globalen Defaults im MGB-Device bereinigen, es gibt dazu einen "reduzierten" Vorschlag als attrTemplate für die MGB. Bitte anschauen und ggf. anwenden. (Lesetipp dazu: https://wiki.fhem.de/wiki/MQTT_GENERIC_BRIDGE)

Dann raw-Definitionen für die MGB und eines der Rollladen-Devices.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

pade84

Hallo Beta_User,

danke für deine Nachricht. Leider stehe ich immer noch etwas auf dem Schlauch:

ZitatWoran meinst du zu erkennen, dass überhaupt MQTT-Befehle an FHEM gesendet worden sein sollen? incoming-count steht auf "0" ;) .
Valider Punkt ;-)

ZitatDamit FHEM (bzw. das MQTT-Modul) sich bei deinem mosquitto subscribed, mußt du an den einzelnen Rollladen-Devices auch "mqttSubscribe" setzen ;) .
Ich habe das mal für das "Velux_12" gemacht und "mqttPublish" und "mqttSubscribe" für "lb_mosquitto" hinzugefügt (s. Bild). Passt das so?

ZitatVorher würde ich aber die globalen Defaults im MGB-Device bereinigen, es gibt dazu einen "reduzierten" Vorschlag als attrTemplate für die MGB. Bitte anschauen und ggf. anwenden. (Lesetipp dazu: https://wiki.fhem.de/wiki/MQTT_GENERIC_BRIDGE)
Ich habe "mqttGeneric" das "attrTemplate" auf "base_settings_to_MQTT_GENERIC_BRIDGE" gesetzt.

Beta-User

Zitat von: pade84 am 24 April 2025, 12:12:39Ich habe das mal für das "Velux_12" gemacht und "mqttPublish" und "mqttSubscribe" für "lb_mosquitto" hinzugefügt (s. Bild). Passt das so?
Nope.

Vielleicht schaust du dir mal das mgb-attrTemplate für cul_hm-Rolläden an. Das passt wohl nicht ganz, aber dann wird die Richtung vielleicht klarer.

Screenshots sind übrigens immer noch nicht erwünscht....
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Guybrush

mit den screenshots kann man nicht viel anfangen...

aber fehlt da nicht noch eine verknüpfung zum auswerten der mqtt queue für deine velux steuerung?ich hab sowas ähnliches für knx in verbindung mit velux klf200. und auch bei mqtt werden ja nur im  mqtt device irgendwelche states aktualisiert. die müsstest du dann noch mit einem notify verarbeiten und ans klf200 weiterleiten.

Beta-User

Zitat von: Guybrush am 26 April 2025, 00:30:48aber fehlt da nicht noch eine verknüpfung zum auswerten der mqtt queue für deine velux steuerung?ich hab sowas ähnliches für knx in verbindung mit velux klf200. und auch bei mqtt werden ja nur im  mqtt device irgendwelche states aktualisiert. die müsstest du dann noch mit einem notify verarbeiten und ans klf200 weiterleiten.
MQTT_GENERIC_BRIDGE kann diesen Job - genau dafür wurde es (auch) entwickelt  ;) .

Aber man muss es auch entsprechend konfigurieren. Daran hapert es hier noch...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors