Daten aus openhab über MQTT einem dritten System zur Verfügung stellen

[evolution100]

Hallo zusammen,

ich bin im Besitz einer Westaflex Lüftungsanlage, welche über ModBUS gesteuert werden kann.
Mit der großartigen Hilfe von PeterA hier aus dem Forum hab ich es in kürzester Zeit geschafft, openHAB 2.5 (da Peter die selbe Version hat) auf einem Raspi zu installieren, den ModBus und das HAT einzurichten und es mit der Anlage über PaperUI abzufragen bzw. zu steuern.

Da ich selbst im Haus aber als Visu und Logik die Software Edomi habe, müsste ich nun die Daten an Edomi weitergeben. Für Edomi selbst gibts z.B. einen Subscribe Client.

Da ich aber blutiger Anfänger mit openHAB und auch mit MQTT bin, bräuchte ich da Hilfe...
Ich hab leider nicht wirklich eine Idee, wie ich die Daten zur Verfügung stelle.

Testhalber habe ich auf dem Raspi mosquitto wie folgt installiert

apt-get update
apt-get dist-upgrade
apt-get install -y mosquitto mosquitto-clients
systemctl enable mosquitto.service

danach konnte ich die Kommunikation auch auf dem Raspi testen

mosquitto -d
mosquitto_sub -d -t test
mosquitto_pub -d -t test -m "Hello world!"
und in einer anderen Konsole bekomme ich mit
mosquitto_sub -d -t test
Nachrichten geliefert.

Wo ich nun aber total überfordert bin ist es, mit diesem Wissen mosquitto mit openHAB zu verbinden?
Vielleicht kann hier jemand einem Anfänger weiterhelfen?

Vielen dank schon mal
Markus

[udo1toni]

Wie hast Du openHAB denn installiert? Ich empfehle dafür immer das openHABian Image, weil es die Option mitbringt, sich um weitere Details (z.B. die Einrichtung von mosquitto) zu kümmern. Aber Du hast ja nun mosquitto schon laufen also ist das eher unwichtig.

Die Einbindung auf openHAB-Seite ist denkbar einfach.

1. Das mqtt2 Binding installieren. Gewöhnlich ist auch nur dieses in der Liste der installierbaren Bindings sichtbar...
   Bitte nicht die mqtt Action installieren, die gehört zum mqtt1 Binding, das solltest Du mit Nichtachtung strafen.
2. Nachdem das Binding installiert ist, legst Du einen MQTT Broker an. Bitte nicht mit dem System MQTT Broker verwechseln, den keinesfalls anlegen.
   Das geht mit Paper UI -> Configuration -> Things -> + -> MQTT Binding -> Add manually -> MQTT Broker.
   Du vergibst einen Namen, z.B. "Mosquitto Broker", eine ThingID, z.B. mosquitto und trägst als IP entweder localhost, 127.0.0.1 oder die IP des Raspberry ein. Solltest Du Zugangsdaten hinterlegt haben, kannst Du mit show more weitere Optionen einblenden. Dort kannst Du auch eine feste ClientID konfigurieren (ansonsten würfelt openHAB beim Neustart eine aus, das ist aber vor allem für Debugging wichtig)
3. Danach legst Du ein Generic MQTT Thing an (auf dem gleichen Weg, wie Du schon die Broker Verbindung erzeugt hast).
   Du vergibst wieder einen sinnvollen Namen, z.B. "MQTT Westaflex", eine ThingID, z.B. westaflex und wählst noch die eben angelegte Bridge aus.
4. Du wählst aus der Liste der Things das eben angelegte Thing aus und legst jetzt Channel an, jede Eigenschaft, die Du publizieren willst, bekommt einen eigenen Channel mit passendem Typ (number, switch, string...). Wenn Du von edomi aus steuernd eingreifen willst, legst Du auch für diese Funktionen eigene Channel an oder kombinierst einen Channel für bidirektionale Kommunikation.

Wichtig ist, dass Du die Topics sinnvoll wählst. Üblich ist eine Verzeichnisstruktur. In diesem Fall könntest Du als root z.B. westaflex nutzen, darunter dann für jeden Channel ein eigenes topic und innerhalb des Topic für Steuerfunktionen noch das Zusatzwort set Das ergäbe dann z.B.

westaflex/solltemperatur und
westaflex/solltemperatur/set als Topics für die Solltemperatur.

Nun kommt der große Knackpunkt, an den Du denken musst. Es gibt in jedem mqtt Channel in openHAB das stateTopic und das commandTopic. es steht Dir frei eines oder beide zu verwenden. Wichtig ist nur, zu verstehen, dass das stateTopic eingehende Nachrichten liefert, während das commandTopic für ausgehende Nachrichten verwendet wird. Das bedeutet, openHAB muss alle Daten, die zu edomi sollen, als command an den Channel senden, während Befehle von edomi nach openHAB als Status auf dem Item ankommen. Die Bezeichnung der Parameter scheint also genau verkehrt herum, das liegt aber daran, dass openHAB gewöhnlich selbst die Rolle der UI übernimmt.

Die Channel koppelst Du mit passenden Items. Je nachdem, wie Du die Westaflex genau angebunden hast, kann es ausreichen, die Channel direkt mit den Items der Westaflex zu koppeln und das Profile "follow" zu setzen, es kann aber auch notwendig sein, dafür eine Rule zu schreiben,

