Dsmr-reader: MQTT does connect/publish/disconnect for EACH message - every second

[ualex73]

I like DSMR Reader, but the MQTT client seems a bit inefficient. DSMR Reader does connect/publish/disconnect for each message. I am have DSMR 5+, so this happens every 1 second. All my other clients, including HA, use a persistent connection to the MQTT Broker.

[dennissiemensma]

Bedankt voor je scherpe opmerking. Ik heb even gekeken hoe dat komt en of het op te lossen is, maar ik zie nog niet zo 1-2-3 een oplossing daarvoor.
Standaard wordt een Keep-Alive gehanteerd van 60 seconden, echter mogelijk wordt de verbinding alsnog afgesloten, afhankelijk van de manier van telegrammen aanleveren.

Gebruik je de standaard datalogger of voer je telegrammen in via de API? Bij laatstgenoemde wordt de API-call (request), en dus ook de MQTT-verbinding, sowieso afgesloten. Want het versturen via MQTT gaat synchroon met het verwerken van het telegram, dus sluit het proces alle gebruikte resources (als een webserver).

[ualex73]

Ja, ik gebruik de standaard datalogger voor het ontvangen van de telegrammen. Alleen ik zie hier duidelijk een connect/publish/disconnect op de MQTT verbinding. De "publish.single(...)" (of "publish.multiple(...)") doen de connect/publish/disconnect volgens mij (zonder dat je het kan zien).

De keep-alive waarde is wat je doorgeeft aan de MQTT broker, indien de client (dus DSMR Reader) geen keep-alive stuurt in die tijd, wordt de verbinding opgeruimd door de Broker en dient de client opnieuwe te connecten. Op dit moment halen we die 60 seconden nooit ;-)

Het volgende voorbeeld:
https://github.com/eclipse/paho.mqtt.python/blob/master/examples/client_pub-wait.py

Toont dat je een MQTT verbinding moet opzetten en daarna kan je publish blijven sturen ... natuurlijk moet je bijhouden of de link open is, reconnect indien nodig (en dan een generiek procedure waar je al je publish message naartoe stuurt) en natuurlijk niet de keep-alive vergeten te sturen. Ik ben zelf niet zo bekend met Python, dus ik weet niet hoe makkelijk/moeilijk is.

[ualex73]

BTW als we dit implementeren, kunnen we ook SSL/TLS ondersteuning toevoegen aan MQTT? Security wordt steeds belangrijker ;-) (al mijn andere devices doen all MQTT met TLS v1.1/1.2)

[dennissiemensma]

Bedankt voor je toevoegingen. Waarschijnlijk kan ik dan wel iets maken voor de datalogger, al moet ik even kijken hoe dat qua architectuur kan.
En anders zal ik het versturen via MQTT asynchroon moeten maken, maar dat heeft niet mijn voorkeur gezien het complexer wordt en niet perse dit issue oplost.

[ualex73]

Klopt, het hoeft niet asynchroon, zolang het maar de connectie kan hergebruiken.

[dennissiemensma]

Ik had je verhaal over SSL gemist, ik heb er een los issue voor aangemaakt:

SSL/TLS support for MQTT #505

[ualex73]

Thanks 👍

[dennissiemensma]

Wat betreft dit huidige issue, ik heb hier nog even over nagedacht. De huidige architectuur van DSMR-reader laat dit niet makkelijk oplossen, omdat er een mix is van langelopende en kortlopende processen die MQTT gebruiken.

De enige structurele verbetering die ik hiervoor zie, is het verplaatsen van alle te versturen MQTT-berichten naar een aparte queue en die dan door het backend-proces laten versturen. En dan iets te maken die ervoor zorgt dat het backend-process slechts éénmalig verbindt én een keep-alive stuurt.

Ik weet dus niet 100% zeker of dat gaat werken, maar het is iets voor mij om uit te proberen.

[dennissiemensma]

Ik ben in #509 bezig met een herbouw van de onderliggende architectuur en ik kom er op uit dat de meest betrouwbare (en robuuste manier) van MQTT messaging, een apart proces is. Zoals dsmr_backend en dsmr_datalogger.

Hiermee kan ik garanderen dat er maar één client nodig is, die zowel reageert op de webinterface (API) als datalogger. Daarnaast zal dit proces niet de backend in de weg zitten en andersom ook niet.

[ualex73]

Klinkt als een goede oplossing van het "probleem", indien je een tester zoekt ... laat het maar horen :-)

[dennissiemensma]

Bedankt, dat zal ik dan zeker doen.

Ik heb een eerste opzet inmiddels klaar, maar alle tests moeten nog aangepast en toegevoegd worden. Zodra dat goed werkt, en het uit te proberen is, laat ik het je weten.

[dennissiemensma]

Waarschijnlijk kun je het morgen wel uitproberen.

De versie die ik nu heb staan lijkt goed te werken. Ik ben nog bezig met de afwerking voor wanneer de verbinding naar de broker wegvalt. Voor de rest draait het prima.

[ualex73]

Thanks, dan wacht ik nog even af :+1:

[dennissiemensma]

@ualex73 je kunt het uitproberen.

• Zorg er wel voor dat je voor de zekerheid een backup van je database hebt. Niet dat de wijzigingen zo spannend zijn, maar altijd just in case.

sudo su - dsmr
git fetch
git checkout -b 509-mqtt-refactoring origin/509-mqtt-refactoring
./post-deploy.sh

Let op: Als je de applicatie bekijkt, staat er een melding met een verwijzing naar de changelog voor meer informatie. Echter, omdat dit nog niet gereleased is, is die pagina nog niet bijgewerkt.

