MQTT2_CLIENT / MQTT2_DEVICE + autocreate dupliziert Einträge in readingList

[nuccleon]

Hallo zusammen,

Ich betreibe den MQTT2_CLIENT an mosquitto und folgende Attribute gesetzt:

Code Auswählen Erweitern


defmod mqtt2 MQTT2_CLIENT raspberrypi:1883
attr mqtt2 autocreate 1
attr mqtt2 room MQTT2_DEVICE
attr mqtt2 subscriptions ebusd/#


Das MQTT2_DEVICE, welches via autocreate angelegt wird, sieht dann folgendermaßen aus:

Code Auswählen Erweitern


defmod MQTT2_mqtt2 MQTT2_DEVICE mqtt2
attr MQTT2_mqtt2 IODev mqtt2
attr MQTT2_mqtt2 readingList mqtt2:ebusd/global/uptime:.* uptime\
mqtt2:ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT, 'vdatetime_', $JSONMAP) }\
mqtt2:ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT, 'vdatetime_', $JSONMAP) }\
mqtt2:ebusd/broadcast/outsidetemp:.* { json2nameValue($EVENT, 'outsidetemp_', $JSONMAP) }\
mqtt2:ebusd/broadcast/outsidetemp:.* { json2nameValue($EVENT, 'outsidetemp_', $JSONMAP) }\
mqtt2:ebusd/hmu/State:.* { json2nameValue($EVENT, 'State_', $JSONMAP) }\
mqtt2:ebusd/hmu/State:.* { json2nameValue($EVENT, 'State_', $JSONMAP) }
attr MQTT2_mqtt2 room MQTT2_DEVICE


Jetzt tauchen alle empangenen Topics doppelt auf ^^
Ist das so gewollt? Oder hab ich noch was falsch gemacht?

LG

[OdfFhem]

Meine MQTT2_CLIENT-Definition sieht recht ähnlich aus ... und die readingList enthält keine mehrfachen Einträge.

Da sich im MQTT2-Umfeld in letzter Zeit recht viel getan hat - nutzt Du den aktuellen Stand der MQTT2-Module?

[nuccleon]

Gestern Abend ein update gemacht, also ja

[rudolfkoenig]

Da es an der readingsList Modifikation seit dem Einbau von JSONMAP nicht viel getan hat, liegt es vmtl. nicht an einem veralteten Modul.

MQTT2_CLIENT mit autocreate ist problematisch, weil MQTT dafuer eigentlich nicht genug Info liefert.
Autocreate in MQTT2_CLIENT ist so gedacht, dass man vom ersten MQTT2_DEVICE die Daten per bridgeRegexp verteilt, und readingsList in dieser ersten Instanz nur als Ideengeber fuer bridgeRegexp dient, und danach entfernt wird.
Das Problem kommt vmtl, weil mosquitto mehrere identische Nachrichten in "einem Schwung" sendet. Bin nicht sicher, ob der Aufwand das zu fixen wg. der o.g. Einschraenkung/Verfahrensweise sich lohnt.

[nuccleon]

Naja, dass das Problem von mosquitto kommt bezweifel ich, da auch kommandos wie z.B.

Code Auswählen Erweitern


set mqtt2 publish ebusd/hmu/State/get


dupliziert in der readingList auftauchen.

Ich verwende autocreate auch nur zum testen

[Beta-User]

Autocreate in MQTT2_CLIENT ist so gedacht, dass man vom ersten MQTT2_DEVICE die Daten per bridgeRegexp verteilt, [...]

Danke für die Klarstellung, das war bisher nirgends so klar formuliert... Sollte man vermutlich in das Wiki aufnehmen (und in der cref für MQTT2_CLIENT klarstellen?).

Vor kurzem bin ich im Rahmen einer PM-Anfrage über genau das Thema gestolpert, und hatte im Prinzip da dieselbe Idee. Daher: Könnten/sollten wir einen Vorschlag für diese "erste" Bridge in die templates aufnehmen?

Habe noch nicht intensiv drüber nachgedacht, aber vermutlich wäre es ein Ansatz, einfach die ersten beiden Teile aus dem Topic-Pfad zu nehmen und dann $1_$2 als CID zu definieren?

