Dsmr-reader: Optie om MQTT-integratie niet telkens uit te schakelen bij falende verbinding
Wat gebruik je?
- DSMR-reader versie: 4.2
- Type RaspberryPi or server: Arch Linux
- Standaardinstallatie of Docker: Standaard installatie (python 3.8.5)
- DSMR-protocol slimme meter v4/v5: DSMR v4
Steeds na een reboot van mijn server heeft DSMR Reader de MQTT verbinding uitgezet. Het vinkje 'Ingeschakeld' onder 'MQTT broker/verbinding wijzigen' is dan niet meer geselecteerd.
Ik vermoed dat dit komt omdat mijn MQTT server (RabbitMQ), welke op dezelfde server staat, pas later opstart dan dsmr_backend.
Relevante log:
Current logging level set to "ERROR". More information can be found here: https://dsmr-reader.readthedocs.io/en/v4/troubleshooting.html#logging
[2020-08-24 14:16:40,772] ERROR MQTT: Failed to connect to broker (localhost:1883), disabling MQTT: [Errno 111] Connection refused
[2020-08-24 14:16:40,787] ERROR Failed to connect to broker
NoneType: None
mvdnes
All 33 comments
Kan bevestigen dat RabbitMQ inderdaad later start dan DSMR Reader.
De log hierboven is van 14:16:40, RabbitMQ is gestart op 14:16:50.
-- Logs begin at Tue 2020-03-24 21:03:56 CET, end at Wed 2020-08-26 13:43:45 CEST. --
aug 24 14:16:33 hostname systemd[1]: Starting RabbitMQ broker...
aug 24 14:16:50 hostname rabbitmq[7735]: ## ## RabbitMQ 3.8.4
aug 24 14:16:50 hostname rabbitmq[7735]: ## ##
aug 24 14:16:50 hostname rabbitmq[7735]: ########## Copyright (c) 2007-2020 VMware, Inc. or its affiliates.
aug 24 14:16:50 hostname rabbitmq[7735]: ###### ##
aug 24 14:16:50 hostname rabbitmq[7735]: ########## Licensed under the MPL 1.1. Website: https://rabbitmq.com
aug 24 14:16:50 hostname rabbitmq[7735]: Doc guides: https://rabbitmq.com/documentation.html
aug 24 14:16:50 hostname rabbitmq[7735]: Support: https://rabbitmq.com/contact.html
aug 24 14:16:50 hostname rabbitmq[7735]: Tutorials: https://rabbitmq.com/getstarted.html
aug 24 14:16:50 hostname rabbitmq[7735]: Monitoring: https://rabbitmq.com/monitoring.html
aug 24 14:16:50 hostname rabbitmq[7735]: Logs: /var/log/rabbitmq/[email protected]
aug 24 14:16:50 hostname rabbitmq[7735]: /var/log/rabbitmq/rabbit@hostname_upgrade.log
aug 24 14:16:50 hostname rabbitmq[7735]: Config file(s): /etc/rabbitmq/rabbitmq.conf
aug 24 14:16:53 hostname systemd[1]: Started RabbitMQ broker.
aug 24 14:16:53 hostname rabbitmq[7735]: Starting broker... completed with 4 plugins.
Bedankt voor je melding en de debugging. Ik heb hier nog geen goede middenweg in kunnen vinden.
Enerzijds is het niet de bedoeling dat DSMR-reader dit soort acties oneindig probeert (want dat doet het wel zonder ingrijpen) en anderzijds is het niet de bedoeling dat dit mechanisme de 'legitieme' foutsituaties verkeerd intepreteert zoals nu gebeurt.
Wellicht dat ik hier iets van een toegestane marge of 'timeout' van fouten voor moet gaan gebruiken.
dennissiemensma
on 26 Aug 2020
Op de korte termijn zou je kunnen kijken of je een workaround kan maken door boot-volgorde van Supervisor aan te passen, want ik heb hier niet direct een oplossing voor.
Ik weet niet of dat mogelijk is, maar ik lees wat over systemd en het definieren van afhankelijkheden in de After regel binnen de [Unit] van de systemd-config voor een proces. Die zou dan moeten wachten op RabbitMQ.
dennissiemensma
on 26 Aug 2020
Met het commando sudo systemctl edit supervisord.service heb ik nu het volgende toegevoegd:
[Unit]
After=rabbitmq.service
Daarmee lijkt het nu wel tijdelijk te werken, bedankt voor de tip.
Desalniettemin zou ik graag een oplossing in DSMR Reader zien, omdat ik het aantal overrides toch zo laag mogelijk wilt houden.
Wat ik vooral vreemd vond is dat het vinkje elke keer uitgezet werd. Een optie die ik doelbewust had aangeklikt. Wellicht dat mensen die dit zelf aanklikken wel accepteren dat er 'oneindig' word geprobeerd? Zeker als dat met iets als exponential backoff zou gebeuren, zou ik dat juist fijn vinden.
mvdnes
on 28 Aug 2020
Bedankt voor de terugkoppeling. De reden dat het vinkje telkens uit wordt gezet is om te voorkomen dat (externe) services oneindig gespamd worden.
In het verleden zijn er issues zoals #841 en vooral #264, waardoor ik er wat terughoudender in ben geworden. Ik kan namelijk niet het verschil zien tussen of de configuratie onjuist is of de host simpelweg onbereikbaar is.
Inderdaad een backoff en/of een beperkt aantal pogingen zou dit wellicht al op kunen lossen.
dennissiemensma
on 29 Aug 2020
Ik heb besloten om dit toch maar wat eenvoudig/pragmatisch op te lossen met een nieuw vinkje onderaan voor MQTT:
Gaat mee in v4.4.
dennissiemensma
on 9 Sep 2020
Dit is voor mij een prima oplossing. Bedankt! :+1:
mvdnes
on 10 Sep 2020
Request: kan je (optioneel) mails/notificaties naar jezelf laten sturen indien:
- de MQTT verbinding breekt / niet meer lijkt te werken
- een reconnect naar de MQTT server mislukt
- de applicatie besluit om geen reconnect pogingen meer te doen.
mchangsp
on 22 Sep 2020
Bedankt voor je melding en de debugging. Ik heb hier nog geen goede middenweg in kunnen vinden.
Enerzijds is het niet de bedoeling dat DSMR-reader dit soort acties oneindig probeert (want dat doet het wel zonder ingrijpen) en anderzijds is het niet de bedoeling dat dit mechanisme de 'legitieme' foutsituaties verkeerd intepreteert zoals nu gebeurt.
Wellicht dat ik hier iets van een toegestane marge of 'timeout' van fouten voor moet gaan gebruiken.
Wellicht helpt deze pagina je in te bepalen hoe om te gaan met deze foutsituaties:
https://docs.microsoft.com/nl-nl/azure/architecture/patterns/retry
mchangsp
on 22 Sep 2020
@mchangsp Bedankt voor je input. Voor nu houd ik het bij een simpel vinkje.
Wat betreft notificaties, ik denk daar geen rol voor DSMR-reader in zit qua scope. Dat klinkt meer als een taak voor monitoringsoftware. De applicatie zal straks altijd proberen te reconnecten.
dennissiemensma
on 22 Sep 2020
Zojuist uitgebracht in v4.4
dennissiemensma
on 25 Sep 2020
Dank je! Ik heb een update gedaan naar v4.4. Update is geslaagd. Nogmaals dank!
mchangsp
on 25 Sep 2020
Fijn om te horen!
dennissiemensma
on 25 Sep 2020
Het lijkt er nu op dat, als de verbinding is mislukt tijdens het opstarten, er niet nogmaals geprobeerd wordt om een nieuwe verbinding te maken. Klopt dat? Het vinkje blijft wel aan staan, maar pas als ik ofwel dsmr_backend herstart, ofwel naar de settings ga en op de broker pagina op opslaan klik, wordt de MQTT verbinding opnieuw geprobeerd.
mvdnes
on 13 Oct 2020
Ik heb gemerkt dat wanneer alles draait, en dat ik dan de mqtt server stop en weer start, dat het dsmrreader niet lukt om weer verbinding met de mqtt server te krijgen.
Dus het reconnected lijkt niet goed te gaan.
Als ik dsmrreader opnieuw start, dan gaat het weer goed.
mchangsp
on 13 Oct 2020
Ik denk dat jullie het beste even in de logs kunnen kijken en delen of daar wat in staat.
Als er niets in staat, dan debug modus tijdelijk aanzetten om te zien welke 'beslissingen' DSMR-reader neemt (als die gelogd worden).
dennissiemensma
on 13 Oct 2020
Ik denk dat jullie het beste even in de logs kunnen kijken en delen of daar wat in staat.
Als er niets in staat, dan debug modus tijdelijk aanzetten om te zien welke 'beslissingen' DSMR-reader neemt (als die gelogd worden).
OK, ik probeer iets reproduceerbaars te maken. Als dat lukt, dan zal ik een nieuwe post maken.
mchangsp
on 14 Oct 2020
Als ik dsmr_reader start zonder dat rabbitmq draait krijg ik deze melding:
[2020-10-14 09:57:21,764] ERROR Failed to connect to broker, retrying next run...
NoneType: None
Daarna krijg ik geen meldingen meer. Ook niet na het starten van rabbitmq.
mvdnes
on 14 Oct 2020
Zelfde issue hier, na een restart vd mqtt server reconnect damr niet enige oplossing is door de settings van de mqtt verbinding opnieuw op te slaan of enable disable.
Bart
bartbakels
on 15 Oct 2020
Bedankt voor jullie meldingen. Ik kijk er voor de volgende release opnieuw naar.
dennissiemensma
on 15 Oct 2020
Ik heb hier een fix voor gemaakt in de volgende release. Oorzaak was het samenvoegen van het voormalige dsmr_mqtt proces met dsmr_backend. Verbindingsfouten zorgden niet voor een herstart, waar dat bij dsmr_mqtt eerder wel was. En daarom is dit ook een issue geworden, omdat dat eerder (onbedoeld, maar correct) zichzelf herstelde.
In de nieuwe release is daarom die extra checkbox voor reconnecten weer weggehaald. Dat is nu standaard gedrag.
dennissiemensma
on 18 Oct 2020
Mocht iemand hier niet op Docker zitten en het zelf al even vroegtijdig willen proberen, laat vooral even weten.
dennissiemensma
on 18 Oct 2020
Zojuist uitgebracht in v4.5
dennissiemensma
on 19 Oct 2020
Na net een reboot te hebben gedaan met versie 4.5 lijkt het allemaal te werken. Bedankt weer!
mvdnes
on 20 Oct 2020
Ik draai onder Docker. Ik heb versie 4.5 laten installeren en het lijkt hier ook allemaal al 2 dagen te werken. Dank je wel!
mchangsp
on 20 Oct 2020
Fijn, dank voor de terugkoppeling
dennissiemensma
on 20 Oct 2020
Docker geupdate, runt nu versie 4.5
Ik zie echter de checkbox van het screenshot hierboven ('keep reconnecting' in de MQTT pagina) niet:
kvh83
on 6 Nov 2020
Volgens mij heeft Dennis de checkbox weer weggehaald. Zie https://github.com/dsmrreader/dsmr-reader/issues/1091#issuecomment-711143495
Ik draai v4.6 en bij mij is de checkbox ook weg (zoals het waarschijnlijk hoort).
mchangsp
on 6 Nov 2020
Thx @mchangsp, die comment had ik gemist.
Helaas reconnect ie bij mij niet (of niet altijd)
Als ik de container herstart, komt de data weer binnen in MQTT
kvh83
on 6 Nov 2020
Thx @mchangsp, die comment had ik gemist.
Helaas reconnect ie bij mij niet (of niet altijd)
Dat is vervelend.
In dat geval kan je het beste logs aanmaken in DSMR en dan hier posten.
Zie https://dsmr-reader.readthedocs.io/nl/v4/troubleshooting.html
Misschien ziet Denns of iemand anders wat er aan de hand is.
mchangsp
on 6 Nov 2020
Thx @mchangsp, die comment had ik gemist.
Helaas reconnect ie bij mij niet (of niet altijd)Als ik de container herstart, komt de data weer binnen in MQTT
Wat denk je dat de oorzaak is dat DSMR stopt met het versturen van berichten naar de MQTT server? Welke software gebruik je voor de MQTT server? Kunnen andere applicaties wel gewoon berichten versturen naar de MQTT server?
mchangsp
on 6 Nov 2020
Ik gebruik moquitto. Andere SW kan nog wel gewoon data versturen (checked met MQTT explorer)
kvh83
on 6 Nov 2020
Ik gebruik moquitto. Andere SW kan nog wel gewoon data versturen (checked met MQTT explorer)
OK dank je. Ik gebruik ook mosquitto. En ik begrijp dat je DSMR Reader in Docker draait. Dat doe ik ook.
Misschien haal je inspiratie uit onderstaande:
Bij mijn upgrade van 4.5 naar 4.6 ging iets mis tijdens het genereren van de Docker containers (ik draai DSMR Reader op een Raspberry Pi in Docker met behulp van https://github.com/xirixiz/dsmr-reader-docker)
Toen heb ik containers + images weggegooid en alles opnieuw gedownload (een docker-compose up -d met de juiste YAML file doet wonderen). Toen werkt alles weer.
(tip: ik gebruik ook https://www.portainer.io/ omdat ik al die Docker command lines niet kan onthouden).
Ik moest ook overstappen naar nieuwe environment variabelen.
Hier kan je mijn Docker file downloaden: https://github.com/xirixiz/dsmr-reader-docker/issues/148#issuecomment-720704681
mchangsp
on 6 Nov 2020
Related issues
bikeymouse
路
10Comments
T1rnanog
路
10Comments
Calimerorulez
路
9Comments
dennissiemensma
路
11Comments
GreyEarl
路
9Comments
Most helpful comment
Ik heb hier een fix voor gemaakt in de volgende release. Oorzaak was het samenvoegen van het voormalige dsmr_mqtt proces met dsmr_backend. Verbindingsfouten zorgden niet voor een herstart, waar dat bij dsmr_mqtt eerder wel was. En daarom is dit ook een issue geworden, omdat dat eerder (onbedoeld, maar correct) zichzelf herstelde.
In de nieuwe release is daarom die extra checkbox voor reconnecten weer weggehaald. Dat is nu standaard gedrag.