Hier staat een schaduwkopie van die pagina:

• https://dsmr-reader.readthedocs.io/nl/509-mqtt-refactoring/changelog.html#v1-23-0-2018-xx-xx

En de verwijzing op die pagina gaat uiteindelijk straks hier naar toe:

• https://dsmr-reader.readthedocs.io/nl/509-mqtt-refactoring/faq.html#how-do-i-retain-mqtt-support-when-upgrading-to-v1-23-0-or-higher

Mochten die instructies niet duidelijk genoeg zijn dan hoor ik het uiteraard graag.

Je kunt altijd terug met:

sudo su - dsmr
git checkout master
./post-deploy.sh

[ualex73]

Thanks, ik zal er een Docker image van maken en dan uitproberen (zal morgen worden, ik moet vanavond werken :-()

[dennissiemensma]

Prima hoor.

Ik heb daarnaast nu ook in #505 / 4b09665f47aed321d92c3e42484261f24c190df5 een opzet klaar staan met ondersteuning voor SSL/TLS. Mocht bovenstaande refactoring goed werken, dan mag je dat eventueel als follow-up uitproberen.
Ik heb het zelf werkend gekregen met een self-signed certificaat, maar ik weet niet wat jullie doorgaans zelf gebruiken voor MQTTS.

[ualex73]

Het goede nieuws, ik heb toch even tijd gevonden om het uit te proberen ... Dus ik laat het even draaien vanavond en ik kijk morgenochtend of alles stabiel is gebleven.

Zodra 1.23.0 uitkomt, push ik hem direct naar mijn docker (https://hub.docker.com/r/ualex73/dsmr-reader-docker/). Was een kopie van Xixiz, maar die loopt wat achter :-( Misschien wil je hier ook een linkje in je wiki voor toevoegen?

Morgen kijk ik ook naar de SSL/TLS fix :-) Alvast bedankt voor het harde werk.

[dennissiemensma]

Goed om te horen! Ik had je ondertussen al toegevoegd in de betreffende branch hoor, maar was het vergeten te melden. ;-)

[ualex73]

Mooi :+1:

Ik kan ook bevestigingen dat de MQTT refactoring hier goed werkt.

Alleen ik zag in je revisies ook nog het volgende "DSMRREADER_MQTT_SLEEP" ... Zoals ik het begrijp, doet doe je een sleep van 1 seconden tussen elke MQTT publish? Dat hoef je echt niet te doen, want je krijgt de MQTT broker niet zo snel stuk hoor ;-)

[ualex73]

Andere korte vraag ... In de MQTT zie ik nog geen laag/normaal tarief flag/waarde (ik heb hem wel in mijn dsmr telegram), of zie ik die over het hoofd?

[dennissiemensma]

Ik kan ook bevestigingen dat de MQTT refactoring hier goed werkt.

Top, dus daarmee is het oorspronkelijke issue van dit ticket opgelost?

---

Zoals ik het begrijp, doet doe je een sleep van 1 seconden tussen elke MQTT publish? Dat hoef je echt niet te doen, want je krijgt de MQTT broker niet zo snel stuk hoor ;-)

Bijna, het werkt andersom. Namelijk om de load van het systeem, waar dsmr-reader op draait, laag te houden. Het proces leest (en verstuurt) maximaal 50 berichten uit de queue (vaak zijn het er slechts een handvol per run). Daarna wacht die even een seconde voordat die bovenstaande opnieuw doet.

Het staat je vrij om DSMRREADER_MQTT_SLEEP lager te zetten. Maar ik zou het eerlijk gezegd alleen veranderen wanneer je ziet dat er een merkbare vertraging is en je er last van hebt. De vertraging is overigens nooit nul, wegens de overhead van het proces zelf.

---

Andere korte vraag ... In de MQTT zie ik nog geen laag/normaal tarief flag/waarde (ik heb hem wel in mijn dsmr telegram), of zie ik die over het hoofd?

Ik heb dit onderdeel gemaakt van de (MQTT) meterstatistieken, omdat het vlaggetje hooguit twee x per dag verandert. Zie binnen MQTT voor electricity_tariff = dsmr/meter-stats/electricity_tariff in de betreffende instellingen.

[dennissiemensma]

Gaat mee in volgende release.

[ualex73]

Aha, the MQTT sleep werkt dus anders dan ik dacht ... 👍 Een kleine vertraging is ansich niet erg, zolang het maar niet (vele) seconden wordt. Okee, ik heb de electricity_tariff gevonden, over het hoofd gezien, sorry.

[dennissiemensma]

@ualex73 v1.23.0 is nu uit, dus je kunt weer wisselen naar master:

git fetch
git checkout master
./deploy.sh

Als het goed is blijft alles werken zoals het was.

[ualex73]

Yups, ik zag v1.23.0 voorbij komen (ik zag de commit op github.com) ... Mijn docker is nu aan het bouwen en als het draait, push ik hem naar hub.docker.com.

[dennissiemensma]

@perryodk / @trizz ter info, de nieuwe release heeft ondersteuning voor TLS/SSL (gezien jullie een duimpje deden bij dit comment).

[trizz]

@dennissiemensma thanks! Op dit moment heb ik het niet (meer) nodig, aangezien ik de backend en webinterface (en nu dus ook het MQTT proces) op dezelfde server heb draaien als Mosquitto.

Upgrade ging probleemloos (zoals gewoonlijk).

[dennissiemensma]

Top, bedankt voor je input.

[perryodk]

@dennissiemensma bedankt voor het toevoegen van TLS/SSL voor MQTT! Het werkt prima!