Vorhandenes MQTT2 Device als "UNDEFINED" (autocreate)

Begonnen von Reinhard.M, 03 Januar 2022, 11:27:14

Vorheriges Thema - Nächstes Thema

Beta-User

Na ja: Im Wiki gibt es zum autocreate-Prozess bei MQTT2_DEVICE ziemlich sicher auch einen Abschnitt zur Bedeutung der CID.
Aber (wichtiger): Diese Angabe ist in deinem list unter dieser Bezeichnung als Internal sichtbar - sonst wäre ich nämlich auch nicht drauf gekommen, dass das der tiefere Grund für die fehlgeleiteten autocreate-Versuche (ad Rudi: gewesen) war...
Ergo: ein tiefer Blick auf das list hätte genügt, um das zu dechiffrieren :P .

Und über den Umstand, dass unsere felsenfesten Überzeugungen halt hin und wieder doch eher unzuverlässige Wunschbilder sind, stolpere ich auch gerne immer mal wieder...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Reinhard.M

Nachtrag bezüglich der vielen MQTT Status Meldungen:
Die "TelePeriod" der Tasmota Devices steht auf 300, also 5 Minuten. Trotzdem spukten alle Devices alle 8 Sekunden den Status aus. Der tatsächliche Verursacher war "TasmoAdmin". Ein Tool zur Verwaltung vieler Tasmota Devices. Das Tool hat mit 8s gepollt. Auf 120s umgestellt und schon ist Ruhe  :)

Beta-User

Zitat von: Reinhard.M am 05 Januar 2022, 16:04:23
"Again what learned"  :D
Jetzt geht es mir genauso :) ...

Wichtig ist halt hin und wieder, dass man eine Idee von der Richtung hat, in der man suchen könnte ;) . Nicht selten liegen die eigentlichen Problemursachen außerhalb.

Trotzdem bleibt die Frage von ganz zu Anfang: Warum wird überhaupt versucht, was neues "abzuladen", und warum tritt das - wenn, dann - so gehäuft auf? Kann natürlich sein, dass FHEM/MQTT2_SERVER wegen der Vielzahl "zu langsam" war (k.A., was die Tasmotas erwarten), aber ich werde den Verdacht nicht los, dass da noch was anderes im Argen ist...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

rudolfkoenig

Zitat[...] eine Änderung der DEF bei MQTT2_DEVICE das Internal DEVICETOPIC ändert, selbst wenn das betreffende Attribut (anders) gesetzt ist.
Danke fuer den Hinweis, habs geaendert.

Reinhard.M

#19
@Beta-User: Falls ich deine Frage richtig verstehe hier ein Erklärungsversuch:
Ich habe insgesamt 31 Tasmota Devices die alle 8 Sekunden abgefragt wurden. Jedes Device liefert auf eine "Status 0" Abfrage 10 Antworten, also 310 Antworten alle 8 Sekunden. Da bist du bei mehr als 2000 Antworten in einer Minute.

Otto123

Zitat von: Reinhard.M am 05 Januar 2022, 16:04:23
Nein, auf RTFM hast du nicht verwiesen. Solche Fragen sind mir nur in einigen Forenbeiträgen aufgefallen und zumindest mir geht dann manches Mal der Hut hoch.
Mit meinen Antworten auf deine Stichwortliste wollte ich im Grunde nur sagen, dass ich an dieser Stelle nichts anders gemacht habe als bei den funktionierenden Devices. Erst die defmod Zeile hat mich dann darauf gebracht, was du meintest. In der Commandref ist zum Thema CID nichts angegeben:
Define
define <name> MQTT_DEVICE
Specifies the MQTT device.

CID fehlt hier in der Beschreibung. Insbesondere wenn man nicht weiß wie autocreate funktioniert wird es dann schwierig solche Zusammenhänge zu sehen. Abgesehen davon war ich ja auch der felsenfesten Überzeugung, dass diese Einträge (DEF und somit CID) wegen automatischer Erzeugung alle richtig sind. "Again what learned"  :D
Ich lese ja immer interessiert mit, das Zitat ist aus der falschen commandref (hier MQTT_DEVICE und nicht MQTT2..) aber trotzdem ist in der commandref zu MQTT2_DEVICE nichts zur CID im define zu finden. Wäre vielleicht schön es als option mit anzugeben? :D
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Reinhard.M

Zitat von: Otto123 am 05 Januar 2022, 18:11:13
Ich lese ja immer interessiert mit, das Zitat ist aus der falschen commandref (hier MQTT_DEVICE und nicht MQTT2..) aber trotzdem ist in der commandref zu MQTT2_DEVICE nichts zur CID im define zu finden. Wäre vielleicht schön es als option mit anzugeben? :D

Shame on me, zu schnell geklickt  :-[
Danke für den Hinweis.  :)

rudolfkoenig

ZitatWäre vielleicht schön es als option mit anzugeben? :D
Danke fuer den Hinweis...habs ergaenzt.

Beta-User

War anders gemeint: was ist die Ursache für die _gelegentlich auftretende Häufung gerade dieser_ messages?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Reinhard.M

Ich habe gerade einen weiteren verbose 5 Lauf gemacht. Ich gehe mal davon aus, du meintest die "myMQTT_Server: dispatch autocreate" Messages. Das es nur gelegentlich auftritt war von mir eine Fehlinterpretation da ich in den Unmengen an Log-Zeilen einfach den Überblick verloren habe. Mit meiner jetzigen Einstellung von TasmoAdmin (120s) sehe ich, dass für jede von einem MQTT-Client reinkommende Message ein "myMQTT_Server: dispatch autocreate" erzeugt wird. Mit der Korrektur der CID wird aber kein Device mehr erzeugt, es bleibt bei den Messages.

Beta-User

Zitat von: Reinhard.M am 05 Januar 2022, 20:06:33
Ich gehe mal davon aus, du meintest die "myMQTT_Server: dispatch autocreate" Messages. Das es nur gelegentlich auftritt war von mir eine Fehlinterpretation da ich in den Unmengen an Log-Zeilen einfach den Überblick verloren habe.
Falls es wirklich eine Fehlinterpretation war, ist es ok. Dass prinzipiell alle eingehenden messages das "flag" haben, ist mir klar, aber deine Beschreibung zu Beginn war: ich habe hin und wieder gehäuft Einträge.
Da die "normalen" messages zugeordnet werden können (über die readingList-Einträge) ging es ursprünglich eben um genau die messages, die weder zugeordnet werden konnten (korrigiert) noch einen readingList-Eintrag hatten.
Wenn es also "sporadisch" auftrat, waren es _andere Messages_ (genauer: andere Topics) als üblich!

Wenn das so ist, überdeckt deine Korrektur nur ein anderes Problem, das dazu führte, dass bestimmte Messages nur zu bestimmten Zeiten gehäuft kamen. MAW: jetzt ins log zu schauen bringt wenig, du musst die alten Logs nochmal ansehen, schauen, was es für messages/Topics sind (oder ob die ursprüngliche Symptombeschreibung wirklich falsch war), und dann erst das Thema abhaken oder eben weiter untersuchen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

minierm

Argh, wieder was gelernt:
Das Autocreate von MQTT nutzt das autocreate device. Wenn man autocreate disabled kann MQTT auch nichts erzeugen. Immer diese Zusammenhänge...