MyUplink binding?

Add-ons Bindings
1

I am looking for a binding for Nibe myUplink devices, but fail to find any binding (not uplink but the newer myuplink). In case you know of any such binding I would greatly appreciate a ”pointer” to it.

2

Hi helander,
in some other Threads there are some discussions about it. I am also reading it with interest as I have NibeUplink running which will be presumably switched off this year after reading the messages from Nibe:

Cheers
Jonathan

3

Hi @helander,
I’ve been using the official nibe uplink binding for a while. Then switched to nibe uplink rest api binding.
Since the move to MyUplink I use iobroker.myuplink adapter running in parallel as interim solution. It’s quite reliable and has all essential channels to monitor and control my VVM500.

4

Hi there I started working on a myUplink binding. It is still in an early state. Currently it supports:

  • automatic discovery of units within the account
  • automatic detection of available channels per dervice
    • no write support currently
    • status/enum channels are just mapped as numbers currently

Compared to the old NibeUplink I miss a few channels. In addition it seems that some channels are not updated unless the heatpump is restarted (such as heat meters) I already reported this to NIBE. If others have similar issues I would recommend to report this as well. It seems that their firmware still has some issues.

Current version can be found here:
myUplink SNAPSHOT Download

3 Likes
5

Thanks for providing.

Dropped into M2, added bridge, discovery of my VVM500 worked like a charm, values are populated.

6

Tahnk you for sharing, but I have some trouble using it:

  • successfully migrated today my VVM500 to myuplink; it is shown there

  • added your latest 4.2 SNAPSHOT to my 4.1.2 openhab installation

  • added bridge with my login data for myUplink
    → no successful login possible
    → UNKNOWN: @text/status.waiting.for.login to OFFLINE (CONFIGURATION_ERROR): Bad Request

  • checked permissions in myuplink account
    → no Third-Party Apps listed

Do you have any further instructions for me?
Do I need openhab 4.2 snapshot version?
If yes, could you provide a 4.1 version too?
Is it possible to configure your plugin via textfiles?

7

@AlexF
Meanwhile I updated openhab to 4.2M2 but again without success. After switchung your plugin to DEGUG I get the following messages repeatly every 5 seconds:

2024-05-14 12:34:41.032 [DEBUG] [ink.internal.command.AbstractCommand] - [Login] running command
2024-05-14 12:34:41.066 [DEBUG] [ink.internal.command.AbstractCommand] - [Login] received content, length: 218, encoding: UTF-8
2024-05-14 12:34:41.066 [DEBUG] [ink.internal.command.AbstractCommand] - [Login] HTTP response 400
2024-05-14 12:34:46.033 [DEBUG] [link.internal.connector.WebInterface] - run queued commands, queue size is 12

8

You will need to create API credentials. Your personal User (Email + password) will not work.

9

Wow, have I been waiting for this… I have a CTC EcoZenith i255, so the NibeUplink binding wasn’t an option for me.
I eagerly just added your initial JAR, created an app at dev.myuplink.com to get the credentials, and discovered my device - values populated!
A HUGE thank you for spending time on this! Looking forward to coming versions. It seems you’ve got this in the bag, but let me know if there is something I can help test…

10

@AlexF
Meanwhile I got it working creating an APP as described by @MrRusch and performed successfully an autodiscover which worked without any trouble.
But I prefer text based configuration. Is there any documentation available?

11

Meanwhile I was able to create successfully text based files for account and thing configuration. The only problem I had is getting the Thing-ID for my VVM500. to be successful I simply performed the autodiscover and took the ID from there (after deleting the previously generated Bridge and Thing).

Here are my details

myuplink.thing:
Bridge myuplink:account:myAccount "myUplink" @ "Nibe Heizung" [ 
    clientId="id from dev.myuplink.com application", 
    clientSecret="secret from dev.myuplink.com application", 
    dataPollingInterval=60 
    ] {
        genericDevice VVM500 "VVM 500" @ "Nibe Heizung" [ deviceId="id taken from automatic discovery" ]
    }

myuplink.items:
Number:Temperature Nibe_Out_Temp	"Außentemperatur [%.1f °C]"	(gNibeVVM) { channel="myuplink:genericDevice:myAccount:VVM500:40004"}
...
12

