MQTT2_CLIENT / MQTT2_DEVICE + autocreate dupliziert Einträge in readingList

Begonnen von nuccleon, 20 Januar 2019, 09:50:36

Vorheriges Thema - Nächstes Thema

Ranseyer

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

Dann 15 Minuten später hatte ich doch dieses zweite Bridge-Device:
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 ?
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

nuccleon

Zitat von: Beta-User am 21 Januar 2019, 12:41:26
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.

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:
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:
[^:]+: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...

Zitat von: nuccleon am 21 Januar 2019, 13:12:53
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).
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

nuccleon

Zitat von: Beta-User am 21 Januar 2019, 13:19:28
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 ?
[^:]+: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...
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

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:
readingList d8/p4/MqttRawMsg:.* MqttRawMsg
d8/p4-error/MqttRawMsg:.* MqttRawMsg
Sobald 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...)
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

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.
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

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...
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

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 ;) ?

Zitat von: Ranseyer am 21 Januar 2019, 16:12:34
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...
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

nuccleon

Zitat von: Beta-User am 21 Januar 2019, 14:16:29
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?


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!
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

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.