LoxBerry MQTT

**74homer** · 20.01.2021, 08:56

Hallo Christian,
ich habe deine Wiki-Artikel zum Plugin wiederholt gelesen.
Zusätzlich habe ich noch Wiki-Artikel zu Aktoren gelesen, die über MQTT mit Loxone verbunden sind, z.B. hier und hier.
Aus meiner Sicht sind die Infos in den Wiki-Artikeln der Aktoren aber verwirrend.
Beispiel:
Warum soll ich bei einem Aktor das Logging aktivieren und auf den Miniserver konfigurieren (siehe MQTT und UDP Einstellungen, Bild 2), wenn ich danach noch MQTT einrichte?

Mein Verständnis deines Plugins ist:
1. Der Aktor sendet seine Daten an den MQTT Broker
2. Die Daten werden bei REST API (empfohlen) an Loxone Miniserver gesendet (= push) oder bei UDP vom Loxone Miniserver abgeholt (= pull)

Der Aktor (in meinem Fall mit Tasmota) kann sich mit dem MQTT verbinden und sendet auch (fleißig) seine Daten.

Für die Steuerung des Aktors muss ich dann Daten von Loxone Miniserver an MQTT Broker senden.
In den Wiki-Artikeln der Aktoren wird aber ein Virtueller Ausgang so eingerichtet, dass die Daten an die IP des Aktors gesendet werden.
Ist das korrekt?
Wenn ja, warum soll dann gemäß deinen Wiki-Artikeln zum Plugin eine UDP-Verbindung vom Miniserver zum MQTT-Gateway/Broker eingerichtet werden?

Gruß
Thomas

**Christian Fenzl** · 20.01.2021, 09:47

https://www.loxwiki.eu/pages/viewpag...ageId=39356011
Dieser Artikel ist auch riesengroß im Hauptartikel des Gateways verlinkt.
Und ein Video gibt’s auch 😉

**Christian Fenzl** · 20.01.2021, 09:57

Beste Konfiguration:

MQTT Gateway an Miniserver -> http (udp deaktivieren)
Miniserver an MQTT Gateway -> udp

Erklärung MQTT -> Miniserver per http:

Übertragung an den Miniserver per http adressiert virtuelle Eingänge DIREKT (im Gegensatz zu UDP, wo Befehlserkennungen jedesmal Suchen am Miniserver auslösen.
Außerdem ist die Einrichtung virtueller Eingänge am Miniserver einfacher als UDP-Eingangsbefehle mit Befehlserkennung
Zudem ist die Übertragung von Texten nur per HTTP möglich ("Virtueller Texteingang")

Erklärung Miniserver -> MQTT per udp:

UDP ist stateless und hat keinen Protokoll-Overhead, daher ist die Menge der Daten viel geringer
Im Gegensatz dazu muss sich bei HTTP der Miniserver am LoxBerry authentifizieren, am LoxBerry wird bei jeder Übertragung eine Apache Session gestartet, die die Daten ans Gateway weitergibt.
Überdies ist die HTTP-Schnittstelle des MQTT Gateways nur ein "Wrapper" - jede eingehende HTTP-Verbindung wird intern am LoxBerry dann sowieso wieder per UDP an das Gateway übermittelt.

**74homer** · 20.01.2021, 10:22

Ich beziehe mich auf diese Wiki-Artikel der Aktoren:
https://www.loxwiki.eu/display/LOX/S...P1+mit+Tasmota
https://www.loxwiki.eu/display/LOX/E...Tasmota+Sonoff

Ich habe gestern das UDP-Monitoring aktiviert und konnte diese Einträge loggen:

Auf Basis dieser Daten habe ich dann einen Virtuellen Ausgang Befehl definiert mit diesem Befehl:
push tasmota/BW-SHP2/cmnd/Power on
push tasmota/BW-SHP2/cmnd/Power off

Der Syntax dieses Befehls habe ich aus dem WebUI von Tasmota entnommen:

Allerdings schaltet der Aktor nicht ein/aus über Loxone.

Was ist der erste Schritt zur Fehleranalyse und -behebung?

Gruß
Thomas

**AlexAn** · 20.01.2021, 12:12

Man möge mir verzeihen falls ich die Tasmota Artikel nicht so eindeutig geschrieben habe...

Tasmota kannst per:
UDP
http
oder
MQTT
einbinden

Such dir das passende für dich aus und den Rest vergiss!

Zum Problem:

Topic einfach halten und schauen was raus geht im Loxone Monitor - eventuell mal den - entfernen
push würde ich auch mal weglassen also nur: tasmota/BW-SHP2/cmnd/Power on

MQTT Log

**74homer** · 20.01.2021, 16:24

Im Logfile /plugins/mqttgateway/mqttgateway.log finde ich diese Einträge:

Wenn ich den den Virtueller Ausgangs Befehl ändere zu tasmota/BW-SHP2/cmnd/Power on, dann steht im Log:
16:16:10.324 INFO: MQTT received: tasmota/BW-SHP2/POWER: ON
16:16:10.325 tasmota/BW-SHP2/POWER is cached
16:16:10.326 tasmota/# matches tasmota/BW-SHP2/POWER, send to MS 1
16:16:10.326 HTTP: Preparing input tasmota_BW-SHP2_POWER (using cache): 1
16:16:31.601 OK: UDP IN: loxmini.lan (172.16.20.4): tasmota/BW-SHP2/cmnd/Power on
16:16:31.602 Publishing: 'tasmota/BW-SHP2/cmnd/Power'='on'
16:16:31.653 INFO: MQTT received: tasmota/BW-SHP2/cmnd/Power: on
16:16:31.654 tasmota/BW-SHP2/cmnd/Power is cached
16:16:31.654 tasmota/# matches tasmota/BW-SHP2/cmnd/Power, send to MS 1
16:16:31.655 HTTP: Preparing input tasmota_BW-SHP2_cmnd_Power (using cache): 1
16:16:31.821 INFO: MQTT received: tasmota/BW-SHP2/RESULT: {"POWER":"ON"}
16:16:31.822 Expanding json message
16:16:31.822 tasmota/BW-SHP2/RESULT/POWER is cached
16:16:31.823 tasmota/# matches tasmota/BW-SHP2/RESULT, send to MS 1
16:16:31.823 HTTP: Preparing input tasmota_BW-SHP2_RESULT_POWER (using cache): 1
16:16:31.825 INFO: MQTT received: tasmota/BW-SHP2/POWER: ON
16:16:31.826 tasmota/BW-SHP2/POWER is cached
16:16:31.826 tasmota/# matches tasmota/BW-SHP2/POWER, send to MS 1
16:16:31.826 HTTP: Preparing input tasmota_BW-SHP2_POWER (using cache): 1

Der Aktor kann jetzt mit Loxone gesteuert werden.

**svethi** · 20.01.2021, 17:33

Und was willst Du uns jetzt damit sagen?

**74homer** · 21.01.2021, 10:54

Hallo Christian,
ich habe eine Frage im Zusammenhang mit MQTT Gateway - Alle FHEM-Readings weitergeben.
Hast du auch das FHEM Modul MQTT2_CLIENT an Stelle von MQTT erfolgreich mit dem Loxberry MQTT Broker verbinden können?
Dieses Modul ist hier im FHEM Wiki dokumentiert.

Ich habe dieses Modul in FHEM so angelegt:
define lb_mqtt MQTT2_CLIENT <loxberry IP>:1883 loxberry <deinMQTTPasswort>
erhalte aber einen Authorisierungs-Fehler.

Mit dem FHEM Modul MQTT gibt es dagegen keine Probleme.

Interessant ist in diesem Kontext auch, dass das <deinMQTTPPasswort> im Klartext steht in der fhem.cfg, Abschnitt zum Device MQTT2_CLIENT.

Gruß
Thomas

**chriz77** · 23.01.2021, 21:24

Hallo,

ich habe Probleme mit MQTT und meinen Shellies. Die Statusinformationen kommen einfach nicht an. Es hat 1-2 mal funktioniert und seitdem kommt nichts mehr an. Ich habe schon die Shellies zurückgesetzt und MQTT auf dem Loxberry neu installiert. Leider alles ohne Erfolg. Wenn ich die Shellies mit einem anderen MQTT-Server (z.B. ioBroker) verbinde funktioniert alles einwandfrei. Also muss es irgendwie am Loxberry liegen. Ich verwende ich neueste Loxberry Version unter Proxmox, das ich über das Image aus dem Wiki installiert habe. Subcription: shellies/#

Irgendwelche Ideen, an was es liegen könnte?

Danke und viele Grüße

Chris

**guenther.wimmer@kt-net.at** · 27.01.2021, 20:28

Hallo Zusammen!

Ich versuche gerade zwei Werte gleichzeitig zur Loxone zu schicken und via Statusbaustein auszuwerten.
rcvr_192.168.20.131_POST_type hängt auf AI1
rcvr_192.168.20.131_POST_username auf AI2
Als Statustext habe ich dann "<v2> macht etwas".
Manchmal bekomme ich "Julia macht etwas" oder aber "0 macht etwas"

Gib es eine Möglichkeit einzustellen wie lange ein wert ausgegeben wird, bis er wieder auf 0 zurück gesetzt wird?
Oder gibt es MQTT seitig die Möglichkeit einen Wert verzögert (0,1s) zu senden?

**Christian Fenzl** · 27.01.2021, 21:20

Servus Günther!
I'm Statusbaustein reicht ein
I1 != 0 UND I2 != 0 -> <v2> macht <v1>
nicht aus?
Ist das Gateway dafür zu schnell?
Ginge es, nur Zb den type auf Reset-After-Send zu setzen, und den Usernamen stehen zu lassen?
Wenn da dann der User switched, müssten wir uns nur darum kümmern, den type zu verzögern.

**guenther.wimmer@kt-net.at** · 27.01.2021, 22:54

Vom Gefühl her ist einmal der Typ dann der User zu schnell bzw. zu langsam.
Ich hab beide VTIs an einen eigenen Tracker angeschlossen.
Um 22:34:02 hat der "Typ" ausgelöst, aber der User ist erst um 22:34:03 aufgeschlagen.
Wenn ich den User stehen lassen, kommt der neue User zu spät.
Aber ich hab es auch schon gehabt das der User schon wieder weg war und der Typ dann erst gekommen ist.

zum besseren Verständnis, ich versuche NodeRed mit MQTT zu tauschen:
Grandstream GDS3710 IP-Video-Türstation - loxwiki - loxwiki -> Event Notification via Node-RED

Angehängte Dateien

**Christian Fenzl** · 28.01.2021, 06:57

Ich hab jetzt nochmal den Code durchgesehen, vom Übertragungsaspekt/Timing her läuft es so ab:
Der rcvr gibt alle Daten gemeinsam ans Gateway weiter, hier gibt es also kein Delay einzelner Datensätze.
Das Gateway gibt die Daten auch als einen Datensatz an MQTT weiter, also auch hier keine Verzögerung zwischen Datensätzen.
Dann empfängt das Gateway die Daten vom Broker wieder als einen gemeinsamen Datensatz.
Nun erfolgt das Zerlegen der Daten. Ab diesem Zeitpunkt ist die Reihenfolge nicht mehr einheitlich.
Jetzt erfolgt das Senden der Daten an den MS. Die Reihenfolge ist nicht definiert, aber jeder Datensatz wird gesendet.
Erst wenn sicher alle Datensätze gesendet sind, erfolgt ein zweiter Durchgang, wo alle Reset-After-Send-Daten wieder auf 0 gesetzt werden, wo die Reihenfolge auch unbestimmt ist.

Vom zeitlichen Aspekt her gibt es dadurch jedenfalls einen Zustand, wo alle Daten gemeinsam gesetzt sind, bevor sie durch Reset-After-Send wieder zurückgesetzt werden.

Kannst du mal zeigen, wie dein Statusbaustein aussieht?
Den Typ, der ja eine Zahl ist, würde ich als VI statt VTI anlegen.

**guenther.wimmer@kt-net.at** · 28.01.2021, 08:51

Ursprünglich hatte ich denn TYP als VI und Username als VTI.
Ich habe das dann bei beiden auf VTI Umgebaut, da ich vermutet habe, dass die Verarbeitung von VTI / VI ell. den unterschied macht.

Theoretisch könnte ich die beiden Werte auf einmal an MQTT übergeben, also "Guenther 100" oder "Julia 301" nur kann ich das dann im Statusbaustein nicht mehr auswerten, oder?
Mit dem Umlaut "ü" hatte ich auch so meine Probleme! ;-)

Angehängte Dateien

**Christian Fenzl** · 28.01.2021, 10:09

Kannst du im Statusbaustein mal in allen Zeilen (außer der letzten) überall dazu nehmen
AI2 ! = 0

und prüfen, ob alles durchkommt, und auch keine False-Positives.

LoxBerry MQTT

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar