Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[mickym]

@wolfgangfb im Gegenteil ich bevorzuge immer reines mqtt, da eine zusätzliche Fehlerquelle ausgeschlossen ist und man nicht darauf angewiesen ist, dass die Informationen vom Adapter richtig interpretiert werden..

[BananaJoe]

Ich schließe mich @mickym an. Insbesondere wenn du einen "richtigen" MQTT Broker wie mosquitto oder ähnlich nimmst und den MQTT Adapter von ioBroker im Client-Modus nutzt.

[WolfgangFB]

@bananajoe

Hi

Danke erstmal für die Antworten. Den mosuitto hatte ich ganz vergessen, den habe ich ja eh wegen meiner Wasseruhr installiert. Aber: Nach der Anleitung auf

https://forum.iobroker.net/topic/11087/adapter-wm-bus-kampstrup-multical-21/81?_=1696252315220

ist der mosquitto als Client und der IO-Broker als Broker/Server eingerichtet. Ich bin jetzt nicht so firm darin, was genau der Client und was der Servber macht, aber warum braucht ich da eigenlich 2 Instzanzen, die sich um MQTT kümmern? Ich hatte das bisher so verstanden, dass der mosuitto Client dazu dient, dass der Dienst für die Wasseruhr MQTT Befehle absetzen kann und der IO-Broker dann derjenige ist, der die Pakete empfängt. Wenn jetzt der IO-Broker der Clieent wäre, hätte ich dann noch die gleichenDatenpunkte die ich in Skripten weiterverarbeiten kann?

[mickym]

@wolfgangfb den mosquito betreibst du immer als Broker den Mqtt Adapter als Client. Auf die Datenpunkte hat das keinen Einfluss, da die topics von dem Gerät festgelegt werden, das published.

[Ein ehemaliger Benutzer]

@wolfgangfb sagte in MQTT vs. Adapter:

ist der mosquitto als Client und der IO-Broker als Broker/Server eingerichtet.

Moin,

hier mal eine Einführung, gibt aber sicher noch mehr im WWW -> https://edistechlab.com/mqtt-einfach-erklaert/?v=3a52f3c22ed6

VG
Bernd

[mickym]

@wolfgangfb Ich würde Dir empfehlen den mosquitto als Broker zu verwenden, der ist zuverlässiger und moderner und den mqtt Adapter als Client. (Ohne eine Option anzuhaken)

[berndsolar13]

Ich hänge mich hier mal kurz rein, weil das Thema auch beschäftigt.
Bisher empfange ich meine Werte der Tasmota Geräte über den Sonoff Adapter.

Ich überlege das nun über Mqtt zu machen, da ich die Werte dann auch an anderen Geräten nutzen kann. Also die MQTT Message.

Wenn ich nun umstelle, dann werden doch meine Grafana Influx DB Werte nicht mehr befüllt oder ? Dann werden doch neue angelegt, und meine Monats Verbrauchsgrafiken gehen nicht mehr. Kann man das irgendwie umgehen ? Oder kann ich im MQTT sagen, speichere es einfach in der alten Indemnität ?

[mickym]

@berndsolar13 Nein das geht nicht - aber Du kannst Dich mit Influx beschäftigen und Deine alten Werten neu konsoldieren. Das solltest Du bei längeren Historien eh machen. Du brauchst sicher nicht alle Minuten oder Stunden Werte die ein Jahr oder älter sind.

Das nennt sich im Übrigen: Downsampling

Zum Skripten bin ich aber nicht der Richtige - da ich keine Daten sammle.

[WolfgangFB]

@dp20eic
Hallo

Zu der Einführung von Ediestechlab eine Frage: Warum sollten Topics möglichst kurz sein?

Ich habe jetzt folgendes Problem. Mein ESP meldet den Fenstergriffzustand mit den Werten 0 (geschlossen), 1 (Griff auf) oder 2 (Griff gekippt). Diese Werte sind hart codiert im yaml.
In den MQTT Datenpunkten erscheint auch der richtige Wert, aber nur kurz. Nach ein paar (ca. 5) Sekunden wird aus der 1 eine 100, aus der 2 ein 100 und aus der 0 eine 1. Wie kann sowas zustandekommen?

[Ein ehemaliger Benutzer]

@wolfgangfb sagte in MQTT vs. Adapter:

Zu der Einführung von Ediestechlab eine Frage: Warum sollten Topics möglichst kurz sein?

Moin,

ich muss dazu sagen, dass ich mich auch erst auf dem Weg befinde und mich da noch besser einlesen muss, aber Topics, sind ja schon Daten, die man sendet und je kürzer, desto besser, liegt halt auch an der Zeit aus dem mqtt stammt und da zählte jedes Bit.
Es gibt da wohl auch Limits, was die Messagelänge angeht, kann man aber glaube ich parametrieren.

@wolfgangfb sagte in MQTT vs. Adapter:

ch habe jetzt folgendes Problem. Mein ESP meldet den Fenstergriffzustand mit den Werten 0 (geschlossen), 1 (Griff auf) oder 2 (Griff gekippt). Diese Werte sind hart codiert im yaml.
In den MQTT Datenpunkten erscheint auch der richtige Wert, aber nur kurz. Nach ein paar (ca. 5) Sekunden wird aus der 1 eine 100, aus der 2 ein 100 und aus der 0 eine 1. Wie kann sowas zustandekommen?

Sorry dazu kann ich nichts sagen, zum einen aus keine Erfahrung, zum anderen ohne die Payload zu sehen oder zu wissen, wie die Datenpunkte aussehen, was da alles auf dem Weg vom Sender zum Empfänger dazwischen hängt. Ist das nicht möglich, da musst, Du glaube ich noch mehr Informationen liefern!

VG
Bernd

[WolfgangFB]

@dp20eic

Hallo

Ich bin jetzt dahinter gekommen was da passiert ist, ich habe gesehen, dass der Wert von 100 nicht durch ESPHome sondern durch Shuttercontrol geschrieben worden ist. Dann ist mir aaufgefallen, dass ich bei der Umstellung der Datenpunkte im Shuttercontrol Adapter die Werte für den Fenstergriff und die Rolladenposition vertauscht habe, der Shuttercontrol Adapter hat dann immer wieder den Wert für den Fenstergriff mit der Rolladenposition überschrieben :-(
Jetzt stimmt das ganze wieder.