[rudolfkoenig]

Von mir aus gerne, ich habe z.Zt. nicht so den Ueberblick ueber die unterschiedlichen Geraete, so dass ich eine sinnvolle Voreinstellung vorschlagen koennte.

[Beta-User]

Hmm,

aus dem Bauch heraus würde ich mal in die Richtung gehen:

Code Auswählen Erweitern

attr DEVICE bridgeRegexp [^:]+:([^/]+)/([^/]+)[/]?.*:.* "$1_$2"

Also als allg. template sowas:

Code Auswählen Erweitern


###############
#MQTT2_CLIENT_Bridge
#
name:A_00_MQTT2_CLIENT_general_bridge
filter:TYPE=MQTT2_DEVICE
desc:recommended to use this as general bridgeing device when using MQTT2_CLIENT as IO to get around missing CID info for distinguishing different devices
attr DEVICE bridgeRegexp [^:]+:([^/]+)/([^/]+)[/]?.*:.* "$1_$2"
attr DEVICE autocreate 1
attr DEVICE setStateList on off
attr DEVICE model A_00_MQTT2_CLIENT_general_bridge

Könnte  mal jemand austesten, der MQTT2_CLIENT nutzt, ob da was sinnvolles rauskommt?

[Ranseyer]

Könnte  mal jemand austesten, der MQTT2_CLIENT nutzt, ob da was sinnvolles rauskommt?

Hmm, wie teste ich das ?
So ?
-Zigbee Geräte löschen
-Die Regex anpassen siehe ein Post höher
-warten wie die Geräte angelegt werden?

Dazu Punkt zwei: Ich will offener werden und möglicherweise FTUI durch NodeRed ersetzen oder ergänzen.
Dazu muss man Anfangs einen möglichst guten Topic-Tree überlegen. Und da ich jetzt gerade das Thema neu aufsetze muss ich mich entscheiden.
Gibt es dazu gute Vorschläge in welche Richtung der Tree am besten geht ?
Laut Wiki würde das vom Filtern her viel Sinn machen, auch wenn mein aktueller Broker so ziemlich beliebig filtern kann:

Richtig schlau (warum, kommt bei den Filtern)

set/zuHause/1_OG/Kueche/Lichtschalter
state/zuHause/1_OG/Kueche/Lichtschalter/state

https://wiki.fhem.de/wiki/MQTT_Einf%C3%BChrung_Teil_2#Basics.2C_Strukturierung


Im Moment filtert mein Bridge-RegEx wohl stumpf nach Topcis die mit zigbee2mqtt beginnen:

attr MQTT2_MQTTServer bridgeRegexp zigbee2mqtt/([A-Za-z0-9]*)[/]?.*:.* "zigbee_$1"

Ich würde mich über einen Vorschlag zum "Tree" freuen und das dann direkt testen auf einer komplett neuen Umgebung was den MQTT-Anteil betrifft... (Und das ganze macht vermutlich nur gemeinsam Sinn)

[Beta-User]

Hmm, wie teste ich das ?

Entweder:

Du solltest ja irgendwo schon mal mind. ein Device haben.
Das über den RAW-Editor duplizieren und auf das Duplikat anwenden. Damit sollten dann alle zusätzlichen Geräte (also alles, was sich in den ersten beiden Angaben unterscheidet und noch nicht in einem anderen MQTT2_DEVICE bekannt ist) dann mit einer CID angelegt werden, die aus den ersten beiden Angaben im Topic-Tree besteht.

Oder: Alle bis auf ein MQTT2_DEVICE löschen, auf das das "generelle" anwenden, und dann sollte zum einen dein Kessel ein neues Gerät bilden, die zigbee2mqtt-Geschichte landet dann in einem anderen (hoffentlich). Auf das dann wieder das zigbee-template sollte dann alle weiteren Geräte vereinzeln.

