Invalid baud rate for Fluvius

[Woutch]

• DSMR-reader versie: v4.1
• Type RaspberryPi or server: VM onder Unraid
• Standaardinstallatie of Docker: Standaard
• DSMR-protocol slimme meter v4/v5: V5 - Fluvius

---

Sinds de upgrade naar v4.1 lijkt de datalogger niet meer te werken. Ik krijg geen nieuwe telegrams meer binnen. Upgrade naar 4.0 was wel goed verlopen.

Ik heb getracht de settings opniew aan te passen en te saven. Geen verschil. Ik heb manueel de seriele poort uitgelezen met: cu -l /dev/ttyUSB0 -s 115200 --parity=none -E q
Dit geeft elke seconde een telegram door.

onder .env de debug logging opgezet, maar er komt geen logging te voorschijn

Onder de DSMR user heb ik deze manueel getracht te starten: ./manage.py dsmr_datalogger --run-once -v 3
Deze blijft hangen en stopt nooit. Ik krijg ook geen logging te zien. (eerst onder supervisor dsmr_datalogger gestopt)

Als ik het process onderbreek lijkt hij vast te hangen op een seriele readline functie? Ofwel is hij juist aan deze functie bezig? Maar daar heb ik niet genoeg python kennis voor.

^C[2020-08-05 12:02:11,228] ERROR    dsmr_datalogger.management.commands.dsmr_datalogger: [!] Exception raised. Traceback (most recent call last):
  File "/home/dsmr/dsmr-reader/dsmr_backend/mixins.py", line 90, in run_once
    self.run(data=self.data, **options)
  File "/home/dsmr/dsmr-reader/dsmr_datalogger/management/commands/dsmr_datalogger.py", line 27, in run
    telegram = next(self.telegram_generator)
  File "/home/dsmr/dsmr-reader/dsmr_datalogger/scripts/dsmr_datalogger_api_client.py", line 42, in read_serial_port
    data = serial_handle.readline()
  File "/home/dsmr/.virtualenvs/dsmrreader/lib/python3.7/site-packages/serial/serialposix.py", line 483, in read
    ready, _, _ = select.select([self.fd, self.pipe_abort_read_r], [], [], timeout.time_left())
KeyboardInterrupt

ERROR:dsmrreader:dsmr_datalogger.management.commands.dsmr_datalogger: [!] Exception raised. Traceback (most recent call last):
  File "/home/dsmr/dsmr-reader/dsmr_backend/mixins.py", line 90, in run_once
    self.run(data=self.data, **options)
  File "/home/dsmr/dsmr-reader/dsmr_datalogger/management/commands/dsmr_datalogger.py", line 27, in run
    telegram = next(self.telegram_generator)
  File "/home/dsmr/dsmr-reader/dsmr_datalogger/scripts/dsmr_datalogger_api_client.py", line 42, in read_serial_port
    data = serial_handle.readline()
  File "/home/dsmr/.virtualenvs/dsmrreader/lib/python3.7/site-packages/serial/serialposix.py", line 483, in read
    ready, _, _ = select.select([self.fd, self.pipe_abort_read_r], [], [], timeout.time_left())
KeyboardInterrupt

Alvast bedankt voor de hulp.

Groetjes,
Wouter

[dennissiemensma]

Bedankt voor je melding. Ik zie sowieso dat ik nog een ander bugje erin heb. Ik weet niet of het ook de oorzaak is voor die van jou.

Wil je dit eens proberen?

sudo su - dsmr
git fetch
git checkout -b debug/v4.1/1067 origin/debug/v4.1/1067
./deploy.sh

Maakt dat verschil?

[Woutch]

Hey Dennis,

Ik heb dit geprobeerd, maar op het eerste zicht maakt dit geen verschil.

Ik zal eens kijken of ik iets in de logging kan vinden.
Ook komt er niets in de datalogger.log als debug op staat. Als deze niet op staat komt volgende er in:
Current logging level set to "ERROR". More information can be found here: https://dsmr-reader.readthedocs.io/en/v4/troubleshooting.html#logging

Dus hij gebruikt de logging level wel.

Groetjes

[dennissiemensma]

Zou je trouwens in de datalogger instellingen in de admin-interface eens willen dubbelchecken dat je de juiste poort hebt ingesteld en dat die op seriele input staat ipv netwerk?

Ik kan het alleen reproduceren met dezelfde blokkering op de readline als ik een seriele poort gebruik die wel bestaat maar niet uit te lezen is.

