search

goecharger / go-eCharger-API-v2

New API specification for V3 and V4 go-eCharger
91 stars 20 forks source link

Erweiterte MQTT Parameter #36

Closed copacetic82 closed 2 years ago

copacetic82 commented 2 years ago

Es wäre gut in den MQTT Einstellungen ein QoS level (0,1,2) definieren zu können. Vor allem hilfreich bei empfindlichen Netzwerkverbindungen wie WLAN, wo die eine oder andere MQTT message evtl. verloren geht. Ebenso hilfreich wäre um den retained parameter setzen zu können

0xFEEDC0DE64 commented 2 years ago

ist denn irgendein parameter nicht retained? die idee wars eigentlich, dass direkt nach dem verbindungsaufbau einmal alle api-keys als retained an den broker gepublished werden, und dann bei Veränderungen einzelne werte erneut retained zu publishen.

copacetic82 commented 2 years ago

Ich habe es grad kontrolliert, die Parameter werden in meinem broker als retained angezeigt. Da ich das nicht in der konfiguration angeben kann, bin ich davon ausgegangen, dass der parameter nicht gesetzt ist. Wie verhält sich der go-e betreffend MQTT QoS? Mit welchem QoS werden die messages piblished? Mein Broker zeigt mir ein QoS von 0 an, wobei ich bei WLAN mindestens 1 für sinnvoll halte.

peterpoetzi commented 2 years ago

Da MQTT auf TCP basiert, werden verlorene Pakete ohnehin erneut gesendet, auch bei einem QoS von 0. Wenn die Verbindung abbricht, sendet der go-eCharger sowieso alle API keys erneut, so dass kein Verlust auftreten kann. Daher sind andere QoS Levels in dieser Applikation nicht sinnvoll.

copacetic82 commented 2 years ago

Stimmt bzw. hilft auch schon bei verlustbehafteten Netzwerken....jedoch betrifft es nur den TCP Stack. Applikationsseitig (Layer 7) wird mit QoS 0 nichts bestätigt, somit aus meiner Sicht schon sinnvoll. Habe schon meine Erfahrung mit nicht-funktionierenden Brokern gemacht wo z.B. lichter von allein angegangen sind, bis das entsprechend MQTT topic gelöscht wurde. Ich werde aber wahrscheinlich bei wichtigen Daten (z.B. Abrechnungsrelevanter Verbrauch) auf direkte API calls zurückgreifen, das ist glaub ich besser.

Am Do., 28. Okt. 2021 um 12:50 Uhr schrieb Peter Pötzi < @.***>:

Da MQTT auf TCP basiert, werden verlorene Pakete ohnehin erneut gesendet, auch bei einem QoS von 0. Wenn die Verbindung abbricht, sendet der go-eCharger sowieso alle API keys erneut, so dass kein Verlust auftreten kann. Daher sind andere QoS Levels in dieser Applikation nicht sinnvoll.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/goecharger/go-eCharger-API-v2/issues/36#issuecomment-953730254, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK4LTSTQ7ZXXVW7YMDQXUB3UJE2GZANCNFSM5GXETGCQ .