Unterschiedliche Anzeige bei gleicher Config

Begonnen von Der-Eine, 14 November 2022, 15:20:17

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: Der-Eine am 15 November 2022, 14:02:27
Mir ist das ganze System noch nicht so wirklich klar und ich vermute ganz stark, dass ich da nicht alleine bin.
Du bist damit ganz sicher nicht alleine, es sind immer wieder dieselben Fragen...

Die wichtiste:
Zitat
Auch welche Funktion die Bridge letztendlich hat ist bei mir noch nicht angekommen. Der Client sollte doch direkt mit dem Server kommunizieren können.
Der Client (MQTT2_CLIENT) stellt "nur" die Verbindung zum Server her und gibt die eingehenden Infos dann an passende Client-Module weiter. Im Moment kommen dafür in Frage: MQTT2_DEVICE, MQTT_GENERIC_BRIDGE und RHASSPY.

Abonniert wird dabei grundsätzlich ALLES! Das default-Client-Modul ist MQTT2_DEVICE.

MQTT_GENERIC_BRIDGE hat eine Doppelfunktion:
- es ist einerseits ein Eventhandler, der jedes Event an einem "überwachten" Device (bei passendem Reading) in Topic+payload umwandelt und dann an das IO-Modul weitergibt (also hier an MQTT2_CLIENT), das das dann eben in die große weite Welt pustet;
- es ist andererseits dazu da, alle eingehenden Messages (so sie bei ihm ankommen!*) zu checken, ob daraus Aktionen abzuleiten sind, also: Schaltaktionen auslösen und/oder Reading-Werte setzen.

So, nach diesen einleitenden Worten schaust du dir bitte an, was das attrTemplate "base_settings_to_MQTT_GENERIC_BRIDGE" tut!

Zitat
attr Ba_Fenster userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long structexclude Diese Werte sind wild zusammenkopiert und vermutlich ist 3/4 gar nicht nötig
Die mqtt.*-Attribute werden vom MGB-Modul hinzugefügt und sind (teilweise) funktional nötig!
Zitat
attr Ba_Fenster mqttForward all Hier wird angegeben das alles weitergeleitet wird?
Es gibt eine Attributbeschreibung dazu. Deine Annahme ist jedenfalls falsch, für die Festlegung, was gepublisht werden soll ist ein anderes Attribut zuständig, und das "forward"-Attribut muss man meistens gar nicht setzen.

Zitat
attr Ba_Fenster mqttSubscribe state:stopic={"$base/set"} Sollte ja nur wichtig sein für Steuerbefehle?
Und das base={"fhem/$device"} aus der Bridge wird hier bei den Geräten als Standard gesetzt?
Korrekt, ist für Steuerbefehle, und der Parameter $base kann in den "globalDefaults" bei der MGB gesetzt werden - optimalerweise gleich getrennt in Sende- und Empfangsrichtung!

ZitatOutgoing. Dieser Wert ändert sich aktuell nur beim Betätigen des Rollos. Sonst wird kein Wert übertragen. Ist das richtig so?
MAn. sollte das so sein, dass nur Änderungen zu einem Publish führen, ja.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Der-Eine

Also, ich bin gerade dabei mal alles von vorne aufzubauen und das zeitgleich auch zu verstehen.

Wieso wird mir bei folgender Config der Positionswert 200 in FHEM angezeigt?
define Ku_Fenster SOMFY 000110
setuuid Ku_Fenster 609ef1ff-f33f-369a-dc79-07dd07ca759b5ea3
attr Ku_Fenster IODev sduino
attr Ku_Fenster devStateIcon open:fts_shutter_10 10:fts_shutter_10 20:fts_shutter_20 30:fts_shutter_30 40:fts_shutter_40 50:fts_shutter_50 60:fts_shutter_60 70:fts_shutter_70 80:fts_shutter_80 90:fts_shutter_90 down:fts_shutter_100 closed:fts_shutter_100
attr Ku_Fenster drive-down-time-to-100 12
attr Ku_Fenster drive-down-time-to-close 15
attr Ku_Fenster drive-up-time-to-100 3
attr Ku_Fenster drive-up-time-to-open 16
attr Ku_Fenster eventMap on:down stop:stop off:up
attr Ku_Fenster model somfyshutter
attr Ku_Fenster room Rollladen
attr Ku_Fenster webCmd down:stop:up
attr Ku_Fenster userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long structexcludeattr Ku_Fenster mqttForward all
attr Ku_Fenster mqttForward all
attr Ku_Fenster mqttPublish *:topic={"$base/$device"}



Beta-User

200 hat nichts mit MQTT zu tun, was es bedeutet sollte in der commandref vom somfy-Modul zu finden sein (ganz geschlossen, 100 = Schlitze noch offen).

Zu den zweien hier:
attr Ku_Fenster mqttForward all
attr Ku_Fenster mqttPublish *:topic={"$base/$device"}

Lösche das erste! Es tut nicht das, was du glaubst...

Zum zweiten: Wenn du also immer noch der Ansicht bist, dass du alle Infos weiterschubsen willst, dann solltest du schon dafür sorgen, dass nicht alles im selben Topic landet...

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Der-Eine

Gesagt getan. Vorsicht. Es ist kein Somfy Modul sondern der Rolladen wird mit einem sduino betrieben.

Für mich sieht es so aus als ob 100 aufliegend mit Rillen ist  und 200 komplett zu (hier geht es beim Status auch sehr schnell wie er hoch zählt).

Wenn ich den attr Ku_Fenster mqttPublish *:topic={"$base/$device"} mit $reading erweitere habe ich 3 Werte. 1x state / position /exact. Das sieht soweit gut und ausreichend aus

Beta-User

Es ist ein SOMFY-Type device, das IO-Modul mag ein signalduino sein. Und drei Werte sind immer noch zwei zu viel, mAn...Aber musst du wissen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Der-Eine

Danke nochmal an Beta-User der mir zur Seite stand und immer wieder zum Nachdenken (und verstehen) in die richtige Richtung geschoben hat.

Nun läuft alles wie gewünscht.