Write access to the API is not yet implemented. Therefore setting channels cannot be modified.
As some users had problems with the jackson dependency: It is now removed and replaced with gson which is made automatically available by the openhab platform. Check out the latest version.
1 Like
Hi Alex, thanks for the great work. Works perfect.
Hi @AlexF, thank you for the great work!
I get similar error messages as ChristophK and HenrikW do:
[WARN ] [beuplink.handler.GenericUplinkHandler] - Could not update channel sensor#43561 - invalid number: âNeinâ
[WARN ] [beuplink.handler.GenericUplinkHandler] - Could not update channel sensor#43536 - invalid number: âNeinâ
[WARN ] [beuplink.handler.GenericUplinkHandler] - Could not update channel sensor#41446 - invalid number: âNeinâ
[WARN ] [beuplink.handler.GenericUplinkHandler] - Could not update channel sensor#44379 - invalid number: âausâ
[WARN ] [beuplink.handler.GenericUplinkHandler] - Could not update channel sensor#44256 - invalid number: âNeinâ
[WARN ] [beuplink.handler.GenericUplinkHandler] - Could not update channel sensor#43160 - invalid number: âNeinâ
[WARN ] [beuplink.handler.GenericUplinkHandler] - Could not update channel sensor#43161 - invalid number: âNeinâ
[WARN ] [beuplink.handler.GenericUplinkHandler] - Could not update channel sensor#43158 - invalid number: âNeinâ
[WARN ] [beuplink.handler.GenericUplinkHandler] - Could not update channel sensor#43159 - invalid number: âNeinâ
[WARN ] [beuplink.handler.GenericUplinkHandler] - Could not update channel sensor#41191 - invalid number: âwartetâ
[WARN ] [beuplink.handler.GenericUplinkHandler] - Could not update channel sensor#40942 - invalid number: âNeinâ
[WARN ] [beuplink.handler.GenericUplinkHandler] - Could not update channel sensor#40340 - invalid number: âNeinâ
[WARN ] [beuplink.handler.GenericUplinkHandler] - Could not update channel sensor#40342 - invalid number: âNeinâ
[WARN ] [beuplink.handler.GenericUplinkHandler] - Could not update channel sensor#40341 - invalid number: âNeinâ
[WARN ] [beuplink.handler.GenericUplinkHandler] - Could not update channel sensor#44702 - invalid number: âNeinâ
[WARN ] [beuplink.handler.GenericUplinkHandler] - Could not update channel setting#48189 - invalid number: âausâ
[WARN ] [beuplink.handler.GenericUplinkHandler] - Could not update channel sensor#40339 - invalid number: âNeinâ
[WARN ] [beuplink.handler.GenericUplinkHandler] - Could not update channel sensor#44908 - invalid number: âinaktivâ
I use the vvm310 openhab model with a VVM500.
Would it be possible to remove those warnings, too? Thank you very much!
Hi write functions / switch things would be nice. In my case when sauna is warm i would like to boost ventilation and when there is lots of people visiting i would like to automatically boost hot water production.
1 Like
Hi,
thank you for that addon, it works almost perfect for me !
I´m just missing one Parameter for my F1255 which is ID 43439 âbrine pump speed EP14-GP2â.
Would it be possible to integrate that parameter ?
Thanks
Hi @tanzbaer2
I have fixed those channels.
@Mikko_Jokinen: I will implement the write access in a later version, as soon as I will find time for itâŚ
@Main666: The channel you mentioned is already implemented, if you do not get any data our setup either does not support this channel or the data is in general not provoded via the NIBE Uplink API.
BR
Alex
Hi Alex,
thanks for the info about the ID43439. My fault was to use PaperUI and then having selected the wrong pump typeâŚ
Moved everything to the good old files, now ist working perfectly.
Thanks again for the great Addon !
Hi all,
in order to get this binding intregrated into the official distribution I need to reduce the complexity in the first step. This means that I am forced to reduce the amount of available channels.
The list of channels will be based on the vvm302-special and adopted to other models. However if you have wishes which channels you want to see in the first version please post your model and channel list here.
Thanks
Alex
Hi @AlexF,
I do not like the idea of reducing the amount of available information. I do not know a lot of details about bindings, so I apologize if the question sounds silly: Would it be possible to restructure the binding in a way so that, e.g., there is one get and one set channel with a parameter for the ID? Would that reduce the âchannel countâ, i.e., the complexity?
Doesnât âthe otherâ Nibe binding include the full data set? While I do understand that the list might be quite extensive if everything is included, I think itâs unfair to have to reduce the data set to get the binding included. What channels are important for one are trash to another and vice versa.
Of course if a simple model gets integrated, full complexity can be added the very next dayâŚ
Well indeed I want to get a basic version integrated. Afterwards two things will happen:
- More and more channels will be added on request by users
- I will try to add a âgeneric thingâ (this will most likely not included in the official openhab dsitro) which just has channels from 10000 - 10050 and 40000 - 49000 (which are afaik the ranges). All channels will then be handled as strings and there wonât be any descriptions as this is generic. This would be for testing and for very advanced users.
Hey Alex,
Thanks for creating this module. I have an F1145 and the module works great. Obviously, I would like to maintain the 1145 channel 
Is there a way to send you a beer (or something similar) as a token of gratitude for your work?
Cheers,
Rik
Gosh thanks for that AlexF thatâs an amazing job!
i stumbled on this article when looking for an alternative to using the Nibeuplink API after i found it had some instability along time (the effective refresh i get from the API goes from time to time down to about 10 minutes or so and over long periods, which is not so good for the more accurate monitoring iâm trying to have).
So i tried your addon to interface my F1145 and it worked straight away out of the box ! it is also very intuitive and well documented, really well done!
for my application i would just need a few more parameters and i was wondering if they could added to the F1145 config. The ones that i found missing are the following:
- Param 10012, giving the âstatus blockedâ of the compressor module
- Param 10033, giving the âstatus blockedâ of the supplementary power module
- Param 43165, giving the status âHPAC External Blocking Active Coolingâ
- Param 43166, giving the status âHPAC External Blocking Passive Coolingâ
- Param 47412, giving the heating/cooling mode the machine is currently working on
I would really appreciate if these could be added as i could then completely switch to using it. please let me know otherwise.
I take the opportunity to report a few warnings i get in the openhab log, may be these could be fixed also, they seem to relate to datatype mismatch for some parameters, here the extract of the recurrent warning messages i get:
2018-02-06 09:51:14.876 [WARN ] [euplink.handler.GenericUplinkHandler] - Could not update channel sensor#43560 - invalid number: 'noâ
2018-02-06 09:51:14.881 [WARN ] [euplink.handler.GenericUplinkHandler] - Could not update channel sensor#43561 - invalid number: 'noâ
2018-02-06 09:51:14.924 [WARN ] [euplink.handler.GenericUplinkHandler] - Could not update channel sensor#43164 - invalid number: 'noâ
2018-02-06 09:51:14.932 [WARN ] [euplink.handler.GenericUplinkHandler] - Could not update channel sensor#43160 - invalid number: 'noâ
2018-02-06 09:51:14.938 [WARN ] [euplink.handler.GenericUplinkHandler] - Could not update channel sensor#43161 - invalid number: 'noâ
2018-02-06 09:51:14.943 [WARN ] [euplink.handler.GenericUplinkHandler] - Could not update channel sensor#43158 - invalid number: 'noâ
2018-02-06 09:51:14.948 [WARN ] [euplink.handler.GenericUplinkHandler] - Could not update channel sensor#43159 - invalid number: 'noâ
2018-02-06 09:51:14.963 [WARN ] [euplink.handler.GenericUplinkHandler] - Could not update channel sensor#41191 - invalid number: 'waitingâ
2018-02-06 09:51:15.035 [WARN ] [euplink.handler.GenericUplinkHandler] - Could not update channel setting#48189 - invalid number: 'offâ
2018-02-06 09:51:15.231 [WARN ] [euplink.handler.GenericUplinkHandler] - Could not update channel sensor#40942 - invalid number: 'noâ
2018-02-06 09:51:15.262 [WARN ] [euplink.handler.GenericUplinkHandler] - Could not update channel sensor#40340 - invalid number: 'noâ
2018-02-06 09:51:15.269 [WARN ] [euplink.handler.GenericUplinkHandler] - Could not update channel sensor#40342 - invalid number: 'noâ
2018-02-06 09:51:15.273 [WARN ] [euplink.handler.GenericUplinkHandler] - Could not update channel sensor#40341 - invalid number: 'noâ
2018-02-06 09:51:15.291 [WARN ] [euplink.handler.GenericUplinkHandler] - Could not update channel sensor#40339 - invalid number: 'noâ
2018-02-06 09:51:15.306 [WARN ] [euplink.handler.GenericUplinkHandler] - Could not update channel sensor#44908 - invalid number: âinactiveâ
congrats again and cheers!
Olivier
Hey, I think the problem is the sheer amount of parameters. The F1155/1255 alone has more than 900 possible variables to read or write to. As the total number being transmitted by the pump is 20 registers (16 bit afaik), wouldnât it be possible to define 20 âtemplate channelsâ for which data type and coil address can be specified by the user? This would reduce complexity, but also make it more generic for whatever to come.
Another question: I would like to adjust NibeHeatPumpDataParser.java to include the variables of my F1255. How can I do that, is there any tutorial on compilation of the binding?
Thanks,
Klayman
@oliviercommelarbre:
I can try to add the channels but I am quite sure that 47412 does not return the heating/cooling mode but the prupose of the X7 I/O which is (in my case) indead used to specify the heating/cooling mode.
Regarding the warnings: I have recently updated the binding and removed many channels because itâs hard to maintain. Instead I have switched to a limited list of channels which should work without any issue. Of course channels can be added as soon as I get a request and a proof that the channels really works via Nibe Uplink.
@klayman:
A limited list of 20 channels is not very much I am already using more than 20 channels. The generic approach might be ok for up to 20 channels but if 50+ channels will be allowed this will also be hard to maintain for the users.
BTW: It is not only 900 channels it is more than 2000 at least my VVM320 returns data on more than 2000 channels. Of course there is no documentation at allâŚ
I have therefore written a little tool that polls ALL possible channels (10000 - 10500 and 40000-50000) and logs data to an excelsheet and any change to the console. I found out that most channels do not change and therefore those are supposed to be settings or even unused registers.
Regarding your question: Which binding are you talking about? My binding has no class called âNibeHeatPumpDataParser.javaâ. And there is no need to adopt any Java Code except a simple enumeration class to add a channel. Most of the work is done in XML files.
Oooh, my bad. I was referring to the Nibe Heat Pump Binding found here. I have put together a small Arduino with an ethernet shield and a RS485 to 232 converter, which sends up to 20 modbus registers to openHAB. Avoids the necessity of Nibe cloud 
There is a software called âNibe Modbus Managerâ from Nibe which allows you to configure the modbus registers to be sent by the heatpump. In there, if you select your model and then export all variables to a file, you get a pretty good idea of the theoretically possible variables. Their numbers and identifiers match the code of the uplink page (some IDs are found in the HTML code).
best,
Klayman
That is exactly what I did in the first place. But unfortunately it turned out that lots of channels are not provided via Nibe Uplink while others are available via NibeUplink that are not available in Nibe Modbus manager.
I do not like the cloud approach either but I have a 10 year warranty in my Nibe and I will definitely lose it if I attach any custom hardware to it. Therefore I am unfortunately limited to Nibe Uplink.
Thank you Alex. you are most probably right about the 47412.
it is effectively documented as the X7 I/O which in my plant could well be used (as for yours) to specify the heat/cool mode to the pump. Indeed i can specify the winter/summer mode via my house clima controller, and probably the X7 is used to carry that automatically to the F1145.
All the parameters i listed are part of the default selection of Nibeuplink accessible via the official API when querying the various system categories (via api/v1/systems/{systemId}/serviceinfo/categories), so i would think they are definitely communicated via Nibeuplink.
In my case i can already confirm that i get consistent updates (via my other interface) on 10012 and 10033. I guess i will have to wait for summertime to see updates on 43165 and 43166.
concerning the warnings: thanks for the info.
are you using this repository to publish the updates?: https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/binding/org.openhab.binding.nibeuplink/ (it is where i initially downloaded the binding a few weeks ago)
Hi @oliviercommelarbre, @tanzbaer2, @mikaelgu and all others
I have implemented a version that supports up to 8 custom channels where you could specify any ID of your choice. Of course all those channels are handled as String type to be generic.
The latest DEV version can be found here: http://friese-de.eu/openhab2/
@oliviercommelarbre You could use this version to test the channels you requested in advance of my official implementation.
BR
Alex