core: DSMR sensor no longer updating
The problem
After a random time the DSMR sensors stops updating.
Environment
-
Home Assistant Core release with the issue:
0.115.3 -
Last working Home Assistant Core release (if known):
Issue existed in 0.114, didn’t have dsmr reader in earlier versions (had to problem since installing it) -
Operating environment (OS/Container/Supervised/Core): Hass.io on VMWare
-
Integration causing this issue:
DSMR -
Link to integration documentation on our website:
https://www.home-assistant.io/integrations/dsmr
Problem-relevant configuration.yaml
- platform: dsmr
host: 192.168.178.77
port: 23
dsmr_version: 5
reconnect_interval: 30
recorder:
exclude:
entities:
- sensor.energy_consumption_tarif_1
- sensor.energy_consumption_tarif_2
- sensor.energy_production_tarif_1
- sensor.energy_production_tarif_2
- sensor.gas_consumption
- sensor.power_consumption
Traceback/Error logs
home-assistant - dsmr debug.log
Additional information
Restarting home assistant resolved the issue, as does a integration reload. Problem returns after a certain time, can be 10 seconds, can be 3 hours.
If sensor is fronzen, telegram can be read from the web-ui as well as telnet client.
Losing connection to the DSMR reader seems to be related:
- Physically disconnecting and reconnecthing the DSMR reader causes the same issue.
- So does a WiFi reset on the DSMR reader.
- Perhaps the random lose of connection can be explained by unstable WiFi?
Added my (redacted) logfile. It shows the final message recieved from the DSMR parser. Then I left the next message (Waze sensor) in as it just seems to stop without logging a reason or error.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 82 (29 by maintainers)
Hey I just wanted to drop by and report my “solution”, which is actually a workaround, that seems to be working:
So I’ve made the following addition to my configuration.yaml:
For this I’ve set up the following parts in my secrets.yaml This requires 1: navigate to \homeassistant.local\config.storage\core.config_entries and grab the entry_id for the DSMR integration 2: a long term token for the RESTfull command (set it up in your profile using the ui)
insert the values from 1 and 2 in the below:
Last I made a automation that is run every minute, it checks if the sensor has not been updated and if so, restarts the integration. As I have a DSMR version 5, it normally sends updates every second. So no data for 30 seconds means its dead.
Adding to this, it does not quite work as expected. the relative_time function returns a string consisting of a number followed by " seconds". This causes unexpected behaviour when comparing to “30”. In fact, the automation will execute when the last update is longer than 10 seconds.
I added my automation below, it should be correctly comparing integers and therefore work on slower update rates.
Done (pull request #73)
@hogend That’s plain simple. I agree, with only waiting for data and not sending, it’ll never run in socket timeouts.
@mjkl-gh If we can get that code pushed to the lib, that’s a quite simple and elegant solution (only 10 or so lines of code).
I am a bit late to the show, but I had exactly this problem, which I solved in DSMR_parser/clients/protocol.py. It is fairly easy to set a receive time-out there (patch available if requested). Since the client is listen-only, it will never be able to detect an improper disconnect and keep listening on, essentially, a dead socket. The DSMR sender side, however, will detect the disconnect when it tries to send a new message and happily open a new socket. Since the sender is quite chatty, I set the receive time-out to 60s.
@RobBie1221 I understand, got the same issue. I got a wired (Ethernet) p1 reader which prevents me from long term testing. I am designing a active splitter to connect two reader on one meter, yet that’s a long term project 😅
My Ethernet P1 reader:
@zuidwijk Thanks (again) for the offer 😃 I preferred investigating other options because this unit would require me to uncouple my own P1 cable, which I rather not do.
It’s also not necessary. I’m able to reproduce the issue. I have Home Assistant running in a Ubuntu VM and a small daemon on the Windows host. What does work is if I kill the daemon, that is detected by the integration. What triggers the hangup is if I cut the network to the VM (which kind of would be similar to a WiFi hickup). In this case, the disconnect is not detected (I’ve waited about 30 minutes after which it still does not work) and updates are stopped until a manual reset is triggered.
Sorry for the confusion. I suggest to update the problem description in first message, because in there it mentions ‘DSMR Reader’ as integration.
It’s not pretty, but I’m pretty happy. Before it was sending me a notification and I was manually reloading it 20 times a day. Trust me, that gets boring really quickly.
No the external power made no difference. I still think its my WiFi connection / router that triggers the problem in the first place.
I’m back to the core integration so if a solution ever becomes available…
Thanks for you effort so far, and thank you @zuidwijk for your assistance as well.
@RobBie1221 he is using my P1 module. This is a Wemos D1 mini with an add-on which is nothing more than a logic inverter and power stabiliser. On the Wemos is esp-link installed which sends the telegrams through telnet.
These issues doesn’t occur when using dsmr-reader (v4.1 and higher). There is the option to connect via web socket and works flawless. Even when the connection drops, it reconnects within a few seconds when the connection is re-established.
In Home Assistant, when the connections is dropped, it won’t reconnect. The Wemos/esp is sending telegrams, you can see them in the uConsole of esp-link and if you telnet to the Wemos/esp. When restarting Home Assistant, it starts work again.
Now I’m not able to test it myself as I’m using an ethernet module and don’t want gaps in my dsmr-reader logging.
The modules are described on my website: https://www.zuidwijk.com/p1-modules/
If you want, I can send you a wifi p1 module so you can test it yourself if you want.