Was den Tree angeht, würde ich empfehlen, dazu einen eigenen Thread aufzumachen.
Vom Ansatz her meine ich, dass "Bridge-Geräte" wie die zigbee2mqtt-Bridge oder die Milight-Bridge sowieso nicht sinnvoll in eine eigene logische Struktur passen, man also eh' zweigleisig arbeiten muß: bei den Tasmotas usw. ist das vermutlich ok, den topic-Tree auch auf den Geräten selbst anzupassen; es wird dann halt schwieriger, die Dinger zu konfigurieren, weil die templates dann uU. nicht mehr ohne weiteres passen.
Meine (ehr) vorläufige Meinung: Wenn es irgendwann mit der GenericBridge und MQTT2-IOs geht: FHEM die Übersetzung machen lassen und dann ggf. damit eine raumähnliche Struktur basteln, die man dann außerhalb von FHEM visualisiert.

Ich werde den anderen Weg gehen und bastle grade devStateIcon-Code für meine HM-Thermostate; dann sollte eigentlich auch FHEMWEB soweit aufzuhübschen sein, dass ich mich nicht in was anderes eindenken muß, Preview anbei (soll dann auch darüber voll bedienbar werden).

[Ranseyer]

Also lassen wir mal den Tree außen vor. Ich fürchte den muss man eh noch umbauem wenn genauer klar ist was allen noch dazu kommt...

Also ich habe mal testweise /opt/fhem/FHEM/lib/AttrTemplate/mqtt2.template um deine Einträge von oben erweitert und zur Sicherheit FHEM neu gestartet.
Ich habe diverses herumgespielt (Das Bridge Device dupliziert und die RegEx siehe oben angepasst.)


Dann ein MQTT Device gelöscht. Und automatischs wieder neu anlegen lassen. Da der Namen genau wie vor den Änderungen war:

Da ich ein aktuelles Backup habe, habe ich beide Bridge-Devices (Original+Kopie) wieder gelöscht. Und die werden gerade nicht wieder automatisch neu angelegt.
Die Zigbee Geräte liefern weiter Daten. Aber das Bridge Device ist weg und ich muss es wohl manuell neu anlegen (Morgen!)

[Beta-User]

Hmm, also die Zigbee-Geräte sollten auch danach genau wieder da landen, wo sie waren.

Interessant wäre vor allem, was mit deinem Ofen/Kessel/Heizdingens (oder was es auch immer ist) ist; wenn dieses Topic in keinem Gerät mehr zu finden ist und du das general-Bridge-template nutzt: Wo landet das dann?

Zur Erläuterung: das sollte auch bisher ein separates Gerät gewesen sein (nach Anwendung der zigbee-Bridge); da kämen dann aber auch alle weiteren Geräte rein, die nichts damit zu tun haben (so wie ganz am Anfang alles zigbee-Zeug und der Ofen).

Mit der general Bridge sollte eben alles, was sich im topictree in den ersten beiden Angaben unterscheidet, auch jeweils in einem eigenen, neuen Gerät wiederfinden... Den Unterschied merkt man aber erst, wenn es ein 3. Gerät (zigbee als eines gedacht) gibt.

[nuccleon]

Also, ich hab mir euren Vorschlag mit bridgeRegexp zu Herzen genommen und dabei auch

Code Auswählen Erweitern


attr DEVICE bridgeRegexp [^:]+:([^/]+)/([^/]+)[/]?.*:.* "$1_$2"

ausprobiert. Funktioniert super!

Und jetzt kommt aber ein Aber, welches sich auf mein ursprüngliches Anliegen bezieht:
Hier nun das automatisch erzeugte MQTT2_DEVICE

Code Auswählen Erweitern


defmod MQTT2_ebusd_470 MQTT2_DEVICE ebusd_470
attr MQTT2_ebusd_470 IODev mqtt2
attr MQTT2_ebusd_470 readingList ebusd/470/HwcTempDesired/get:.* get\
ebusd/470/BMUB51101StorageTemp/get:.* get\
ebusd/470/BMUB51101StorageTemp/get:.* get\
ebusd/470/HwcTempDesired:.* { json2nameValue($EVENT, 'HwcTempDesired_', $JSONMAP) }\
ebusd/470/HwcTempDesired:.* { json2nameValue($EVENT, 'HwcTempDesired_', $JSONMAP) }\
ebusd/470/BMUB51101StorageTemp:.* { json2nameValue($EVENT, 'BMUB51101StorageTemp_', $JSONMAP) }\
ebusd/470/BMUB51101StorageTemp:.* { json2nameValue($EVENT, 'BMUB51101StorageTemp_', $JSONMAP) }\
ebusd/470/HwcActualTempDesired:.* { json2nameValue($EVENT, 'HwcActualTempDesired_', $JSONMAP) }\
ebusd/470/HwcActualTempDesired:.* { json2nameValue($EVENT, 'HwcActualTempDesired_', $JSONMAP) }\
ebusd/470/YieldThisYear:.* { json2nameValue($EVENT, 'YieldThisYear_', $JSONMAP) }\
ebusd/470/YieldThisYear:.* { json2nameValue($EVENT, 'YieldThisYear_', $JSONMAP) }
attr MQTT2_ebusd_470 room MQTT2_DEVICE

setstate MQTT2_ebusd_470 2019-01-21 10:17:36 BMUB51101StorageTemp_temp1_value 50.0
setstate MQTT2_ebusd_470 2019-01-21 10:17:36 HwcTempDesired_temp1_value 49.0
setstate MQTT2_ebusd_470 2019-01-21 10:17:35 get


Auch hier wieder die Einträge in der readingList doppelt. Ok, mit doppelt kann ich leben.

Jetzt das große Aber:
Ich hab hier ein paar Devices, bei denen wächst die readingList gerade ins Unendliche. Die Liste erweitert sich permanent beim Empfang von topics die ein $ im string haben. Das kann auf Dauer nicht gut gehen :-/

Code Auswählen Erweitern


defmod MQTT2_homie_io_eg MQTT2_DEVICE homie_io_eg
attr MQTT2_homie_io_eg IODev mqtt2
attr MQTT2_homie_io_eg readingList homie/io_eg/$stats/interval:.* interval\
homie/io_eg/$stats/interval:.* interval\
homie/io_eg/$stats/signal:.* signal\
homie/io_eg/$stats/signal:.* signal\
homie/io_eg/$stats/uptime:.* uptime\
homie/io_eg/$stats/uptime:.* uptime\
homie/io_eg/$fw/name:.* name\
homie/io_eg/$fw/name:.* name\
homie/io_eg/$fw/version:.* version\
homie/io_eg/$fw/version:.* version\
homie/io_eg/$fw/checksum:.* checksum\
homie/io_eg/$fw/checksum:.* checksum\
homie/io_eg/$implementation/version:.* version\
homie/io_eg/$implementation/version:.* version\
homie/io_eg/$implementation/ota/enabled:.* enabled\
homie/io_eg/$implementation/ota/enabled:.* enabled\
homie/io_eg/in-0/alias:.* alias\
homie/io_eg/in-0/alias:.* alias\
homie/io_eg/in-0/state:.* state\
homie/io_eg/in-0/state:.* state\
homie/io_eg/in-1/alias:.* alias\
homie/io_eg/in-1/alias:.* alias\
homie/io_eg/in-1/state:.* state\
homie/io_eg/in-1/state:.* state\
homie/io_eg/in-2/alias:.* alias\
homie/io_eg/in-2/alias:.* alias\
homie/io_eg/in-2/state:.* state\
homie/io_eg/in-2/state:.* state\
homie/io_eg/in-3/alias:.* alias\
homie/io_eg/in-3/alias:.* alias\
homie/io_eg/in-3/state:.* state\
homie/io_eg/in-3/state:.* state\
homie/io_eg/$stats/interval:.* interval\
homie/io_eg/$stats/interval:.* interval\
homie/io_eg/$fw/name:.* name\
homie/io_eg/$fw/name:.* name\
homie/io_eg/$fw/version:.* version\
homie/io_eg/$fw/version:.* version\
homie/io_eg/$fw/checksum:.* checksum\
homie/io_eg/$fw/checksum:.* checksum\
homie/io_eg/$implementation/version:.* version\
homie/io_eg/$implementation/version:.* version\
homie/io_eg/$implementation/ota/enabled:.* enabled\
homie/io_eg/$implementation/ota/enabled:.* enabled\
homie/io_eg/$stats/signal:.* signal\
homie/io_eg/$stats/signal:.* signal\
homie/io_eg/$stats/uptime:.* uptime\
homie/io_eg/$stats/uptime:.* uptime\
homie/io_eg/$stats/interval:.* interval\
homie/io_eg/$stats/interval:.* interval\
homie/io_eg/$fw/name:.* name\
homie/io_eg/$fw/name:.* name\
homie/io_eg/$fw/version:.* version\
homie/io_eg/$fw/version:.* version\
homie/io_eg/$fw/checksum:.* checksum\
homie/io_eg/$fw/checksum:.* checksum\
homie/io_eg/$implementation/version:.* version\
homie/io_eg/$implementation/version:.* version\
homie/io_eg/$implementation/ota/enabled:.* enabled\
homie/io_eg/$implementation/ota/enabled:.* enabled\
homie/io_eg/$stats/signal:.* signal\
homie/io_eg/$stats/signal:.* signal\
homie/io_eg/$stats/uptime:.* uptime\
homie/io_eg/$stats/uptime:.* uptime\
homie/io_eg/$stats/interval:.* interval\
homie/io_eg/$stats/interval:.* interval\
homie/io_eg/$fw/name:.* name\
homie/io_eg/$fw/name:.* name\
homie/io_eg/$fw/version:.* version\
homie/io_eg/$fw/version:.* version\
homie/io_eg/$fw/checksum:.* checksum\
homie/io_eg/$fw/checksum:.* checksum\
homie/io_eg/$implementation/version:.* version\
homie/io_eg/$implementation/version:.* version\
homie/io_eg/$implementation/ota/enabled:.* enabled\
homie/io_eg/$implementation/ota/enabled:.* enabled\
homie/io_eg/$stats/signal:.* signal\
homie/io_eg/$stats/signal:.* signal\
homie/io_eg/$stats/uptime:.* uptime\
homie/io_eg/$stats/uptime:.* uptime\
homie/io_eg/$stats/interval:.* interval\
homie/io_eg/$stats/interval:.* interval\
homie/io_eg/$fw/name:.* name\
homie/io_eg/$fw/name:.* name\
homie/io_eg/$fw/version:.* version\
homie/io_eg/$fw/version:.* version\
homie/io_eg/$fw/checksum:.* checksum\
homie/io_eg/$fw/checksum:.* checksum\
homie/io_eg/$implementation/version:.* version\
homie/io_eg/$implementation/version:.* version\
homie/io_eg/$implementation/ota/enabled:.* enabled\
homie/io_eg/$implementation/ota/enabled:.* enabled\
homie/io_eg/$stats/signal:.* signal\
homie/io_eg/$stats/signal:.* signal\
homie/io_eg/$stats/uptime:.* uptime\
homie/io_eg/$stats/uptime:.* uptime\
homie/io_eg/$stats/interval:.* interval\
homie/io_eg/$stats/interval:.* interval\
homie/io_eg/$fw/name:.* name\
homie/io_eg/$fw/name:.* name\
homie/io_eg/$fw/version:.* version\
homie/io_eg/$fw/version:.* version\
homie/io_eg/$fw/checksum:.* checksum\
homie/io_eg/$fw/checksum:.* checksum\
homie/io_eg/$implementation/version:.* version\
homie/io_eg/$implementation/version:.* version\
homie/io_eg/$implementation/ota/enabled:.* enabled\
homie/io_eg/$implementation/ota/enabled:.* enabled\
homie/io_eg/$stats/signal:.* signal\
homie/io_eg/$stats/signal:.* signal\
homie/io_eg/$stats/uptime:.* uptime\
homie/io_eg/$stats/uptime:.* uptime\
homie/io_eg/$stats/interval:.* interval\
homie/io_eg/$stats/interval:.* interval\
homie/io_eg/$fw/name:.* name\
homie/io_eg/$fw/name:.* name\
homie/io_eg/$fw/version:.* version\
homie/io_eg/$fw/version:.* version\
homie/io_eg/$fw/checksum:.* checksum\
homie/io_eg/$fw/checksum:.* checksum\
homie/io_eg/$implementation/version:.* version\
homie/io_eg/$implementation/version:.* version\
homie/io_eg/$implementation/ota/enabled:.* enabled\
homie/io_eg/$implementation/ota/enabled:.* enabled\
homie/io_eg/$stats/signal:.* signal\
homie/io_eg/$stats/signal:.* signal\
homie/io_eg/$stats/uptime:.* uptime\
homie/io_eg/$stats/uptime:.* uptime
attr MQTT2_homie_io_eg room MQTT2_DEVICE

