Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

OBIS reference filter help #100

Open
Proxy5 opened this issue Feb 12, 2022 · 7 comments
Open

OBIS reference filter help #100

Proxy5 opened this issue Feb 12, 2022 · 7 comments

Comments

@Proxy5
Copy link

Proxy5 commented Feb 12, 2022

hello,

it is possible to filter this out of the data sent by the meter
0-0: 96.13.0.255,
it is not relevant data and its processing is problematic, because the service provider, 0xff, fills in the location of the message.

Thanks, Tomas
@lowdef
Copy link
Contributor

lowdef commented Feb 12, 2022

Hi Tomas, can you send an example message?

@lowdef
Copy link
Contributor

lowdef commented Feb 12, 2022

In principle you can delete the line, before you offer it to the parser. Make sure you switch of CRC check in this case.

@Proxy5
Copy link
Author

Proxy5 commented Feb 12, 2022 via email

@lowdef
Copy link
Contributor

lowdef commented Feb 12, 2022

In principle recent versions of the parser can handle this, the offending line is just ignored:

P1_MESSAGE_TIMESTAMP: 	 2022-02-12T15:32:50+01:00	[None]
ELECTRICITY_IMPORTED_TOTAL: 	 3970.901	[kWh]
ELECTRICITY_USED_TARIFF_1: 	 1827.309	[kWh]
ELECTRICITY_USED_TARIFF_2: 	 2143.592	[kWh]
ELECTRICITY_DELIVERED_TARIFF_1: 	 0.000	[kWh]
ELECTRICITY_DELIVERED_TARIFF_2: 	 0.000	[kWh]
ELECTRICITY_ACTIVE_TARIFF: 	 0002	[None]
CURRENT_ELECTRICITY_USAGE: 	 0.572	[kW]
CURRENT_ELECTRICITY_DELIVERY: 	 0.000	[kW]
INSTANTANEOUS_VOLTAGE_L1: 	 232.0	[V]
INSTANTANEOUS_CURRENT_L1: 	 2	[A]
EQUIPMENT_IDENTIFIER_GAS: 	 9940192257	[None]

ignore line with signature \d-\d:96\.13\.0.+?\r\n, because parsing failed.
Traceback (most recent call last):
  File "/home/hanserik/projects/dsmr_parser/dsmr_parser/parsers.py", line 59, in parse
    telegram[signature] = parser.parse(match.group(0))
  File "/home/hanserik/projects/dsmr_parser/dsmr_parser/parsers.py", line 201, in parse
    return CosemObject(self._parse(line))
  File "/home/hanserik/projects/dsmr_parser/dsmr_parser/parsers.py", line 151, in _parse
    raise ParseError("Invalid '%s' line for '%s'", line, self)
dsmr_parser.exceptions.ParseError: ("Invalid '%s' line for '%s'", '0-0:96.13.0(\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\r\n', <dsmr_parser.parsers.CosemParser object at 0x7ff488d029a0>)

@apulai
Copy link

apulai commented Mar 21, 2024 •
edited
Loading

Hello,

I also have the same problem. 0-0: 96.13.0.255 is filled with 0xff.
Provider's manual says it is reserved for further use and is filled with '????'s. In reality it is 0xff.

I understand that it is ignored when parsing as lowdef wrote.

However I would like to use it from Home Assisstant.

This is the log I see in Home Assisstant:

File "/usr/local/lib/python3.12/site-packages/dsmr_parser/clients/protocol.py", line 132, in data_received
telegram = telegram.encode("latin1").decode("ascii")
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 1371: ordinal not in range(128)

The dsmr_parser/clients/protocol.py
Tries to convert it to an ASCII string and rightfully fails, since 0xff cannot be converted to ASCII.

So I am proposing to change this code below.
I think a try block would help:

        for telegram in self.telegram_buffer.get_all():
            # ensure actual telegram is ascii (7-bit) only (ISO 646:1991 IRV required in section 5.5 of IEC 62056-21)

             try:
                telegram = telegram.encode("latin1").decode("ascii")
            except UnicodeDecodeError as e:
                pass
                or maybe ???:
                telegram = telegram.encode("latin1").decode("latin1")

            self.handle_telegram(telegram)

Please comment on it.
Is there an elegant way to get around this issue?
Thanks,
Andras

@apulai
Copy link

apulai commented Mar 26, 2024

Hello,

Actually after modifiying /usr/local/lib/python3.12/site-packages/dsmr_parser/clients/protocol.py
around line 132 in Homassistant (inside the container) from the original to

        for telegram in self.telegram_buffer.get_all():
            # ensure actual telegram is ascii (7-bit) only (ISO 646:1991 IRV required in section 5.5 of IEC 62056-21)

             try:
                telegram = telegram.encode("latin1").decode("ascii")
            except:
                telegram = telegram.encode("latin1").decode("latin1")

            self.handle_telegram(telegram)

It works even with the non-comformant telegram (0xff bytes under last part of the message).

Dear @ndokter, please advise or comment.

Thanks,
Andras

@ndokter
Copy link
Owner

ndokter commented Mar 26, 2024

I don't feel like i'm knowledged enough to comment on it. I'd think that maybe just processing it as latin1 might be better then? I think it will be fine, but am unable to predict side effects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@ndokter @lowdef @apulai @Proxy5