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?

[Ranseyer]

Ich hatte erst alles gelöscht und dann FHEM neu gestartet.

Dann 15 Minuten später hatte ich doch dieses zweite Bridge-Device:

Code Auswählen Erweitern

Internals:
   CFGFN     
   CID        zigbee2mqtt_bridge
   DEF        zigbee2mqtt_bridge
   DEVICETOPIC MQTT2_zigbee2mqtt_bridge
   IODev      MQTTServer
   NAME       MQTT2_zigbee2mqtt_bridge
   NR         544
   STATE      offline
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-01-21 12:46:40   associatedWith  MQTT2_MQTTServer
     2019-01-21 12:46:40   state           offline
Attributes:
   DbLogExclude .*
   IODev      MQTTServer
   readingList zigbee2mqtt/bridge/state:.* state
   room       MQTT2_DEVICE

Was per MQTT so kommt bestimmt für die Heizung ein Perl-Skript (s. Anlage). Ich kann das selbst nicht ändern. (Allgemein kann man sagen dass dieses für meinen Geschmack etwas zu gespächig ist)

Ich würde nun dann das RegEx und autocreate auf die Zweite Bridge setzen: "attr DEVICE bridgeRegexp [^:]+:([^/]+)/([^/]+)[/]?.*:.* "$1_$2""
-dann Sicherheitshalber FHEM neu starten und Heizungsdaten senden ?

[nuccleon]

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?

Abgewönen ist schwierig, das Gerät arbeitet nach https://github.com/homieiot/convention/blob/develop/convention.md.
Es ist zu erwarten, dass mehrere Solche Geräte auftauchen, nicht nur bei mir

Der Log behauptet, autocreate ginge schief ^^. Das tut er aber offensichtnicht nicht vollständig, da zumindest die $ topics in der readingList doppelt auftauchen.

Code Auswählen Erweitern