setstate MQTT2_homie_io_eg 0
setstate MQTT2_homie_io_eg 2019-01-21 10:27:49 alias wohnzimmer
setstate MQTT2_homie_io_eg 2019-01-21 10:27:53 associatedWith MQTT2_mqtt2
setstate MQTT2_homie_io_eg 2019-01-21 10:27:49 state 0


[Ranseyer]

Interessant wäre vor allem, was mit deinem Ofen/Kessel/Heizdingens (oder was es auch immer ist) ist; wenn dieses Topic in keinem Gerät mehr zu finden ist und du das general-Bridge-template nutzt: Wo landet das dann?

Also nochmals.
-Ich habe einen "MQTT2_CLIENT" der greift auf den "MQTT-Server" zu (Mosquitto).
-Ich hatte das MQTT_Device mit Bridge Funktion gelöscht, das wurde nun doch wieder automatisch angelegt (aber das dauert 1-2 Minuten, keine Ahnung warum). Diesem habe ich das Template A_00_MQTT2_CLIENT_general_bridge zugewiesen
-Die beiden Heizungs-Devices sind gelöscht !
-Wenn ich will kann ich zwei Topics ansprechen: d8/p4 und d8/p4-error

=> Es wird kein Device für Heizung automatisch angelegt.
Statt dessen im Eventlog:

Code Auswählen Erweitern

xZeitxx Global global UNDEFINED MQTT2_ST000-Softwareversion|50.04.05.09
xZeitxx Global global UNDEFINED MQTT2_ERR0000-date|2019-01-08 19:05:17

Das ist die automatisch angelegte Bridge mit dem genannten Template:

Internals:
   CFGFN     
   CID        MQTTServer
   DEF        MQTTServer
   DEVICETOPIC MQTT2_MQTTServer
   IODev      MQTTServer
   NAME       MQTT2_MQTTServer
   NR         586
   STATE     
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
Attributes:
   DbLogExclude .*
   IODev      MQTTServer
   autocreate 1
   bridgeRegexp [^:]+:([^/]+)/([^/]+)[/]?.*:.* "$1_$2"
   model      A_00_MQTT2_CLIENT_general_bridge
   room       MQTT2_DEVICE
   setStateList on off

[Beta-User]

@Ranseyer:
Hast du zwischendurch dann nach Speichern FHEM neu gestartet oder MQTT2_DEVICE neu geladen (reload)?
(Bekannte Geräte werden m.E. uU. nicht angelegt; da muß ggf. erst alles neu initialisiert werden, kann das aber grade nicht verifizieren, ist nur ein Erfahrungswert).

Werden die zigbee-Geschichten neu angelegt? (also erst wieder ein "global-Device", darauf dann das zigbee-bridge-template usw.?) Wenn nein, ggf. auch MQTT2_CLIENT mal neu laden, wenigstens das Device für den eigentlichen Dienst sollte dann erscheinen (wie im Wiki beschrieben, die weiteren Geräte, die nichts regelmäßig senden, muß man dann ggf. durch ein publish über das IO "händisch" anstoßen).

Also, ich hab mir euren Vorschlag mit bridgeRegexp zu Herzen genommen und dabei auch

Code Auswählen Erweitern


attr DEVICE bridgeRegexp [^:]+:([^/]+)/([^/]+)[/]?.*:.* "$1_$2"

ausprobiert. Funktioniert super!

Danke für die Rückmeldung, dann werde ich das bei Gelegenheit mal einchecken, wenn nicht jemand was schlaueres einfällt.

Zum Rest kann ich leider nichts wirklich substantielles sagen; vielleicht würde es helfen, die "$" in der readingsList zu maskieren? (Ist aber nur eine spontane Idee, muß nicht funktionieren; am besten wäre es, dem Gerät dieses Zeichen abzugewöhnen...).

@Rudi: hast du dazu eine Idee?