Skip to content

Conversation

JeroenWiersma
Copy link

Disable "Invalid identification string" test as this prevents the code from working with devices that have a "9" instead of "3" or "5" as 4th character, but that work properly with the rest of the code.

See esphome/issues#6487 for more details

Disable "Invalid identification string" test as this prevents the code from working with devices that have a "9" instead of "3" or "5" as 4th character, but that work properly with the rest of the code.
@glmnet
Copy link
Owner

glmnet commented Jan 6, 2025

I don't know what a 3 or 5 means, neither do know what a 9 means, but I guess it will be safer to add 9 to the "allowed" list of values instead of removing all the checks at all, what do you think?
Can you briefly check what these values mean so we can be more positive on what the underlying problem is?

Thanks

@geduxas
Copy link

geduxas commented Jan 6, 2025

From IEC 62056-21 specification

IMG_20250106_195225

Screenshot_2025-01-06-19-54-30-42_e2d5b3f32b79de1d45acd1fad96fbb0f

@JeroenWiersma
Copy link
Author

Nice work!
So position Z (or 13) refers to the baud rate. But interestingly the baud rate is controlled via https://esphome.io/components/sensor/dsmr.html.
In my case the ID string is ISk9\2MIE7T-200 and it communicates with these UART settings 115200,7,1. So possibly we should expand the code to also check for a '9' on this position. Or change it to check for any value between '0' and '9'

Apparently I'm not the only one that ran into these problems. Have a look at matthijskooijman#47 where the owner committed this PR (see matthijskooijman@ad23937.

As your code (which is used as the base for ESPHome) is a fork of that code I want to ask you to commit my pull request.

Another reasoning: what can be the downside of accepting my pull request? The check I propose to disable only checks on the value of position 'Z' (or 13) from within IEC 62056-21 specification which according to the standard should only allow 2400 baud ('3') or 9600 baud ('5') while the most common setting is 115200 baud. And the UART speed is controlled via ESPHome/DSMR settings. But for the code coming this far it must have been able to communicate and retrieve the ID string. So the baud settings must have been correct. There really is no added value in the validation that is done in this step :).

@glenndehaan
Copy link

I have a somewhat related issue, i'm trying to connect a Warmtelink from Vattenfall via ESPHome. But it seems the Warmte link is sending something that is non-complient:

14:57:03 | [E] | [dsmr:266] | /NWA-WARMTELINK  ^ Invalid identification string

@glenndehaan
Copy link

Yeah so small update I disabled this check and changed the MBUS ID to 1 and this seems to allow monitoring of the Warmtelink:

15:21:48 | [D] | [text_sensor:064] | 'Telegram': Sending state '/NWA-WARMTELINK  1-3:0.2.8(50) 0-0:1.0.0(250304152148W) 0-0:96.1.1(ADE3300000352292) 0-0:96.13.1() 0-0:96.13.0() 0-1:24.1.0(004) 0-1:96.1.0(622125562D2C0B0C) 0-1:24.2.1(250304152148W)(247.703*GJ) !E8E7 '
afbeelding

Would I be an idea to create a boolean just like the CRC Check so we can expose this in ESPHome?

@thomwiggers
Copy link

#23 is an alternative version of this

@paran1
Copy link

paran1 commented Aug 3, 2025

/NWA-WARMTELINK

According to 13a in the spec posted above (#24 (comment)) that should mean that the warmtelink uses "mode A"? As - is a printable character not used by the other modes.

I agree that removing the check makes sense as the value is not used for anything. Personally I would add a bit more details in the comments (this PR just comments out the code, the one in #23 removes code and all comments) but that is just my opinion as another random esphome user.

@paran1
Copy link

paran1 commented Aug 3, 2025

/NWA-WARMTELINK

According to 13a in the spec posted above (#24 (comment)) that should mean that the warmtelink uses "mode A"? As - is a printable character not used by the other modes.

The DSMR spec is based on mode D, and says to always use baud 115200 and that "This is not conforming to EN-IEC 62056-21 Mode D", so the DSMR spec is more relevant here. For DSMR 5 it also says that the number in the identifier should always be "5".

So as far as I understand meters sending "9" or "-" are not following the standard. Some of the ones with "9" have been reported from meters used in some Swedish power grids. It is not standards compliant here either as the Swedish H1-port standard refers directly to the Dutch DSMR/P1 standard. (I am in Sweden but does not have a meter with this issue)

Anyway the check still needs to be removed or be made optional to work with these meters.

@thomwiggers
Copy link

It's probably worth noting that this NWA-WARMTELINK unit is a device used to measure delivered hot water through a district heating grid, not the usual power meter. So it may not need to be compliant with DSMR, which might lead to a sloppy implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants