MQTT intervall

[michael99]

Hallo,

 

meine Wallbox sendet in Sekundenabständen etliche Informatioen über MQTT. Ist das Intervall irgendwie einzustellen?

Michael

[rtrbt]

Moin,

Stand jetzt kannst du das nicht einstellen. Die Wallbox schickt MQTT-Nachrichten nur bei Änderung der Werte, prüft aber jede Sekunde auf Änderungen, auch damit das Webinterface nicht extrem langsam ist (das Webinterface benutzt bis auf MQTT selbst die selben Mechanismen). evse/state und ein paar andere Topics beinhalten Werte, die sich praktisch immer ändern (z.B. die Uptime), deshalb bekommst du jede Sekunde eine Nachricht. Ich habe noch auf der TODO-Liste mir zu überlegen ob und wenn ja wie man das limitieren kann.

[michael99]

Ja, das wäre doch erfreulich, denn was jede Sekune gesendet wird, belastet unnötig das Netz. Bei mird es auch noch von FHEM gespeichert.

[chris_kmn]

Moin zusammen,

ich würde mich dem Wunsch anschließen. Wundervoll wäre es das Intervall und die Botschaften auswählen zu können. Den kompletten Payload benötigt man wohl nur in den seltensten Fällen.

viele Grüße, Chris

[floho]

🤚

[alestrix]

Was das sekündliche Schreiben auf Flash-Speicher (ich nehme einfach mal an, FHEM läuft auf einem Minicomputer mit SD-Karte) angeht, kann ich das gut nachvollziehen - lange macht die Karte das wahrscheinlich nicht mit...

Aber was die "Netzverseuchung" angeht - ich weiß nicht so recht... Bei mir werden pro Sekunde etwa 480 Byte (keys+payload) per MQTT von der WARP versendet. Selbst wenn das mit MQTT-, TCP- und IP-Protokolloverhead auf den Faktor 3 ansteigen würde, ist man bei etwa 12kbps. Ist das für heutige Haus-LANs tatsächlich ein Problem?

Was ich damit sagen will: Nicht alles, was auf den ersten Blick wie ein Problem aussieht, ist auch eines :)

[floho]

Das stimmt natürlich, solange man die Box einzeln betrachtet. Allerdings gibt es da Shellys, andere MQTT Sensoren, Gateways, mehrere Wallboxen, ... und es ist auch das WLAN welches belastet wird, nicht das LAN. Somit bin ich generell bei dir, fände aber dennoch eine Möglichkeit gut die zyklischen Daten nicht pauschal im vollen Set und sekündlich zu senden. Eine niederpriores Anliegen, aber wert überdacht zu werden ;-)

 

[E-t-h]

Am 16.4.2021 um 09:27 schrieb michael99:

Ja, das wäre doch erfreulich, denn was jede Sekune gesendet wird, belastet unnötig das Netz. Bei mird es auch noch von FHEM gespeichert.

Du kannst im FHEM unter DbLogInclude die Intervalle zum abspeichern einstellen (gehe davon aus dass Du in eine DB loggst).
Bsp.
attr GT_Warp_1 DbLogInclude energy_abs:3600,energy_rel:3600,vehicle_state:3600

[michael99]

 Es ist doch ohne Zweifel richtig, dass das Intervall der MQTT Publishings eingestellt werden kann. Über Sinn und Zweck muss man nicht lange diskutieren, sondern es einfach lösen. Also bitte sorgt dafür.

[floho]

Wurde doch schon aufgenommen. Warum so pampig? Klingt zumindest für mich so. Ein workaround bis es soweit ist, ist wohl auch kein Angriff.

schönen restlichen Abend, Florian. 

[michael99]

vor 3 Minuten schrieb floho:

Wurde doch schon aufgenommen. Warum so pampig? Klingt zumindest für mich so. Ein workaround bis es soweit ist, ist wohl auch kein Angriff.

schönen restlichen Abend, Florian. 

Hallo,

ich bin also pampig wenn ich indirekt daran erinnere, dass wir jetzt November haben und mein Wunsch seit Apriil ja bekannt ist. Dass es als Änderung aufgenommen wurde, ergibt sich nicht aus den Antworten. Für die Programmierer dürfte es doch eine ganz kleine Änderung sein, für die man nicht Monate braucht.

 

[floho]

Guten Morgen, 

ja, der "Ton" kommt mir pampig rüber, auch wenn ein Grund dafür angeführt wird. Ich will hier nicht den Lehrer spielen, natürlich "darfst" Du das machen wie du willst. 

Ich denke: wenn man eine WB von "klassischen" Firmen kauft, werden Kundenwünsche in der Regel nicht umgesetzt, hier wird auf fast jeden Wunsch eingegangen. Dadurch entsteht wohl so eine Art Selbstverständnis dass alles umbesetzt werden muss, wie man es übrigens öfters bei Open Source und kundennahen Projekten beobachten kann. Gekauft wurde der ist-Zustand, der funktioniert. Somit ist diese Aufforderung keine Mangelbeseitigung, sondern ein Wunsch. Diese vermittle ich persönlich lieber nett ;-)

Gruß und schönen ersten Advent, Florian.

p.s. man hat sich ja auch für ein Open-Source Projekt entschieden ... also ran an den Speck Code ;-)

Edit: oben steht geschrieben, dass die WB bei Änderung sendet und Änderungen sekündlich geprüft werden. Eventuell ist das gar nicht so einfach gemacht wie 1000 auf 5000 zu ändern im Code. 

bearbeitet November 28, 2021 at 07:24 von floho

[michael99]

Guten Morgen,  Gibt es etwas Neues für den WARP1 zu berichten über den Stand meiner Anfrage?

[rtrbt]

Indirekt ja: In der WARP2 Beta, die wir gerade veröffentlicht haben sind uptime und time_since_state_change nicht mehr in evse/state sondern im Low-Level-State. Das führt dazu, dass wenn du nur auf evse/state subscribst nicht mehr sekündlich "Änderungen" reinkommen.

Alles weitere, also Kontrolle über Intervalle bzw. welche Topics überhaupt geschickt werden, gibt es noch nicht, wir werden aber voraussichtlich vor der finalen 2.0.0 (die dann auch für WARP 1 kommt) ein anderes Problem mit der MQTT-API angehen (dieses: https://github.com/Tinkerforge/esp32-firmware/issues/77). Im Zuge dessen sehen wir uns dann auch nochmal die Problematik an.

[michael99]

time_since_state_change nicht mehr in evse/state sondern im Low-Level-State.

Ich habe als Topic warp-SNk, evcc ergänzt es auf warp-SNk/evse/state. Darum läuft evcc auch auf einen Fehler. Da brauche ich mich nicht zu wundern. Da kommt dann die Meldung: charger: warp-SNk/evse/state outdated: 10s worüber ich bisher nichts gefunden hatte.

Wie kann ich das ändern?

Michael

[rtrbt]

EVCC unterstützt noch nicht die Firmware 2.0.0. Hier wird dran gearbeitet: https://github.com/evcc-io/evcc/pull/1700 Ich glaube aber, dass die Änderung damit EVCC mit einem geänderten MQTT-Sende-Intervall umgehen kann noch nicht im Pull-Request sind.