Ik heb ook nog een andere oorzaak als vermoeden, maar het vreemde is dat het hier op mijn Pi met seriele poort wel gewoon werkt.

[Woutch]

Dit zijn mijn instellingen:

Als ik volgende commando draai onder de dsmr omgeving krijg ik gewoon mijn telegrams te zien:
cu -l /dev/ttyUSB0 -s 115200 --parity=none -E q

[dennissiemensma]

Kun je nog eens updaten op die branch:

sudo su - dsmr
./deploy.sh

• Datalogger logging zou nu beter moeten werken.
• Ik heb wat veranderd in het gebruik van de seriele poort. Deze heropent hem nu telkens na elk telegram.

[Woutch]

Hoi, spijtig genoeg geen verschil.

Ik heb voor de update ook mijn debian installatie geupdate, zou een nieuwe versie van python ofzo mij parten kunnen spelen?

[dennissiemensma]

Dat is mogelijk. Wat is de output hiervan:

sudo su - dsmr
pip freeze | grep pyserial

[Woutch]

(dsmrreader) dsmr@dsmr:~/dsmr-reader$ pip freeze | grep pyserial
pyserial==3.4
pyserial-asyncio==0.4

[dennissiemensma]

Bedoel je dat je Debian hebt geupdate voordat je naar DSMR-reader 4.0 ging? Of daarna, maar voordat je naar 4.1 ging?

[Woutch]

Tijdens elke dsmr upgrade doe ik ook een package upgrade via apt update/upgrade.
Dus zowel naar 4.0 en naar 4.1 gedaan. Ben niet meer 100% zeker bij welke upgrade het was, maar heb ook python updates zien passeren. Python zelf zit op versie 3.7.3

[dennissiemensma]

Het makkelijkste is om dan even v4.0 weer te proberen. Dan weten we of het aan je OS ligt of aan de DSMR-reader versie. Ik vermoed het laatste, omdat er veel wijzgiingen zijn geweest aan de datalogger, maar ik kan het niet reproduceren.

Probeer 4.0 anders even:

sudo su - dsmr
sh dsmrreader/provisioning/downgrade/v4.0.sh
git checkout tags/v4.0.0
./deploy.sh

Dat downgradescript kan wel even duren merk ik hier.

Check na afloop ook even de datalogger-instellingen. Ik weet niet wat die ervan maakt bij het terugdraaien van migraties.

[dennissiemensma]

Het kan ook zijn dat je processen ondertussen crashen. Als de deploy ze niet start:

sudo supervisorctl restart all

[Woutch]

Ok, het draait weer :-)
Zat even vertraging op, maar momenteel verwerken ze weer

[dennissiemensma]

Oke bedankt voor het proberen. Ik heb dan geen directe oplossing voor je helaas.

[Woutch]

Geen probleem ik blijf wel even op versie 4.0 dan

[dennissiemensma]

Ik heb wat aangepast in de manier waarop de datalogger nu berichten inleest. Mogelijk wijzigt dat in jouw situatie iets.

Zou je dat morgenavond eens willen proberen?

sudo su - dsmr
git checkout debug/v4.1/1067
./deploy.sh

Als dat niet werkt kun je dus rustig weer terug naar v4.0:

sudo su - dsmr
sh dsmrreader/provisioning/downgrade/v4.0.sh
git checkout tags/v4.0.0
./deploy.sh

[Woutch]

Hoi, net even getest, nog identiek hetzelfde.

Terug gedowngrade naar 4.0 en werkt weer. Ik moet wel elke keer via supervisor de services herstarten, via deploy werkt het niet van de eerste keer.

Groetjes en bedankt al om dit mee uit te spitten.

[dennissiemensma]

Bedankt voor het proberen. Kon je toevallig zien in de debug log of er een andere foutmelding was? En of die op een andere plek bleef hangen?

[mrombouts]

Hallo Denis,
Ik heb hetzelfde probleem als hier beschreven. Ik ben momenteel terug naar 3.11 gegaan en een database restore gedaan. Ik zal volgend weekend eens terug naar 4.x gaan en kijken of ik verder kan helpen met debuggen.

Vraagje, zou het kunnen liggen aan Belgische telegrammen? Zowel Woutch als ik staan op de Belgische fluvius meter, jij kan het niet reproduceren...

Mvg

[dennissiemensma]

Bedankt voor je aanvulling @mrombouts ! Grote kans dat het dan daar in zit inderdaad, anders is het wel heel toevallig met twee keer fluvius. Het schijnt wel goed te gaan op DSMR-reader 4.0, dus je kunt ook daar eventueel op blijven. Dat scheelt je telkens de upgrade en database restore (er zijn wel scripts voor qua downgrade, ik zal dat beter documenteren).

