After updating from 0.113.1 to 0.116.x and also 0.117.2 the DSMR integration isn't working anymore. The entities are no longer available.
configuration.yamlsensor:
- platform: dsmr
host: 192.168.179.110
port: 2001
dsmr_version: 5
I've activity on port 2001 (tcpdump) and after some sec. the connection is closed. socket 2 (fd8) is at EOF exiting with status 0
Now I'm using sensor.py from (May27) which seams to work fine. https://raw.githubusercontent.com/home-assistant/core/cfaa851b5b8ace3d14262c2e8c57a237d5f9d3ec/homeassistant/components/dsmr/sensor.py
I'm using the smarty_dsmr_proxy to decode the telegram
https://github.com/mweimerskirch/smarty_dsmr_proxy
I don't have/had a DSMR card in Configuration->Integrations.
dsmr documentation
dsmr source
(message by IssueLinks)
Potential duplicate of #40595
I asked @humanoidlux to make a new issue in #40595, because that issue handles ungraceful disconnects which are not detected. As far as I can see, in this case the validation in yaml import fails.
Could you try to put back original sensor.py and add to configuration.yaml key below? I'd like to see the telegram it's receiving.
logger:
logs:
dsmr_parser: debug
Here are the the screenshot.
Here the 1st telegram
the last telegram
Could you go to Configutation->Logs and copy/paste the output as plain text? Then I can copy it in my daemon and see what happens.
The reason it's not working is that during import, it validates connection by searching for equipment identifier for electricity and gas meter.
Those are:
0-0:42.0.0(53414731303330373030313039333531) for electricity and
0-1:96.1.0(3232323241424344313233343536373839) for gas
It needs the equipment identifier to generate unique ids for the entities and set a unique id for the ConfigEntry.
The DSMR standard is described here: https://www.netbeheernederland.nl/_upload/Files/Slimme_meter_15_a727fce1f1.pdf
Where:

Smarty however is specified here: https://smarty.creos.net/wp-content/uploads/P1PortSpecification.pdf
Where:

So according to the Dutch standard (which you are configuring), equipment identifier (for electricity) should be send through 0-0:96.1.1. You are however getting the serial over 0-0:42.0.0. This is not recognized by the integration.
In order for this to work, the OBIS reference must be added to https://github.com/ndokter/dsmr_parser and similar to 5B (B=Belgium) we probably need to add 5L for Luxembourg.
Made a pull for supporting library: https://github.com/ndokter/dsmr_parser/pull/62
Once that is merged and there is a new PyPi package, this can be fixed on HA side.
Ok i see now. I will contact them, because they are referring to the Dutch DSMR specification. And on the last page they have the same telegram as in the Dutch document. So something is wrong in this document.
Ok i see now. I will contact them, because they are referring to the Dutch DSMR specification. And on the last page they have the same telegram as in the Dutch document. So something is wrong in this document.
I don't think it's wrong, they use a slightly different specification. Similarly, the Belgian is slightly different.
It's fixable, but needs some time because the supporting library needs an update.
W.r.t. their example, that's a telegram from an ISKRA meter, would have been better if they'd use their own telegram as example. Probably they copied that from the DSMR specification.
By the way, if you want I can provide a workaround for you.
Thank you Rob.
It's ok. I've copied the old sensor.py and the other files as custom_components in this directory configcustom_componentsdsmr
So for the moment it works fine :-)
tnx
@RobBie1221 would you have a chance to fix this in the core ? I鈥檓 waiting to upgrade as it would break the integration. Thanks
My fix has been merged in the dsmr-parser library, but I'm waiting for a new PyPi package before I can fix it here. I'll poke the maintainer to see how that is going.
Got an answer from Creos, they will update the document in the next weeks... without any further information...
They will probable update the example in the attachment which contained ISKRA data instead of their own? Seems highly unlikely they will change their specification, that needs firmware update of the meter.
@humanoidlux do you have gas readings? ELCO just came to fix my setup, and from their side all is well now, but I can't see gas related datagrams in the readouts.
@Trefex
Just send en mail to customer.care ([at]) creos(dot)net with your SN of your smarty, home address etc. They will add it to the telegram.
Mine was also missing
@Trefex How did you get it to work?
@RobBie1221 in HA? Not at all, I'm using an older version in a demo sandbox 馃憤
Or did you mean something else?
Nope, I meant HA. I was triggered by the "from my side everything is well now". Thought that you had fixed it somehow, but then we're on the same page again.
Nope, I meant HA. I was triggered by the "from my side everything is well now". Thought that you had fixed it somehow, but then we're on the same page again.
I wrote from "their" side, meaning Creos, the provider :) Nothing is yet good on my side. lol-
Ok, totally read that wrong. Anyway, I poked the maintainer of dsmr parser, once a new release is there I'll make a pull here to fix it.