MQTT_GENERIC_BRIDGE generiert massenhaft incoming-count Events. Rekursion?

Begonnen von nuccleon, 02 März 2019, 20:46:53

Vorheriges Thema - Nächstes Thema

Beta-User

Es ist grundsätzlich kompatibel, aber man muss ein paar Dinge beachten.

Die Ursache für die Events dürfte darin liegen, dass 00_MQTT.pm wirklich nur weitergibt, für was es subscriptions gibt, die beiden MQTT2_IO's leiten dagegen alles weiter und erst auf der Ebene MGB wird geprüft, ob es überhaupt interessant ist. Von daher ist hier die Zahl der eingehenden Infos eben nicht gleichbedeutend mit der Zahl der verwerteten Infos.

Vermutlich macht es im Moment Sinn, event-on-change-reading so zu setzen, dass der incoming count raus ist, bis wir mir Rudi geklärt haben, ob und wie man das Zusammenspiel zwischen MGB und den MQTT2-IO's verbessern kann.
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

Daniel123

Testweise habe ich jetzt wieder MQTT2_FHEM_Server als IOdevice in Verwendung, und bei den event-on-change-readings nur den "outgoing-count" angegeben. Das klappt soweit - danke für deine Erklärung.

Wie nuccleon am 05.03.19 geschrieben hat, ist die Anzahl der incoming-count Meldungen abhängig von der Zeit zwischen den set(publish) Befehlen. Ich meinem Fall wurde die Lampe dadurch 1-2 s zeitlich verzögert eingeschaltet, wenn der Taster länger nicht betätigt wurde. Bin gespannt, ob durch das Unterdrücken der Events auch die zeitliche Verzögerung verschwindet. Ich werde in den kommenden Tagen davon berichten.

Beta-User

Es könnte schon mit der (sonstigen) Event-Verarbeitung zu tun haben.

Es gibt übrigens dazu und zu weiteren Themen seit eben zwei bzw. drei patches: https://forum.fhem.de/index.php/topic,117423.0.html
Falls du direkt eine konsolidierte Fassung haben willst: [EDIT: link entfernt] (läuft seit eben bei mir im Hauptsystem, aber trotzdem keine Garantie für gar nix...)
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

Daniel123

Wie es aussieht, war die Verzögerung tatsächlich der Event-Verarbeitung geschuldet. Jetzt klappt alles super :) .

Gerade habe deine überarbeitete Version eingefügt und diese läuft auch bei mir ohne Probleme. Danke für den Link zu den anderen Beiträgen. Diese werde ich weiter verfolgen.

Beta-User

Da hexenmeister das zwischenzeitlich auch offiziell eingecheckt hat, hier noch die späte Frage an den TE, ob er das Thema als [gelöst] kennzeichen kann und mag?

Ab jetzt bitte auch wieder die offizielle Version benutzen, falls jemand noch das aus meinem Repo verwendet!
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

nuccleon

Hallo zusammen,

ich hab eben ein update gemacht und bei MGB event-on-change reading gelöscht.
Und siehe da, kein Event Sturm mehr.

Super Job! Vielen Dank ;-)