[erledigt]Wie retain message löschen ?

Begonnen von TomLee, 25 April 2020, 14:03:56

Vorheriges Thema - Nächstes Thema

TomLee

Hallo,

eigentlich wollte ich am MQTT2_Server folgendes publish absetzen:

-r cmnd/solarmax44009/DeepSleepTime 0

wegen copy+paste und schnell, schnell kam aber das dabei raus:

-r Publish2 cmnd/solarmax44009/DeepSleepTime 0

danach hab ich mit

-r Publish2 cmnd/solarmax44009/DeepSleepTime

versucht die Message zu löschen, womit jetzt

{"Publish2":"cmnd/solarmax44009/DeepSleepTime","ebusd/global...}

im RETAIN-Reading steht.

Wid bekomme ich die Message gelöscht ?

Gruß

Thomas

edit:

Habs  ::)

-r Publish2

hoppel118

#1
Hi Thomas,

wir machen hier mal weiter und nicht in meinem p4d Thread, damit der "sauber" bleibt. Ich übernehme mal unsere kommunikation:

Zitat von: hoppel118 am 26 April 2020, 14:09:16
Moin Thomas,

danke für den Hinweis. Einzelne Retain-Nachrichten kann ich über diesen Weg löschen. Durch die ganzen Spielereien und den homeassistant Kram habe ich jetzt aber hunderte solcher retain Nachrichten. Kann ich retain auch irgendwie vollständig zurücksetzen? Wenn nicht, lösche ich kurz das Device "MQTT2_SERVER".

EDIT: Ich habe nun kurz den MQTT2_SERVER gelöscht und neu definiert. Danach werden sofort die relevanten Nachrichten eingelesen und der ganze Müll ist weg. Wäre trotzdem noch interessant zu verstehen, ob es dafür eine elegantere Möglichkeit gibt.

Gruß Hoppel

Zitat von: TomLee am 26 April 2020, 14:25:13
Gute Frage würde mich auch interessieren, kann man vlt. regex verwenden, habs noch nicht probiert ?

Meine Nachrichten im RETAIN Feld sahen übrigens ungefähr wie folgt aus (Meine Heizung announced momentan ca. 40 Readings):

p4d_publisher:homeassistant/sensor/Aussentemperatur_0x4/config ...
p4d_publisher:p4d2mqtt/sensor/Au__entemperatur_0x4/state ...
p4d_publisher:p4d2mqtt/sensor//Aussentemperatur_0x4/state ...
p4d_publisher:p4d2mqtt/sensor/Aussentemperatur_0x4/state ...


Lediglich der letzte Eintrag war richtig und sollte bleiben.

Ich habe folgendes probiert:

set mqtt2server publish -r homeassistant.*
set mqtt2server publish -r p4d2mqtt
set mqtt2server publish -r p4d_publisher


Alle drei Befehle haben nichts bewirkt. Weitere Ideen? :D

Gruß Hoppel
Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

rudolfkoenig

Zitatp4d_publisher:homeassistant/sensor/Aussentemperatur_0x4/config ...
Schaut fuer mich merkwuerdig aus, weiss nicht, wie das ClientID da reingeschafft hat, ich kan es nicht nachstellen.

Ohne ClientId kann man es mit "set mqtt2server publish -r homeassistant/sensor/Aussentemperatur_0x4/config" entfernen, hier greifen keine Regexps, weil -r nicht fuer remove steht, sondern fuer retain (Senden einer Nachricht mit Retain Flag), was als Nebeneffekt das RETAIN Reading bzw. Internal pflegt.

hoppel118

OK, zur Aufklärung: Die ClientID war natürlich nicht im RETAIN Feld enthalten. Ich hatte sie nur ergänzt, damit man versteht, warum ich die dort aufgeführten 3 Varianten "set mqtt2server publish -r ..." ausprobiert habe. Das war wohl Blödsin...

Das man einzelne Einträge löschen kann, hatte ich verstanden. Aber bei knapp 160 Einträgen, wovon nur noch 40 valide sind, war mir das zu blöd, alle Einträge einzeln zu löschen, so dass ich dann einfach den MQTT2_SERVER gelöscht und neu angelegt habe. Hatte die Hoffnung, dass das irgendwie eleganter geht. Aber ok, es gibt also keine Möglichkeit das RETAIN Feld grundsätzlich zu resetten.

Danke dir und Gruß Hoppel
Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

rudolfkoenig

ZitatHatte die Hoffnung, dass das irgendwie eleganter geht.
Ja: "deletereading mqtt2_server RETAIN" und FHEM-Neustart.

hoppel118

hm... Ich bin der Meinung, dass ich das probiert hatte. Auch die von Beta-User aufgezeigte Variante hatte ich probiert, um das RETAIN Feld zu löschen:

deletereading -q DEVICE (?!associatedWith).*

Das Reading ist dann zwar kurz weg, aber es kommt nach kurzer Zeit wieder und bringt alle (auch die veralteten) Inhalte mit. Meine deletereading Tests habe ich immer ohne FHEM Neustart ausgeführt. Dann war das wohl das Problem. Ich werde das testen.