[evolution100]

Hallo udo1toni,

vielen lieben Dank für die genaue Anleitung.
Ich mach mich in nächster Zeit dann mal drüber und berichte.

Vielen dank schon mal

Markus

[udo1toni]

Immer gerne

[evolution100]

Ich bin nun mal genau nach der Anleitung vorgegangen.
Nur zur Sicherheit.. den unter Punkt 4 angelegten Channel lege ich vom Generic MQTT Thing aus an?

Und dann... wie koppel ich die Items mit dem Channel? Ich find da weder im angelegtem MQTT Channel noch in den ModBUS Data Items was.
Wo würde man das Profile "follow" setzen?

NACHTRAG:
Ich hab vergessen auf den angelegten Channel zu klicken und hier den Link anzulegen
Das sollte es gewesen sein. Dann versuch ich weiter mein Glück

[evolution100]

So nun hab ich die Verbindung... aber noch ein Problem..

Kurz zusammengefasst was ich gemacht hab.

Alles wie udo1toni beschrieben angelegt.
Den Channel "SollTemperatur_MQTT" hab ich wie folgt konfiguriert

State Topic => westaflex/solltemperatur/set
Command Topic => westaflex/solltemperatur

Rest auf Standard gelassen.

Als Linked item hab ich auf das ModBus Item SollTemp_ModBUS gelinkt. Beides ist vom Type Number

Wenn ich nun via MQTTlens "westaflex/solltemperatur" abonniere und dann in openHAB unter Controll den SollTemp_ModBUS einen anderen Wert gebe, dann sehe ich, dass im MQTTlens der Wert kommt.

Wenn ich nun im MQTTlens einen Wert auf das Topic "westaflex/solltemperatur/set" publishe, dann sehe ich kurz im openHAB und im Log von openHAB die Änderung, die dann aber umgehend wieder zurückgenommen wird

2021-03-03 09:52:57.307 [vent.ItemStateChangedEvent] - SollTemp_ModBUS changed from 28 to 29
2021-03-03 09:53:02.098 [vent.ItemStateChangedEvent] - SollTemp_ModBUS changed from 29 to 28

Mach ich da was falsch?

[udo1toni]

Du musst noch das Profile "follow" setzen (im Item SollTemp_ModBUS)

[evolution100]

Muss ich dann das bestehende Standard Profile löschen und ein neues mit follow auswählen?
Wenn ich ein zusätzliches hinzufüge, dann hab ich SollTemp_ModBUS nicht mehr zur Auswahl.

Ich habe mal ein zweiten Channel im Thing MQTT Westaflex angelegt. FanSpeed_MQTT. Das Profile hab ich auf follow gesetzt.
State Topic => westaflex/FanSpeedSetting/set
Command Topic => westaflex/FanSpeedSetting

Wenn ich im MQTTlens das Topic westaflex/FanSpeedSetting subscribe, bekomme ich alle 10 Sec ein Update?!
Wenn ich dann über westaflex/FanSpeedSetting/set den Wert auf 1 setze.. kommt diese Meldung im Log

2021-03-03 11:45:06.582 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler GenericMQTTThingHandler of thing mqtt:topic:72b155fb tried updating channel westaflex although the handler was already disposed.

[udo1toni]

Das Update müsste vom Modbus kommen, openHAB sendet ja nicht selbst. Mit der Warnmeldung kann ich irgendwie nichts anfangen...

[evolution100]

Ich hab nun mein System nochmal zurück gesetzt. Also auch ohne Mosquitto etc., danach nochmal alles genau nach Beschreibung gemacht. Die Warnmeldung ist weg aber ich kann per MQTT keinen Aktion auslösen.

Wenn ich per Putty am openHAB dieses absetze

mosquitto_pub -d -t westaflex/FanSpeedSetting/set -m "2"

erscheint im openHAB log
2021-03-04 07:53:46.696 [vent.ItemStateChangedEvent] - FanSpeedSetting_ValueAsNumber changed from 3 to 2
2021-03-04 07:53:48.974 [vent.ItemStateChangedEvent] - FanSpeedSetting_ValueAsNumber changed from 2 to 3

mehr kommt da nicht. Das gleiche, wenn ich vom Windows Rechner aus über MQTTlens ein westaflex/FanSpeedSetting/set mit der Message 2 sende.

Wenn ich über Control den Wert vom MQTT FanSpeed verändere, dann nimmt er es. Vermutlich, da das ja nicht wirklich über MQTT läuft.

Im Log sieht es aber auch etwas anders aus
2021-03-04 08:16:11.060 [ome.event.ItemCommandEvent] - Item 'FanSpeedSetting_ValueAsNumber' received command 2
2021-03-04 08:16:11.380 [nt.ItemStatePredictedEvent] - FanSpeedSetting_ValueAsNumber predicted to become 2
2021-03-04 08:16:11.878 [vent.ItemStateChangedEvent] - FanSpeedSetting_ValueAsNumber changed from 3 to 2

Damit stellt er die Drehzahl runter.

Nochmal zur Kontrolle, in der Config des FanSpeedSetting channels habe ich als

MQTT State Topic
westaflex/FanSpeedSetting/set

und
MQTT Command Topic
westaflex/FanSpeedSetting

gesetzt.

Hast du noch eine Idee bzw. siehst vielleicht meinen Fehler?

vielen Dank
Markus