Nibe uplink binding

Tags: #<Tag:0x00007f876684f0e0> #<Tag:0x00007f876684eed8>

(oliviercommelarbre) #61

Hi Alex, thank you that’s very kind. I’ll test asap and report back.
just a quick question, did you document somewhere how to configure these additional IDs (e.g. via the thing config? or by altering some XML file in the binding jar?). I went to your repository on github but did not find the answer. any help is appreciated, thanks!

(Alexander F) #62

Hi @oliviercommelarbre

the answer can be found in the README:

The channels are configured via the Thing configuration. This can be done either via Paper-UI (if the thing was added via PaperUI) or in the config file if the thing was added via config file.

(Alexander F) #63


currently Nibe Uplink service is providing faulty / outdated data. This is not related to the binding and it seems to be a general problem. So it is not related to your personal setup.

Just in case you are confused about what the hell is going on with your Nibe…

(oliviercommelarbre) #64

Thanks Alex, sorry i had missed that.
There is just one more thing. I can’t figure out what should be the channel name to recall from the item. I’ve tried ‘CH01’, ‘sensor@CH01’, ‘custom#CH01’, ‘sensor#10012’, ‘custom#10012’ or ‘customChannel01’ but none of these seem to be the right channel name. In my trials i was trying to assign the custom channel 1 to the param number 10012.

here my things config:

nibeuplink:f1145:nibe [ user="...", password="...", nibeId="...", customChannel01=10012 ]

and my item:

String TestNibeuplinkCustom {channel="nibeuplink:f1145:nibe:custom#CH01"}

Importantly, I’ve also tried with using a known parameter such as 40071 (instead of 10012) but again with no luck, while indeed i get this param perfectly through the ‘sensor#40071’ channel.

I must do something wrong but can’t figure out where, could you may be help? thanks

(Alexander F) #65

Hi @oliviercommelarbre

it should be custom#CH01 to custom#CH08.

In Debug logging mode you should see lines like this:

2018-03-01 18:00:51.294 [DEBUG] [n.handler.GenericUplinkHandler:178  ] - Channel is to be updated: custom#CH01: Nein

In the paperui custom channels should always be visible like here in the screenshot



(oliviercommelarbre) #66

Thank you Alex, problem solved. My problem was that i had to uninstall (from the console) the 2.2 bundle that was still active although i had removed the corresponding jar. Anyway it was great help to have your confirmation about the naming of the custom channels. I’ll be soon back with some feedback on the new IDs i’m testing.

(Bauer August) #67

Hi Alex,
i am facing the problem, that it seems i am getting no data anymore from nibeuplink. is that right? you have written that nibeuplink delivers faulty data? is there any new update now or do i maybe have other problems?

PS: I had to reinstall my openhab due to a big bug (where nobody could help me). Now everything except nibeuplink is owrking fine again. Nibe just dont send any data, i dont get any updates. Last data from nibeuplink in my mysql DB was on 2.March. But i cannot reproduce if this was from the openhab bug or from the nibeuplink problem.

thanks in advance

(Bauer August) #68

Hi Alex,

just for your information.
With paperui i uninstalled and installed the nibeuplink addon again with NO success.

But i read a few posts ago from your latest DEV version and tested this one.
First, i switched to DEBUG Mode and after that i put the DEV version into addons folder. A few seconds later i got connection and data got in. NICE!

Great that it works again, BUT, it is a little bit strange why it didnt work before (fresh install with configuration restore) and also not after deinstall an reinstall.
Maybe you should have a look at this … maybe someone else has this problem too … maybe :wink:

As for now, i am really happy because everything works fine again and my database gets filled with data.
Thanks for your great work!

(Alexander F) #69

Hi @htpzc:

thanks for your information, I will check the “stable” version if there are any issues. Currently I am using the DEV version, too.

@all: Currently I am trying to implement write access which was at least partly successful for my VVM320.
Unfortunately it is quite complicated because each channel uses it’s own URL. If I do not pass the data to the correct URL it is not accepted. Therefore it is a lot of work and of course each and every channel has to be verified for each model.

