Unterschiedliche Anzeige bei gleicher Config

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

Vorheriges Thema - Nächstes Thema

Der-Eine

Hi zusammen,
ich sage es gleich vorweg.. meine Config habe ich mir wild zusammen kopiert und ich bin selber verwundert, dass es funktioniert :)
Egal wieviel ich lese, MQTT will nicht in meinen Kopf hinein.

Aktuell habe ich folgendes Problem:
Config: Esszimmer Fenster
define Es_Fenster SOMFY 000011
setuuid Es_Fenster xxyyzz
attr Es_Fenster userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long structexclude
attr Es_Fenster IODev sduino
attr Es_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 Es_Fenster drive-down-time-to-100 13
attr Es_Fenster drive-down-time-to-close 15
attr Es_Fenster drive-up-time-to-100 3
attr Es_Fenster drive-up-time-to-open 16
attr Es_Fenster eventMap on:down stop:stop off:up
attr Es_Fenster model somfyshutter
attr Es_Fenster mqttForward all
attr Es_Fenster mqttSubscribe state:stopic={"$base/set"}
attr Es_Fenster room Rollladen
attr Es_Fenster webCmd down:stop:up


Config: Bad Fenster
define Ba_Fenster SOMFY 000014
setuuid Ba_Fenster xxyyzz
attr Ba_Fenster userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long structexclude
attr Ba_Fenster IODev sduino
attr Ba_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 Ba_Fenster drive-down-time-to-100 13
attr Ba_Fenster drive-down-time-to-close 17
attr Ba_Fenster drive-up-time-to-100 4
attr Ba_Fenster drive-up-time-to-open 18
attr Ba_Fenster eventMap on:down stop:stop off:up
attr Ba_Fenster model somfyshutter
attr Ba_Fenster mqttForward all
attr Ba_Fenster mqttSubscribe state:stopic={"$base/set"}
attr Ba_Fenster room Rollladen
attr Ba_Fenster webCmd down:stop:up


Wenn ich nun per MQTT Explorer schaue welche Werte durchgegeben werden, dann habe ich 2 verschiedene Ansichten. Und das dürfte doch dann nochmal nicht sein oder?

Im Anhang befindet sich noch ein Screenshot wo zu sehen ist, dass ich beim Esszimmer Fenster nur state=open und exact=0 (Was auch beides NICHT stimmt)
Bei Bad Fenster habe ich state=80, position=80 und exact=78 stehen.

Habe ich evtl irgendwas komplett falsch?

Perfekt wäre es, wenn ich möglichst viele Informationen per MQTT weitergeben kann (in diesem Fall dann unter Homeassistant abrufen)


Beta-User

Manöverkritik:
- Was versendet wird, ist aus den RAW-listings nicht zu erkennen; das steht wohl im MQTT_GENERIC_BRIDGE-Device und scheint irgendeine Form von "globalPublish" zu sein. Von dieser Art der Konfiguration halte ich persönlich nichts;
- es fehlen die Reading-Werte in den RAW-Listings. Vermutlich (!) wird halt weitergegeben, was da ist...
- der gedankliche Ansatz, "alles" per MQTT versenden zu wollen, sollte m.E. überdacht werden. Interessant ist doch eigentlich nur der Öffnungsgrad, oder? (Ganz egal, ob man das an der MGB definiert oder am Device).
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

Hey,
vielen Dank für die schnelle Antwort.

define mqttGeneric MQTT_GENERIC_BRIDGE
setuuid mqttGeneric xxyyzz
attr mqttGeneric IODev ha_MQTT2
attr mqttGeneric globalDefaults sub:qos=2 pub:qos=2 retain=2 base={"fhem/$device"}
attr mqttGeneric icon mqtt_bridge_2
attr mqttGeneric room MQTT,Rollladen
attr mqttGeneric stateFormat in: incoming-count out: outgoing-count devices: device-count
attr mqttGeneric verbose 0


reicht das hier? An sich sollte der Status sowie der Öffnungsgrad schon ausreichen.
Wie würdest du das in meinem Fall lösen?

Beta-User

#3
Hmm, also allgemein:
- die qos-Einstellungen braucht man oder auch nicht;
- "retain" würde ich auch mit Vorsicht genießen (ist aber in Senderichtung hier nicht dramatisch)
- base würde ich in Sende- und Empfangsrichtung getrennt setzen und dann gleich auch ignoreRegexp am IO passend konfigurieren (siehe meine Anmerkungen zu attrTemplate für MGB, bitte selbst suchen).

Konkreter:
- Es gibt offenbar gar keine globalPublish-Einstellung => wenn da was passiert, dann wohl nur wegen des "mqttForward all" an beiden Devices.

Im Ergebnis scheinst du nur zu sehen, was du selbst gepublisht hast... Kein Wunder, dass es verschieden ist ;) .

Nachtrag: Wenn du die Reading-Werte immer wegläßt ist es auch schwieriger für mich. Z.B. wäre es interessant, wie viele publishes denn die MGB vorgenommen hat... (outgoing-count!)
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

Puh.
- Also kann ich qos und retain dann einfach weg lassen?
- base muss ich mich einlesen (da herrscht grad wirklich nur Bahnhof)

- Das Ergebnis verstehe ich trotzdem nicht. Wie eingangs gesagt.. der Groschen wie das ganze Funktioniert ist einfach noch nicht gefallen.

- Nachtrag ich habe nix weg gelassen. Unter FHEM habe ich beim In/Outgoing-Count beides mal 0 stehen. (hatte vor ca 30 Min neu gestartet)

Beta-User

Zitat von: Der-Eine am 14 November 2022, 16:03:46
Puh.
- Also kann ich qos und retain dann einfach weg lassen?
- base muss ich mich einlesen (da herrscht grad wirklich nur Bahnhof)
Siehe dazu https://forum.fhem.de/index.php/topic,117987.0.html. Da sind auch im ersten Beitrag noch ein paar interessante Threads verlinkt.

Zitat
- Das Ergebnis verstehe ich trotzdem nicht. Wie eingangs gesagt.. der Groschen wie das ganze Funktioniert ist einfach noch nicht gefallen.

- Nachtrag ich habe nix weg gelassen. Unter FHEM habe ich beim In/Outgoing-Count beides mal 0 stehen. (hatte vor ca 30 Min neu gestartet)
Ad counts: Wenn das weiter so ist, obwohl du den/die betr. Rollläden von FHEM aus schaltest, hast du den Beweis, dass was in deiner publish-Konfiguration nicht stimmt.

Das Ergebnis, das du im MQTT-Explorer siehst, kann "irgendwoher" kommen und ist ggf. einfach ein uralter Stand, der daher rührt, dass mal was mit "retain"-Flag gesendet wurde, von wem auch immer. Ich würde empfehlen dafür zu sorgen, dass der MQTT-Server diese Daten vergißt. Bei MQTT2_SERVER gibt es dazu einen setter, mosquitto muss man in den Standardeinstellungen einfach nur neu starten.

Das ganze ist kein wirklich selbsterklärendes Thema, und es würde mich wirklich freuen, wenn wir das so aufbreitet bekommen, dass es ggf. auch für andere nachvollziehbar ist. Vielleicht setzt du mal attrTemplate für die MQTT_GENERIC_BRIDGE auf den empfohlenen default und schaust dir dann das an, was ich für Einstellungen für Rollläden (CUL_HM) an Vorschlag als attrTemplate vercoded hatte? (Bin grade auch nicht aktuell im Thema drin und muss mich ggf. nachher mal hinsetzen, um das nachzuspielen, was man wann sehen kann).
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

Hey, also meinst du

set MQTT_GENERIC_BRIDGE attrTemplate mgb_send_all_readings und den Rest raus hauen? Hab ich das richtig verstanden?

Beta-User

Zitat von: Der-Eine am 14 November 2022, 18:25:43
Hey, also meinst du

set MQTT_GENERIC_BRIDGE attrTemplate mgb_send_all_readings und den Rest raus hauen? Hab ich das richtig verstanden?
Nein.

Ich hatte dazu auch mal einen Wiki-Beitrag angefangen: https://wiki.fhem.de/wiki/MQTT_GENERIC_BRIDGE. Da findest du für die settings an der Bridge das attrTemplate "base_settings_to_MQTT_GENERIC_BRIDGE". Das "mgb_send_all_readings" ist dann "eigentlich" für den Rollladen. ABER: Ich finde das nach wie vor FALSCH, alle Readings pauschal zu senden. Das attrTemplate ist nur da, weil es Leute gibt, die so einen Sch... unbedingt haben wollen.
=> Schau das Rollladen-attrTemplate an.
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

Oha, wenn ich zb. das Ba_Fenster mit diesem atrrTemplate versehe, dann kommen auf einmal einige "Out" Werte an.

Damit ich nun aber Grundsätzlich sauber anfange.. Sollte ich nun den Retain Wert auf 0 setzen?
Und per MQTT Explorer hier mal alles löschen?

Beta-User

Zitat von: Der-Eine am 15 November 2022, 10:03:16
Oha, wenn ich zb. das Ba_Fenster mit diesem atrrTemplate versehe, dann kommen auf einmal einige "Out" Werte an.
Was ist konkret gemeint? Das von mir nicht empfohlene "mgb_send_all_readings"?
Oder das spezielle für Rollläden? Bitte künftig genauer schreiben, was du gemacht hast

Zitat
Damit ich nun aber Grundsätzlich sauber anfange.. Sollte ich nun den Retain Wert auf 0 setzen?
Und per MQTT Explorer hier mal alles löschen?
Nachdem nun vermutlich etwas klarer ist, wie die Zusammenhänge (zumindest sendeseitig) sind, ist es m.E. eine gute Idee, Altlasten zu entsorgen. Auf welchem Weg ist mir eigentlich egal, zumal du zur Frage des eingesetzten MQTT-Servers bisher laut geschwiegen hast.
Und das "retain"-Flag sollte man m.E. nur dann setzen (default ist aus, afaik!), wenn man sehr sicher ist, dass man es (wirklich!) braucht. Anders gesagt: Es ist meistens kontraproduktiver Unfug! Vor allem für Anweisungen an FHEM sollte man es unbedingt vermeiden, sonst kann es passieren, dass Rollläden mitten in der Nacht fahren und keiner weiß warum (doch: ich... da hat sich der Server neu mit dem Client auf der FHEM-Seite verbunden!).
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

Ich werde mir Mühe geben alle Infos künftig bereitzustellen.

Raspberry Pi4 "SH"
FHEM
MQTT Server ist Mosquitto in HomeAssistant
läuft beides auf dem selben Pi

