MQTT2-Anfänger: Ignorieren von publishs

Begonnen von pula, 19 Juni 2020, 09:44:29

Vorheriges Thema - Nächstes Thema

Beta-User

 :) du darfst gerne helfen, das zu verbessern, was unter https://wiki.fhem.de/wiki/MQTT2_CLIENT steht:

Und es ist schon so, dass man erst mal ein Gefühl für das Ganze entwickeln muß; ist normal und nervt (noch) nicht. Grade, weil es dazu erst rudimentäre Doku gibt...

Also:
Wer MQTT2_CLIENT nutzt, sollte NEBEN den eigentlichen MQTT2_DEVICES _zwei_ weitere haben:
- ein separates (!) MQTT2_DEVICE für die "allgemeine" bridgeRegexp (es kann daneben weitere Geräte mit bridgeRegexp-Ausdrücken geben). Dieses Device hat nur den Zweck, die Erkennung via CID zu "simulieren", die der SERVER built-in bietet.
Dieses Device kannst du mit bridgeRegexp-Zeilen nach "" ergänzen, damit man autocreate und MQTT_GENERIC_BRIDGE parallel betreiben kann (? so verstehe ich den Hinweis von Rudi).
- Ein "Sammeldevice", das als "Mülleimer" für alle Messages dient, die nicht irgendwo anders hin umgeleitet werden (falls autocreate an ist). So sieht man "auf einen Blick", wenn Handlungsbedarf ist...

Was das Verständnis von bridgeRegexp angeht, ist es grade umgekehrt: Das ist _nur relevant_, wenn autocreate im Spiel ist. Sobald es auch nur ein Device gibt, das sich für zuständig erklärt (also eine passende readingList hat), greift bridgeRegexp nicht mehr.

(Deswegen hatte ich zu Beginn geschrieben: Das mit bridgeRegexp muß man v.a. dann verstanden haben, wenn man es mit CLIENT zu tun hat ;) .)
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

rudolfkoenig

Wobei meines Wissens Bridge-device und Muelleimer-device ein und dasselbe sein kann.
@Beta-User: wieso findest Du zwei separate MQTT2_DEVICE Instanzen sinnvoller?

Beta-User

Hmm, also:
Ja klar, bridgeRegexp und "Mülleimer"-Device können identisch sein.

Jetzt rätsle ich grade darüber, warum ich damals (um diesen Thread herum oder etwas vorher: https://forum.fhem.de/index.php/topic,98126.0.html) beides getrennt habe. Ursprünglich war das dasselbe Device. Ich meine mich dunkel zu erinnern, dass ich das bei den Tests zum Ebus dann eher so praktiziert hatte, die readingList im Sammeldevice manuell nach und nach aufzulösen, und da war das vollständige "Zerstören" der readingList durch Änderungen der bridgeRegexp irgendwie nicht so recht kompatibel; kann sein, dass die cmnd-Zweige der Tasmota-Geräte da auch eine (gedankliche) Rolle gespielt hatten, die ich auch "abfangen" wollte. Sonst hatte ich damit selbst wenig praktisch zu tun, und alle freundlichen Bitten, doch mal was dazu zu sagen, ob das ganze setup mit der General-Bridge jetzt ok ist (oder nicht), sind irgendwie (gefühlt) ohne Rückmeldung geblieben. Auch die meisten Umsteiger haben dann nach einem Test mit SERVER direkt umgestellt und dann keinen Bedarf mehr für Verbesserungen an diesem template...

Daher ist es jetzt halt so wie es ist bzw. irgendwann in grauer Vorzeit aus welchen Gründen auch immer mal so (einsam) entschieden wurde. Aber die Frage stellt sich (spätestens seit Einführung von ignoreRegexp) tatsächlich, ob man das heute nicht doch wieder umdrehen sollte und nur 1 Device für beides nutzen?

Es wäre vermutlich einfacher für Neulinge zu verstehen, und wer als Fortgeschrittener die "Doppelfunktion" trennen will, kann das ja tun...?

(Und wie bringen wir ignoreRegexp unter die Leute; in dem sonos-Thread habe ich mich redlich bemüht, zu vermitteln, dass man die homeassistant-autodiscovery-Zweige wirklich nicht braucht, aber die User wollen sich einfach nicht von Infos trennen, die sie erhalten können, selbst wenn sie völlig nutzlos sind... Aber ich kann das ja ggf. doppelt nähen und via bridgeRegexp dafür sorgen, dass wenigstens Nutzer des "general"-Templates davon nicht mehr behelligt werden?).
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

pula

Hallo,

war leider krank. Kann ich hier noch irgendwas beitragen?

Cheers,
Pula
fhem (debian auf proxmox), HM-LAN und wired, MySensors, FritzBoxes, Kodi, vdr, Onkyo, squeezeplayers, nanoCUL, wifilight (Ethernet-Bridge), Heizungssteuerung (python/vncdotool), doorpi, ESP/Arduinos/MQTT, Alexa, HomeConnect, Sonoff/Tasmota, espRGBWW, esphome, Telegram

Beta-User

Dann mal wilkommen zurück!

TomLee hat aus einem etwas anderen Anlaß jetzt den finalen Anstoß gegeben, das mit dem MQTT2_CLIENT_general_bridge und den ignoreRegexp-Themen etwas anders anzugehen; der kurzen Abschnitt im Wiki ist auch entsprechend geändert. Vermutlich würde es Sinn machen, wenn du diesen Thread hier schließt und wir das ganze dann in dem betreffenden Thread weiter diskutieren:

https://forum.fhem.de/index.php/topic,112383.0/topicseen.html

(Würde mich natürlich freuen, wenn du da mittestest und ggf. Verbesserungsvorschläge zu den templates und dem Wiki machst...).
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

pula

Super, danke!
Ich werde dort mitlesen. Und wenn ich alles bei mir am Laufen habe, werde ich mal einen Vorschlag für eine Erweiterung vom Wiki unterbreiten. Vielleicht geht es auch anderen wie mir...
Cheers,
Pula
fhem (debian auf proxmox), HM-LAN und wired, MySensors, FritzBoxes, Kodi, vdr, Onkyo, squeezeplayers, nanoCUL, wifilight (Ethernet-Bridge), Heizungssteuerung (python/vncdotool), doorpi, ESP/Arduinos/MQTT, Alexa, HomeConnect, Sonoff/Tasmota, espRGBWW, esphome, Telegram