MQTT Gateway 2.x

[t_heinrich]

Das hat keine Veränderung gebracht.
Es liegt doch aber auch (zum Teil) an meiner Config, oder? Weil für den unteren Teil liegt ja immer ein "0" an. Der untere Taster wird also geschalten, wenn ich auf "1" schalte und dann aber wieder auf "0" zurückspringt.

[svethi]

Also ich bin ja der Meinung dass da mehr kommen muss. Im Video sieht man, dass die damit auch dimmen wenn man den Knopf gedrückt hält. Das wiederum bedeutet, dass es da ein Event geben muss, wenn man die Taste drückt und ein Event, wenn man sie loslässt. Sonst könnte man nicht so dimmen. Wenn da per MQTT nicht mehr ankommt, dann liegt das am Zigbee2MQTT

[t_heinrich]

svethi ganz Unrecht hast du nicht.

Also wenn ich die Taste gedrückt halte, gibt es bei dem Topic "zigbee2mqtt_IKEA_Button_04_action" folgende Werte:

• 0 (bei Taste 0)
• 1 (bei Taste 1)
• brightness_move_up (bei Taste 1)
• brightness_move_down (bei Taste 2)
• brightness_stop (bei Taste 1 und 2)

Heißt aber vermutlich auch, dass ich die beiden Tasten (am Taster) nicht unterschiedlich nutzen kann, oder?

[Christian Fenzl]

Ich seh schon, das ist tricky.
Entweder du schaltest Reset-After-Send aus, dann bekommst du 1 oder 0, aber nie eine erneute 1, wenn nochmal gedrückt wird.
Oder zu schaltest Reset-After-Send ein, dann bekommst du keine extra 0 bei Taste 0.

Problem ist, dass dieser Doppel-Schalter die gleichen Daten liefert wie der Einfach-Taster.

In der Zigbee2Mqtt Config dieses Tasters gibt es einen Legacy-Mode, der Click-Events liefert, vielleicht hilft dir der weiter.

[Fuxi]

Hallo,es funktioniert alles wie es soll,aber bekomme seit neuestem öfters die Meldung per Mail:

etc/cron.hourly/logrotate:
error: Compressing program wrote following message to stderr when compressing log /var/log/mosquitto/mosquitto.log.1:
gzip: stdin: file size changed while zipping

Ich weiss es ist sicher nichts aufregendes,aber wollte es nur erwähnt haben.Kann ja rin bischen englisch und kann mir was vorstellen unter der Meldung.

[t_heinrich]

Christian Fenzl das mit dem Legacy-Mode schau ich mir mal an.

Ansonsten bin ich jetzt schon ein gutes Stück weiter, es fehlt halt weiterhin die Möglichkeit die "0" auszuwerten; da in der LoxConfig ja immer eine "0" anliegt.
Es funktionniert jetzt aber die "1" und das Dimmen "hoch" und "runter".

[mastercheef]

Habe hier ein sehr eigenartiges Problem.

Hardware: Pi 4 8GB
Verbunden per LAN Miniserver Go Gen2
aktuelles MQTT Plugin.

6 Shellys

Sofern nur diese aktiviert sind ist alles ok. (Reaktionszeit eigentlich ohne Verzögerung) HTTP VIRTUAL INPUTS (331 Entries)

Wenn ich jetzt mein zusätzliches Device hinzufügen (NibePi) (Gateway Modbus auf MQTT) steigt die Anzahl auf ca HTTP VIRTUAL INPUTS (1000 Entries)

In dieser Konstellation ist das MQTT vom und zum Miniserver eigentlich unbrauchbar teilweise über 30 Sekunden Reaktionszeit.

Muss ich hier alle "Not found" Einträge entfernen oder wo fange ich hier an?

Anmerkung:
Der Broker läuft stabil da es mit externen Tools (MQTT Explorer oder MQTT Android Client) ohne Verzögerung läuft.
Also gibt's hier irgendwo ein issue zwischen Loxberry und Miniserver.


Logfile folgt, ich kann das am Android irgendwie nicht downloaden.

[svethi]

Das Problem sind die Unmengen an HTTP-Verbindungen zu Deinem Miniserver. So wie Du schreibst, kommen auf einmal 669 Einträge hinzu. Hier muss das Plugin ja für jeden Eintrag prüfen ob es dafür einen VI im MiniServer gibt. Dies dauert nunmal und erzeugt unheimlich viel Netzwerklast. Als erste Maßnahme könntest Du bei Deinen Subscriptions aufräumen und dort nur das eintragen, was Du auch wirklich benötigst.

[Christian Fenzl]

Wie Sven sagt: Subscriptions gezielt setzen, bzw. per Subscription Filter Einträge nicht weiterleiten lassen.

Es besteht auch noch ein Unterschied zwischen der Anzeige im UI und dem, was das Gateway macht. Das Gateway arbeitet sehr schnell, und so "nebenbei" werden die Daten für das UI aufbereitet, und auch der Browser wird langsamer, was aber das Gateway selbst nicht beeinflusst.

Dann kommt noch der Cache. Beim Start wird das Gateway tatsächlich 15-30 Sekunden damit beschäftigt sein, dem Miniserver die Daten zu übermitteln.
Danach greift aber der Cache, und ab dann wird es für den Miniserver gemütlich.

Je mehr du jedoch schon von vornherein wegfiltern kannst, desto weniger wird dein Miniserver belastet.

[mastercheef]

OK das ist verständlich.

Leider sieht's aber auch nach 1 Tag Laufzeit nicht besser aus wo alles gecached sein sollte.

Jetzt zum wegfiltern.
Wie gehe ich hier am vernünftigen vor?

Überall so not forward setzten?
oder gibt's hier einen Button alle nicht gefundenen Daten beim 2. Versuch nicht senden?

[svethi]

Aha, ich sehe schon, da gibt es viele Daten in JSON‘s. Ist dann schwieriger einzeln zu filtern.

[mastercheef]

Hab's schon. 👍
das hab ich ja direkt übersehen dass hier sauber per RegEx gefiltert werden kann.
Kurz ein paar Filter reingeklopft und es läuft absolut smooth.

Besten Dank!

[svethi]

👍🏻

[brau01ma]

Wenn ich den go-eCharger V3 per MQTT anbinde, werden mir eigentlich gleiche Parameter jeweils so angezeigt wie im Anhang..
Kann ich das irgendwie umgehen?

[Vossi]

Wenn du sie nicht brauchst, hau sie einfach in den RegEx Filter

[brau01ma]

Ja, aber ich brauche sie ja.
Die Variable steht ja links, was eigentlich nach rechts muss wo aktuell die 1 steht.

[Christian Fenzl]

Das ist ein Array - wie schaut denn die JSON-Payload im Original aus?
Manchmal sind die gelieferten Datenmodelle "schräg", Zb warum.wird ein Wert als Array geliefert.

[brau01ma]

Im original sieht es so aus:

"lcctc":499704377,"tma":[13,18],"amt":32,"nrg":[227,227,228,0,0,0,0,0,0,0,0,0,0,0,0,0],

Ist das ausreichend?
auch der Parameter nrg bringt das im MQTT Gateway genauso angezeigt.