Nibe uplink binding

Add-ons Bindings
,
201

Hi all and thanks for a great integration.

Is it possible to block additional electrical heating via paid API subscription?
I’m looking into the possibility to reduce power usage on cold nights when I would like to use as much power as possible for charging a EV.
I know there might me a solution to schedule blocking, but that’s done hard on the unit itself.

/t

202

Hi folks,
I am pretty new here, so sorry if I missunderstand sth…

I own a Nibe Heatpump sold by Alpha Innotec here in Switzerland since 1 week, and realized, that I could possibly link it to my openhab2. Only thing is in Switzerland the Alpha-Version of the HP uses not www.myuplink.com, but an exact copy named www.myupway.com
I believe it would be easy to include some variable in the binding where one could choose the portal where the Data comes from, no?
if that would be possible, all Alpha Innotec Owners of the Nibe-Manufactured HP could use the binding as well… the Controller is the same as the SMO-40 from Nibe, ist simply rebranded and named NP-CS40.
thanks for help on this, really appreciated!
Mark

203

FYI, I had Alpha Innotec install the NIBE firmware explicitly because of API support not being available (at least officially) from AI. Works, apart from the fact that I now somehow have to figure out the values for my F2120 (alias NP-AW 20-16).

1 Like
204

Hi, thats interesting. I had one call with them, and they said its not possible… could you maybe direct me in the direction how to fix this? and why do you need to figure out the values - are they different from the ones of NP-AW 20-16? I have the same pump… would be cool to get one step forward here…
thx!

205

This is easy to implement but currently I do not have a lot of time and of course I cannot test it.

1 Like
206

I created a test version which now uses www.myupway.com but this is hardcoded so just a test version. You can find it here: http://friese-de.eu/openhab2/myupway/

1 Like
207

Hi Alex,
sorry for the late reply… i tried it, but somehow did not get it to work properly… due to little time i will give it another try asap.
but the good thing is: NIBE / AIT will anyway change my firmware to the SMO-40 one, so I can use the official API and fetch and maybe also alter data via their API… so at the end I wont need the feature.
but it might anyway be a good option for someone stuck with the Alpha Innotec Version?
Best, mark

208

Hi Alex,

great job with this Binding, thx a lot!
I currently use it with a Nibe SMO-40 master unit and an outside F2120-16 slave unit, would that be possible to add as a supported device? Most of the channels from the F1145 as well as the VVM320 are identical and work, but I would love to add some more, and also define the divider & value correct…
thx, Mark

209

Hi there,

I just improved the custom channels a little bit:

  1. There is support for 16 instead of 8 custom channels
  2. Scaling for custom channels can now be applied via configuration instead of using rules.

This is currently only availble in the DEV version. I will create a PR as soon as this has been tested for a while.

1 Like
210

Would love to test that. Do you have a link to the Dev. version? can I just install it over the existing one?

best regards
Mark

211

I have backported the changes to 2.4 as the 2.5 SNAPSHOT version is no longer compatible with 2.4.0 release of openhab.

2.4 backport: http://friese-de.eu/openhab2/org.openhab.binding.nibeuplink-2.4.0-SNAPSHOT.jar
2.5 snapshot: http://friese-de.eu/openhab2/org.openhab.binding.nibeuplink-2.5.0-SNAPSHOT.jar

212

Hi @AlexF, i hope you’re doing well after all this time.

i’m still a heavy and very happy user of your binding since the first beta version. now so glad it made its way through the official distrib.

I’m writing to you as, as you have probably noticed, the nibeuplink API itself has been suffering up and downs recently. i’ve been suffering its impact on the system after not being able to get records for relatively long periods, or even not having the machine able to push new measurements, in turn leaving the binding to return invariable measurements for long periods of time. In order to mitigate that, i’ve been looking for some measure of the reliability of the measurements themselves, even though the binding reports the thing ‘online’ where at the end it effectively is, but without taking into account the fact that the nibe itself may not be able to refresh the measurements on the API. For instance i’ve implemented a check that verifies whether the API point is responding over http (i.e. a pure connectivity test) and whether the nibe thing is effectively online (it means it could connect/authenticate), and that has already allowed me to implement appropriate measures for when typically the internet connectivity suffers problems or when the API does not accept logins. This is however proving not to be enough, as recently the API looks healthy and the binding is itself on-line and functioning but the measurements do not get updated or very sporadically.
On this, I remember from the times when i had implemented myself an interface with the API, that the date of the last update from the equipment is also published through the API. In fact, i guess it is what is being used by the nibeuplink web page to report on the on-line/off-line status of the equipment. Looking back at my old code, i was getting that info from the /api/v1/systems/ interface in the ‘LastActivityDate’ element of the returned JSON.
I thought it could be an idea to publish this date through the binding in a new generic channel (of type DateTimeType). I know it’s a bit of a ‘nice to have’ wrt to all what the binding already offers, but it would solve this last point about reliability, at least for me.
WHat do you think about this and could it be something you’d be willing to support in the binding?