For my VVM320 I have successfully implemented:

  • 43005 Degree Minutes (16 bit)
  • 47011 Heat Offset S1
  • 48132 Temporary Lux
  • 47041 Hot water mode
  • 47260 Selected Fan speed

Values are sent to a URL like this:

The XXXXX is replaced by your Nibe ID but the last part is individual for each parameter. So to implement write access for other models I need those URLs for each channel.
All channels that provide non numeric data need a mapping in addition because each String is mapped to a number internally. To be able to set a value you need to send the raw number code to the API. That is quite complicated. :frowning:

For my VVM320 I have planned to implement further channels that cover these areas:

  • vacation mode (/System/xxxxx/Manage/4.7)
  • auto / manual mode (/System/xxxxx/Manage/4.2)
  • periodic hotwater (/System/xxxxx/Manage/2.9.1)

So any other ideas regarding channels which should have write access enabled?

(Bauer August) #70

Sorry, but i was too enthusiastic. i only looked into the debug log and saw that in mysql the tables have been created.
but in the end, there is no data written in the database. only first time from 0 to X. After that nothing gets written.
when i check the debug log i got the following messages:
14:33:48.433 [DEBUG] [ding.nibeuplink.handler.UplinkPolling] - polling NibeUplink org.openhab.binding.nibeuplink.config.NibeUplinkConfiguration@xxx[user=xxx,password=xxx,nibeId=xxx,pollingInterval=300,houseKeepingInterval=3600,asyncTimeout=120,syncTimeout=120]
14:33:48.888 [DEBUG] [.internal.command.GenericStatusUpdate] - received content, length: 1554
14:33:48.941 [DEBUG] [.internal.command.GenericStatusUpdate] - HTTP response 200
14:33:48.980 [DEBUG] [.internal.command.GenericStatusUpdate] - onComplete()
14:33:49.021 [DEBUG] [.internal.command.GenericStatusUpdate] - JSON String: {“IsOffline”:false,“OnlineImage”:"\u003ci class=“fa fa-check-circle ONLINE”\u003e\u003c/i\u003e",“Date”:“19.03.2018 13:33:48”,“FuzzyDate”:“Vor \u003c1 min”,“Values”:[{“VariableId”:40004,“CurrentValue”:“2.4°C”},{“VariableId”:40067,“CurrentValue”:“0.5°C”},{“VariableId”:43005,“CurrentValue”:"-30GM"},{“VariableId”:43009,“CurrentValue”:“26.8°C”},{“VariableId”:43161,“CurrentValue”:“Nein”},{“VariableId”:40008,“CurrentValue”:“26.5°C”},{“VariableId”:40012,“CurrentValue”:“22.6°C”},{“VariableId”:40072,“CurrentValue”:“5.1l/m”},{“VariableId”:43081,“CurrentValue”:“3.8h”},{“VariableId”:43084,“CurrentValue”:“0.0kW”},{“VariableId”:47212,“CurrentValue”:“6.5kW”},{“VariableId”:44308,“CurrentValue”:“11702.4kWh”},{“VariableId”:44304,“CurrentValue”:“0.0kWh”},{“VariableId”:44302,“CurrentValue”:“0.0kWh”},{“VariableId”:44300,“CurrentValue”:“11721.3kWh”},{“VariableId”:40013,“CurrentValue”:“50.8°C”},{“VariableId”:40014,“CurrentValue”:“45.4°C”},{“VariableId”:44306,“CurrentValue”:“730.3kWh”},{“VariableId”:44298,“CurrentValue”:“730.4kWh”},{“VariableId”:48132,“CurrentValue”:“aus”},{“VariableId”:47041,“CurrentValue”:“Sparm.”},{“VariableId”:43424,“CurrentValue”:“202h”},{“VariableId”:43420,“CurrentValue”:“3456h”},{“VariableId”:43416,“CurrentValue”:“372”},{“VariableId”:40022,“CurrentValue”:“6.0°C”},{“VariableId”:40019,“CurrentValue”:“22.4°C”},{“VariableId”:40018,“CurrentValue”:“45.0°C”},{“VariableId”:40017,“CurrentValue”:“26.4°C”},{“VariableId”:43136,“CurrentValue”:“21Hz”},{“VariableId”:43122,“CurrentValue”:“20.0Hz”},{“VariableId”:43123,“CurrentValue”:“118Hz”}]}
14:33:49.541 [DEBUG] [beuplink.handler.GenericUplinkHandler] - Handling channel update.
14:33:49.581 [DEBUG] [beuplink.handler.GenericUplinkHandler] - Channel is to be updated: general#44302: 0.0kWh
14:33:49.626 [DEBUG] [beuplink.handler.GenericUplinkHandler] - Channel is to be updated: compressor#43136: 21Hz
14:33:49.674 [DEBUG] [beuplink.handler.GenericUplinkHandler] - Channel is to be updated: general#44304: 0.0kWh