Danke und Gruß Hoppel
Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

hoppel118

By the way... Rudi hatte in meinem anderen Thread übrigens noch folgendes gepostet:

Zitat von: rudolfkoenig am 28 April 2020, 23:47:47

ZitatKann ich den MQTT2_Server eigentlich irgendwie stoppen?

delete MQTT2_Server
oder
modify MQTT2_Server 1884

Das disable Attribut verhindert nur das Senden.

Gruß Hoppel
Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

TomLee

Hallo,

hab mir vor Monaten beim "testen" mit Valetudo enorm viele homeassistant-Topics in RETAIN "eingefangen".
Die längsten (Karten) und auch viele weitere hab ich bisher mit -r gelöscht, es würde aber ewig dauern jeden Topic händisch zu löschen.

Mit deletereading:
Zitat von: rudolfkoenig am 27 April 2020, 12:12:19
Ja: "deletereading mqtt2_server RETAIN" und FHEM-Neustart.
sind die Topics nach einem restart weiterhin vorhanden.

Geht es nur über den Umweg den MQTT2_SERVER zu löschen und wieder neu anzulegen ?

Beta-User

Mein Test eben mit Rudi's Vorschlag, einem sicherheitshalber danach abgeschossenen "save statefile" und einem Neustart zeitigte am Ende einen deutlich ververkleinerten Reading-Inhalt. Was jetzt wieder (denke ich zumindest, dass es wieder ist) drinsteht, erscheint mir plausibel, es verbinden sich halt dann wieder alle Clients und dann gibt es auch wieder einige Retain-Einträge...
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

TomLee

Sry, nach dem schreiben vorhin bin ich direkt eingespannt worden was zu arbeiten.

Habs mir jetzt nochmal genauer angeschaut.

Also ich meine festgestellt zu haben das es nach einem löschen des Reading RETAIN der Fall sein kann das gleich wieder alle vorherigen Topics reingeschrieben werden, gleich nach Aktualisieren von FHEMWEB stehen diese wieder drin.
Meine Vermutung dabei ist das dieses Verhalten auftritt wenn gleich nach dem löschen des Reading irgendein Gerät was gesendet hat, die ganze "Liste" an Topics die zuvor gelöscht wurde wieder ergänzt wird.
Ist man aber schnell genug bzw. hat Glück das (nach meiner Vermutung) nach dem deletereading kein Gerät was sendet, ein save das leere Reading auch wirklich speichert und rechtzeitig den restart macht, erst dann die alten Topics nach dem neu laden weg sind.


Beta-User

Zitat von: rudolfkoenig am 27 April 2020, 10:10:10
was als Nebeneffekt das RETAIN Reading bzw. Internal pflegt.
Ohne in den Code gesehen zu haben hätte ich auch getippt, dass da ein Internal mit einem Array/einer Liste von Hashes existiert, das beim Senden einer Nachricht mit -r Flag dann ausgewertet wird. Also entweder schnell sein mit dem shutdown restart, oder eine Schleife basteln, die einmal das leere publish auf alle relevanten Topics macht...
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

TomLee

Zitat... dass da ein Internal mit einem Array/einer Liste von Hashes existiert,...

Wie ist das genau zu verstehen, wie sieht man dieses Internal ?

Hab showInternalValues aktiviert, versteckt sind die vermuteten Hashes auch nicht.

OT

Genauso wenig verstehe ich auch nicht wo der Gesamtwert eines on-for-timer in den Internals stehen soll, den sehe ich auch nicht unter den versteckten Internals.

Beta-User

Bei einem "normalen" MQTT2_SERVER sieht das list in etwa so aus - es gibt also einen (uU. leeren) Bereich namens "retain", in den dann die Einträge geschrieben werden (#495ff in 00_MQTT2_SERVER.pm)
ZitatInternals:
   CONNECTS   2
   Clients    :MQTT2_DEVICE:
   ClientsKeepOrder 1
   DEF        1883 global
   FD         7
   FUUID      60224629-f33f-b0ff-8bbc-4e15414fbd176c54
   NAME       m2server
   NR         14
   PORT       1883
   STATE      Initialized
   TYPE       MQTT2_SERVER
   .attraggr:
   .attrminint:
   MatchList:
     1:MQTT2_DEVICE ^.
   READINGS:
     2022-01-04 09:52:55   lastPublish     shellyplus1-a8032abcd5e8/events/rpc:{"src":"shellyplus1-a8032abc41a8","dst":"shellyplus1-a8032abc41a8/events","method":"NotifyStatus","params":{"ts":1636379194.60,"switch:0":{"id":0,"output":true,"source":"WS_in"}}}
     2022-03-14 09:18:37   nrclients       2
     2022-03-14 09:18:13   state           Initialized
   clients:
     m2server_127.0.0.1_51032 1
     m2server_127.0.0.1_51033 1
   retain:
Auch bei SetExtensions-Timern sollte was im list zu sehen sein. Siehe z.B. die ersten paar Zeilen von SetExtensions.pm
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