cheers

213

Hi @AlexF!
I’m working on updating the nibe uplink binding to be able to use the official Nibe Uplink REST API. So far I have managed to get authentication working and some other calls to the api that can be used for thing discovery (and also implemented a discovery service, so things are addedd to the inbox once the bridge is set up). I have quite a bit of more work to do to implement more functionality and make it more stable, but I’m going to need your help in integrating it into the existing binding.

My work is currently done as a separate binding because it made it easier for me to learn all the internal workings (it’s my first attempt at creating a binding), but I hope it can be integrated with the existing one. My work so far is available at github. Do you have any idea what would be the easiest approach to integrate it? (I’m sorry if my code is a bit of a mess, I most noteably need do document it better :wink:)

214

Sounds to me more like it would actually be a replacement.

Is there any difference in features between REST and webinterface?

215

There are some differences. I wrote a short summary in this post.
If I would replace the current binding some users might lose functionality, most notably to change settings, so I’d rather just add it as a separate bridge to the existing binding.
But it can be hard to work with someone else’s code, especially since I’m not very experienced. That’s why it’s currently a separate project.

216

I will consider this for my next release. Currently there is a huge change waiting for approval to be merged. As long as this is not merged back I will not continue as the approval process might result in changes which could also affect my further adoptions.

217

Hi @pacive:
There are 2 main reasons why I did not implement the official API:

  1. There is (currently) no write access supported
  2. The official API uses OAuth and I did not manage to get my binding authenticated this way.

I had a short look at your code, it seems to me that you have chosen a different approach and thus it will be quite hard to integrate it into the existing binding. You decided to use a bridge + things, I did not use a bridge but just a simple thing which has all channels attached. I do not have auto discovery because I decided to focus on the core functionality.
I have created another binding (SolarEdge) which has a very similar approach. There I have implemented two different APIs the API can be chosen by configuration. Basically this approach could also be used to add another API to the NIBE binding.
While in case of SolarEdge there was a good reason for implementing two different APIs I do not see this reason here. The “private” API does not have any disadvantage compared to the official one.

218

I agree that write access is a big advantage with your approach, which is why I definitely think it should still be an option, but I wouldn’t say it doesn’t have any disadvantages:

  1. Since it’s a private API, Nibe could change it at any moment without notice, which would break the binding. The public API promises to always be backwards compatible, and developers are notified in advance of any changes.
  2. The public API supports virtual thermostats, that can control the heating demand of the system, just by using a temp sensor already connected to OH. Some other settings are also available, such as vacation mode, temporary lux, ventilation boost and temperature setpoint/parallel adjustment of the heating curve. Though not as many as the private API.
  3. OAuth is more secure since no user credentials need to be stored in plain text. I found OH’s implementation really easy to work with, but I believe it’s quite new and might not have been available when you started your work.
  4. After adding the bridge, auto-discovery can be used to add any connected system, and also dynamically add channels (I still have to work more on that).

It might be possible to have both approaches living side by side, by just modifying the Handler Factory and adding my classes as-is. We just have to make sure there aren’t any naming collisions. WDYT?

219

The public API supports virtual thermostats, that can control the heating demand of the system, just by using a temp sensor already connected to OH

Didn’t you say right before it doesn’t have any write access?

220

It doesn’t have write access for most settings. With the current implementation, any setting that’s available on the nibeuplink.com website could potentially be changed. Not sure how many are implemented in the binding though. With the public API, some settings can be altered, those are transient ones that gets reset to default after 30 min (I guess so the system won’t be in a bad state if the connection should be lost).

But thermostat support is IMO one of the biggest ups with the public API, I have a personal implementation and use it extensively. I can, for example, lower the setpoint when it’s sunny outside to save energy and reduce the temperature at night or when nobody’s home. You can also start vacation mode, to lower both temperature and hot water (to a predefined value set in the heatpump) when you’re away for a longer period (should be possible to implement in the current binding as well, if not already), temporarily increase the hot water temperature, and boost the ventilation. But that’s about all the public API allows. And the values need to be posted with regular intervals, otherwise it’s reset to default. But that’s no problem to implement.