Add parsing of product data

[elupus]

No description provided.

[elupus]

I think it's a greedy string. nibepi does some weird things with the first byte + 5 or similar to get the length. https://github.com/anerdins/nibepi/blob/080db44d7ecca82b5c75bd7defd2f078687ab877/index.js#L383

[yozik04]

I agree that nibepi does some weird stuff... GreedyString seems to be right.
Is this PR ready? I am ready to merge.

[yozik04]

I think you want to add some logic here:
https://github.com/elupus/yozik04_nibe/blob/7a8dac0dad48cddad0f3afab31fa55db43de2298/nibe/connection/nibegw.py#L109

[elupus]

Yes probably. Any thoughts on how it should be exposed? I think it could be sent to other addresses than MODBUS40

[yozik04]

I can implement it myself. But tomorrow. I have a good idea how to do this. Jevgeni

…

10 сент. 2022 г., в 15:05, Joakim Plate ***@***.***> написал(а):  Yes probably. Any thoughts on how it should be exposed? I think it could be sent to other addresses than MODBUS40 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[elupus]

Sounds good.

Ps. Initial native home assistant implementation: https://github.com/home-assistant/core/compare/dev...elupus:home-assistant:nibe/local?expand=1

Just plain sensors for now. Will look at the other fun stuff later.

[yozik04]

Take a look. I am not confident in read_product method name and Product dataclass name. Need to think about it.

[elupus]

I think we should cache the product data. It seems its only sent quite infrequently. Since we cant trigger it to be sent, it feel like a cache of last received data might be in order?

[yozik04]

It is sent every 15 seconds. I'd wait for this message as part of initial connection process. The response can be cached, yes.

[yozik04]

I think this can be merged already.

[elupus]

Looks good.