Zouden jullie anders ook een telegram van jullie meter willen delen? Ik heb er hier al een staan voor automatische tests, maar wellicht is die van jullie anders.
Vergeet niet jullie ID/serienummers eruit te halen, in bovenstaande link zijn dat de fictieve nummers 12345678901234567890123456789012.

Los hiervan heb ik nu wel een idee waar het precies mis gaat, dus ik zal vanavond even kijken naar een nieuwere versie van de datalogger-oplossing voor jullie.

[Woutch]

Hoi Dennis,

Ik heb nog een paar testen gedaan. In de supervisor log komt nog steeds niets bij (in debug mode). Maar als ik hem manueel draai met --run-once krijg ik wel iets te zien. Het process blijft idd in een loop hangen en stopt niet.
Dit is de melding die dan blijft komen:

[2020-08-07 08:19:11,974] DEBUG    [2020-08-07 08:19:11.974912] Read 0 Byte(s)
[2020-08-07 08:19:12,976] DEBUG    [2020-08-07 08:19:12.976489] Read 0 Byte(s)
[2020-08-07 08:19:13,978] DEBUG    [2020-08-07 08:19:13.978031] Read 0 Byte(s)

Hier gaat hij er uit op ctrl-c, maar sinds hij wel lijkt te loopen over iets kan deze lijn een beetje random zijn.

^C[2020-08-07 08:19:16,664] ERROR    dsmr_datalogger.management.commands.dsmr_datalogger: [!] Exception raised. Traceback (most recent call last):
  File "/home/dsmr/dsmr-reader/dsmr_backend/mixins.py", line 90, in run_once
    self.run(data=self.data, **options)
  File "/home/dsmr/dsmr-reader/dsmr_datalogger/management/commands/dsmr_datalogger.py", line 27, in run
    telegram = next(self.telegram_generator)
  File "/home/dsmr/dsmr-reader/dsmr_datalogger/scripts/dsmr_datalogger_api_client.py", line 40, in read_telegram
    incoming_bytes = serial_handle.read(MAX_BYTES_PER_READ)
  File "/home/dsmr/.virtualenvs/dsmrreader/lib/python3.7/site-packages/serial/serialposix.py", line 483, in read
    ready, _, _ = select.select([self.fd, self.pipe_abort_read_r], [], [], timeout.time_left())
KeyboardInterrupt

Wat ook opvalt is dat er 5 telegrams in unprocessed staan. Deze worden ook niet verwerkt in de laatste versie. Maar dit is mss een stap na het ophalen.

Dan nog zoals gevraagd de telegrams.

/FLU5\253770234_A

0-0:96.1.4(50213)
0-0:96.1.1(12345678901234567890123456789012)
0-0:1.0.0(200807081625S)
1-0:1.8.1(001924.771*kWh)
1-0:1.8.2(002549.919*kWh)
1-0:2.8.1(001968.622*kWh)
1-0:2.8.2(000692.984*kWh)
0-0:96.14.0(0001)
1-0:1.7.0(00.000*kW)
1-0:2.7.0(00.411*kW)
1-0:32.7.0(236.4*V)
1-0:31.7.0(002*A)
0-0:96.3.10(1)
0-0:17.0.0(999.9*kW)
1-0:31.4.0(999*A)
0-0:96.13.0()
0-1:24.1.0(003)
0-1:96.1.1(12345678901234567890123456789012)
0-1:24.4.0(1)
0-1:24.2.3(200807081552S)(01414.287*m3)
!463B

(deze komt uit dsmr en hieronder recht van de seriele interface)

/FLU5\253770234_A

0-0:96.1.4(50213)
0-0:96.1.1(12345678901234567890123456789012)
0-0:1.0.0(200807082711S)
1-0:1.8.1(001924.771*kWh)
1-0:1.8.2(002549.919*kWh)
1-0:2.8.1(001968.710*kWh)
1-0:2.8.2(000692.984*kWh)
0-0:96.14.0(0001)
1-0:1.7.0(00.000*kW)
1-0:2.7.0(00.611*kW)
1-0:32.7.0(235.6*V)
1-0:31.7.0(002*A)
0-0:96.3.10(1)
0-0:17.0.0(999.9*kW)
1-0:31.4.0(999*A)
0-0:96.13.0()
0-1:24.1.0(003)
0-1:96.1.1(12345678901234567890123456789012)
0-1:24.4.0(1)
0-1:24.2.3(200807082502S)(01414.287*m3)
!973E

