Create complete json files for the separate parts of M12676EN

[elupus]

This document contains registers and mappings for S-series pumps and looks to be in better shape compared to what get exported from the pumps:
https://www.nibe.eu/download/18.3db69dc1795e0d992c5722/1622634529178/Modbus%20S-series%20EN%20M12676EN-1.pdf
nibe-m12676en.pdf

Would make sense to create json files from that split on the different accessories.

[cybermaus]

How do you want us to help you? Report individual anomalies we find? Comment or confirm the lines in the document? Do nothing and wait for you to first have the initial document programmed?

[elupus]

If you want to help you could create separate json files (matching the other we have) for each of the sections in that document.

[cybermaus]

So I have a question on the ID numbers
I know it came up as part of the testing and troubleshooting, but I may not have grasped the significance.

Now I do realise there is a chance there is a good reason for it, but I just want to bring it up, just in case.

Q: Why are the ID's listed in the CSV exports and the ones listed in the JSON files off by one?

For example:
Export:

#Fan speed (EB101)	MODBUS_INPUT_REGISTER	401	1	rpm	5	0	0	0
#Heating medium pump speed (GP1)	MODBUS_INPUT_REGISTER	1636	1	%	4	0	0	0

JSON

  "30402": {
    "title": "Fan speed (EB101)",
    "factor": 1,
    "unit": "rpm",
    "size": "u16",
    "name": "fan-speed-eb101-30402"
  "31637": {
    "title": "Heating medium pump speed (GP1)",
    "factor": 1,
    "unit": "%",
    "size": "u8",
    "name": "heating-medium-pump-speed-gp1-31637"

I know during testing, it was said "oh, we need to offset by one"
But the JSON files were generated from the CSV. Is not the situation more akin to "The JSON files were accidentally, and incorrectly, generated with 1 offset, and thus now we read them with negative 1 offset too"

Would not a better solution be (especially now the solution is still not widespread): Re-generate the JSON files?

And to take two examples from the document above:

Operating prioritisation 1028 FC04 Input Register u8 - 1 R
 10 - off 20 - hot water 30 - heat 40 - pool 60 - cooling 
Alarm number 1975 FC04 Input Register u16 - 1 R

  "31029": {
    "title": "Priority",
    "factor": 1,
    "size": "u8",
    "name": "priority-31029"
  "31976": {
    "title": "Alarm number",
    "factor": 1,
    "size": "s16",
    "name": "alarm-number-31976"

[elupus]

That is sadly how modbus specifies it. Look at Entity Numbers and addresses on: https://en.wikipedia.org/wiki/Modbus

[cybermaus]

Ok: "...the entity location (1 to 9,999) is translated into a 0-based entity address (0 to 9,998) by subtracting 1."

However, but that means there is no reason the "name" string should not store it in "traditional convention" rather then "data communications" convention, especially since the name is a human readable representation that ends up in the HA user interface.

But maybe it is already to late. The modbus/tcp solution may be new and as yet unreleased, but I guess the gateway and MQTT solution is already older. And also it would probably be quite some work. But if it stays this way, it probably needs to be clearly added to the documentation, that paper references and CSV will differ -1 from the value seen in HA.

though.. "used by 3 active installations". Is that just us 3 testers?
God, you sure put in a lot of work already for 3 users......

[elupus]

Lera hope i grows a bit from 3 :).
The thing is the same number in the docs could be used for one holding register and one input register, and they are in no way related. So we do need the entity type tacked on there (4 or 3 prefix). I do understand your concern though.

I was hoping the numbers would line up with the older pumps, they are at least in the same format now

[nkrepo]

I think it is related to conversation, it would be very useful to create files with the allowed values and the corresponding text for each holding registers from the official documentation.

For example the following register has 4 allowed values :

''"Operating prioritisation 1028 FC04 Input Register u8 - 1 R
10 - off 20 - hot water 30 - heat 40 - pool 60 - cooling"

[elupus]

Yup that should be done.