Hmm,
kann auch nur raten.
Der Topic-Pfad der discovery-message scheint auch eine Rolle zu spielen. Das war ja hier
fhem/vacuum/valetudo_rockrobo/config
fhem war der Ersatz für homeassistant (siehe Antwortvon krikan auf meine Frage dazu ganz am Anfang) => könnte der "Indikator" sein, dass das eine "spezielle" Message vorliegt.
"vacuum" könnte man als Geräteklasse übersetzen, das scheint mit den Dateien in
https://github.com/home-assistant/home-assistant/tree/dev/homeassistant/components/mqtt/vacuum zusammenzuhängen, wo dann wieder drinsteht, was es alles als setter, Readings usw. gibt?
valetudo_rockrobo scheint aus den anderen beiden Angaben aus
diesem Beitrag zusammengesetzt zu sein.
Wenn ich mir das so ansehe, erscheint es mir zwar logisch aufgebaut, aber wir müßten dann eine parallele Struktur aufbauen, die dieselben Elemente pflegt, sonst ist es nutzlos. Meine vorläufige Einschätzung daher: Braucht man diese dahinterliegende Datenstruktur auch nch, bringt es wegen des zusätzlichen Pflegeaufwands gg. den templates keinen wirklichen Mehrwert, jedenfalls, solange der user nicht hergeht und dann sehr viel an den topic-Trees dreht (was die Erkennungsrate der template-Codes verschlechtert). Letzteres tun aber nur totale Anfänger (immer weniger, habe ich den Eindruck), oder die, die sowieso wissen, was sie tun und an sich auch ohne autodiscovery-Mechanismus klarkämen.
Ergo sollte man dem geneigten Anwender daher empfehlen, das feature abzuschalten, FHEM-interner Ersatz ist attrTemplate. Meinstens scheint man den HASS-support aktivieren zu müssen, valetudo scheint der einzige Fall zu sein, in dem es by default bereits aktiviert ist.
@krikan: In
diesem Beitrag war in dem .json als einziges, das mal als "Schalter" zur Aktivierung ansehen könnte die Angabe des "autoconfPrefix". Lust zu testen, was passiert, wenn das nicht da ist? Sonst war mMn. nichts enthalten, was man als Aktivierung des features interpretieren könnte. Oder hast sonst du irgendeinen "Schalter" gesehen, mit dem man das abstellen kann?
Ansonsten wäre (der Spur nach) die Frage, ob man diese Art messages auf eine (konfigurierbare) "blacklist" beim IO setzen sollte, damit es dort dann direkt verworfen wird?