Groetjes,
Wouter

[dennissiemensma]

@Woutch dank voor de update. Wat zie je helemaal bovenaan de log? Daar staan namelijk de instellingen die gebruikt worden, bijvoorbeeld:

[2020-08-07 19:04:10,125] DEBUG    dsmr_datalogger.management.commands.dsmr_datalogger: Starting infinite command loop...
[2020-08-07 19:04:10,125] INFO     [2020-08-07 19:04:10.125454] Opening serial connection "/dev/fake-serial-reader" using
 options: {'baudrate': 115200, 'bytesize': 8, 'parity': 'N', 'stopbits': 1, 'xonxoff': 1, 'rtscts': 0}

Komen die wel overeen met hoe je het handmatig uitleest met cu?

Als het goed is kun je de output nog terugvinden in de logs, zonder weer te hoeven wisselen van branch.

[dennissiemensma]

@Woutch @mrombouts ik heb een nieuwe variant gemaakt van de datalogger. Deze is nog uitgebreider qua foutafhandeling tov v4.1:

• Na 20 seconden uitlezen stopt en logt het proces de huidige poging (zichtbare fout in logs). En laat zien of er data gelezen is en hoeveel tekens.

Als dat gebeurt dan kan het erop wijzen dat de gegevens wel gelezen worden, maar dat er geen telegram uitgehaald kan worden. Als die stopt, maar aangeeft dat er geen enkele data gelezen is, dan is het duidelijk dat het uitlezen uberhaupt niet werkt.

---

Dit is verplaatst naar een nieuwe branch:

sudo su - dsmr
git fetch
git checkout -b wip/v4.2 origin/wip/v4.2
./deploy.sh

Als dat niet werkt kun je weer terug naar v4.0:

sudo su - dsmr
sh dsmrreader/provisioning/downgrade/v4.0.sh
git checkout tags/v4.0.0
./deploy.sh

[mrombouts]

Hi Denis,

Ik heb naar 4.2 geupdate en zie hetvolgende:

[2020-08-07 20:31:58,048] DEBUG    dsmr_datalogger.management.commands.dsmr_datalogger: Starting infinite command loop...
[2020-08-07 20:31:58,049] INFO     [2020-08-07 20:31:58.049305] Opening serial connection "/dev/ttyUSB0" using options: {'baudrate': 9600, 'bytesize': 7, 'parity': 'E', 'stopbits': 1, 'xonxoff': 1, 'rtscts': 0}

daarna:

[2020-08-07 20:32:17,890] DEBUG    [2020-08-07 20:32:17.890398] Read 0 Byte(s)
[2020-08-07 20:32:18,141] DEBUG    [2020-08-07 20:32:18.141050] Read 0 Byte(s)
[2020-08-07 20:32:18,142] ERROR    dsmr_datalogger.management.commands.dsmr_datalogger: [!] Exception raised. Traceback (most recent call last):
  File "/home/dsmr/dsmr-reader/dsmr_backend/mixins.py", line 90, in run_once
    self.run(data=self.data, **options)
  File "/home/dsmr/dsmr-reader/dsmr_datalogger/management/commands/dsmr_datalogger.py", line 27, in run
    telegram = next(self.telegram_generator)
  File "/home/dsmr/dsmr-reader/dsmr_datalogger/scripts/dsmr_datalogger_api_client.py", line 46, in read_telegram
    len(buffer)
RuntimeError: It took too long to detect a telegram (timeout: 20s). Bytes currently in buffer: 0

Het lijkt of de baudrate niet juist staat...

mvg,
Michiel

[dennissiemensma]

Dank! Dat verklaart alles! Ik had er ook nog geen test voor, dus vandaar dat dit over het hoofd gezien is..

Bij deze de fix (7303f29) die het eindelijk zou moeten oplossen:

sudo su - dsmr
git fetch
git checkout -b wip/v4.1.1 origin/wip/v4.1.1
./deploy.sh

Als dit werkt dan maak ik er een release voor aan.

[mrombouts]

Yep... dat lijkt te werken.
v4.1.1 draait nu correct lijkt het

Bedankt!!

[dennissiemensma]

Jullie bedankt voor het geduld en testen!

[Woutch]

Dennis, idem hier, v4.1.1 draait correct.

Merci om dit te bekijken!!

Groetjes,
Wouter

[dennissiemensma]

Ik heb het uitgebracht in v4.1.1. Om weer op de normale release flow te komen kunnen jullie dit doen:

sudo su - dsmr
git checkout v4
./deploy.sh