Registers missing from binding, but present in API

[uqs]

Hi there, thanks for working on this! I just upgraded my F1255 to the new myuplink and tested the API call on their page, so I have a dump of all the registers.

When converting my .items file over to the new binding, I noticed the following:

1. Old binding has the channels as ...#123, like most any other binding, but the new one has them as ...:123, why is that?
2. Several registers I was using are no longer in the new API call (and binding), e.g. 43005, which had the current degree*minutes value, I assume it can be replaced with 40940.
3. 43136 disappeared (current compressor frequency), but can probably replaced with 41778 ?
4. The actual problem: 40940 is returned by the API, but not selectable in the binding, see API dump below.
5. Same for 43416, the new number of compressor starts. It's in the API, but not shown by the binding.

Just adding those 2 channels (even though they don't show up?) seems to just work, as I can get the number of compressor starts and degree minutes just fine.

So here's the dump, these 2 don't show up in the binding channels, but they work nevertheless:

[
  {
    "category": "F1255-12 E EM",
    "parameterId": "40940",
    "parameterName": "current value",
    "parameterUnit": "DM",
    "writable": true,
    "timestamp": "2024-07-15T08:55:06+00:00",
    "value": 0,
    "strVal": "0DM",
    "smartHomeCategories": [],
    "minValue": -30000,
    "maxValue": 30000,
    "stepValue": 100,
    "enumValues": [],
    "scaleValue": "0.1",
    "zoneId": null
  },
  {
    "category": "F1255-12 E EM",
    "parameterId": "43416",
    "parameterName": "Com­pressor starter",
    "parameterUnit": "",
    "writable": true,
    "timestamp": "2024-07-14T12:00:21+00:00",
    "value": 2939,
    "strVal": "2939",
    "smartHomeCategories": [],
    "minValue": null,
    "maxValue": null,
    "stepValue": 1,
    "enumValues": [],
    "scaleValue": "1",
    "zoneId": null
  }
]

^^ why is latter one "writable"?

This one seems buggy, claiming compressor is running at 1Hz, when it's off. I do have an earlier json dump where the value correctly was 0Hz ... oh well, will have to see what happens when the hot water starts later today. Isn't it possible to do some input verification in the items file? I might want to rewrite 1Hz to 0Hz there ...

  {
    "category": "F1255-12 E EM",
    "parameterId": "41778",
    "parameterName": "Current com­pressor fre­quency",
    "parameterUnit": "Hz",
    "writable": false,
    "timestamp": "2024-07-14T12:48:01+00:00",
    "value": 1,
    "strVal": "1Hz",
    "smartHomeCategories": [],
    "minValue": null,
    "maxValue": null,
    "stepValue": 1,
    "enumValues": [],
    "scaleValue": "0.1",
    "zoneId": null
  }

[alexf2015]

Regarding your questions:

1. The old binding was build in a very static way. I put the channels into groups and therefore the syntax was different. The new one is built in a more generic way it just takes all channels which are provied by the API. But this way no grouping is possible. Well it could be grouped by "category" but this would not improve the situation very much as there are only 2-3 categories.
2. The binding offers everything which is available via API. Sorry I cannot add anything which is not supported by the API.
3. Well some channels are moved to another Id. I observed the same but in some cases the behaviour also changed.
4. Some channels are marked as "advanced". You can check the box to show advanced channels in the UI.
5. see above

Regarding the current compressor frequency. If this is a bug in the API you should contact NIBE. I also reported one bug for my model and it got fixed in the next firmware release. I will not add any workarounds in the binding. As mentioned above it is built in a generic way and thus it will be hard to implement a specific workaround which will most likely not apply to all devices but only to some models.

So I do not see any bug in my binding -> Closed.