Jump to content

MQTT intervall


michael99

Recommended Posts

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.

Link zu diesem Kommentar
Share on other sites

  • 6 months later...

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 :)

Link zu diesem Kommentar
Share on other sites

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 ;-)

 

Link zu diesem Kommentar
Share on other sites

  • 2 weeks later...
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

Link zu diesem Kommentar
Share on other sites

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.

 

Link zu diesem Kommentar
Share on other sites

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 von floho
Link zu diesem Kommentar
Share on other sites

  • 2 months later...

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.

Link zu diesem Kommentar
Share on other sites

  • 4 weeks later...

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

Link zu diesem Kommentar
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gast
Reply to this topic...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...