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.
I’m sure I already got my build from that post… But let’s try again
If it’s still the same build number I can upload it again, perhaps something went wrong there.
Still the same:
255 │ Active │ 80 │ 2.5.13.202101281056 │ openHAB Add-ons :: Bundles :: NibeUplinkRest BindingI uploaded it again and used the link to download it to make sure it’s the correct version.
If it doesn’t work for you you might need to clear the cache in OH. Stop OH, then run openhab-cli clean-cache (if on linux), and start OH again. You might need a second restart after a few minutes (without clearing the cache!) because there are som bugs on the first startup.
Build number remains the same, so guess I’ll have clear cache, but there does not seem to be openhab-cli command (I’m on Synology NAS)
255 │ Active │ 80 │ 2.5.13.202101281056 │ openHAB Add-ons :: Bundles :: NibeUplinkRest Binding