The latest version now supports various enum types which allows automatic mapping of numbers to text representation. In addition switch type is supported which has write access to the API.
My model only has 2 official channels which support write access and both are switches. This might be different for other models or change in future versions of the API. The official APP at least allows to change almost everything that can also be changed directly at the device.

13

Awesome! Thanks again Alexander,

I now have 34 channels available for my boiler and connected heat pump. All are of Number type.
The one function I actually use through the myUplink app is “extra hot water” which allows me to boost hot water production for a set number of hours (0.5 increments).
Changing this value through the binding does nothing sadly. So I guess just hope for API update?

Is there some specification on which channels support write access for which model? Or just trial and error…?

14

Well most channels base on some kind of number. But most channels should have a more specific number type depending on the unit e.g. °C → Number:Temperature. Otherwise something seems to be wrong.

Temporary Lux works for my model. It is a Switch type which can be set to ON or OFF. You could implement a rule which sets it back to OFF after a defined period of time.

You could either activate debug logging or manually trigger the API call at:
https://api.myuplink.com/swagger/index.html
It is the /v2/devices/{}/points endpoint which returns a complete list of all channels/points that are officially supported and also contains information, which channels are writable. In my case there are only 2 channels which are writable. You could share this JSON result with me it could help me to improve the binding.

15

Its working fine, many Numbers do indeed have a subtype.

I have sent you a message with the JSON-response of that API call. It appears I have 11 writeable channels - of which extra hot water is one! :grinning:

16

Looks like you own a totally different model. Not even a NIBE as it seems.
I will try to adopt the binding based on the data you provided. There are some enum types that have alot of different values. In the current state my binding relies on static enum types. But I think that is too much effort. I will evaluate how such types could be created dynamically. This will makes the binding more flexible.

17

I think the easiest path for this is to use them as options for the state description on the channel. Perhaps some additional logic is needed to create switch channels for those that only have on/off mappings.

When I query the API, it reports degree minutes as writeable. Haven’t tested if it actually works, but I haven’t got a use case for it anyway so for me the temporary lux and ventilation boost is enough. Great work!

18

NIBE purchased CTC in 2017. Hopefully it doesn’t cause too much problems. Thanks again for your efforts! :pray:

19

I also had a channel with multiple mappings, for smart price adaptation that couldn’t be handled.

Log

2024-05-22 07:55:01.405 [INFO ] [uplink.internal.model.ChannelFactory] - could identify enum type with values: [{"value":"0","text":"Unknown","icon":""},{"value":"1","text":"Low","icon":""},{"value":"2","text":"Normal","icon":""},{"value":"3","text":"High","icon":""}]
2024-05-22 07:55:01.772 [WARN ] [nal.model.GenericResponseTransformer] - no mapping implemented for channel type 'type-add-heat-status'
2024-05-22 07:56:01.162 [WARN ] [nal.model.GenericResponseTransformer] - no mapping implemented for channel type 'type-add-heat-status'
2024-05-22 07:57:01.097 [WARN ] [nal.model.GenericResponseTransformer] - no mapping implemented for channel type 'type-add-heat-status'

Point data from API (v3 endpoint)

  {
    "category": "NIBEF F750 CU 3x400V",
    "parameterId": "41929",
    "parameterName": "Mode (Smart Price Adaption)",
    "parameterUnit": "",
    "writable": false,
    "timestamp": "2024-05-22T04:00:01+00:00",
    "value": 3,
    "strVal": "High",
    "smartHomeCategories": [],
    "minValue": null,
    "maxValue": null,
    "stepValue": 1,
    "enumValues": [
      {
        "value": "0",
        "text": "Unknown",
        "icon": ""
      },
      {
        "value": "1",
        "text": "Low",
        "icon": ""
      },
      {
        "value": "2",
        "text": "Normal",
        "icon": ""
      },
      {
        "value": "3",
        "text": "High",
        "icon": ""
      }
    ],
    "scaleValue": "1",
    "zoneId": null
  },
20

First of all, thanks Alex for supporting this binding, really appreciated!
I have a Nibe F370 and generally your new binding worked perfectly. I understand work is still in progress, but I have two questions regarding the binding (maybe it is for Nibe to answer):

  • Can channels be added if the heapump raises an alarm (switch item) and another with the alarm message (string)?
  • I get a message in the log (no mapping implemented for channel type ‘type-add-heat-status’), think @pacive has some similar issue. I can of course remove this with a filter, but if there is a “better” solution?