By default it updates every minute, but the API only allows to request 15 parameters at a time, so if you have many channels connected they are split into chunks which are sent in 5 second interval until all have been updated.
You can change the polling interval on the bridge, but setting it too low can cause problems if not all requests have been sent before the next update cycle.
Last question related to the fact that I’ve noticed REST API gets “stuck”, so it might not receive updates for hours and I can confirm it from “Last update” field:
Have you noticed this on your setup? Could I troubleshoot this somehow to find out if it’s just my setup or a software bug?
No, never had this problem. But note that that value is the last time Nibe received values from your heatpump, not necessarily the last time the binding got the values. Do you see different values when you log into nibeuplink.com?
Yes, nibeuplink.com shows different values that I can confirm to be correct ones by locally comparing them to heatpump’s values.
…also now that I tried to disable/enable Nibe things, only API bridge got back online
update: restarting openHAB service fixed this (for now)
Could you enable trace logging and let it run for a while the next time it happens? log:set TRACE org.openhab.binding.nibeuplinkrest in the karaf console. It should log every time it sends a request, so can be quite chatty, but should give some hints.
As for disabling/enabling the things I’ve never actually done that, but will try to see what happens and correct it.
I’ve noticed that nibe’s service have been unstable lately, sometimes returning 50x errors, in which case the binding changes the bridge status to OFFLINE and clears all requests until it’s back online. When it’s going OFFLINE/ONLINE frequently this might cause it to take time before it can update values successfully. Also, the requests that do succeed takes a long time to return, causing the queue to fill up faster than the requests can be executed, which can also cause problems. I will see if I can get the binding to handle this more gracefully, but might need to refactor the code quite a bit, so might take a few days.
1 Like
”Last update” is showing GMT+0 time and not my local time. Can this be changed somewhere? Other bindings/things are showing local time.
Hmm, GMT+0 is what the API returns, and when put into a DateTimeType i think it should handle timezone conversion automatically (it’s internally stored as a ZonedDateTime) but not sure how to tell OH in what timezone to display. But I also see that DateTime items from other bindings are displayed differently, will check how they do it.
The timezone issue was an easy fix, uploaded a new build. I also increased the trace logging to make it easier to debug the other issues. Now you should be able to follow the requests from when they’re put in the queue to when the channels are updated.
1 Like
Air velocity sensor is not returning any value (it does on the nibeuplink.com), only reference value is shown:
Is this something that you are observing as well?
Can you check the state of the item in some other way? PaperUI doesn’t display the raw state of the Item, I would guess it is either NULL or UNDEF for some reason. What does your events.log show for this Item?
It’s “NULL”
events.log has a lot of entries for reference air velocity, but not so many for air velocity:
2021-01-15 16:48:12.785 [ome.event.ItemUpdatedEvent] - Item 'NibeF750RESTAPI_Defrosting_ValueAirVelocitySensor' has been updated.
2021-01-15 17:41:40.655 [vent.ItemStateChangedEvent] - NibeF750RESTAPI_Defrosting_ReferenceAirVelocitySensor changed from 226.9 to UNDEF
2021-01-15 17:47:40.766 [vent.ItemStateChangedEvent] - NibeF750RESTAPI_Defrosting_ReferenceAirVelocitySensor changed from UNDEF to 228.1
(for some reason the most recent entries were from 15th, although the file itself had a modification time stamp of today)
Is it just the Nibe REST binding that doesn’t have any newer log entries or are there none at all since the 15th? In the former case, try to restart the binding (bundle:restart org.openhab.binding.nibeuplinkrest) or openHAB. If there are no entries at all I’m afraid you might have bigger problems (possibly a failing SD-card if you’re using a Raspberry Pi), which you should look into.
@tunnus @emiel I made some updates to the binding which should hopefully make it a bit more stable when Nibe uplink goes down and up again rapidly. I can only say hopefully because the only way to actually test it is when the service goes down the next time, so unless you want to help me test it out you might want to wait with updating.
It also includes some other improvements, such ar better handling of configuration updates of the bridge (when changing the update intervals) and autodiscovery of thermostats (if you don’t want to use them, just ignore them in the inbox).
The OH3 version is available here and OH2 version here.
Note that for the OH2 version the version number has changed, which requires some additional steps to update:
- Delete the old .jar from the addons-folder
- Login to the karaf console and execute
bundle:uninstall org.openhab.binding.nibeuplinkrest - Drop the new .jar into the addons-folder
Alternatively, delete the old .jar, put the new one and restart openHAB.
If you have any issues, just tell me and I will try to solve them.
No, it’s not just REST binding. Even after I restarted openHAB, there are no new log entries 
Running openHAB on NAS (with a plenty of disk space), so the problem is something else than a failing SD.
Then I would suggest you open a new thread and see if someone can help you figure out what’s wrong with your installation, I have no experience with running OH on a NAS, so can’t help there I’m afraid…
…this (logging) problem is solved, as I noticed there were two (almost) identical events.log files, but in different folders 
Which were the folders?
/public/openHAB/tmpfs/userdata/logs
/public/openHAB/userdata/logs