and so on.

I got every 60seconds a new entry.
But when i end debug mode nothing is written in the event.log (with my old version everything was logged) and also not written in the database.

Any idea what i am missing?

Thanks in advance.

(Alexander F) #71

According to the log entries communication with Nibe Uplink is established and data is retrieved and parsed correctly. So maybe your items are not correctly linked to the channels.
The channel names have slightly been changed a few weeks ago. Before all channels were prefixed with either “sensor” or “setting”. This is now changed, so you need to update your configuration accordingly.

(Bauer August) #72

oh sh** … i checked everything, the id, number etc. but not the category/channel.
Yes, thats it. Thank you.

Am i right, that there is no KT (Kälteträger) in and out anymore. A lot of sensors dont make so much sense, but this two i am really missing. As im seeing in your latest posts, i can add them as a custom channel, so i will check this the next days and give your reply.


(Alexander F) #73


If there are important channels missing please report back with channel ID and type (String or Number) and unit (such as °C, kWh, …) and nibe model.
I will then add those to the list of official channels.

(oliviercommelarbre) #74

Hi there Alex
Sorry to come back so late. We’ve had negative temperatures recently here down in italy and i was more busy getting the heating system to work than improving the monitoring with the binding :wink:
So i’m back on it and i confirm the custom channels work great, thanks.
and thanks also for your previous help getting the right syntax.

In the meantime i figured out when switching to 2.3 snapshot that some of the items i was using with the former 2.2 were no more published by default in 2.3 so i ended up using all 8 custom channels to fill the gap and i still miss a few.

Here is the complete list i’m missing for my application with F1145, it would be great if you could consider adding these to the default list for the next version (for F1145 and i would think also for the F1155 since they are very similar as far as i understood, but i can confirm only concerning F1145) :

param     datatype    unit   name      
40083     Number      A      Current BE1
40081     Number      A      Current BE2
40079     Number      A      Current BE3
40015     Number      °C     Compressor Brine-In Temperature
40016     Number      °C     Compressor Brine-Out Temperature
43439     Number      %      Compressor Brine Pump Speed
43437     Number      %      Compressor Heat Medium Pump Speed
44270     Number      °C     HPAC Calculated Flow Temperature
43165     Number             HPAC External Blocking AC (boolean 0=OFF / 1=ON)
43166     Number             HPAC External Blocking PC (boolean 0=OFF / 1=ON)
10012     Number             Compressor Blocked (boolean 0=OFF / 1=ON)
10033     Number             Supplementary Power Blocked (boolean 0=OFF / 1=ON)

Basically these params (together with most others already in the default F1145 list) are the ones that are displayed in real-time in the info menus of the machine itself.
I’ve checked they all respond. the boolean ones return “yes” or “no” when coming in string format but it would be more handy in openhab to get directly the raw numeric form (boolean 0 or 1).

For now i do it without the HPAC ones and found a workaround for 10033 so it just fits in with the 8 custom channels.
thanks again for your good work and looking forward to the next devs!
cheers for now!

(Alexander F) #75

Hi @oliviercommelarbre,

thanks for your input. I will add those channels.


(Alexander F) #76

I have published an updated version which - again - has some breaking changes. I have switched to another API url which provides RAW data this is especially useful when dealing with “list-type” channels such as hotwater mode. The API I used before returned language specific strings which is not easy to handle. In addition it requires additional effort to send this to influxdb/grafana.
The new API uses raw values (numbers) internally for those list types. In the UI those raw values automatically get translated into an english string.
However in persitence as well as in your rules you need to deal with raw values. So switching to the new version might break some of your rules.

Second (small) change is a few new channels for all models:

  • 40079
  • 40081
  • 40083
  • 10012
  • 10033

On my Nibe the three current channels (BE1 - BE3) seem to return always the same value. I would expect them to change on different activity. But maybe those apply only to the additional heater which is blocked all the time in my setup.

Third change: Write Access to the API has finally been implemented. At least for VVM320 and a few channels only. I believe that the channels I have activated should be available on the other models, too so it should be quite easy to activate for other models.

(oliviercommelarbre) #77

Thanks Alex for this, i will test it with more time after Easter.

Concerning the current channels BE1-BE3 they do respond according to any power activity (not only on additional heater activity) on my setup (a tri-phase F1145). I think that however there needs to be some specific installation for it to work (probes to be installed around the power lines).

(oliviercommelarbre) #78

Hi there Alex,

Sorry i have to edit this post, i had a typo in my item config which is the reason why it was not working.
Please ignore!

previous post (to ignore):

here is a channel i find does not update with the DEV version. I wonder i you could also add this one in the default list for the F1145 (and probably F1155 which is very similar as far as i understood)

param     datatype    unit   name      
40022     Number      °C     Compressor Suction Gaz Temperature


(Tobias Schwind) #79

Hello Alex,
I tried to add the current Status of my VVM320 & F2040 to my sitemap, but I doesn’t seem to work.
It Returns the value = -32768

nibeuplink:vvm320:NibeF2040-8 [ user="", password=“myPassword”, nibeId=“myId”, pollingInterval=300, customChannel01=43086 ]

String Nibe_43086_HeatingAction “NIBE - Aktueller Modus [MAP(]” {channel=“nibeuplink:vvm320:NibeF2040-8:custom#CH01”}

41=Pool 2
50=Transfer (?)

Do I miss something? By the way it seems the current DEV-Plugin Returns old values and Freeze them.

(oliviercommelarbre) #80

Hi Alex

i’ve been testing the new DEV version (the one you advertised in your post of Mar 28) and wanted to provide my feedback. Unfortunately i’ve had to revert to the previous version (see reasons after), I’ll wait for your feedback first.

One of the changes from the previous version is the use of the raw value, which has the side-effect of rendering the values with a wrong scale that no more corresponds to the expected unit. For instance, all temperatures are multiplied by 10, degree minutes also, and power channels (normally in kW) get multiplied by 100. I noticed it is not the case for the new current channels you had just added (40079, 40081 and 40083) that are given with the right scale in Amperes.

Nibe is pretty consistent however on the scale they apply on the raw value depending on the unit (i.e. temperatures are always scaled with factor 10, power with 100, degree minutes with 10, and so on), so i was wondering whether you could apply it before rendering the value.

The alternative is unfortunately quite cumbersome as it requires to systematically define temporary items and rules to rescale the value from the temporary to the final item, otherwise items get stamped in DB (through persistence) with their wrong unit.
I did not find any easier way to scale on the fly (e.g. the generic transformation services act only for display on the UI but not on the item value itself). However there are some bindings (see for instance the modbus binding) that allow rescaling on the fly the raw value before attaching it to the item (by reusing the generic openhab transformation concepts and syntax). You could alternatively follow a similar approach, however while i find it makes sense for Modbus (as modbus is actually always carrying integers), it would make little sense for nibeuplink as i see very little use case of wiling to apply a different scaling than the right one.

Looking back to the fact that the new BE1, BE2, BE3 current channels you have added indeed apply the /100 scaling to get to the right number in Amperes, i suppose that your intention is indeed to provide directly the scaled value and that you may have forgotten to do it for the previous channels.

looking forward to your feedback!