Disable "Invalid identification string" test

[JeroenWiersma]

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

[glmnet]

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]

From IEC 62056-21 specification

[JeroenWiersma]

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 :).