Ich versuche mal ein "außer dem Shelly und openHAB ist noch nichts passiert":
- Für mqtt braucht es einen Broker. Wenn man openHAB mittels des openHABian Image auf einem Raspberry betreibt oder alternativ manuell mit openHABian aufgesetzt hat, kann man mosquitto über openhabian-config einfach nachinstallieren.
- Aktuell gibt es immer wieder die Rückmeldung, dass man keinen Kontakt zum Broker bekommt. Um das zu verifizieren, sollte man einen mqtt Sniffer wie z.B. mqtt.fx einsetzen (es gibt aber auch kostenlose Apps für iOS und Android). Damit kann man bequem testen, ob man sich erfolgreich mit dem Broker verbinden kann.
- openHAB muss ebenfalls mit dem Broker Kontakt aufnehmen, über das mqtt Binding.
- mqtt ist aus Sicht von openHAB ein Bussystem. Entsprechend braucht es eine Bridge.
- Für jedes Gerät am Bus braucht es ein Thing.
- Jede Eigenschaft eines Thing, welche gesteuert oder ausgelesen werden soll, muss einen Channel erhalten.
Zu 4.: Einrichtung über Administration -> Einstellungen -> Things -> Add Thing (das weiße Plus in blauem Kreis rechts unten) -> MQTT Binding -> MQTT Broker (nicht System MQTT Broker!) -> uniqueID auf einen sinnvollen wert setzen (z.B. mosquitto) Label kann bleiben oder auch später angepasst werden, nicht so die uniqueID... Broker Hostname ist die IP, über die openHAB erreichbar ist (angenommen, mosquitto läuft auf dem gleichen Rechner) localhost oder 127.0.0.1 ist hier nur 2. Wahl, denn nur über die normale IP ist auch sichergestellt, dass die Kommunikation auch wirklich funktioniert.
Zu 5.: Genauso wie bei der Bridge, nur jetzt statt MQTT Broker ein generic MQTT Thing anlegen. Auch hier gilt: sinnvolle Bezeichnung in uniqueID eintragen! Die uniqueID darf nur aus Buchstaben des englischen Alphabets sowie arabischen Ziffern und dem Unterstrich bestehen [A-Z|a-z|0-9|_] und jedes Zeichen ist exakt einzutragen. Großbuchstaben und Kleinbuchstaben sind unterschiedliche Zeichen! In den Eigenschaften muss natürlich noch die Bridge ausgewählt werden. Show Advanced bringt weitere Optionen.
Man kann ein LWT setzen. LWT heißt "LastWill&Testament" und jedes Gerät, welches über MQTT kommuniziert, kann dem Broker beim Verbindungsaufbau eine Payload mitteilen, die der Broker über das LWT des Geräts in dessen Namen veröffentlicht, falls der Kontakt zum Broker abreißen sollte. Darüber kann man also hervorragend feststellen, ob ein Gerät Online oder Offline ist. Natürlich kann man auch die entsprechende Payload eintragen, welche ausgewertet werden soll.
Nachdem das Thing angelegt ist, kann man es direkt wieder öffnen und Channel hinzufügen. Dabei ist es wichtig, den korrekten Channeltyp zu nutzen, also z.B. On/Off Switch, falls es sich um ein Relais handelt.
Das MQTT State Topic ist die Rückmeldung vom Shelly, dass das Relais geschaltet wurde. Das Topic ist ein anderes, als das, über welches der Schaltbefehl an den Shelly gesendet wird. Der Status ist ebenfalls in JSON eingepackt. Entsprechend brauchen wir JSONPATH zum Auswerten des Status. (muss gesondert installiert werden)
In der Gegenrichtung kommt das Command Topic ins Spiel. Da auch hier JSON verwendet wird, muss die ausgehende Nachricht entsprechend formatiert werden.
Sowohl die ankommende als auch die abgehende Message variiert pro Gerät, da muss man halt selbst schauen, was da hin kommt. Der Punkt ist aber, dass der eigentliche Wert als true und false abgeliefert wird. Entsprechend setzt man diese beiden Werte für den On-Value und den Off-Value ein. Ankommend liefert JSONPATH dann direkt true oder false, was zu ON und OFF wird. Abgehend setzt man in die Payload, welche zum Broker geschickt wird an der Stelle, wo true oder false stehen muss den Platzhalter %s ein.
Der Channel wird nohc mit einem Switch Item verlinkt, welches man anschließend verwenden kann, um das Relais im Shelly ein- und auszuschalten. Umgekehrt muss jeder Schaltvorgang am Shelly fast unmittelbar dazu führen, dass das Item seinen Zustand ändert.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.2.2, LXC), mit openHABian eingerichtet