shellyUni über MQTT Reading ignorieren wie

Begonnen von masterpete23, 11 November 2022, 10:15:30

Vorheriges Thema - Nächstes Thema

masterpete23

Hi,

ich habe einen ShellyUni an meine Kligel geklemmt und über MQTT mit FHEM verbunden.
Nun schwankt das Reading adc_0 die ganze Zeit.
Dieses Reading will ich nun ignorieren da es "alles vollspammt".
An welcher Stelle muss ich hier wie vorgehen, damit ich es weder als Reading habe noch im Filelog.
Ein Löschen aus der Reading list fügt immer die letzte Zeile automatisch wieder ein:

shellyuni_34945477DFA9:shellies/shellyuni-34945477DFA9/online:.* online
shellyuni_34945477DFA9:shellies/shellyuni-34945477DFA9/announce:.* { json2nameValue($EVENT) }
shellyuni_34945477DFA9:shellies/shellyuni-34945477DFA9/relay/0:.* relay_0
shellyuni_34945477DFA9:shellies/shellyuni-34945477DFA9/relay/1:.* relay_1
shellyuni_34945477DFA9:shellies/shellyuni-34945477DFA9/input/0:.* input_0
shellyuni_34945477DFA9:shellies/shellyuni-34945477DFA9/input/1:.* input_1
shellyuni_34945477DFA9:shellies/shellyuni-34945477DFA9/info:.* { json2nameValue($EVENT) }
shellyuni_34945477DFA9:shellies/shellyuni-34945477DFA9/input_event/0:.* { json2nameValue($EVENT) }
shellyuni_34945477DFA9:shellies/shellyuni-34945477DFA9/input_event/1:.* { json2nameValue($EVENT) }

shellyuni_34945477DFA9:shellies/shellyuni-34945477DFA9/adc/0:.* adc_0

Beta-User

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

masterpete23

Perfekt.
danke

shellyuni_34945477DFA9:shellies/shellyuni-34945477DFA9/adc/0:.* {}
Löste das Problem.

Beta-User

Zitat von: masterpete23 am 11 November 2022, 12:25:07
Perfekt.
danke
:)

Zitat
shellyuni_34945477DFA9:shellies/shellyuni-34945477DFA9/adc/0:.* {}
Löste das Problem.
Anmerkung: Ich lösche prinzipiell die ClientID-Angaben aus den readingsList-Einträgen und würde das generell auch allen anderen so empfehlen. Keine Ahnung, warum anscheinend alle anderen User so an dieser Angabe hängen...
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

masterpete23

Hi,

wie meinst du das mit dem Löschen der ID? Wo? Wofür?

Ich stehe (mal wieder ) aufm Schlauch :(

Beta-User

Stattshellyuni_34945477DFA9:shellies/shellyuni-34945477DFA9/adc/0:.* {}
shellies/shellyuni-34945477DFA9/adc/0:.* {}
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

masterpete23

Es wird ja automatisch durch das Modul / Template so erzeugt oder?

Beta-User

#7
Durch das Modul, ja. Bestens bekannt! Ändert nichts an meiner Empfehlung
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

OdfFhem

Ich nutze im produktiven Einsatz MQTT2_CLIENT und auf dem Testsystem MQTT2_SERVER. Die autom. generierten readingList-Attribute enthalten in beiden Fällen nie eine clientID.

Ich bin mir nicht sicher, aber wahrscheinlich werden die schon bei Verwendung von einem "bridgeRegexp"-Device verschluckt ...?...

masterpete23

Welchen Vorteil hat das weglassen - verstehe ich noch nicht

Beta-User

Zitat von: masterpete23 am 12 November 2022, 16:41:56
Welchen Vorteil hat das weglassen - verstehe ich noch nicht
Es hat einen Nachteil: MQTT2_DEVICE braucht einen sehr kleinen Schritt mehr beim Dispatchen.

Es hat den Vorteil, dass klar ist, dass die CID NICHT Teil des Topics ist. Dass die CID eine derart große Rolle spielt, ist eine Besonderheit des MQTT2_SERVER, das gibt es sonst nirgends. Ergo: kommst du irgendwann (aus welchem Grund auch immer) in die Verlegenheit, Kontakt mit der allgemeinen MQTT-Welt zu haben, wirst du auf die Nase fallen mit der "vollständigen" readingList.

Kann man glauben oder es sein lassen, siehe auch die Anmerkung von OdfFhem zum Wechsel zwischen MQTT2_SERVER und MQTT2_CLIENT als IO. (Ja, bridgeRegexp ist für diese Besonderheit "verantwortlich")
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