hass_nibe
hass_nibe copied to clipboard
elupus
Official list of parameters
Hi,
In the readme file you mention to use the various parameters to create switches and climate entries. I stumbled upon the following list on Nibe's website: https://api.nibeuplink.com/docs/v1/Parameters
Do you use another list for your implementation? If not is the list I provided exhaustive or have you implemented other parameters?
Thanks!
That list is very Short. You have one here: https://github.com/openhab/openhab1-addons/wiki/Nibe-Heat-Pump-Binding
But i haven't wanted to copy that for now.
Hi,
Thanks a lot. That looks like the full list of sensors. Is there anywhere I can find the list of possible switches?
Thanks!
ok. Thanks. Worth asking Nibe then. I can take that upon me and will revert to this thread.
Ask them for a parameter that tells if the pump is currently producing hot water or heat. While you are at it :) Like the one in the status menu of the pump. Currently no good way to deduce.
Which menu do you refer to? 3.2?
I have now asked Nibe support but considering that on this page https://api.nibeuplink.com/docs/v1/Parameters they mention that "In most cases this is provided to you via the API" I am not even sure they have a full list themselves.
Playing a bit in PostMan with the API, you get already a quite exhaustive list using this function GET api/v1/systems/{systemId}/serviceinfo/categories?parameters=true - Which I guess you already know since your code seems based on this. All of the other System functions can also help get the parameters but still, it is very hard to find which ones are actually actionable and which ones are just sensors.
Will keep this thread posted. To that purpose, maybe we should re-open this issue?
So, I talked to Nibe and here are some updates:
- They don't have a list of parameter Ids
- The list of available options for each pump is available when you perform the following API request: https://api.nibeuplink.com/docs/v1/Api/GET-api-v1-systems-systemId-serviceinfo-categories_systemUnitId_parameters - Based on that you get the parameters and their values (which this component seems to do)
- The parameters that can be used as switch are here: https://api.nibeuplink.com/docs/v1/Parameters in the section Settings. Their security restriction (or financial interest) do not allow for modification of any other parameters.
- I tried this method https://api.nibeuplink.com/docs/v1/Api/PUT-api-v1-systems-systemId-parameters on various parameters that I can modify in the app/web site and the above statement seems right (at least in my case). I get a 400 error every time I try to set something not authorised.
With all of that being said, I wonder of the choice of ventilation is handled with the API as per this post: https://github.com/elupus/hass_nibe/issues/10 - In my understanding you can only set a ventilation boost with the API (i.e. set it to 100% for a few hours) and can't decide about the various levels of ventilation.
@elupus - You still did not answer my question on my previous post.
Hope this helps!
Ok. Roger that. I think I got this in some API calls I made. Will check again and revert back.
Do you have ventilation component? What parameters are listed for it under categories? Do you get current fan speed?
Yes I do. here are the results from the API call GET api/v1/systems/{systemId}/serviceinfo/categories
{
"categoryId": "VENTILATION",
"name": "ventilation",
"parameters": [
{
"parameterId": 10001,
"name": "10001",
"title": "fan speed",
"designation": "",
"unit": "%",
"displayValue": "75%",
"rawValue": 75
},
{
"parameterId": 40025,
"name": "40025",
"title": "exhaust air",
"designation": "BT20",
"unit": "°C",
"displayValue": "21.6°C",
"rawValue": 216
},
{
"parameterId": 40026,
"name": "40026",
"title": "extract air",
"designation": "BT21",
"unit": "°C",
"displayValue": "-7.1°C",
"rawValue": -71
}
]
}
In the menu I can change the ventilation to the following speed in the pump and online on nibeuplink.com
normal (75%)
speed 1 (0%)
speed 2 (30%)
speed 3 (80%)
speed 4 (100%)
which corresponds to the following parameters id
{
"parameterId": 47264,
"name": " 47264",
"title": "Exhaust Fan speed 1",
"designation": "",
"unit": "%",
"displayValue": "0%",
"rawValue": 0
},
{
"parameterId": 47265,
"name": " 47265",
"title": "Exhaust Fan speed normal",
"designation": "",
"unit": "%",
"displayValue": "75%",
"rawValue": 75
},
{
"parameterId": 47263,
"name": " 47263",
"title": "Exhaust Fan speed 2",
"designation": "",
"unit": "%",
"displayValue": "30%",
"rawValue": 30
},
{
"parameterId": 47262,
"name": " 47262",
"title": "Exhaust Fan speed 3",
"designation": "",
"unit": "%",
"displayValue": "80%",
"rawValue": 80
},
{
"parameterId": 47261,
"name": " 47261",
"title": "Exhaust Fan speed 4",
"designation": "",
"unit": "%",
"displayValue": "100%",
"rawValue": 100
},
But as you can see the parameter raw value are not 0 or 1. Meaning not a boolean. Any attempt of changing the value with PUT api/v1/systems/{systemId}/parameters will result in an error. Which corresponds to what Nibe has said so far. Which is why I wonder how the selection of the fan speed was possible in the other post.
As for the parameters 3.1 and 3.2. I do not have them either, nor in category listing nor in the full list that you provided here: https://github.com/openhab/openhab1-addons/wiki/Nibe-Heat-Pump-Binding
Hi elupus, im also looking for a working register to se what the heatpump does. To help you on your way. All the sensor numbers is modbus registers. And to get the right "register" you can download modbus manager from nibe. The register that tells if the heatpump does hotwater, heating, pool etc is called "prio" you can also get the state from ep14 to see if compressor is running. And at last. If theres no other option you can get relaystatus. I hope nibes api let thisbinfo throught the api so we can read it.
@rickardnr1 sadly i wasn't able to find those things. I did figure out that the system reports a status string telling which subsystem is currently active. So that is now used to tell if we are heating house or hotwater (that will be wrong if there are multiple compressors.)
@elupus, if you download modbus manager (https://proffs.nibe.se/upload/NEW/Support/Kommunikation/NIBE%20ModbusManager%201.0.9%20%5bv8310%5d%20Setup.exe) and chose product you will get all register and what walue you will recive. The sad thing is that not all registers is open throught the api. I found out a way to see if my groundsourcebheatpump isbdoing hw or househeating by registrer for amounts of compressors doing hw and heating. Strange that the register prio is closed in the api.
To see prio on ex 1145 read registers: 43427 (20=stopped, 40=starting, 60=running, 100=stops) 44283 (how many compressors doing heating, for a normal stand alone in a regular house you get 0 or 1) 44282 how many compressors doing hotwater, for a normal stand alone in a regular house you get 0 or 1)
@elupus feel free to ask, i work with all nibes products so i know what almost all registers mean and do
@rickardnr1 - another way to get the prio is via the status/system api call. It returns an ordered list of actions on the system, with the first item in the list being the active one (verified against the priority indication on the pump's panel). So for example you'd get something like ["Hot Water", "Ventilation", "Compressor", "Heating Medium Pump"] (just the title attribute of each item included for brevity).
I've wrapped that in a custom NibeSystemStatusSensor class and it shows up nicely under a History Graph Card.
@alecx as far as i've seen the order of the data doesn't mean much. But it does indicate if something is currently active (in the list or not). I'm using that since a while back to deduce if we are heating home or hot water. But it's ugly to rely on titles.
@rickardnr1 sadly those parameters are not available on my system:
{
"parameterId": 44282,
"name": "44282",
"title": "Used cprs. HW",
"designation": "",
"unit": "",
"displayValue": "--",
"rawValue": -32768,
"value": null
}
{
"parameterId": 44283,
"name": "44283",
"title": "Used cprs. heat",
"designation": "",
"unit": "",
"displayValue": "--",
"rawValue": -32768,
"value": null
}
What heatpump model do you have elupus?
Den ons 13 mars 2019 13:08Joakim Plate [email protected] skrev:
@rickardnr1 https://github.com/rickardnr1 sadly those parameters are not available on my system:
{ "parameterId": 44282, "name": "44282", "title": "Used cprs. HW", "designation": "", "unit": "", "displayValue": "--", "rawValue": -32768, "value": null } { "parameterId": 44283, "name": "44283", "title": "Used cprs. heat", "designation": "", "unit": "", "displayValue": "--", "rawValue": -32768, "value": null }
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/elupus/hass_nibe/issues/17#issuecomment-472395713, or mute the thread https://github.com/notifications/unsubscribe-auth/Ac6tFBs1jvB8eT42f4xayfPJYSI_fH6bks5vWOoqgaJpZM4agoht .
Strange, what software version?
Den ons 13 mars 2019 13:37Joakim Plate [email protected] skrev:
F1155
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/elupus/hass_nibe/issues/17#issuecomment-472404477, or mute the thread https://github.com/notifications/unsubscribe-auth/Ac6tFK--FG3rbWO7K-xndXNCk-5YUmSmks5vWPEHgaJpZM4agoht .
Here’s a long list of interesting parameters (although in xml format): https://github.com/paulianttila/openhab2-addons/blob/nibe2-final/addons/binding/org.openhab.binding.nibeheatpump/ESH-INF/thing/f1x45-types.xml
Hi, that parameter is closed throught the api and returns unknown. The xml is only for grund source heatpumps with on/off compressor, the best way to be updated is to use modbus manager when all products is shown and use an updated database.
Den sön 17 mars 2019 07:13bohtho [email protected] skrev:
@rickardnr1 https://github.com/rickardnr1 @elupus https://github.com/elupus Try 43086 for list of priority and current action.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/elupus/hass_nibe/issues/17#issuecomment-473620135, or mute the thread https://github.com/notifications/unsubscribe-auth/Ac6tFMhLTiteLafj3XkC8gMXyQC58tIaks5vXdz3gaJpZM4agoht .
43086 indeed seems blocked through the API.. But I have confirmed with ModbusManager 1.0.9 Database 8310 with my products chosen (VVM320/F2120) that 43086 is the prio list.
Yes many registers is the same for all products, i dont know they have closed the prio, and also som other useful states but many usless registers are open.
Den sön 17 mars 2019 08:46bohtho [email protected] skrev:
43086 indeed seems blocked through the API.. But I have confirmed with ModbusManager 1.0.9 Database 8306 with my products chosen (VVM320/F2120) that 43086 is the prio list.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/elupus/hass_nibe/issues/17#issuecomment-473625906, or mute the thread https://github.com/notifications/unsubscribe-auth/Ac6tFMJXNV7CfXl4bwaidZmaElY2pSoLks5vXfK5gaJpZM4agoht .
Very odd.
Is 8310 the latest database version ? And more importantly: Is the API using the latest database ..... ? :-/ Could any of you Swedes ask NIBE and remind them to update the API on behalf of a Norwegian and many others? :)
For example: "water_heater.nibe_67980_40014" always returns off when I have set my VVM320´s hotwater to "smart control" (new setting in latest software upgrade). API seems very outdated.
Yes , i got that version to and updater says its the latest
Very odd.
Is 8310 the latest database version ?
Does anyone have an email address to somebody more specific than info at nibe dot eu ? Someone more of a technical contact person ? Ideally working on the API. To get them to update the parameters available via the API.
I’ve contacted Uplink Support about the strange selection of parameters currently available and directed them to the latest modbus database.
Yeah i contacted them to just about why some registers where closed throught the api and got the answer: yeah some values is closed i dont know why but it is so. I put your questions further.... Not so impressive answer...
Den fre 22 mars 2019 12:40bohtho [email protected] skrev:
I’ve contacted Uplink Support about the strange selection of parameters currently available and directed them to the latest modbus database.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/elupus/hass_nibe/issues/17#issuecomment-475588937, or mute the thread https://github.com/notifications/unsubscribe-auth/Ac6tFCSpNHvqvBNcxWjttCJIDhN_AzHDks5vZMEkgaJpZM4agoht .
I got desperate and set up my Mac as a proxy for my NIBE (luckily proxy can be set locally in the NIBE Uplink menu). I even tried to do a "MITM-attack"/intercept https calls by making a SSL-certificate for nibeuplink.com, but as I havent figured out how to put a corresponding CA sertificate on the NIBE itself, and the NIBE is protected with SSL-pinning, I only got to see that it first contacted control.nibeuplink.com (which is hosted on Microsoft Azure) without encryption for a textfile with the current Uplink IP, and then only wanted to go further by https/SSL-encrypted (which I either couldn't read because of SSL, or it failed because it noticed I tried to simulate a SSL certficate for controlnibeuplink.com which it couldnt verify).
There's also a telnet service running on port 23 which drops the connection anytime I try to connect, which may mean it's busy and already connected to somewhere.
Had the API call interception worked I am sure I could have reverse-engineered the local API, and read all Modbus parameters. The Hass_nibe plugin maybe could have been reworked to both work locally (with all parameters and without internet) and against NibeUplink.com (for remote connections and smart functions).
I honestly think NIBE should make a locally accessible API as well (ie. just accept local unencrypted connections).
Would love if they allowed local access. Initially was going to do the plug-in over modbus, but this was easier.
There's great potential in a good API with benefits of remote smart functions, but I agree something direct and local would be great.
I wonder if the telnet connection is for modbus TCP. And if it's possible to break the current telnet connection which makes it busy and inaccesible to us (or open it by a setting on the NIBE?).
I read that someone was asking for some kind of prio sensor. I have been running this template sensor for some months now and it works really well. I just installed the new Hass_Nibe component and it still works great. I have a F750 and the sensor has never showed the Error message.
Just replace the "XXXXX" with your own System ID.
sensor:
- platform: template
sensors:
nibe_prio:
friendly_name: "Prio"
value_template: >-
{% if states.sensor.nibe_XXXXX_43115.state != 'unavailable' and states.sensor.nibe_XXXXX_43064.state == 'unavailable' %}
Hot water
{% elif states.sensor.nibe_XXXXX_43115.state == 'unavailable' and states.sensor.nibe_XXXXX_43064.state != 'unavailable' %}
Heating
{% elif states.sensor.nibe_XXXXX_43115.state == 'unavailable' and states.sensor.nibe_XXXXX_43064.state == 'unavailable' %}
Ventilation only
{% else %}
Error
{% endif %}
Interesting.... I have a F470, I have neither sensor 43115 or 43064. What are they called in your system?, i.e. "designation" or "friendly name"?
In my F750:
- 43064 has friendly_name: heat: dT calc. value (värme: dT börvärde)
- 43115 has friendly_name: HW: charge calc value (vv: laddbörvärde)
Michael
15 apr. 2019 kl. 21:10 skrev a94marbo [email protected]:
Interesting.... I have a F470, I have neither sensor 43115 or 43064. What are they called in your system?, i.e. "designation" or "friendly name"?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
Hmm... how do your nibe config look like?.. I seem not to get these sensors... This is my config.
nibe: systems: - system: XXXXX units: - unit: 0 categories: True statuses: True climates: True water_heaters: True
@rickardnr1 do you know if there is parameter to detect if there is a ventilation unit?
i guess 48071 is the parameter for it . its called flm1 acessory and 1=activated, 0=inactivated
Yes I do. here are the results from the API call GET api/v1/systems/{systemId}/serviceinfo/categories
{ "categoryId": "VENTILATION", "name": "ventilation", "parameters": [ { "parameterId": 10001, "name": "10001", "title": "fan speed", "designation": "", "unit": "%", "displayValue": "75%", "rawValue": 75 }, { "parameterId": 40025, "name": "40025", "title": "exhaust air", "designation": "BT20", "unit": "°C", "displayValue": "21.6°C", "rawValue": 216 }, { "parameterId": 40026, "name": "40026", "title": "extract air", "designation": "BT21", "unit": "°C", "displayValue": "-7.1°C", "rawValue": -71 } ] }In the menu I can change the ventilation to the following speed in the pump and online on nibeuplink.com
normal (75%) speed 1 (0%) speed 2 (30%) speed 3 (80%) speed 4 (100%)which corresponds to the following parameters id
{ "parameterId": 47264, "name": " 47264", "title": "Exhaust Fan speed 1", "designation": "", "unit": "%", "displayValue": "0%", "rawValue": 0 }, { "parameterId": 47265, "name": " 47265", "title": "Exhaust Fan speed normal", "designation": "", "unit": "%", "displayValue": "75%", "rawValue": 75 }, { "parameterId": 47263, "name": " 47263", "title": "Exhaust Fan speed 2", "designation": "", "unit": "%", "displayValue": "30%", "rawValue": 30 }, { "parameterId": 47262, "name": " 47262", "title": "Exhaust Fan speed 3", "designation": "", "unit": "%", "displayValue": "80%", "rawValue": 80 }, { "parameterId": 47261, "name": " 47261", "title": "Exhaust Fan speed 4", "designation": "", "unit": "%", "displayValue": "100%", "rawValue": 100 },But as you can see the parameter raw value are not 0 or 1. Meaning not a boolean. Any attempt of changing the value with PUT api/v1/systems/{systemId}/parameters will result in an error. Which corresponds to what Nibe has said so far. Which is why I wonder how the selection of the fan speed was possible in the other post.
As for the parameters 3.1 and 3.2. I do not have them either, nor in category listing nor in the full list that you provided here: https://github.com/openhab/openhab1-addons/wiki/Nibe-Heat-Pump-Binding
Changing the fan speed is possible on F750 by setting the paramterId 47260 to the values 0,1,2,3,4 (0 = normal)
I´ve seen some more people requesting this and I would also love to see this implemented if possible. :)
In my F750: - 43064 has friendly_name: heat: dT calc. value (värme: dT börvärde) - 43115 has friendly_name: HW: charge calc value (vv: laddbörvärde) Michael …
Does anyone know the appropriate parameters to use for “prio”/status on the VVM320/F2120?
I don't understand how to list the sensors/parameters. E.g. the "outdoor temp" (40004) which previously got the name "sensor.nibe_XXXXX_40004" in an old version of this integration. How do I get that value? What does
nibe:
systems:
- system: XXXXX
units:
- unit: 0
categories: true
statuses: true
climates: true
water_heaters: true
fans: true
sensors:
- outdoor_temp
- out_temp
- BT1_outdoor_temp
- 40004
- '40004'
- nibe_XXXXX_40004
- 'BT1 outdoor temp'
- 'outdoor temp'
and restarted, but no sensor was created. (XXXXX replaced with my system id) And no new attribute was added to the 4 entities that was created (climate.room, climate.supply, fan, water_heater).
Please help!
Please check what sensors you already have. In developer options states. Nothing is added to GUI in Lovelace automatically.
PS. The sensor setting with just a number was correct.
Also I you upgraded yesterday , you probably got hit by a bug that caused a lot of sensors to fail.
I did. I checked in states but no luck. And i did update a lot this morning and spent most of the day getting things working.
It works. I got all my old sensors back. Not only the 40004 I asked for, so I don't know what the parameter is for. But that's ok. Thanks!
Does someone know if it would be possible to block the compressor/heating based on a sensor input through the nibe write capabilities? I want to block my heating if the BT71 sensor is above a certain point, to reduce the number of start/stops.
There's also a telnet service running on port 23 which drops the connection anytime I try to connect, which may mean it's busy and already connected to somewhere.
Try this: Create a file named „TELNET.KEY“ with the word „dextermorgan“ (without quotes) in it. Put the file on a USB stick and insert the stick into the USB port of the NIBE. There will appear a key in the heat pump symbol at the main menu. Now the telnet connection seems to stay, but the heat pump doesnt send any text....
There's also a telnet service running on port 23 which drops the connection anytime I try to connect, which may mean it's busy and already connected to somewhere.
Try this: Create a file named „TELNET.KEY“ with the word „dextermorgan“ (without quotes) in it. Put the file on a USB stick and insert the stick into the USB port of the NIBE. There will appear a key in the heat pump symbol at the main menu. Now the telnet connection seems to stay, but the heat pump doesnt send any text....
This is really interesting! How did you come about the password?!
I wonder if it needs a command for each type of reply.
@bohtho did you test that telnet key stuff? Seems he registered on github just to write that comment. That's his only activity. So it's likely internal info. But i get no reaction trying it on my pump. Felt a bit scary given what Dexter Morgan did for a living :)
Very odd. But no, I never went that route, especially since he said he didn’t get a response from the heat pump. I have a Modbus to WiFi gateway I need to remove dust from and finish adjusting, while I use your project (Hass nibe) in the meantime.
anyone else tried the Telnet stuff?