HA: parser error for 99.97.0

[didiermiller]

Hi,

I am running into the following error. For some reason the telegram information for OBIS 99.97.0 is empty for my ISKRA-AM550. I assume this has always been the case, I am not sure why that would change suddenly.

I upgraded to the latest version of HA (2020.12.0 and OS 5.8) and suddenly this because an issue.

Logger: dsmr_parser.clients.protocol Source: /usr/local/lib/python3.8/site-packages/dsmr_parser/clients/protocol.py:112 First occurred: 10:56:35 AM (394 occurrences) Last logged: 11:03:39 AM failed to parse telegram

Traceback (most recent call last): File "/usr/local/lib/python3.8/site-packages/dsmr_parser/clients/protocol.py", line 108, in handle_telegram parsed_telegram = self.telegram_parser.parse(telegram) File "/usr/local/lib/python3.8/site-packages/dsmr_parser/parsers.py", line 59, in parse telegram[signature] = parser.parse(match.group(0)) File "/usr/local/lib/python3.8/site-packages/dsmr_parser/parsers.py", line 249, in parse return ProfileGenericObject(self._parse(line)) File "/usr/local/lib/python3.8/site-packages/dsmr_parser/parsers.py", line 148, in _parse raise ParseError("Invalid '%s' line for '%s'", line, self) dsmr_parser.exceptions.ParseError: ("Invalid '%s' line for '%s'", '99.97.0()\r\n', <dsmr_parser.parsers.ProfileGenericParser object at 0x7f13411fe2e0>)

I removed all entries for 99.97 in the python code (power event log or something along those lines) and that helped.

Here is an example of the actual telegram:

1-3:0.2.8(50) 0-0:1.0.0(201214112909W) 0-0:96.1.1(4530303533303037353234343134343139) 1-0:1.8.1(000177.571kWh) 1-0:1.8.2(000130.312kWh) 1-0:2.8.1(000072.503kWh) 1-0:2.8.2(000031.774kWh) 0-0:96.14.0(0002) 1-0:1.7.0(00.000kW) 1-0:2.7.0(00.139kW) 0-0:96.7.21(00010) 0-0:96.7.9(00002) 1-0:99.97.0() 1-0:32.32.0(00000) 1-0:32.36.0(00002) 0-0:96.13.0() 1-0:32.7.0(241.2V) 1-0:31.7.0(001A) 1-0:21.7.0(00.000kW) 1-0:22.7.0(00.134kW) !72C0 ~/ISK5\2M550E-1013

[fnxpt]

having the same issue with DSMR 5

[ndokter]

After a quick look i found 2 commits that might be related:

ProfileGeneric parser working, TODO complete ProfileGenericObject + Test https://github.com/ndokter/dsmr_parser/commit/b6278a8991c8729c22c35cc0960fa0ff1dc72518

make all objects able to print their own values https://github.com/ndokter/dsmr_parser/commit/a0ce89054a02651c86fe8a4559a4218a5047df5c

[juliusgaiuscaesar]

I can confirm the issue with the ISKRA-AM550 (a v5 'slimme meter') on HA after the upgrade to v2020.12.0 for HA and v5.8 for the OS.

[fnxpt]

looks like there is a PR already #57

[ndokter]

Thanks for bringing up #57. I've merged the supposed fix and created a new build. Is anyone able to test it? It's released as version 0.25

You might be able to update the requirement with: pip install dsmr-parser --upgrade

[fnxpt]

the issue is still there

  File "/usr/local/lib/python3.8/site-packages/dsmr_parser/clients/protocol.py", line 108, in handle_telegram
    parsed_telegram = self.telegram_parser.parse(telegram)
  File "/usr/local/lib/python3.8/site-packages/dsmr_parser/parsers.py", line 59, in parse
    telegram[signature] = parser.parse(match.group(0))
  File "/usr/local/lib/python3.8/site-packages/dsmr_parser/parsers.py", line 249, in parse
    return ProfileGenericObject(self._parse(line))
  File "/usr/local/lib/python3.8/site-packages/dsmr_parser/parsers.py", line 148, in _parse
    raise ParseError("Invalid '%s' line for '%s'", line, self)
dsmr_parser.exceptions.ParseError: ("Invalid '%s' line for '%s'", '99.97.0()\r\n', <dsmr_parser.parsers.ProfileGenericParser object at 0x7ff653e298b0>)```

[fnxpt]

It looks like I was running a older version... running dsmr_console I get the following error

handle: <Handle SerialTransport._read_ready()>
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/asyncio/events.py", line 81, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/local/lib/python3.8/site-packages/serial_asyncio/__init__.py", line 106, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.8/site-packages/dsmr_parser/clients/protocol.py", line 96, in data_received
    self.handle_telegram(telegram)
  File "/usr/local/lib/python3.8/site-packages/dsmr_parser/clients/protocol.py", line 117, in handle_telegram
    self.telegram_callback(parsed_telegram)
  File "/usr/local/lib/python3.8/site-packages/dsmr_parser/__main__.py", line 37, in print_callback
    print(obj.value, obj.unit)
AttributeError: 'ProfileGenericObject' object has no attribute 'value'

[lowdef]

The fix for https://github.com/ndokter/dsmr_parser/pull/57 is erroneous as also already indicated in that thread. Not sure why it is merged now? Please revert this merge.

What is causing this is that several meters are not conforming to the standard, alas we can not fix that.

The solution is to make the parser robust against such culprits.

I also sketched the solution in the comments to issue https://github.com/ndokter/dsmr_parser/pull/57: https://github.com/ndokter/dsmr_parser/pull/57#pullrequestreview-536008205.

We need to recognize such cases and return a valid ProfileGeneric Object.

A valid ProfileGeneric object representing an empty value has the following member values:

buffer_type : None
buffer_length : 0
buffer : []
values : []

[didiermiller]

I agree, this should be a None object. Upvoted your comment

[ndokter]

I've reverted the fix that was merged yesterday (#57), so we're back at the original issue

[RobBie1221]

I've pinned 0.25 to Home Assistant, at least from that side it fixes the issue. The empty value represents POWER_EVENT_FAILURE_LOG which is not parsed from HA side, so it won't bother that the ProfileGeneric object is invalid.

I'll see if I can push the solution proposed by @lowdef to have a sustainable solution that works for everyone.

[lowdef]

@RobBie1221 are you going to provide a code change, or shall I have a go at it during the Christmas vacation?

[fnxpt]

I can confirm that now it works on Home Assistant, thank you guys.

[RobBie1221]

@lowdef I was planning to provide a code change but if you are willing to have a look at it then that's fine by me as well. You seem to have a better understanding of how it should work, I'll have to dig into that :-)

[lowdef]

Pull Request #69 provides a fix for the issue.