small improvement ReadingsVal

Begonnen von immi, 05 August 2020, 19:05:13

Vorheriges Thema - Nächstes Thema

Dr. Boris Neubert

Zitat von: Christoph Morrison am 08 August 2020, 16:53:34
This does not invalidate the idea, but the other things i mention are doing this. It's a cumbersome way to store any structured data and should not be supported. We do have plenty of methods for structuring data in a single value string (JSON, XML, Storables, etc.) and those values can be unrolled into single key-value pairs as you mentioned.

But not any of these do justify a change to the API.

Agreed.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

immi

Zitat von: Dr. Boris Neubert am 08 August 2020, 16:12:44
I would rather recommend rethinking the code of the device module and create separate FHEM readings from the single data line received from the physical device.
Dear Boris
I implemented the readings of 00_THZ as transparent representation of heatpump registers logic (oxymoron :) ....) .
Some registers contain 1 value, some 50+ values.
We reverse-engineered about 230 registers (depending on the firmware and the build year), many of them undocumented.
Many years ago >7, after long discussions, we decided not to flatten (unroll) the registers with multiple values, in order to keep the number of readings low (230, instead of nearly 1000 if flattened)
Plotting was never a problem (you can address multiple columns easily) and userreadings made advanced users happy.

You convinced me that the "use case" is only related to thz; Maybe I will write a helper function inside the thz module, which will not affect other modules.


Dear Christoph
you asked for some register examples; please find a screenshot enclosed

immi

Dr. Boris Neubert


Dear Immi,

Zitat von: immi am 09 August 2020, 08:51:11
I implemented the readings of 00_THZ as transparent representation of heatpump registers logic (oxymoron :) ....) .
Some registers contain 1 value, some 50+ values.
We reverse-engineered about 230 registers (depending on the firmware and the build year), many of them undocumented.
Many years ago >7, after long discussions, we decided not to flatten (unroll) the registers with multiple values, in order to keep the number of readings low (230, instead of nearly 1000 if flattened)

thank you for this additional information. Now I much better understand the actual case at hand.

Given that you are thinking about including a helper function into the THZ module, I suppose that this topic has come to a resolution.

You probably had good reasons for choosing the register-based implementation over the readings-based implementation. I suggest not to reopen this discussion, at least not in this thread.

Kind regards
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Christoph Morrison

So the "solution" is THZ_Val(), mostly a copy of ReadingsVal() instead of transforming sControl into a more accessible data structure (e.g. JSON) and adding a retrieval function if necessary - and THZ_Val() does also reside in the main namespace (and clutters common ground).