Looks like it’s running a ramdisk of some sort to reduce writes to disk, the most recent is the one in the tmpfs-directory, correct? Anyway, do you still have issues with Items not being updated? Any hints in the logs (either events.log or openhab.log)?
Currently those files seem to have identical content, so not sure which one is the most recent.
But yes, the original problem persists, air velocity is still “NULL”. openhab.log does not give anything useful in this context, and events.log only has entries for reference air velocity
Are you certain that the item is linked correctly to the channel? What is the channel id of the channel? (In my system it’s defrosting#40050)
Fixed a bug where a bad json-string received from nibe would cause the request thread to crash, preventing further item updates. Fixed versions are available from the same links above.
Id is 41026. I unlinked it, but couldn’t link it back as there wasn’t suitable item. And that could be because this channel is created with string type, and not number as reference air velocity?
That explains the problem, but not sure how it happened. Nibe must have sent a strange value for it when the binding requested all available parameters to create the channels. Anyway, deleting the thing and rediscovering it should hopefully recreate it correctly.
Edit: it might actually be a bug in the binding, i had hardcoded the channel as a specific type, but since your parameter id is different from mine it didn’t catch that. It’s easy to fix though, will upload a new version shortly.
Updated, but the channel still has string as a type. Do I have delete the thing?
Yes, delete it and rediscover it, everything should come back the way it was before (except for the channel), including all connected items.
It’s still “string”, although I did deletion & rediscovery?
Hmm, perhaps the result gets cached, then you need to delete the thing, restart the bundle (or openhab) and then rediscover. In the meantime, since nibe had some downtime this weekend i got the opportunity to debug and solve some stability issues, should be much better now. OH2 version and OH3 version are available for download. If you delete your thing before placing the new jar in the addons folder the bundle gets restarted when it updates, and then it should hopefully be discovered correctly.
Now I deleted thing, stopped openHAB, replaced jar, started openHAB, rediscovered thing but string type is still there for the channel 
For what’s it worth, in the items air velocity has correct type:
That’s odd. If you connect a String item to the channel, does it get any updates? If that doesn’t work I would need to see some trace logging output for when the items are updated.
There’s no corresponding string item, only that item with number type, and that I cannot link to a channel that has string type…
But now I have bigger problems as with these newer builds, API does not update any values. Well, after openHAB restart, it updates once, but not after that 
Can’t you create a new string item and link it to the channel?
I would still need to see some log output to help you further.
Could you give some example commands for the logs that would provide useful info?
Some logs right after restart:
15:25:01.720 [TRACE] [ndler.NibeUplinkRestBaseSystemHandler] - Setting channel sam#40141 to 16.9 °C
15:25:01.729 [TRACE] [ndler.NibeUplinkRestBaseSystemHandler] - Setting channel status#40014 to 45.9 °C
15:25:01.746 [TRACE] [ndler.NibeUplinkRestBaseSystemHandler] - Setting channel sam#40142 to -5.0 °C
15:25:01.759 [TRACE] [ndler.NibeUplinkRestBaseSystemHandler] - Setting channel status#40079 to 4.2 A
15:25:01.770 [TRACE] [ndler.NibeUplinkRestBaseSystemHandler] - Setting channel status#40081 to 0.2 A
15:25:01.779 [TRACE] [ndler.NibeUplinkRestBaseSystemHandler] - Setting channel ventilation#10001 to 72.0 %
15:25:01.785 [TRACE] [ndler.NibeUplinkRestBaseSystemHandler] - Setting channel status#40083 to 9.4 A
15:25:06.790 [TRACE] [.internal.api.NibeUplinkRestConnector] - Executing request of type PARAMETER_GET for system XXX
15:25:06.796 [TRACE] [rnal.api.NibeUplinkRestRequestHandler] - Sending GET request to /api/v1/systems/XXX/parameters
15:25:07.108 [TRACE] [ndler.NibeUplinkRestBaseSystemHandler] - Updating 15 parameters for system XXX
15:25:07.110 [TRACE] [ndler.NibeUplinkRestBaseSystemHandler] - Setting channel system1#40033 to 23.0 °C
15:25:07.116 [TRACE] [ndler.NibeUplinkRestBaseSystemHandler] - Setting channel control#47398 to 20.0 °C
15:25:50.995 [TRACE] [.internal.api.NibeUplinkRestConnector] - Queueing system request for XXX
15:25:50.999 [TRACE] [.internal.api.NibeUplinkRestConnector] - Queueing parameter request for XXX with 15 parameters
15:25:51.003 [TRACE] [.internal.api.NibeUplinkRestConnector] - Queueing parameter request for XXX with 15 parameters
15:26:51.007 [TRACE] [.internal.api.NibeUplinkRestConnector] - Queueing system request for XXX
15:26:51.012 [TRACE] [.internal.api.NibeUplinkRestConnector] - Queueing parameter request for XXX with 15 parameters
15:26:51.015 [TRACE] [.internal.api.NibeUplinkRestConnector] - Queueing parameter request for XXX with 15 parameters
15:27:51.017 [TRACE] [.internal.api.NibeUplinkRestConnector] - Queueing system request for XXX
15:27:51.019 [TRACE] [.internal.api.NibeUplinkRestConnector] - Queueing parameter request for XXX with 15 parameters
15:27:51.022 [TRACE] [.internal.api.NibeUplinkRestConnector] - Queueing parameter request for XXX with 15 parameters
15:28:51.024 [TRACE] [.internal.api.NibeUplinkRestConnector] - Queueing system request for XXX
15:28:51.027 [TRACE] [.internal.api.NibeUplinkRestConnector] - Queueing parameter request for XXX with 15 parameters
15:28:51.029 [TRACE] [.internal.api.NibeUplinkRestConnector] - Queueing parameter request for XXX with 15 parameters
15:29:51.033 [TRACE] [.internal.api.NibeUplinkRestConnector] - Queueing system request for XXX
15:29:51.037 [TRACE] [.internal.api.NibeUplinkRestConnector] - Queueing parameter request for XXX with 15 parameters
15:29:51.042 [TRACE] [.internal.api.NibeUplinkRestConnector] - Queueing parameter request for XXX with 15 parameters
So basically gets values once after restart, and then nothing. Finally queue is full:
15:33:51.086 [WARN ] [.internal.api.NibeUplinkRestConnector] - Deque full
15:33:51.087 [TRACE] [.internal.api.NibeUplinkRestConnector] - Queueing parameter request for XXX with 15 parameters
15:33:51.089 [WARN ] [.internal.api.NibeUplinkRestConnector] - Deque fullIt looks like you’re not on the latest version of the binding, what’s the output of
bundle:list | grep -i nibe
In the karaf console?
255 │ Active │ 80 │ 2.5.13.202101281056 │ openHAB Add-ons :: Bundles :: NibeUplinkRest BindingThere should be a later build available from the link in this post with some improvements to the request handling and for the channel creation. Try updating to that one first and report back if your problems are still there.