Nibe REST API

Add-ons Bindings
Tags: #<Tag:0x00007f173a233838>
#1

@pacive, thanks again for the excellent Nibe uplink API binding! I’ve used it only a couple of hours with F750, but would have some suggestions for improvement:

Screenshot 2020-12-28 at 22.56.18

Here, the actual air velocity is incorrect, should be divided by 10. Also, for the temperature values, is it possible to add a unit (e.g. °C)?

About rounding, it would be nice if values had one decimal or at least if it would be configurable.

Lastly, there’s something wrong with current (amperage) values:

  • nibeuplinkrest:nibef750:5b64bd0d:xxxxx:status#40081
  • nibeuplinkrest:nibef750:5b64bd0d:xxxxx:status#40079

Although these two seem to have different id (40081 & 40079), they seem to point to the same actual value.

Nibe uplink binding
#2

What is your Item definition? Is it defined as Temperature ?

#3

Yes

Screenshot 2020-12-28 at 23.12.20
Screenshot 2020-12-28 at 23.12.20824×174 10.3 KB

Screenshot 2020-12-28 at 23.12.06

1 Like
#4

That’s strange, might have to do with the auto discovery of the channels, will look into it. In the meantime, it’s possible to change the scaling factor manually on the channel (click the pencil icon beside the channel in the thing view).

As for the units, I added this when updating the binding for OH3, but should be quite easy to backport.

Thanks for the feedback!

#5

Thanks, now it shows correctly

#6

Did you manage to confirm whether those current (amperage) values point to the same value? At least it seems so. Rounding those values does not make sense, as 0.4 A is shown as 0…

Another thing, do you know if it’s possible to get information on “periodic hot water increase” through the API?

#7

I haven’t been able to test the amperage values, since the sensors are not installed in my system, but will have a look at how the channels are created and updated if all of them report the same value. Also, there shouldn’t be any rounding done, but the problem is that the API reports all values as integers that have to be divided by 10 or 100, or not at all. E.g. a temperature of 21.3 is reported as 213. When the channels are created the binding tries to deduce what the scaling factor should be, but it can miss sometimes, that’s why it can be overridden.

I have backported the support for units and will test it out quickly before uploading it. Can add some more debug logging so we can find out what’s going on.

#8

Ok. Btw, there seems to be IDs for periodic hot water increase:

“Periodic HW”;“Activates the periodic hot water generation”;47050
“Periodic HW Interval”;“Interval between Periodic hot water sessions”;47051

‘Hot water mode’ would also be a nice addition:

“Hot water mode”;" 0=Economy 1=Normal 2=Luxury";47041

#9

There is a Hot Water Boost channel available, that activates luxury mode for hot water during a certain amount of time (3h, 6h, 12h or one-time raise). The other channels aren’t available through the rest api unfortunately, the only ones that can be controlled are hot water boost, ventilation boost, vacation mode, parallel adjustment and target temperature for the different systems. Those are all available in the Control channel group.

#10

The updated binding is now available here. I had some issues when updating, all changes to the thing didn’t appear immediately. To make sure it goes smooth, delete your system thing (the bridge doesn’t have to be deleted), then replace the file in the addons folder, and finally rediscover your thing. Note that in addition to supporting units, quite a few channels have been marked as ‘advanced’ to reduce the clutter in paperUI. To see all channels, just click “show more” in the top of the channel list.

To check what’s up with your current channels enable debug logging by typing log:set DEBUG org.openhab.binding.nibeuplinkrest in the karaf console. Within a minute you should get a few log entries like: Setting channel status#40083 to 0.1 A. If everything works, there should be three entries for channels 40083, 40081 and 40079.

#11

I guess this is the only way to update? I’ll lose e.g. all tags that I’ve added and just wondering that going forward, do all updates require starting from scratch?

#12

You don’t have to delete any Items, and they should be automatically relinked, since the channel names should be the same as before. I did however discover that the channels for compressor frequency gets created as Number:Energy type, this is an issue either in OH core or the UOM library. Have added a manual override to set it to Number:Frequency and will upload the updated binding shortly, so you might want to wait a bit before updating.

1 Like
#13

The patched binding is now available here!

#14

Well, I did already update :slight_smile: (for clarity, this is the previous patch, not the one you just posted)

[DEBUG] [ndler.NibeUplinkRestBaseSystemHandler] - Setting channel status#40079 to 0.3 A
[DEBUG] [ndler.NibeUplinkRestBaseSystemHandler] - Setting channel status#40081 to 0.4 A
[DEBUG] [ndler.NibeUplinkRestBaseSystemHandler] - Setting channel status#40083 to 4.5 A

But the problem is that UI links these to the same value:

Screenshot 2020-12-31 at 12.44.57

When I link one channel, all three are “activated”. Should there be a unique name for all three channels? E.g. NibeF750_Status_Current1, NibeF750_Status_Current2 …?

Screenshot 2020-12-31 at 12.42.37
Screenshot 2020-12-31 at 12.42.37970×656 9.08 KB

#15

It seems like you have the same Item linked to all three channels (There are three Current1 in the list). The Name of the Items need to be unique, so creating different Items like you said needs to be done. If you look at the channel list it should look something like this:

image
image1436×639 50.9 KB

Where the item name is the one in the parenthesis, and this need to be be different for all three channels.

As for the rounding you mentioned earlier this is done by paperUI in the Control page, the value stored in the Item itself should be exact. If you use basicUI or habpanel the correct value should be displayed.

#16

Okay, now it works as expected. Somehow I thought only label was editable…

#17

Glad that it works now! Let me know if you have any more problems. Found some minor bugs myself and created a new build, available here.

1 Like
#18

Unsure if I installed your latest version of the binding, is there any version number I could check (on the console of PaperUI) so that won’t have to install it “just in case”*?

#19

When you run:

bundle:list | grep -i nine

In the karaf console, you should get output like this:

273 │ Active │  80 │ 2.5.12.202012311345     │ openHAB Add-ons :: Bundles :: NibeUplinkRest Binding

The 2.5.12.202012311345 part is the version number, and the last part is the time it was built. You could compare this to the creation date of the .jar file to see if it’s an earlier version not fool-proof, but I don’t know if there’s a better way.

#20

Btw, how often does this API poll Nibe’s service (and therefore updating all values)?