Does that mean that you are in fact communicating directly with the machine instead of the cloud service?
Mikael
No. The heatpump itself does not have any usable open ports. I’ve scanned it.
It has only 23/tcp open tcpwrapped
No idea what it is. It closes the connection as soon as I try to connect.
My script uses nibe uplink. But does the same that a user would do. Logs in with your username and password and then queries https://www.nibeuplink.com/PrivateAPI/Values endpoint with a list of variables.
I see, very interesting.
Mikael
I agree, what confuses me is that there seems to be different links and even different ways to catch up the parameters.
Regarding to https://www.marshflattsfarm.org.uk/wordpress/?page_id=3480 is the interesting parameters catched up one by one. And you must before you even can catch them, make your account authorized and in this process get an token which you then use for further catching of parameters.
In your code, you will login in once and then catch all parameters as you described, right?
Is the result delivered as JSON?
Lot of questions is’nt it:slight_smile:
Locking forward to see your code.
//Örjan
And here is the promised code.
See examples/mqtt.py to make it work as a service (This will authenticate ~ once a day).
All parameters are fetched in one request.
If somebody wants a debian package for the nibe -> mqtt bridge feel free to ask. That will simplify installation for non python people.
Hi,
Great, I will have a closer look asap, but so far it’s look nice.
//Basse
Hi,
I’m the author of https://marshflattsfarm.org.uk and I’m also an OpenHab 2 user though so far I haven’t attempted to integrate NIBE Uplink with OpenHab in any way. Like @yozik04 I’m publishing the parameter values I read from NIBE Uplink using MQTT so that’s how I thought I might get them into OpenHab in the future.
While MQTT should work OK for reading parameter values (e.g. to display the outside temperature in the OpenHab GUI), in order to use the Heat Pump “Manage” facilities (available via the Premium subscription for NIBE Uplink) I suspect we’d want to use some sort of tighter integration than MQTT.
Once you know the list of numeric Parameter IDs you want to retrieve (up to a limit of 15) you can do that via one API call with the Public API using GET https://api.nibeuplink.com/api/v1/systems/{systemId}/parameters (at least according to the API manual - I haven’t actually tried that yet).
The challenge is knowing which set of numeric Parameter IDs apply to a particular Heat Pump installation - they vary by Heat Pump Model and by the presence or absence of optional Heat Pump Accessories in a specific Installation. That’s my excuse for having my script query the “Categories” for a particular Heat Pump “System” (i.e. a particular installation) and then grab the Parameters for each Category (via one API call per Category, and from memory there are 2 Categories for my installation) - plus I wanted to capture all of the available Parameters, and there are more than 15.
Thanks to @Basse_03 for mentioning he was working on this topic when he contacted me via my Blog, which brought me here…
dMb
Hi there,
I managed to create an Openhab2 binding for Nibe Uplink. It is written in plain java so it is fully integrated into Openhab.
It is still in an early state of development so it supports only read access currently and only a few parameters.
Reverse engeneering of those undocumented parameters is quite a lot of work and unfortunately it depends on the heat pump model. Currently the binding supports only one generic thing which has one channel for each parameter Id.
Maybe it would be better to have one thing for each specific heatpump model and one thing for each additional module (compressor, exhaust/supply fan module, etc). But that would be a lot of effort.
Please check out the binding here:
Alex
Hi,
Great work, i will have a closer look asap, but first some questions.
You will make the nibeId once, when you are connected to the link described and then use this nibeId for all further collecting of posts, right?
Is it possible to set up an account without any working heatpump?
Regards Örjan
Parameters can be found from Nibe modbus application in CSV format per pump model (application can be download from internet). I created awk script to generate channel types from CSV for nibe heat pump 2 binding. See https://github.com/paulianttila/openhab2-addons/blob/nibe2-final/addons/binding/org.openhab.binding.nibeheatpump/ESH-INF/thing/f1x45-types.xml. See more details from my repo or PR https://github.com/openhab/openhab2-addons/pull/1960.
Not sure, if all parameters are available from uplink.
1 Like
Parameters can be found from Nibe modbus application in CSV format per pump model (application can be download from internet)
Thanks, that is exactly what I was looking for. It seems that this is only available on the swedish web page of nibe but finally I found it!
I created awk script to generate channel types from CSV for nibe heat pump 2 binding. See https://github.com/paulianttila/openhab2-addons/blob/nibe2-final/addons/binding/org.openhab.binding.nibeheatpump/ESH-INF/thing/f1x45-types.xml
Thanks again that will save me a lot of effort!
Not sure, if all parameters are available from uplink.
I already tested it and Nibe uplink came back with more than 5000 parameter values when I requested 10000 - 99999. So I guess it is all available although it is not documented anywhere.
I have now added support for following heatpump models:
- VVM310 / 500
- VVM320 / 325
- F750
- F1145 / 1245
- F1155 / 1255
Is is possible to add support also for f2025? 
I have one together with VVM310, which I see you have already supported.
Awesome job! I look forward to trying it out once I get my setup complete.
Mikael
Unfortunately the Modbus manager database does not know the F2025. Is that a new model? Maybe it will be added to the database at a later point of time.
Actually, it may be too old then. It is basically a 2020 with minor enhancements. Oh well, I might install the binding and see what I get with VVM310 data. Cheers!
If the F2020 supports Nibe Uplink I just need a mapping of channel IDs.
You could login to Nibe Uplink and use for example Firebug to analyze the JSON responses to the periodic POST requests. It will return pairs of keys (Nibe IDs) and values (actual sensor data) to be displayed in the WEB-UI.
Of course the WEB-UI offers only a small subset of sensor data but I think that is the most relevant data.
Cool!
How should I format it, and which data do you actually want?
For example, the heat pump compressor hours has ID44071 (and gives me 10904 hours). The title text is “compressor operating time EB101”.
Here’s anyway the data. But let me know if I miss something, or shall reformat!
(I see now, that I actually has a F2026, not 2025, as I wrote first. But they are very similar anyway!)
status
ID44396,charge pump speed EB101
ID44362,outdoor temp. EB101-BT28
compressor module
ID10014,blocked
ID44071,compressor operating time EB101
ID44073,compressor operating time hot water EB101
ID44069,compressor starts EB101
ID44058,condenser out EB101-BT12
ID44363,evaporator EB101-BT16
ID44059,hot gas EB101-BT14
ID44060,liquid line EB101-BT15
ID44055,return temp. EB101-BT3
ID44061,suction gas EB101-BT17
info
Title Value
ID0, product F2026-8
ID44014,version EB101Hi Micael,
the F2026 is the outdoor unit belonging to your VVM310? In that case all data should be retrieved by the VVM310. Outdoor units are not handled seperately.
Aha! Yes, this is the outdoor unit - and it looks like all the ID’s are supported, as you say, through the 310. 
Is there a jar somewhere? I’m on 2.10 release still will it work or does it need 2.2? (I am considering upgrading to 2.2, so if this is needed for this binding, I’ll do this).