attTemplate mgb_send_all_readings muss ein Gerät angegeben werden, hier habe ich zum "Test" mal den Rollo im Bad (Ba_Fenster) hinterlegt. Daten werden jetzt alle 5 Sekunden aktualisiert
3 Werte:
State= -11917092420
position= -11917092420
exact= -11917094240
Hier war jedoch immer wieder im HomeAssistant ein falscher Wert zu sehen (der Rolladen war 3/4 geschlossen, daher vermute ich ist der jetzige Stand so falsch.

Ich denke wenn alles sauber läuft, dann kann man von dem all_readings auf die Rollladen anpassen

Beta-User

Zitat von: Der-Eine am 15 November 2022, 10:41:38
Ich werde mir Mühe geben alle Infos künftig bereitzustellen.

Raspberry Pi4 "SH"
FHEM
MQTT Server ist Mosquitto in HomeAssistant
läuft beides auf dem selben Pi
Dann sollte es reichen, den mosquitto neu zu starten, um alte Werte los zu werden.

Welches IO-Modul? MQTT oder MQTT2_CLIENT?

Zitat
attTemplate mgb_send_all_readings muss ein Gerät angegeben werden, hier habe ich zum "Test" mal den Rollo im Bad (Ba_Fenster) hinterlegt.
Mal abgesehen davon, dass das "all" immer noch Mist ist, war die Angabe des Gerätes erst mal der richtige Weg.

ZitatIch denke wenn alles sauber läuft, dann kann man von dem all_readings auf die Rollladen anpassen
Du solltest dir gleich Gedanken machen, was du brauchst und direkt versuchen zu verstehen, wie man es eingrenzt. Sonst musst du hinterher ggf. bei anderen, gespächigeren Devices unnötig viel aufräumen...

ZitatDaten werden jetzt alle 5 Sekunden aktualisiert
Hast du so häufig Events?!? Dann bitte mal mit "event-on-change-reading" bändigen!



Zitat3 Werte:
State= -11917092420
position= -11917092420
exact= -11917094240
Hier war jedoch immer wieder im HomeAssistant ein falscher Wert zu sehen (der Rolladen war 3/4 geschlossen, daher vermute ich ist der jetzige Stand so falsch.
Diese Werte sind aber auch komisch. Sind das wirklich die Reading-Werte?
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

ZitatDann sollte es reichen, den mosquitto neu zu starten, um alte Werte los zu werden.

Welches IO-Modul? MQTT oder MQTT2_CLIENT?
Ich habe den MQTT2_Client

ZitatMal abgesehen davon, dass das "all" immer noch Mist ist, war die Angabe des Gerätes erst mal der richtige Weg.
Von meiner Seite aus nutze ich aktuell FHEM nur für die Rollladen (da existiert auch ein Raum für)
Da wäre es evtl. sinnig das auf diesen Raum zu beschränken.
"All" kann man gar nicht anders setzen.

ZitatHast du so häufig Events?!? Dann bitte mal mit "event-on-change-reading" bändigen!
Schaue ich mir auch noch an

ZitatDiese Werte sind aber auch komisch. Sind das wirklich die Reading-Werte?
Ja die waren tatsächlich so im Device hinterlegt. Hatte ihn dann nochmals per Up Befehl im FHEM getriggert und schon war die korrekte 0 angezeigt

Beta-User

Zitat von: Der-Eine am 15 November 2022, 11:02:01
Ich habe den MQTT2_Client
OK. Dir ist klar, dass du dann
- clientOrder anpassen mußt (macht das MGB-attrTemplate, meine ich), und
- sinnvollerweise ignoreRegexp setzen solltest (für alles, was an Daten rausgeht).

Zitat
Von meiner Seite aus nutze ich aktuell FHEM nur für die Rollladen (da existiert auch ein Raum für)
Da wäre es evtl. sinnig das auf diesen Raum zu beschränken.
"All" kann man gar nicht anders setzen.
Das "all-Readings"-attrTemplate und die Frage der devspec für die von MGB überwachten Devices sind zwei paar Stiefel. Ich bin immer noch der Ansicht, dass es reichen würde, wenn du nur das "position"-Reading weitergeben würdest (das ich dann auf der MQTT-Topic-Seite als "pct" benennen würde, wenn es von 0-100 geht...).
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

ZitatOK. Dir ist klar, dass du dann
- clientOrder anpassen mußt (macht das MGB-attrTemplate, meine ich), und
- sinnvollerweise ignoreRegexp setzen solltest (für alles, was an Daten rausgeht).
Mir ist das ganze System noch nicht so wirklich klar und ich vermute ganz stark, dass ich da nicht alleine bin.

Lt. der Config habe ich folgende Infos hinterlegt:
define ha_MQTT2 MQTT2_CLIENT IP:Port
setuuid ha_MQTT2 628c9e04-f33f-0bd3-25c8-95ff9550b0c4b218
attr ha_MQTT2 clientId fhem
attr ha_MQTT2 keepaliveTimeout 60
attr ha_MQTT2 msgAfterConnect -r fhem/connection/status connected
attr ha_MQTT2 msgBeforeDisconnect -r fhem/connection/status disconnected
attr ha_MQTT2 qosMaxQueueLength 100
attr ha_MQTT2 room MQTT
attr ha_MQTT2 username fhemqtt

Das ist hier für mich alles nachvollziehbar und der Connected/Disconnected Status ist beim MQTT Server auszulesen.

Die Config von der Bridge:
define mqttGeneric MQTT_GENERIC_BRIDGE
setuuid mqttGeneric 628c9e04-f33f-0bd3-25c8-95ff9550b0c4b218
attr mqttGeneric IODev ha_MQTT2
attr mqttGeneric globalDefaults sub:qos=0 pub:qos=2 retain=0 base={"fhem/$device"}
attr mqttGeneric icon mqtt_bridge_2
attr mqttGeneric room MQTT,Rollladen
attr mqttGeneric stateFormat in: incoming-count out: outgoing-count devices: device-count
attr mqttGeneric verbose 0

attr mqttGeneric globalDefaults sub:qos=0 pub:qos=2 retain=0 base={"fhem/$device"} Wieso wird hier ein base Wert angegeben? Ist dieser nicht direkt beim Device anzulegen?
Auch welche Funktion die Bridge letztendlich hat ist bei mir noch nicht angekommen. Der Client sollte doch direkt mit dem Server kommunizieren können.

define Ba_Fenster SOMFY 000014
setuuid Ba_Fenster 609ef3bc-f33f-361a-ba2d-6af0c0a82cac39d2
attr Ba_Fenster userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long structexclude
attr Ba_Fenster IODev sduino
attr Ba_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 Ba_Fenster drive-down-time-to-100 13
attr Ba_Fenster drive-down-time-to-close 17
attr Ba_Fenster drive-up-time-to-100 4
attr Ba_Fenster drive-up-time-to-open 18
attr Ba_Fenster eventMap on:down stop:stop off:up
attr Ba_Fenster model somfyshutter
attr Ba_Fenster mqttForward all
attr Ba_Fenster mqttSubscribe state:stopic={"$base/set"}
attr Ba_Fenster room Rollladen
attr Ba_Fenster webCmd down:stop:up

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
attr Ba_Fenster mqttForward all Hier wird angegeben das alles weitergeleitet wird?
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?

Heute hatte ich noch ein Update gemacht. Bis heute morgen hatte ich ca 50000 Einträge unter Outgoing. Dieser Wert ändert sich aktuell nur beim Betätigen des Rollos. Sonst wird kein Wert übertragen. Ist das richtig so?

Tut mir schrecklich Leid für die vielen Fragen, aber wenn man das auf einfache Weise niederschreibt.. dann haben bestimmt viele etwas davon.