2019.01.21 10:27:48 3: unsupported character in readingname $homie
2019.01.21 10:27:50 3: unsupported character in readingname $homie
2019.01.21 10:27:50 3: unsupported character in readingname $mac
2019.01.21 10:27:50 3: unsupported character in readingname $mac
2019.01.21 10:27:50 3: unsupported character in readingname $name
2019.01.21 10:27:50 3: unsupported character in readingname $name
2019.01.21 10:27:50 3: unsupported character in readingname $localip
2019.01.21 10:27:50 3: unsupported character in readingname $localip
2019.01.21 10:27:51 3: unsupported character in readingname $implementation
2019.01.21 10:27:51 3: unsupported character in readingname $implementation
2019.01.21 10:27:51 3: unsupported character in readingname $type
2019.01.21 10:27:52 3: unsupported character in readingname $type
2019.01.21 10:27:52 3: unsupported character in readingname $properties
2019.01.21 10:27:52 3: unsupported character in readingname $properties
2019.01.21 10:27:52 3: unsupported character in readingname $type
2019.01.21 10:27:52 3: unsupported character in readingname $type
2019.01.21 10:27:52 3: unsupported character in readingname $properties
2019.01.21 10:27:52 3: unsupported character in readingname $properties
2019.01.21 10:27:52 3: unsupported character in readingname $type
2019.01.21 10:27:52 3: unsupported character in readingname $type
2019.01.21 10:27:52 3: unsupported character in readingname $properties
2019.01.21 10:27:52 3: unsupported character in readingname $properties
2019.01.21 10:27:52 3: unsupported character in readingname $type
2019.01.21 10:27:52 3: unsupported character in readingname $type
2019.01.21 10:27:52 3: unsupported character in readingname $properties
2019.01.21 10:27:52 3: unsupported character in readingname $properties
2019.01.21 10:27:52 3: unsupported character in readingname $online
2019.01.21 10:27:52 3: unsupported character in readingname $online
2019.01.21 10:27:53 3: unsupported character in readingname $online
2019.01.21 10:27:53 3: unsupported character in readingname $online
2019.01.21 10:28:11 3: unsupported character in readingname $online
2019.01.21 10:28:11 3: unsupported character in readingname $online
2019.01.21 10:28:24 3: unsupported character in readingname $homie
2019.01.21 10:28:24 2: autocreate: define MQTT2_{"name":"homie-io","device_id":"io_eg","wifi":{"ssid":"n***internet"},"mqtt":{"host":"raspberrypi","port":1883,"base_topic":"homie_","auth":false},"ota":{"enabled":true},"settings":{"publishInterval":30,"deepSleep":true,"alias-in-0":"kueche","alias-in-1":"flur","alias-in-2":"wc","alias-in-3" MQTT2_DEVICE {"name":"homie-io","device_id":"io_eg","wifi":{"ssid":"n***internet"},"mqtt":{"host":"raspberrypi","port":1883,"base_topic":"homie_","auth":false},"ota":{"enabled":true},"settings":{"publishInterval":30,"deepSleep":true,"alias-in-0":"kueche","alias-in-1":"flur","alias-in-2":"wc","alias-in-3"
2019.01.21 10:28:24 1: ERROR: Invalid characters in name (not A-Za-z0-9._): MQTT2_{"name":"homie-io","device_id":"io_eg","wifi":{"ssid":"n***internet"},"mqtt":{"host":"raspberrypi","port":1883,"base_topic":"homie_","auth":false},"ota":{"enabled":true},"settings":{"publishInterval":30,"deepSleep":true,"alias-in-0":"kueche","alias-in-1":"flur","alias-in-2":"wc","alias-in-3"


Das $ war auch schon bei MQTT_DEVICE problematisch, da wurde es aber gefixed. Zum Thema:
https://forum.fhem.de/index.php/topic,79257.msg725681.html
https://forum.fhem.de/index.php/topic,86270.msg787057.html

[Beta-User]

@Ranseyer
Also du hast im Moment ein MQTT2_Device, richtig?

Die ganz ursprüngliche readingList sah so aus:

Code Auswählen Erweitern

readingList MQTTServer:zigbee2mqtt/bridge/state:.* stateMQTTServer:d8/p4/MqttRawMsg:.* MqttRawMsg
MQTTServer:d8/p4-error/MqttRawMsg:.* MqttRawMsg
Dann würde ich die general Bridge drauf anwenden, und die bridgeRegexp um ein zweites Element erweitern:

Code Auswählen Erweitern

[^:]+:d8/p4.*:.* "P4D" Danach mal den mosquitto neu starten (eigentlich sollte er dann alles, was er weiß, nochmal preisgeben und die diversen Geräte dann automatisch angelegt werden. Wenn das nicht so ist, den zigbee2mqtt-Dienst neu starten. Dann sollte wenigstens ein "state"-MQTT2-Device angelegt werden.
Wie man den Brenner überreden kann, ein publish zu machen, weiß ich leider auch nicht, und das Perlscript wollte ich mir grade nicht antun...

Abgewönen ist schwierig, das Gerät arbeitet nach https://github.com/homieiot/convention/blob/develop/convention.md.
Es ist zu erwarten, dass mehrere Solche Geräte auftauchen, nicht nur bei mir

Das $ war auch schon bei MQTT_DEVICE problematisch, da wurde es aber gefixed. Zum Thema:
https://forum.fhem.de/index.php/topic,79257.msg725681.html
https://forum.fhem.de/index.php/topic,86270.msg787057.html

Hmm, das ist dann halt so, muss dann aber vermutlich (wie bei MQTT_DEVICE auch) im Modul gefixt werden (es sei denn, Maskieren hilft, was ich aber nicht glaube).

[nuccleon]

Hmm, das ist dann halt so, muss dann aber vermutlich (wie bei MQTT_DEVICE auch) im Modul gefixt werden (es sei denn, Maskieren hilft, was ich aber nicht glaube).

Also zumindest das "anwachsen" der readingList ins unendliche sollte IMHO auf jeden Fall gefixed werden. An wen kann ich mich da wenden?

[Ranseyer]

Ich habe zwei Bridge Devices:
A)  MQTT2_MQTTServer : Regex: [^:]+:([^/]+)/([^/]+)[/]?.*:.* "$1_$2"
B) MQTT2_zigbee2mqtt_bridge: Kein Template=> z.B. daher kein Autocreate, Keine Bridge Regex vergeben. Angeblich "offline".

Das zweite Bridge-Device habe ich noch nicht ohne Rücksprache mit dir anfassen wollen. Da ist also kein Template und keine RegEx zugewiesen.
Soll ich nun also in A) einfach noch am Ende der RegEx dieses anhängen ?

Code Auswählen Erweitern

[^:]+:d8/p4.*:.* "P4D"
Ich hätte eher mal vermutet: Auf der zweiten Bridge das gleiche Template wie bei der ersten anwenden und anschliessend das RegEx tauschen (siehe eine Zeile höher).

Alle Zigbee2MQTT-Devices wurden nun gelöscht (vorher nur eins).

Die Daten per MQTT neu reinzubekommen ist leicht: Das Perl-Script starten wegen Heizung, und für ZigBee2 MQTT den Daemon neu starten wie duschreibst.

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

Das selbe bei den zigbee2mqtt Geräten, daher würde ich gerne warten was du genau für die Bridges vorschlägst damit du auch das gewünschte Ergebnis bekommst...

[Beta-User]

@nuccleon:
Der betreffende Modulverantwortliche aus der MAINTANER.txt liest hier bereits mit . Bin ziemlich sicher, dass er sich dann schon melden wird, wenn er dafür Zeit findet, sich das näher anzusehen.

Vermutlich wäre dein Problem übrigens schneller zu erkennen gewesen, wenn du schon im ersten Post ein list geliefert hättest .

@Ranseyer:
im Prinzip ist es egal, wie herum man das macht, weil (neben der "MQTTServer" des MQTT2_CLIENT) die einzige "echte" CID sowieso die vom Broker mosquitto ist und alle anderen Dinge (insbesondere die readingList) weitestgehend gelöscht werden.
Es macht aber Sinn, auf das Device, das die "richtige" readingList für zigbee2mqtt hat, auch das betreffende template anzuwenden.
Das mit der doppelten bridgeRegexp macht vermutlich nicht den großen Sinn, da beide regexe passen; hier würde ich dazu tendieren, das P4D-Device unter Verwendung der bekannten Readinglist einfach manuell zu erstellen (testweise die CID in der DEF weglassen und auch aus der readingList draußen halten). So etwa:

Code Auswählen Erweitern

readingList d8/p4/MqttRawMsg:.* MqttRawMsg
d8/p4-error/MqttRawMsg:.* MqttRawMsgSobald es ein Device gibt, das paßt, müßte autocreate eigentlich "still" sein und alle Readings dann in diesem Device landen...

Wenn die autocreate-Funktion nicht will: Keine Ahnung, wo das herkommt, vermutlich irgendwelche internen Infos, die nach dem Löschen trotzdem noch da sind; da hilft dann nur ein reload/restart von FHEM; das kommt aber wenn überhaupt nur davon, dass zwischendurch irgendwas gelöscht wurde. Eigentlich kann man alles, was ordnungsgemäß funktioniert auch lassen...)

[Ranseyer]

Hmm evtl reden wir aneinander vorbei. Ich habe derzeit kein Problem und brauche auch keine Hilfe. Ich habe nur getestet was du wissen wolltest.

Wenn ich alle MQTT-Devices lösche und FHEM neu starte wird automatisch angelegt:
MQTT2_MQTTServer

Wenn ich auf MQTT2_MQTTServer das Template A_00_MQTT2_CLIENT_general_bridge anwende (manuell in die Template Datei von mir kopiert) erhalte ich zusätzlich automatisch angelgt:
MQTT2_zigbee2mqtt_bridge (ohne RegEx und Autocreate)

Die Zigebee Geräte werden damit  nicht mehr automatisch angelegt. (Auch nicht nach FHEM Neustart und mehrmaligem publishen)
Wenn ich dem zweiten Bridge Device auch das Template A_00_MQTT2_CLIENT_general_bridge anwende und FHEM neu starte werden trotzdem keine neuen Devices angelegt.

Ist ja eigentlich auch klar. Zigbee Geräte werden nur über die RegEx aus dem Template L_01_zigbee2mqtt_bridge angelegt.

Fazit: Um das ganze einfach einzurichten
Teil1:
-Client Anlegen
-Device wird automatisch ezeugt, Darauf das Template L_01_zigbee2mqtt_bridge anwenden und man hat die Zigbee Geräte.

Teil2: Andere Geräte (wie die Heizung in meinem Fall)
-Mir unklar wie man das automatisch hinbekommt. (Manuell ist das kein Problem)
Das wäre natürlich schick wenn man künftig mehr Geräte usw. hat.

[Ranseyer]

Hi nochmals,

wen ich mir das so überlege bräuchte man für "diverse Zwecke" doch nur eine halbwegs Doku wie man sich die RegEx zusammenschustert um automatisch die Geräte erzeugt zu bekommen...
Und am einfachsten wäre doch für jeden speziellen Zweck so ein Bridge Device mit der entsprechenden RegEx zu haben ?
-Dann kann man diese einzeln deaktivieren wenn gerade nichts neues integriert werden soll...

Grüße

PS: Sorry ich gebe nochmals zu ich habe von den RegEx'en keine Ahnung, auch wenn ich schon mühevoll 1-2 zusammengeschustert habe...

[Beta-User]

@Ranseyer:

Danke für's testen und sorry, dass ich deine Rückmeldungen offenbar mißverstanden habe.
Aber so, wie du es jetzt rückgemeldet hast, ist es eigentlich Wiki-tauglich, oder ?

Hi nochmals,

wen ich mir das so überlege bräuchte man für "diverse Zwecke" doch nur eine halbwegs Doku wie man sich die RegEx zusammenschustert um automatisch die Geräte erzeugt zu bekommen...
Und am einfachsten wäre doch für jeden speziellen Zweck so ein Bridge Device mit der entsprechenden RegEx zu haben ?
-Dann kann man diese einzeln deaktivieren wenn gerade nichts neues integriert werden soll...

Im Prinzip gebe ich dir da recht, im Detail ist es m.E. aber schwierig, gerade weil das ganze Konstrukt bei MQTT so flexibel ist und - im Prinzip - jeder machen darf, was er will. Ich vermute, deswegen wollte Rudi auch keinen Vorschlag machen...

Etwas ausführlicher:
Bei MQTT2_SERVER ist es einfacher, da kennen wir die originäre Datenquelle über ihre CID. Ergo benötigt man dort nur für IO's die Bridge-Devices mit passender bridgeRegexp, die nur als Sammelstellen für die diversen Daten von woanders her dienen - wie zigbee2mqtt oder die MiLight-Bridge. Der Rest geht sowieso ootb.

Bei MQTT2_CLIENT ist es etwas anders, weil da nur der topictree zur Verfügung steht, um verschiedene Geräte auseinanderzuhalten. Die jetzige bridgRegexp ist dabei auch nur ein Kompromiß, der aber schon bei deinem Heizungs-tree versagt, weil da schon nur der erste Bestandteil konstant ist, und nicht wenigstens die ersten beiden Teile.

Nimmt man wiederum nur den ersten Teil, benötigt man vermutlich "Folge-Brücken" für alle möglichen Gerätegruppen. Ist irgendwie auch nicht befriedigend...
Vom Gefühl her würde ich das erst mal so lassen, damit bekommt man "irgendwas vorverdautes" und kann dann entweder manuell anpassen, oder die noch fehlenden Teile mit Hilfe der templates zusammenbasteln (solange man innerhalb der defaults bleibt).

Aber ich kann weder für mich in Anspruch nehmen, da vollständig den Durchblick zu haben, und das "Basteln" von regex läuft mir auch nicht einfach so von der Hand (es dauert oft schon sehr lange, das nachzuvollziehen, was irgendwo schon aufgeschrieben ist). Also wenn da jemand noch bessere Ideen hat, her damit...

[nuccleon]

Der betreffende Modulverantwortliche aus der MAINTANER.txt liest hier bereits mit . Bin ziemlich sicher, dass er sich dann schon melden wird, wenn er dafür Zeit findet, sich das näher anzusehen.

Ok, bis es einen Fix dafür gibt, hast du einen Tip für mich wie ich verhindere, dass das logfile zu gespamed wird?

Code Auswählen Erweitern


2019.01.21 17:47:54 3: unsupported character in readingname $properties
2019.01.21 17:47:54 3: unsupported character in readingname $type
2019.01.21 17:47:54 3: unsupported character in readingname $type
2019.01.21 17:47:54 3: unsupported character in readingname $properties
2019.01.21 17:47:54 3: unsupported character in readingname $properties
2019.01.21 17:47:54 3: unsupported character in readingname $type
2019.01.21 17:47:54 3: unsupported character in readingname $type
2019.01.21 17:47:54 3: unsupported character in readingname $properties
2019.01.21 17:47:54 3: unsupported character in readingname $properties
2019.01.21 17:47:54 3: unsupported character in readingname $type
2019.01.21 17:47:54 3: unsupported character in readingname $type
2019.01.21 17:47:54 3: unsupported character in readingname $properties
2019.01.21 17:47:54 3: unsupported character in readingname $properties
2019.01.21 17:47:55 3: unsupported character in readingname $online
2019.01.21 17:47:55 3: unsupported character in readingname $online
2019.01.21 17:47:55 3: unsupported character in readingname $online
2019.01.21 17:47:55 3: unsupported character in readingname $online
2019.01.21 17:47:55 3: unsupported character in readingname $type
2019.01.21 17:47:55 3: unsupported character in readingname $type
2019.01.21 17:47:55 3: unsupported character in readingname $properties
2019.01.21 17:47:55 3: unsupported character in readingname $properties
2019.01.21 17:47:55 3: unsupported character in readingname $type
2019.01.21 17:47:55 3: unsupported character in readingname $type
2019.01.21 17:47:55 3: unsupported character in readingname $properties
2019.01.21 17:47:55 3: unsupported character in readingname $properties
2019.01.21 17:47:55 3: unsupported character in readingname $type
2019.01.21 17:47:55 3: unsupported character in readingname $type
2019.01.21 17:47:55 3: unsupported character in readingname $properties
2019.01.21 17:47:55 3: unsupported character in readingname $properties
2019.01.21 17:47:55 3: unsupported character in readingname $type
2019.01.21 17:47:55 3: unsupported character in readingname $type
2019.01.21 17:47:55 3: unsupported character in readingname $properties
2019.01.21 17:47:55 3: unsupported character in readingname $properties
2019.01.21 17:47:56 3: unsupported character in readingname $online
2019.01.21 17:47:56 3: unsupported character in readingname $online


Sorry, ich bin relativer FHEM Neuling und hab gerade keine Ahnung ob man irgendwo ein verbose Level o.ä. definieren kann

[Beta-User]

Hmm,- das mit dem Maskieren hast du versucht? also ein \vor das $ schreiben?
- Sonst: verbose ändern (auf einen niedrigeren Wert als 3 setzen)
- ggf. Zeile 294 in MQTT2_DEVICE ändern (return undef;). Achtung: Das ist aber ungetestet und uu. gefährlich!

[nuccleon]

Ich muss gestehen, das mit \ hab ich nicht ausprobiert. Es sind einfach zuuu viele.
Dafür hat verbose funktioniert, Danke!

[rudolfkoenig]

Ich habe zwar keine Idee, wieso es in so einem einfachen fall wie am Anfang (z.Bsp: mqtt2:ebusd/broadcast/vdatetime) das verdoppelt wird, aber ich habe eine Pruefung eingebaut: wenn was vorhanden ist sollte nicht mehr eingebaut werden. Waere nett wenn ich feedback kriegen wuerde, da ich mich mit Testen schwer tue.

Dass es mit homie/io_eg/$fw/name ein Problem gibt ist klar: $ wird im regexp speziell behandelt.
Ich habe autocreate angepasst: solche Zeichen werden ab sofort im Regexp-Teil geschuetzt und im ReadingsName-Teil mit _ ersetzt.

Wenn ich sonst was anschauen soll, bitte melden: da die Diskussion teilweise mAn Off-Topic ist, habe ich nicht alles exakt verfolgt.

[nuccleon]

Super, vielen Dank. Grundsätzlich ist ja $ ein gültiges Zeichen in einem Topic. Es sollte schon möglich sein, sich darauf zu subscriben und die readings zu bekommen, ohne dass Fehlermeldungen im Log auftauchen.
So wie ich das jetzt einschätze, ist da auch noch was im MQTT2_CLIENT zu tun.

Ich werde das morgen (spät. übermorgen) testen und melde mich dann hier wieder.

[nuccleon]

Funktioniert, danke!