openhabforum.de

KellerK1nd hat geschrieben: ↑11. Sep 2020 18:08 Darum bin ich weg vom Shell Binding und hin zum MQTT. Hatte auch diesen Fehler.

Das scheint mir als Anfänger sehr umfangreich, oder nicht?

Innocent hat geschrieben: ↑11. Sep 2020 06:58 ...
Habe jetzt noch das problem, daß der angezeigte Status des relays nicht stimmt.
Schalte ich die Dose in der Shelly App wird das nicht in basic ui bzw der App angezeigt.

Nur mal für mich zum Verständnis, warum schaltest Du die Dose in der Shelly App und nicht über Openhab?

Um die Funktion und den Status zu überprüfen. In der App funktioniert das zuverlässig. In Openhab nicht, traue mir da selbst noch nicht.

Innocent hat geschrieben:

KellerK1nd hat geschrieben: ↑11. Sep 2020 18:08 Darum bin ich weg vom Shell Binding und hin zum MQTT. Hatte auch diesen Fehler.

Das scheint mir als Anfänger sehr umfangreich, oder nicht? [emoji848]

Man arbeitet sich da rein. Dafür gibt es hier im Forum auch immer gut Hilfe. [emoji6]

Innocent hat geschrieben: ↑11. Sep 2020 19:49

KellerK1nd hat geschrieben: ↑11. Sep 2020 18:08 Darum bin ich weg vom Shell Binding und hin zum MQTT. Hatte auch diesen Fehler.

Das scheint mir als Anfänger sehr umfangreich, oder nicht?

Wieso? mqtt ist kein Hexenwerk. Ich finde, dass es im Gegenteil ein sehr gut durchdachtes M2M Protokoll ist, welches gut auch vom Anwender gelesen und sogar gesendet werden kann. Ob der möglichen Geschwindigkeit von mqtt frage ich mich sogar manchmal, ob es nicht sinnvoll wäre, ein Smarthome um mqtt herum aufzubauen (also mqtt quasi als Ersatz für den openHAB Bus zu verwenden). Allerdings bin ich kein Programmierer und das Projekt wäre durch die schiere Größe zum Scheitern verurteilt (wobei man natürlich openHAB als Wandler nutzen könnte, bis alle benötigten Module mit dem Broker kommunizieren können..)

Du brauchst für mqtt nur einen Broker, z.B. mosquitto ist sehr beliebt, weil kostenlos und leistungsstark. mosquitto kann parallel zu openHAB auf dem Rechner laufen.
In openHAB brauchst Du eine Bridge zum Broker und gewöhnlich für jedes Gerät ein Thing, für jede Eigenschaft einen Channel.
Im Gegensatz zu CoAP ist es extrem leicht, sich in die Kommunikation einzuklinken und live mitzuverfolgen, warum etwas nicht so läuft, wie gewünscht (z.B. mqtt.fx oder mqtt spy), da sowohl Payload als auch Topics im Klartext da stehen. Trotzdem ist sichere Kommunikation möglich sowohl mit ssl als auch mit User/Passwort Absicherung.

udo1toni hat geschrieben: ↑11. Sep 2020 20:36

Innocent hat geschrieben: ↑11. Sep 2020 19:49

KellerK1nd hat geschrieben: ↑11. Sep 2020 18:08 Darum bin ich weg vom Shell Binding und hin zum MQTT. Hatte auch diesen Fehler.

Das scheint mir als Anfänger sehr umfangreich, oder nicht?

Wieso? mqtt ist kein Hexenwerk. Ich finde, dass es im Gegenteil ein sehr gut durchdachtes M2M Protokoll ist, welches gut auch vom Anwender gelesen und sogar gesendet werden kann. Ob der möglichen Geschwindigkeit von mqtt frage ich mich sogar manchmal, ob es nicht sinnvoll wäre, ein Smarthome um mqtt herum aufzubauen (also mqtt quasi als Ersatz für den openHAB Bus zu verwenden). Allerdings bin ich kein Programmierer und das Projekt wäre durch die schiere Größe zum Scheitern verurteilt (wobei man natürlich openHAB als Wandler nutzen könnte, bis alle benötigten Module mit dem Broker kommunizieren können..)

Du brauchst für mqtt nur einen Broker, z.B. mosquitto ist sehr beliebt, weil kostenlos und leistungsstark. mosquitto kann parallel zu openHAB auf dem Rechner laufen.
In openHAB brauchst Du eine Bridge zum Broker und gewöhnlich für jedes Gerät ein Thing, für jede Eigenschaft einen Channel.
Im Gegensatz zu CoAP ist es extrem leicht, sich in die Kommunikation einzuklinken und live mitzuverfolgen, warum etwas nicht so läuft, wie gewünscht (z.B. mqtt.fx oder mqtt spy), da sowohl Payload als auch Topics im Klartext da stehen. Trotzdem ist sichere Kommunikation möglich sowohl mit ssl als auch mit User/Passwort Absicherung.

