Glad you got it working!
Personally, I only use the thermostat, and just change the setpoint, e.g. lower it by 2 degrees when on holiday, and lately even based on the electric price after I got an hourly spot price based subscription. (The heatpump has this functionality built-in, but apparently it doesn’t work together with a setpoint, and it’s also quite unintelligent)
Hi folks,
I just recognized that at least the heatmeter values are misaligned in my setup and I don’t think it is because of mis-configuration.
The heatmeter values are showing up as multiplied with a factor of 0.1:
And here what Nibe Uplink shows:
(I also confirmed this on the display of the heatpump as well as with my parallel path via NibeHeatPump-Binding)
I have nothing set in the state description metadata - this was the first place I was looking for the root cause. The item is configured as follows:
Is this known or is this also valid for anybody else using this binding?
Cheers
Jonathan
You can change this in the channel configuration. All values received from nibe are integers, and many need to be scaled down by a factor of 10 or 100. When creating a thing from the API the binding uses some heuristics to determine the factor, but this might fail some times and the wrong factor gets configured.
But if you go to the Thing and find the faulty channel, you can override the configuration manually.
Ah, right 
. This is one thing I read somewhere about but obviously forgot about it…
Thanks for the heads up @pacive.
Cheers Jonathan
Hello,
I am running into a similar question as frede above; I’d like to control control#47398 (the S1 heating setpoint) from openHAB.
The Smarthome toggle is active, and I do not have any thermostats configured. Room sensor is active.
If I try to set my item that is connected to the control I am seeing the following in the logs:
2023-03-10 09:18:59.376 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'HeatPump_RoomSensorSetpoint_Heating' received command 20.5
2023-03-10 09:18:59.382 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'HeatPump_RoomSensorSetpoint_Heating' predicted to become 20.5
2023-03-10 09:18:59.429 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'HeatPump_RoomSensorSetpoint_Heating' changed from 21 °C to 20.5 °C
2023-03-10 09:19:42.240 [TRACE] [internal.api.NibeUplinkRestConnector] - Queueing system and status request for XXXXX
2023-03-10 09:19:42.246 [TRACE] [internal.api.NibeUplinkRestConnector] - Executing request of type SYSTEM for system XXXXX
2023-03-10 09:19:42.249 [TRACE] [linkrest.internal.api.RequestWrapper] - Sending GET request to https://api.nibeuplink.com/api/v1/systems/XXXXX
2023-03-10 09:19:42.258 [TRACE] [internal.api.NibeUplinkRestConnector] - Queueing parameter request for XXXXX with 11 parameters
2023-03-10 09:19:42.528 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Updating system info for system XXXXX
2023-03-10 09:19:47.536 [TRACE] [internal.api.NibeUplinkRestConnector] - Executing request of type STATUS for system XXXXX
2023-03-10 09:19:47.542 [TRACE] [linkrest.internal.api.RequestWrapper] - Sending GET request to https://api.nibeuplink.com/api/v1/systems/XXXXX/status/system
2023-03-10 09:19:47.884 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Updating status channels for system XXXXX
2023-03-10 09:19:52.892 [TRACE] [internal.api.NibeUplinkRestConnector] - Executing request of type PARAMETER_GET for system XXXXX
2023-03-10 09:19:52.897 [TRACE] [linkrest.internal.api.RequestWrapper] - Sending GET request to https://api.nibeuplink.com/api/v1/systems/XXXXX/parameters
2023-03-10 09:19:53.039 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Updating 11 parameters for system XXXXX
2023-03-10 09:19:53.043 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Setting channel cprInfoEp14#40016 to 7.7 °C
2023-03-10 09:19:53.051 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Setting channel cprInfoEp14#40015 to 12.2 °C
2023-03-10 09:19:53.059 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Setting channel status#43005 to -74.1
2023-03-10 09:19:53.064 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Setting channel system1#40033 to 20.5 °C
2023-03-10 09:19:53.073 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Setting channel heatMeter#44300 to 3815.2 kWh
2023-03-10 09:19:53.080 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Setting channel heatMeter#44298 to 2001.7 kWh
2023-03-10 09:19:53.087 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Setting channel system1#40008 to 30.1 °C
2023-03-10 09:19:53.091 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Setting channel cprInfoEp14#43437 to 37 %
2023-03-10 09:19:53.098 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Setting channel control#47398 to 21 °C
2023-03-10 09:19:53.103 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Setting channel energyMeter#40995 to 1660.07 kWh
2023-03-10 09:19:53.107 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Setting channel system1#43009 to 30.2 °C
2023-03-10 09:19:53.124 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'HeatPump_RoomSensorSetpoint_Heating' changed from 20.5 °C to 21 °C
Interestingly I am not seeing any PUT/POST call to send my updated parameter to the NIBE Uplink.
I’ve verified with the holiday setting, which is working as expected.
2023-03-10 09:18:02.824 [TRACE] [internal.api.NibeUplinkRestConnector] - Executing request of type MODE_SET for system XXXXX
2023-03-10 09:18:02.829 [TRACE] [linkrest.internal.api.RequestWrapper] - Sending PUT request to https://api.nibeuplink.com/api/v1/systems/XXXXX/smarthome/mode with data {"mode":"DEFAULT_OPERATION"}
Any pointer what I might be doing wrong? 
There should definitely be a PUT request in the log when sending a command to that channel. I’m on vacation this week, but will investigate and see if I can reproduce it when I get home.
Thanks!
One more slight issue I found, is with parameter 40072, the flow. Which is reported as l/min but the channel is defined as number:area which does not make sens. openHAB does not seem to be able to convert it back to something readable.
2023-03-10 17:59:53.886 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Setting channel heatMeter#40072 to 7.8 l/m
I managed to identify the reason for the first of your problems. That is simply because I had missed the handling of QuanityType commands (don’t use that channel myself, so hadn’t noticed the problem). I had to change around some things in the code, but when testing everything seems to work ok.
The second problem is probably partly Nibe’s fault. Based on @elektrolubach’s picture above:
it seems as it presents the unit as l/m instead of l/min, which gets read as litres per meter (which consequently is a area unit). Since no heatpump is probably ever going to use that kind of unit it is probably safe to create a hardcoded exception for that unit. I have no channels like that on my system, so cannot verify it is working and need your help to test it. You will have to delete and recreate the Thing to get the correct dimension for the channel, and possibly recreate the Item as well to match.
And while we’re at it @elektrolubach, i tweaked the heuristics a bit so your kWh channels should hopefully not require any manual overrides.
Update: The new version is now published, to update, just uninstall and reinstall the binding, and then delete and rediscover the system Things. Let me know if you encounter any more problems!
Thanks! That works like a charm!
Flow is correctly recognized now. Updates to the temperature works (still have to test the curve offset). And the kWh of the heat meter and external counter are correct by default 
Looks like I managed to break it again 
2023-03-15 12:09:01.329 [TRACE] [internal.api.NibeUplinkRestConnector] - Executing request of type PARAMETER_GET for system XXXXXX
2023-03-15 12:09:01.331 [TRACE] [linkrest.internal.api.RequestWrapper] - Sending GET request to https://api.nibeuplink.com/api/v1/systems/XXXXXX/parameters
2023-03-15 12:09:01.558 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Updating 4 parameters for system XXXXXX
2023-03-15 12:09:01.561 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Setting channel status#43005 to 99.2
2023-03-15 12:09:01.573 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NumberFormatException: Character N is neither a decimal digit number, decimal point, nor "e" notation exponential mark.
at java.math.BigDecimal.<init>(BigDecimal.java:522) ~[?:?]
at java.math.BigDecimal.<init>(BigDecimal.java:405) ~[?:?]
at java.math.BigDecimal.<init>(BigDecimal.java:838) ~[?:?]
at org.openhab.core.library.types.QuantityType.<init>(QuantityType.java:166) ~[?:?]
at org.openhab.binding.nibeuplinkrest.internal.handler.NibeUplinkRestBaseSystemHandler.transformIncoming(NibeUplinkRestBaseSystemHandler.java:312) ~[?:?]
at org.openhab.binding.nibeuplinkrest.internal.handler.NibeUplinkRestBaseSystemHandler.lambda$3(NibeUplinkRestBaseSystemHandler.java:224) ~[?:?]
at java.util.ArrayList.forEach(ArrayList.java:1541) ~[?:?]
at org.openhab.binding.nibeuplinkrest.internal.handler.NibeUplinkRestBaseSystemHandler.parametersUpdated(NibeUplinkRestBaseSystemHandler.java:195) ~[?:?]
at java.util.Optional.ifPresent(Optional.java:183) ~[?:?]
at org.openhab.binding.nibeuplinkrest.internal.api.NibeUplinkRestConnector.processRequests(NibeUplinkRestConnector.java:575) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
Which seems to block the whole queue, as it now will try to add requests and end up with a full queue.
2023-03-15 12:13:34.860 [TRACE] [internal.api.NibeUplinkRestConnector] - Queueing system and status request for XXXXXX
2023-03-15 12:13:34.863 [TRACE] [internal.api.NibeUplinkRestConnector] - Queueing parameter request for XXXXXX with 15 parameters
2023-03-15 12:13:34.865 [TRACE] [internal.api.NibeUplinkRestConnector] - Queueing parameter request for XXXXXX with 4 parameters
2023-03-15 12:16:34.910 [TRACE] [internal.api.NibeUplinkRestConnector] - Queueing system and status request for XXXXXX
2023-03-15 12:16:34.917 [TRACE] [internal.api.NibeUplinkRestConnector] - Queueing parameter request for XXXXXX with 15 parameters
2023-03-15 12:16:34.923 [DEBUG] [internal.api.NibeUplinkRestConnector] - Queue full, request discarded
2023-03-15 12:16:34.930 [TRACE] [internal.api.NibeUplinkRestConnector] - Queueing parameter request for XXXXXX with 4 parameters
2023-03-15 12:16:34.935 [DEBUG] [internal.api.NibeUplinkRestConnector] - Queue full, request discarded
I’ve checked all channels that I have linked, and all of them have correct values, so I can’t really figure out on what channel it is exploding.
Hmm, I guess the value somehow ended up as NaN before being passed to the QuantityType. This caused the thread reading from the Queue to crash. A restart of the binding (bundle:restart org.openhab.binding.nibeuplinkrest in the karaf console) should make it work again. Have this problem happened more than once? I’ll add some checks and logging to perhaps get some more info on the cause.
I tried restarting the binding, but it does fail on the first update again.
A more complete TRACE log of a fresh restart. If you want I can also post the full initialization if needed.
2023-03-15 14:05:38.085 [DEBUG] [.handler.NibeUplinkRestBridgeHandler] - Initializing Rest Api Bridge
2023-03-15 14:05:38.087 [DEBUG] [.handler.NibeUplinkRestBridgeHandler] - Rebuilding thing-types
2023-03-15 14:05:38.562 [DEBUG] [internal.api.NibeUplinkRestConnector] - Checking connected systems...
2023-03-15 14:05:38.563 [TRACE] [linkrest.internal.api.RequestWrapper] - Sending GET request to https://api.nibeuplink.com/api/v1/systems
2023-03-15 14:05:38.617 [DEBUG] [dler.NibeUplinkRestBaseSystemHandler] - Initializing thing nibeuplinkrest:nibef1255:1a7d3e186b:XXXXXX
2023-03-15 14:05:38.621 [DEBUG] [internal.api.NibeUplinkRestConnector] - Adding callback listener for system XXXXXX
2023-03-15 14:05:38.622 [DEBUG] [internal.api.NibeUplinkRestConnector] - Start polling jobs
2023-03-15 14:05:38.623 [DEBUG] [internal.api.NibeUplinkRestConnector] - Standard request producer started with interval 60 seconds
2023-03-15 14:05:38.624 [DEBUG] [internal.api.NibeUplinkRestConnector] - Software request producer started with interval 7 days
2023-03-15 14:05:38.625 [DEBUG] [internal.api.NibeUplinkRestConnector] - Thermostat request producer started
2023-03-15 14:05:38.626 [DEBUG] [internal.api.NibeUplinkRestConnector] - Mode request producer started
2023-03-15 14:05:38.626 [DEBUG] [internal.api.NibeUplinkRestConnector] - Request processor started
2023-03-15 14:05:38.627 [TRACE] [internal.api.NibeUplinkRestConnector] - Queueing software update request for XXXXXX
2023-03-15 14:05:38.627 [TRACE] [internal.api.NibeUplinkRestConnector] - Queueing system and status request for XXXXXX
2023-03-15 14:05:38.630 [TRACE] [internal.api.NibeUplinkRestConnector] - Executing request of type SYSTEM for system XXXXXX
2023-03-15 14:05:38.634 [TRACE] [linkrest.internal.api.RequestWrapper] - Sending GET request to https://api.nibeuplink.com/api/v1/systems/XXXXXX
2023-03-15 14:05:38.641 [TRACE] [internal.api.NibeUplinkRestConnector] - System XXXXXX is now tracking parameter 40013
2023-03-15 14:05:38.643 [TRACE] [internal.api.NibeUplinkRestConnector] - System XXXXXX is now tracking parameter 40004
2023-03-15 14:05:38.653 [TRACE] [internal.api.NibeUplinkRestConnector] - System XXXXXX is now tracking parameter 43005
2023-03-15 14:05:38.659 [TRACE] [internal.api.NibeUplinkRestConnector] - System XXXXXX is now tracking parameter 43439
2023-03-15 14:05:38.664 [TRACE] [internal.api.NibeUplinkRestConnector] - System XXXXXX is now tracking parameter 43437
2023-03-15 14:05:38.676 [TRACE] [internal.api.NibeUplinkRestConnector] - System XXXXXX is now tracking parameter 40015
2023-03-15 14:05:38.678 [TRACE] [internal.api.NibeUplinkRestConnector] - System XXXXXX is now tracking parameter 40016
2023-03-15 14:05:38.681 [TRACE] [internal.api.NibeUplinkRestConnector] - System XXXXXX is now tracking parameter 40012
2023-03-15 14:05:38.685 [TRACE] [internal.api.NibeUplinkRestConnector] - System XXXXXX is now tracking parameter 43136
2023-03-15 14:05:38.693 [TRACE] [internal.api.NibeUplinkRestConnector] - System XXXXXX is now tracking parameter 43009
2023-03-15 14:05:38.694 [TRACE] [internal.api.NibeUplinkRestConnector] - System XXXXXX is now tracking parameter 40008
2023-03-15 14:05:38.696 [TRACE] [internal.api.NibeUplinkRestConnector] - System XXXXXX is now tracking parameter 40033
2023-03-15 14:05:38.699 [TRACE] [internal.api.NibeUplinkRestConnector] - System XXXXXX is now tracking parameter 43084
2023-03-15 14:05:38.701 [TRACE] [internal.api.NibeUplinkRestConnector] - System XXXXXX is now tracking parameter 44300
2023-03-15 14:05:38.704 [TRACE] [internal.api.NibeUplinkRestConnector] - System XXXXXX is now tracking parameter 44298
2023-03-15 14:05:38.706 [TRACE] [internal.api.NibeUplinkRestConnector] - System XXXXXX is now tracking parameter 40072
2023-03-15 14:05:38.708 [TRACE] [internal.api.NibeUplinkRestConnector] - System XXXXXX is now tracking parameter 40995
2023-03-15 14:05:38.710 [TRACE] [internal.api.NibeUplinkRestConnector] - System XXXXXX is now tracking parameter 47398
2023-03-15 14:05:39.154 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Updating system info for system XXXXXX
2023-03-15 14:05:39.185 [DEBUG] [internal.api.NibeUplinkRestConnector] - 1 systems found
2023-03-15 14:05:39.188 [TRACE] [linkrest.internal.api.RequestWrapper] - Sending GET request to https://api.nibeuplink.com/api/v1/systems/XXXXXX/config
2023-03-15 14:05:39.355 [TRACE] [linkrest.internal.api.RequestWrapper] - Sending GET request to https://api.nibeuplink.com/api/v1/systems/XXXXXX/serviceinfo/categories
2023-03-15 14:05:39.893 [DEBUG] [l.provider.NibeUplinkRestTypeFactory] - Creating thing type with id nibef1255
2023-03-15 14:05:44.159 [TRACE] [internal.api.NibeUplinkRestConnector] - Executing request of type SOFTWARE for system XXXXXX
2023-03-15 14:05:44.164 [TRACE] [linkrest.internal.api.RequestWrapper] - Sending GET request to https://api.nibeuplink.com/api/v1/systems/XXXXXX/software
2023-03-15 14:05:44.304 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Updating software channels for system XXXXXX
2023-03-15 14:05:49.308 [TRACE] [internal.api.NibeUplinkRestConnector] - Executing request of type SYSTEM for system XXXXXX
2023-03-15 14:05:49.313 [TRACE] [linkrest.internal.api.RequestWrapper] - Sending GET request to https://api.nibeuplink.com/api/v1/systems/XXXXXX
2023-03-15 14:05:49.507 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Updating system info for system XXXXXX
2023-03-15 14:05:54.511 [TRACE] [internal.api.NibeUplinkRestConnector] - Executing request of type STATUS for system XXXXXX
2023-03-15 14:05:54.515 [TRACE] [linkrest.internal.api.RequestWrapper] - Sending GET request to https://api.nibeuplink.com/api/v1/systems/XXXXXX/status/system
2023-03-15 14:05:54.838 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Updating status channels for system XXXXXX
2023-03-15 14:06:38.630 [TRACE] [internal.api.NibeUplinkRestConnector] - Queueing system and status request for XXXXXX
2023-03-15 14:06:38.635 [TRACE] [internal.api.NibeUplinkRestConnector] - Executing request of type SYSTEM for system XXXXXX
2023-03-15 14:06:38.640 [TRACE] [linkrest.internal.api.RequestWrapper] - Sending GET request to https://api.nibeuplink.com/api/v1/systems/XXXXXX
2023-03-15 14:06:38.642 [TRACE] [internal.api.NibeUplinkRestConnector] - Queueing parameter request for XXXXXX with 15 parameters
2023-03-15 14:06:38.653 [TRACE] [internal.api.NibeUplinkRestConnector] - Queueing parameter request for XXXXXX with 3 parameters
2023-03-15 14:06:38.817 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Updating system info for system XXXXXX
2023-03-15 14:06:43.822 [TRACE] [internal.api.NibeUplinkRestConnector] - Executing request of type STATUS for system XXXXXX
2023-03-15 14:06:43.827 [TRACE] [linkrest.internal.api.RequestWrapper] - Sending GET request to https://api.nibeuplink.com/api/v1/systems/XXXXXX/status/system
2023-03-15 14:06:44.025 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Updating status channels for system XXXXXX
2023-03-15 14:06:49.028 [TRACE] [internal.api.NibeUplinkRestConnector] - Executing request of type PARAMETER_GET for system XXXXXX
2023-03-15 14:06:49.035 [TRACE] [linkrest.internal.api.RequestWrapper] - Sending GET request to https://api.nibeuplink.com/api/v1/systems/XXXXXX/parameters
2023-03-15 14:06:49.272 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Updating 15 parameters for system XXXXXX
2023-03-15 14:06:49.286 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Setting channel system1#40012 to 22.9 °C
2023-03-15 14:06:49.296 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Setting channel status#40013 to 50.6 °C
2023-03-15 14:06:49.318 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Setting channel cprInfoEp14#43136 to 0 Hz
2023-03-15 14:06:49.334 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Setting channel cprInfoEp14#43437 to 15 %
2023-03-15 14:06:49.350 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Setting channel control#47398 to 21.5 °C
2023-03-15 14:06:49.368 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NumberFormatException: Character N is neither a decimal digit number, decimal point, nor "e" notation exponential mark.
» at java.math.BigDecimal.<init>(BigDecimal.java:522) ~[?:?]
» at java.math.BigDecimal.<init>(BigDecimal.java:405) ~[?:?]
» at java.math.BigDecimal.<init>(BigDecimal.java:838) ~[?:?]
» at org.openhab.core.library.types.QuantityType.<init>(QuantityType.java:166) ~[?:?]
» at org.openhab.binding.nibeuplinkrest.internal.handler.NibeUplinkRestBaseSystemHandler.transformIncoming(NibeUplinkRestBaseSystemHandler.java:312) ~[?:?]
» at org.openhab.binding.nibeuplinkrest.internal.handler.NibeUplinkRestBaseSystemHandler.lambda$3(NibeUplinkRestBaseSystemHandler.java:224) ~[?:?]
» at java.util.ArrayList.forEach(ArrayList.java:1541) ~[?:?]
» at org.openhab.binding.nibeuplinkrest.internal.handler.NibeUplinkRestBaseSystemHandler.parametersUpdated(NibeUplinkRestBaseSystemHandler.java:195) ~[?:?]
» at java.util.Optional.ifPresent(Optional.java:183) ~[?:?]
» at org.openhab.binding.nibeuplinkrest.internal.api.NibeUplinkRestConnector.processRequests(NibeUplinkRestConnector.java:575) ~[?:?]
» at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
» at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) ~[?:?]
» at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) ~[?:?]
» at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
» at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
» at java.lang.Thread.run(Thread.java:829) [?:?]
I had a theory I just confirmed, the scaling factor might under certain conditions be set to 0, which causes a calculation to fail, but should be an easy fix. In the meantime, if you can identify the problematic channel you can either unlink it or set the scaling manually, then restart the binding. I’m just surprised I’ve never encountered this issue before.
Uploaded new version now, you might need to delete and recreate the thing to get rid of the faulty configurations.
This version should also be cross-compatible between OH 3.4 and 4.0.
Nice, it’s working again! 
Had to remove and install the binding and remove/re-add the system thing.
(is there a better way to update marketplace bindings aside from re-installing them?)
I think that’s the only way unfortunately, the alternative is to delete the jar from the filesystem, but that would probably require a restart of OH to get it back.
I might have found one more discrepancy.
The status#cooling switch stays off, while the machine is cooling for the last couple of days.
Thing channels
NIBE Uplink
Thanks for reporting this, my system don’t support cooling, so I haven’t been able to test this channel myself. What is likely the cause is that the API is sending a different string than I thought. I’ll get back to you on how you can help me determine the correct value.
I’ve updated the binding to add logging of all the currently active components. If you enable TRACE logging level (log:set TRACE org.openhab.binding.nibeuplinkrest) You should be able to regurlarly see a line in the log like this:
12:49:25.982 [TRACE] [ndler.NibeUplinkRestBaseSystemHandler] - Updating status channels for system <SYSTEM ID>. Active components: priceOfElectricity, ventilation
If you can get back to me with that output when you have cooling active I should be able to correct the channel.
To update the binding, just uninstall it and reinstall from the marketplace. Things/Items will continue to work without change.
Hi @pacive thanks for the update!
My system dropped out of cooling mode on that same morning, but looking at the weather forecast, I expect to be cooling again this weekend.
I will report back!