Welche Literatur kannst empfehlen?
Oder wie da einsteigen?

Uhh... Literatur dazu, keine Ahnung... ich hab mir die wichtigsten Sachen aus dem Internet zusammengesucht...

Es gibt da aber auch nicht viel, was man unbedingt wissen muss:

• Es gibt einen zentralen Server (der Broker, z.B. mosquitto)
• Die Kommunikation läuft default über den Port 1883
• jeder Client sollte einen eigenen Identifier haben, der Client kümmert sich selbst darum, falls man nicht explizit einen definiert
• Die Kommunikation läuft über Topics und den Payload der Topics
• Solange man nicht spezielle Einstellungen vornimmt, läuft die Kommunikation unverschlüsselt und jeder Client darf in jedem Topic lesen und schreiben
• Jeder Client kann Topics publishen (also einen bestimmten Payload auf ein Topic senden) und abonnieren
• hat ein Client ein Topic abonniert, so wird der Broker jedes Publish auf dieses Topic umgehend direkt an den Client senden
• Die Topics sind hierarchisch aufgebaut, man kann sich das wie einen Verzeichnisbaum vorstellen. Die einzelnen Hierarchien sind jeweils mit einem / voneinander getrennt. Groß/Kleinschreibung wird unterschieden, ein Client muss das aber nicht unbedingt berücksichtigen. Ein Topic kann mit einem / beginnen, das ist aber nicht erwünscht.
• Der Payload kann eine beliebig lange Zeichenkette sein. Üblich sind diskrete Werte (Wort oder Zahl) sowie JSON Objekte, man kann aber auch xml nutzen oder ein eigenes Format definieren (wenn man selbst einen Client programmiert natürlich). Der Payload kann auch null sein (im Sinne von: Länge = 0 Bytes).

Ansonsten muss man in der Dokumentation der jeweiligen Clients nachschauen, welche Topics unterstützt werden und was sie bewirken.
Üblicherweise sendet ein Client auch ein besonderes Topic, welches als LastWillAndTestament bezeichnet wird. Viele Clients verwenden hier LWT als letztes Subtopic, dies ist aber nicht festgelegt. Wenn der Broker feststellt, dass er keinen Kontakt zum Client mehr hat, setzt er das LWT auf den zuvor vereinbarten Wert. Der Client sagt also z.B. LWT = offline und sendet anschließend das LWT mit online.
Wenn nun der Kontakt zum Broker verloren geht, setzt der Broker LWT auf offline.

Wenn man die Daten anschauen möchte, so nutzt man dazu einen MQTT Sniffer wie z.B. mqtt.fx oder mqtt spy, welcher sich als Client am Broker anmeldet. Um mit einemSchlag mehrere Toics zu abonnieren, dient die # als Symbol "ab hier egal", also z.B. liefert ein Abo auf tasmota/meinDevice/# alle Topics, welche das Device tasmota/meinDevice publisht, das Topic # liefert jeglichen Datenverkehr, der im Broker landet. Ein + funktioniert ähnlich der #, ist aber auf den Level begrenzt. So liefert ein tasmota/+/LWT dann alle LWT-Topics aller Devices, die unter dem Haupt-Topic tasmota zusammengefasst sind.
Mit einem $SYS/# bekommt man interne Informationen über den Broker selbst.

So, nun bist Du zwar noch kein Experte weißt aber schon im Groben, wie mqtt funktioniert. Es gibt noch verschiedene weitere Funktionen, z.B. retain (der Broker liefert den letzten gesendeten Wert sobald ein Client das Topic abonniert) und q (verschiedene Stufen, wie eine Nachricht versendet wird), aber das brauchst Du für erste Experimente eher nicht.
Wenn Du ein Device hast, welches mit Tasmota geflasht wurde, schau Dir die Dokumentation von MQTT und speziell der Commands an, um zu erkennen, wie einfach und gleichzeitig mächtig mqtt ist.

Viel Input. Danke.

Da musst Du durch das haben andere auch schon leidvoll erfahren müssen... wenn ich mal was zu einem Thema absondere, wird der Text länger

udo1toni hat geschrieben: ↑12. Sep 2020 20:25 wenn ich mal was zu einem Thema absondere, wird der Text länger

...aber immer gut