Nibe uplink binding

[AzraelMasters (Tobias)]

It seems to work now Thanks for that.
My Items are now updating with the latest DEV Version of 2.4.

I can successfully change “Hot Water-Mode”, but the “Ventilation-Level” doesn’t seem to work.
I receive the correct Values of both Vents, but I can’t set it via Level.

Maybe this Errorlog has something to do with it:

2018-06-13 19:11:01.071 [ERROR] [ersey.server.ServerRuntime$Responder] - An I/O error has occurred while writing a response message entity to the container output stream.
org.glassfish.jersey.server.internal.process.MappableException: org.eclipse.jetty.io.EofException
	at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:92) [172:org.glassfish.jersey.core.jersey-server:2.22.2]
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162) [171:org.glassfish.jersey.core.jersey-common:2.22.2]
	at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:1130) [171:org.glassfish.jersey.core.jersey-common:2.22.2]
	at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:711) [172:org.glassfish.jersey.core.jersey-server:2.22.2]
	at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:444) [172:org.glassfish.jersey.core.jersey-server:2.22.2]
	at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:434) [172:org.glassfish.jersey.core.jersey-server:2.22.2]
	at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:329) [172:org.glassfish.jersey.core.jersey-server:2.22.2]
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) [171:org.glassfish.jersey.core.jersey-common:2.22.2]
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) [171:org.glassfish.jersey.core.jersey-common:2.22.2]
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315) [171:org.glassfish.jersey.core.jersey-common:2.22.2]
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297) [171:org.glassfish.jersey.core.jersey-common:2.22.2]
	at org.glassfish.jersey.internal.Errors.process(Errors.java:267) [171:org.glassfish.jersey.core.jersey-common:2.22.2]
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317) [171:org.glassfish.jersey.core.jersey-common:2.22.2]
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305) [172:org.glassfish.jersey.core.jersey-server:2.22.2]
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154) [172:org.glassfish.jersey.core.jersey-server:2.22.2]
	at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473) [169:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
	at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427) [169:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388) [169:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341) [169:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228) [169:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
	at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.service(ServletContainerBridge.java:76) [15:com.eclipsesource.jaxrs.publisher:5.3.1.201602281253]
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:848) [87:org.eclipse.jetty.servlet:9.3.21.v20170918]
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:584) [87:org.eclipse.jetty.servlet:9.3.21.v20170918]
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) [185:org.ops4j.pax.web.pax-web-jetty:6.0.9]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) [86:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) [84:org.eclipse.jetty.security:9.3.21.v20170918]
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226) [86:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180) [86:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:284) [185:org.ops4j.pax.web.pax-web-jetty:6.0.9]
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512) [87:org.eclipse.jetty.servlet:9.3.21.v20170918]
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) [86:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112) [86:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) [86:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) [185:org.ops4j.pax.web.pax-web-jetty:6.0.9]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) [86:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.server.Server.handle(Server.java:534) [86:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:333) [86:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251) [86:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283) [78:org.eclipse.jetty.io:9.3.21.v20170918]
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108) [78:org.eclipse.jetty.io:9.3.21.v20170918]
	at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) [78:org.eclipse.jetty.io:9.3.21.v20170918]
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303) [89:org.eclipse.jetty.util:9.3.21.v20170918]
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148) [89:org.eclipse.jetty.util:9.3.21.v20170918]
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136) [89:org.eclipse.jetty.util:9.3.21.v20170918]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671) [89:org.eclipse.jetty.util:9.3.21.v20170918]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) [89:org.eclipse.jetty.util:9.3.21.v20170918]
	at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: org.eclipse.jetty.io.EofException
	at org.eclipse.jetty.io.ChannelEndPoint.flush(ChannelEndPoint.java:199) ~[78:org.eclipse.jetty.io:9.3.21.v20170918]
	at org.eclipse.jetty.io.WriteFlusher.flush(WriteFlusher.java:420) ~[78:org.eclipse.jetty.io:9.3.21.v20170918]
	at org.eclipse.jetty.io.WriteFlusher.write(WriteFlusher.java:313) ~[78:org.eclipse.jetty.io:9.3.21.v20170918]
	at org.eclipse.jetty.io.AbstractEndPoint.write(AbstractEndPoint.java:147) ~[78:org.eclipse.jetty.io:9.3.21.v20170918]
	at org.eclipse.jetty.server.HttpConnection$SendCallback.process(HttpConnection.java:731) ~[86:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:241) ~[89:org.eclipse.jetty.util:9.3.21.v20170918]
	at org.eclipse.jetty.util.IteratingCallback.iterate(IteratingCallback.java:224) ~[89:org.eclipse.jetty.util:9.3.21.v20170918]
	at org.eclipse.jetty.server.HttpConnection.send(HttpConnection.java:519) ~[86:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.server.HttpChannel.sendResponse(HttpChannel.java:745) ~[86:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.server.HttpChannel.write(HttpChannel.java:801) ~[86:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:235) ~[86:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:219) ~[86:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:496) ~[86:org.eclipse.jetty.server:9.3.21.v20170918]
	at java.io.OutputStream.write(OutputStream.java:75) ~[?:?]
	at org.glassfish.jersey.servlet.internal.ResponseWriter$NonCloseableOutputStreamWrapper.write(ResponseWriter.java:320) ~[?:?]
	at org.glassfish.jersey.message.internal.CommittingOutputStream.write(CommittingOutputStream.java:218) ~[?:?]
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$UnCloseableOutputStream.write(WriterInterceptorExecutor.java:294) ~[?:?]
	at org.eclipse.smarthome.io.rest.core.internal.GsonProvider.writeTo(GsonProvider.java:71) ~[?:?]
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.invokeWriteTo(WriterInterceptorExecutor.java:265) ~[?:?]
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo(WriterInterceptorExecutor.java:250) ~[?:?]
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162) ~[?:?]
	at org.glassfish.jersey.server.internal.JsonWithPaddingInterceptor.aroundWriteTo(JsonWithPaddingInterceptor.java:106) ~[?:?]
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162) ~[?:?]
	at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:86) ~[?:?]
	... 46 more
Caused by: java.io.IOException: Die Verbindung wurde vom Kommunikationspartner zurückgesetzt
	at sun.nio.ch.FileDispatcherImpl.writev0(Native Method) ~[?:?]
	at sun.nio.ch.SocketDispatcher.writev(SocketDispatcher.java:51) ~[?:?]
	at sun.nio.ch.IOUtil.write(IOUtil.java:148) ~[?:?]
	at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:504) ~[?:?]
	at org.eclipse.jetty.io.ChannelEndPoint.flush(ChannelEndPoint.java:179) ~[78:org.eclipse.jetty.io:9.3.21.v20170918]
	at org.eclipse.jetty.io.WriteFlusher.flush(WriteFlusher.java:420) ~[78:org.eclipse.jetty.io:9.3.21.v20170918]
	at org.eclipse.jetty.io.WriteFlusher.write(WriteFlusher.java:313) ~[78:org.eclipse.jetty.io:9.3.21.v20170918]
	at org.eclipse.jetty.io.AbstractEndPoint.write(AbstractEndPoint.java:147) ~[78:org.eclipse.jetty.io:9.3.21.v20170918]
	at org.eclipse.jetty.server.HttpConnection$SendCallback.process(HttpConnection.java:731) ~[86:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:241) ~[89:org.eclipse.jetty.util:9.3.21.v20170918]
	at org.eclipse.jetty.util.IteratingCallback.iterate(IteratingCallback.java:224) ~[89:org.eclipse.jetty.util:9.3.21.v20170918]
	at org.eclipse.jetty.server.HttpConnection.send(HttpConnection.java:519) ~[86:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.server.HttpChannel.sendResponse(HttpChannel.java:745) ~[86:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.server.HttpChannel.write(HttpChannel.java:801) ~[86:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:235) ~[86:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:219) ~[86:org.eclipse.jetty.server:9.3.21.v20170918]
	at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:496) ~[86:org.eclipse.jetty.server:9.3.21.v20170918]
	at java.io.OutputStream.write(OutputStream.java:75) ~[?:?]
	at org.glassfish.jersey.servlet.internal.ResponseWriter$NonCloseableOutputStreamWrapper.write(ResponseWriter.java:320) ~[?:?]
	at org.glassfish.jersey.message.internal.CommittingOutputStream.write(CommittingOutputStream.java:218) ~[?:?]
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$UnCloseableOutputStream.write(WriterInterceptorExecutor.java:294) ~[?:?]
	at org.eclipse.smarthome.io.rest.core.internal.GsonProvider.writeTo(GsonProvider.java:71) ~[?:?]
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.invokeWriteTo(WriterInterceptorExecutor.java:265) ~[?:?]
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo(WriterInterceptorExecutor.java:250) ~[?:?]
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162) ~[?:?]
	at org.glassfish.jersey.server.internal.JsonWithPaddingInterceptor.aroundWriteTo(JsonWithPaddingInterceptor.java:106) ~[?:?]
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162) ~[?:?]
	at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:86) ~[?:?]
	... 46 more

My Sitemap Looks like:

Selection item=nibeUplink_47260_AirFanSpeed label="Ventilation" mappings=[0="60% (Normal)", 1="0% (Aus)", 2="20%", 3="40%", 4="80% (Maximal)" ]

My Item Looks like:

Number Nibe_47260_AirFanSpeed               "NIBE - Lüftungsstufe [MAP(nibeuplink_47260.map):%s]" <status>(g_NibeUplink_ChartFan, g_NibeUplink_ChartFanSpeed){channel="nibeuplink:vvm320:NibeF2040-8:airsupply#47260"}

My Map Looks like:

0=60% (Normal) 
1=0%  (Aus)
2=20% 
3=40% 
4=80% (Maximal)

[AzraelMasters (Tobias)]

Sorry I found it by myself….
Looking at the newest Definition, it is a String, not a Number

[AzraelMasters (Tobias)]

Hm just an idea, but is there any Timestamp which I can Show in the Sitemap, when Data is received/changed and published the last time?
So that I can see, that the Plugin, Inetconnection, Uplink or Solaredge-Interface is working and up2date?

[AlexF (Alexander F)]

No there is currently no such date available. Especially Solaredge is often “stuck” which means it is online and returning data but it is totally outdated. If you want to discuss this issue further we should switch to the corresponding topic.

[htpzc (Bauer August)]

Hi Alex,

i just reinstalled my openhab again because of a zwave problem. But when i looked into the logs i got before and after reinstall the following message:
2018-06-18 20:46:21.078 [DEBUG] [ing.nibeuplink.handler.UplinkPolling] - polling NibeUplink org.openhab.binding.nibeuplink.config.NibeUplinkConfiguration@1560eb9[user=…,password=…,nibeId=43770,pollingInterval=300,houseKeepingInterval=3600,asyncTimeout=120,syncTimeout=120]

2018-06-18 20:46:21.788 [DEBUG] [internal.command.GenericStatusUpdate] - received content, length: 144

2018-06-18 20:46:21.795 [DEBUG] [internal.command.GenericStatusUpdate] - HTTP response 302

2018-06-18 20:46:21.800 [DEBUG] [internal.command.GenericStatusUpdate] - onComplete()

==> /var/log/openhab2/events.log <==

2018-06-18 20:46:21.819 [hingStatusInfoChangedEvent] - ‘nibeuplink:f1155:nibe’ changed from ONLINE: logged in to OFFLINE (COMMUNICATION_ERROR): Found

==> /var/log/openhab2/openhab.log <==

2018-06-18 20:46:22.839 [DEBUG] [ng.nibeuplink.internal.command.Login] - received content, length: 130

2018-06-18 20:46:22.844 [DEBUG] [ng.nibeuplink.internal.command.Login] - HTTP response 302

==> /var/log/openhab2/events.log <==

2018-06-18 20:46:22.857 [hingStatusInfoChangedEvent] - ‘nibeuplink:f1155:nibe’ changed from OFFLINE (COMMUNICATION_ERROR): Found to ONLINE: logged in

---

So i decided to look for a new version. First i was not able to find nibeuplink in the paperui bindings section (is this normal?)

Next i took the 2.4.0 snapshot and put it in the addons folder, but then the next problem:
2018-06-18 20:43:44.081 [DEBUG] [org.openhab.binding.nibeuplink ] - BundleEvent UNINSTALLED - org.openhab.binding.nibeuplink

2018-06-18 20:43:54.339 [DEBUG] [org.openhab.binding.nibeuplink ] - BundleEvent INSTALLED - org.openhab.binding.nibeuplink

2018-06-18 20:43:54.482 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.nibeuplink-2.4.0-SNAPSHOT%20(1).jar

org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.nibeuplink [220]

Another singleton bundle selected: osgi.identity; type=“osgi.bundle”; version:Version=“2.3.0.201803121609”; osgi.identity=“org.openhab.binding.nibeuplink”; singleton:=“true”

at org.eclipse.osgi.container.Module.start(Module.java:444) [?:?]

at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) [?:?]

at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [9:org.apache.felix.fileinstall:3.6.4]

at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [9:org.apache.felix.fileinstall:3.6.4]

at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [9:org.apache.felix.fileinstall:3.6.4]

at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [9:org.apache.felix.fileinstall:3.6.4]

at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [9:org.apache.felix.fileinstall:3.6.4]

at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [9:org.apache.felix.fileinstall:3.6.4]

2018-06-18 20:43:54.496 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.nibeuplink-2.4.0-SNAPSHOT%20(1).jar

org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.nibeuplink [220]

Another singleton bundle selected: osgi.identity; type=“osgi.bundle”; version:Version=“2.3.0.201803121609”; osgi.identity=“org.openhab.binding.nibeuplink”; singleton:=“true”

at org.eclipse.osgi.container.Module.start(Module.java:444) [?:?]

at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) [?:?]

at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [9:org.apache.felix.fileinstall:3.6.4]

at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [9:org.apache.felix.fileinstall:3.6.4]

at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [9:org.apache.felix.fileinstall:3.6.4]

at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [9:org.apache.felix.fileinstall:3.6.4]

at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [9:org.apache.felix.fileinstall:3.6.4]

---

Any idea what the problem could be?

Thanks in advance

[AlexF (Alexander F)]

Hi @htpzc

in the last weeks the data privacy terms had been updated (due to General Data Protection Regulation) and therefore just after login there was a new page where you just need to accept once. If you did not yet do this, please login via browser and accept. This could be the reason for the first failure.

The second failure is because you now have two versions of the binding running at the same time.
See here for a detailed description how to manage bindings via karaf console. This is the easiest way to clean up your setup.

Nibe uplink binding

@Mikko_Jokinen and @AlexF: i think i found an easy way to update the bundle version without having to stop openhab but using the karaf console (that you start with the command: ssh openhab@localhost -p 8101). here is what i did: first you look for the ID of the current NibeUplink bundle: openhab> bundle:list | grep NibeUplink 10 | Active | 80 | 2.3.0.201805221510 | NibeUplink Binding in my case i have ID=10. Then you stop it, upgrade it using Alex’s url pointing to the 2.4.0, and fin…

BR
Alex

[htpzc (Bauer August)]

Sorry for that bad mistake from my side. Just had so much to work and didnt see the problem in the new AGB.

The Karaf resolution is great. Got that in my documentation for now.

Thank you so much!

[Mikko_Jokinen]

i can confirm that data is updated to item with 0.2.4 and Nibe F750 il try the added channels later.
Thank you AlexF

[Mikko_Jokinen]

AlexF i gave you wrong id for setting fanspeed for f750 it is the same #47260 as some other devices not the #43108 wich is the current fan speed value that is not settable.

Thanks for the binding now i can increase water temperature automaticaly when more people are visiting and when you fix my wrong id for ventilation i can increase ventilation speed when our sauna is ready to go.

[AlexF (Alexander F)]

@Mikko_Jokinen: fixed

new binding version is now available. All String Type channels have been converted to number type. This means when updating you will have to update your configuration.

A mapping of those numbers to textual represenataions is described in this posting:

Nibe uplink binding

@AlexF concerning the datatype for status channels: i understand your point however i believe you have somehow a better way in openhab to do what you want using the MAP transforms. Let’s suppose from your example that the temporary lux mode channel would return a number (not a string type as it is at present) Number TemporaryLuxMode "Temporary Lux Mode" {channel="nibeuplink:f1145:nibe:hotwater#48132"} then to map the corresponding labels you can define a transformation map (a .map file) that…

BR
Alex

[elektrolubach (Jonathan Lubach)]

Hej,

I am using the latest snapshot build of OH2.4 as well as the latest build of the nibeuplink binding from @AlexF on an openhabian machine.

I have a NIBE F730 heat pump.

During initialisation of the binding after reading the *.things file, the binding returns to state “UNINITIALIZED (HANDLER_INITIALIZING_ERROR)” with the following log entries:

2018-08-01 22:47:17.497 [hingStatusInfoChangedEvent] - 'nibeuplink:f730:mynibe' changed from UNINITIALIZED to INITIALIZING

2018-08-01 22:47:17.502 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.nibeuplink.handler.GenericHandler@1c45aeb': null

java.lang.NullPointerException: null

	at org.openhab.binding.nibeuplink.internal.model.CustomChannel.setCode(CustomChannel.java:30) [90:org.openhab.binding.nibeuplink:2.4.0.201807250812]

	at org.openhab.binding.nibeuplink.handler.UplinkBaseHandler.setupCustomChannels(UplinkBaseHandler.java:115) [90:org.openhab.binding.nibeuplink:2.4.0.201807250812]

	at org.openhab.binding.nibeuplink.handler.UplinkBaseHandler.initialize(UplinkBaseHandler.java:100) [90:org.openhab.binding.nibeuplink:2.4.0.201807250812]

	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]

	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]

	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]

	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]

	at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [96:org.eclipse.smarthome.core:0.10.0.201808011124]

	at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [96:org.eclipse.smarthome.core:0.10.0.201808011124]

	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]

	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]

	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]

	at java.lang.Thread.run(Thread.java:748) [?:?]

2018-08-01 22:47:17.536 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occurred while initializing handler of thing 'nibeuplink:f730:mynibe': null

java.lang.NullPointerException: null

	at org.openhab.binding.nibeuplink.internal.model.CustomChannel.setCode(CustomChannel.java:30) [90:org.openhab.binding.nibeuplink:2.4.0.201807250812]

	at org.openhab.binding.nibeuplink.handler.UplinkBaseHandler.setupCustomChannels(UplinkBaseHandler.java:115) [90:org.openhab.binding.nibeuplink:2.4.0.201807250812]

	at org.openhab.binding.nibeuplink.handler.UplinkBaseHandler.initialize(UplinkBaseHandler.java:100) [90:org.openhab.binding.nibeuplink:2.4.0.201807250812]

	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]

	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]

	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]

	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]

	at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [96:org.eclipse.smarthome.core:0.10.0.201808011124]

	at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [96:org.eclipse.smarthome.core:0.10.0.201808011124]

	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]

	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]

	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]

	at java.lang.Thread.run(Thread.java:748) [?:?]

2018-08-01 22:47:17.545 [hingStatusInfoChangedEvent] - 'nibeuplink:f730:mynibe' changed from INITIALIZING to UNINITIALIZED (HANDLER_INITIALIZING_ERROR)

Do you folks have any idea, what is causing the binding to not initialise?
Thanks!

Jonathan

[oliviercommelarbre]

Hi Alex, the last 2.4 snapshot seems to work great, thanks again for that
i have to add though that the switch to using UoM creates a big mess… i’ll revert for the moment.
any chance you would support in the future a handling of the binding that allows to not use UoM by config and still return properly dimensioned values (like temperatures in degree Celsius)? the thing is that the openhab persistence services are not all adapted to it, and the values get stored in a funny way while loosing track to the initial quantity (for instance influxdb binding does not seem to record the value as a quantity but just stores the value that openhab gives it, so basically you have lost the way to get back to the quantity. Since i use then the database outside of openhab i would need to reconvert everything back to the usable quantity. UoM is may be smart as an approach but in my view openhab is not yet ready for it.
Reversely if i don’t use the UoM quantity attached to the Number item definition, i get the raw value and i’m back to square one having to dimension myself the values via rules which is again really not ideal.
please let me know your plans, thanks again.

[AlexF (Alexander F)]

Hi @oliviercommelarbre,

you are right, persistence is not aware of the UoM. But if you define an explicit unit in the item definition the values are converted to that unit before being passed to the item and therefore before getting passed to the persistence service.
I also use persistence (influxdb + grafana) and it works great. So I think it is just a matter of configuration.

My plan is to keep UoM because the openhab team wants developers to use UoM. Otherwise the binding will not become officially integrated into the openhab distribution.

BR
Alex

[AlexF (Alexander F)]

Hi Jonathan,

this is a bug which I had already fixed in the past but however the change got lost when I refactored the code.
It is because you do not have set up custom channels. It should be fixed in the latest version.

BR
Alex

[oliviercommelarbre]

Hi @AlexF and thanks for your quick feedback

what you describe is actually what i would like but it is not what i observe. Maybe you can help me find out what i do wrong. Now i’ve reverted so i do not have it live but this is out of memory what i have done yesterday and observed, with example on param #40071 (supply temp)

Number:Temperature NibeClimaExternalFlowTemperature "Nibe Clima External Flow Temperature  [%.2f °C]" {channel="nibeuplink:f1145:nibe:base#40071"}

i would need to recheck to be sure but this is most likely what was my config was (just added the :Temperature suffix to the item type definition, and changed general#40071 for base#40071)

and this is what i got in influxdb, i.e. the raw unscaled value:

influx -username openhab -password openhab -database openhab -precision rfc3339 
> select * from NibeClimaExternalFlowTemperature where time > '2018-08-01T22:00:00.000Z'
name: NibeClimaExternalFlowTemperature
time                     value
----                     -----
2018-08-01T22:22:08.168Z 112
2018-08-01T22:23:08.218Z 122
2018-08-01T22:24:08.389Z 127
2018-08-01T22:25:08.555Z 137
2018-08-01T22:26:08.335Z 142
2018-08-01T22:27:08.377Z 147
2018-08-01T22:28:08.446Z 152
>

with the former 2.4 bundle (without UoM, hence using directly the Number type as opposed to Number:Temperature) i would get scaled value directly in influxdb as you would expect, for instance:

> select * from NibeClimaExternalFlowTemperature where time > '2018-07-31T00:00:00.000Z'
name: NibeClimaExternalFlowTemperature
time                     value
----                     -----
2018-07-31T00:08:07.869Z 10.3
2018-07-31T00:09:07.675Z 10.3
2018-07-31T00:09:20.452Z 10.3
2018-07-31T00:10:20.413Z 10.3
2018-07-31T00:11:20.4Z   10.3
2018-07-31T00:12:20.336Z 10.3
2018-07-31T00:13:20.452Z 10.3

could you help me spot my mistake in the config?

[AlexF (Alexander F)]

Your configuration looks good so far. So this is my working sample:

Number:Temperature      NIBE_ROOM_TEMP         "Raumtemperatur"                         <temperature>         (Persist6Hourly)                { channel="nibeuplink:vvm320:home:base#40033" }
Number:Temperature      NIBE_OUT_TEMP          "Aussentemperatur [%.2f °C]"             <temperature>         (PersistHourly)                 { channel="nibeuplink:vvm320:home:base#40004" }

It even works without an explicit unit because I defined default units in the binding itself.

I remember that I also had the issue that raw values got written to the persistence. But this occoured only for the short period during the binding/configuration upgrade. After a restart everything was fine.

BR
Alex

[oliviercommelarbre]

Thanks Alex, in fact after some time of debugging i realise that exactly the same has happened to me and i got confused… After some tests, and various restarts with a clean config i fot it 100% working, hurray!

What has created the confusion on my side in the first place comes from the degree minutes parameter (base#43005) that i also have in my config. I had defined it with Dimensionless quantity as advertised but with the custom appelation ‘DM’ used by Nibe and this created an exception.
my former config for this parameter:

Number:Dimensionless NibeCompressorDegreeMinutes "Compressor Degree Minutes [%.2f DM]" {channel="nibeuplink:f1145:nibe:base#43005"}

which made the whole thing block with the exception:

16:17:51.769 [ERROR] [ome.core.internal.events.EventHandler] - Creation of ESH-Event failed, because one of the registered event factories has thrown an exception: Error invoking #valueOf(String) on class 'org.eclipse.smarthome.core.library.types.QuantityType' with value '1858.0 d(°·min)'.
java.lang.IllegalStateException: Error invoking #valueOf(String) on class 'org.eclipse.smarthome.core.library.types.QuantityType' with value '1858.0 d(°·min)'.
	at org.eclipse.smarthome.core.items.events.ItemEventFactory.parseSimpleClassName(ItemEventFactory.java:178) ~[?:?]
	at org.eclipse.smarthome.core.items.events.ItemEventFactory.parseType(ItemEventFactory.java:146) ~[?:?]
	at org.eclipse.smarthome.core.items.events.ItemEventFactory.getState(ItemEventFactory.java:124) ~[?:?]
...
...

and nothing was put in persistence, not even the other parameters, so in fact the raw values i was reading back from DB queries where the ones that had been input before while i was updating the config (i.e. before changing the Number types with the quantity notation Number:Temperature…) similarly to what you reported. So this explains what, sorry for forwarding the confusion to you.

To avoid the exception i found two ways. 1/ is to type the item simply with ‘Number’ but then you will get the raw unsigned value which you don’t want, 2/ is to type it ‘Number:Dimensionless’ as per what is advertised and to give it a unit compatible with degrees * minutes such as ‘°·min’ or even ‘°·h’, ‘°·d’ etc. Concerning this last point, all compatible combinations do work and will not trigger the exception and lead to a persisted number. However this persisted number will vary accordingly to the relationships of the time unit with the minute (e.g. the number will be divided by 60 when using ‘°·h’). In my opinion, this is not really wanted as it makes little sense for this very custom unit ‘DM’ legacy of Nibe heat pumps.

This would hence be my only remaining suggestion, that is to let this particular parameter without a relation to units, i.e. really dimensionless with no relation to UoM degrees or minutes, but still to provide a value that is /10 from that read from NibeUplink. This will have the advantage of avoiding confusion on this particular parameter and let people use the notation DM or whichever other one they would wish. I guess for that the item definition could be left simply as:

Number NibeCompressorDegreeMinutes "Compressor Degree Minutes [%.1f DM or whatever else]" {channel="nibeuplink:f1145:nibe:base#43005"}

The problem of this today (which is solution 1/ above) is that it does not return the scaled value, and this would be the only thing to correct.

Obviously my suggestion is debatable since the DM number of Nibe probably relates somehow to ‘degree times minutes’ as a dimension but i’ve read a bit about it and it is really a Nibe thing used in Nibe systems. that’s why i think it is better to leave it ‘as is’ without any relation to UoM concepts that are there to ease unit translations but which is here rather irrelevant in this case.

what do you think?

[elektrolubach (Jonathan Lubach)]

Hey there,

today I added all relevant items using Paper UI and afterwards I came to the logging view showing me this:

2018-08-04 23:19:36.020 [ERROR] [me.core.internal.events.EventHandler] - Creation of ESH-Event failed, because one of the registered event factories has thrown an exception: Error invoking #valueOf(String) on class 'org.eclipse.smarthome.core.library.types.QuantityType' with value '-32768.0 done'.

java.lang.IllegalStateException: Error invoking #valueOf(String) on class 'org.eclipse.smarthome.core.library.types.QuantityType' with value '-32768.0 done'.

	at org.eclipse.smarthome.core.items.events.ItemEventFactory.parseSimpleClassName(ItemEventFactory.java:178) ~[?:?]

	at org.eclipse.smarthome.core.items.events.ItemEventFactory.parseType(ItemEventFactory.java:146) ~[?:?]

	at org.eclipse.smarthome.core.items.events.ItemEventFactory.getState(ItemEventFactory.java:124) ~[?:?]

	at org.eclipse.smarthome.core.items.events.ItemEventFactory.createStateEvent(ItemEventFactory.java:111) ~[?:?]

	at org.eclipse.smarthome.core.items.events.ItemEventFactory.createEventByType(ItemEventFactory.java:77) ~[?:?]

	at org.eclipse.smarthome.core.events.AbstractEventFactory.createEvent(AbstractEventFactory.java:50) ~[?:?]

	at org.eclipse.smarthome.core.internal.events.EventHandler.createESHEvent(EventHandler.java:121) ~[?:?]

	at org.eclipse.smarthome.core.internal.events.EventHandler.handleEvent(EventHandler.java:95) ~[?:?]

	at org.eclipse.smarthome.core.internal.events.EventHandler.handleEvent(EventHandler.java:72) ~[?:?]

	at org.eclipse.smarthome.core.internal.events.ThreadedEventHandler.lambda$0(ThreadedEventHandler.java:67) ~[?:?]

	at java.lang.Thread.run(Thread.java:748) [?:?]

Caused by: java.lang.reflect.InvocationTargetException

	at sun.reflect.GeneratedMethodAccessor138.invoke(Unknown Source) ~[?:?]

	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]

	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]

	at org.eclipse.smarthome.core.items.events.ItemEventFactory.parseSimpleClassName(ItemEventFactory.java:169) ~[?:?]

	... 10 more

Caused by: java.lang.IllegalArgumentException: done not recognized (in -32768.0 done at index 9)

	at tec.uom.se.quantity.Quantities.getQuantity(Quantities.java:80) ~[?:?]

	at org.eclipse.smarthome.core.library.types.QuantityType.<init>(QuantityType.java:89) ~[?:?]

	at org.eclipse.smarthome.core.library.types.QuantityType.valueOf(QuantityType.java:132) ~[?:?]

	at sun.reflect.GeneratedMethodAccessor138.invoke(Unknown Source) ~[?:?]

	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]

	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]

	at org.eclipse.smarthome.core.items.events.ItemEventFactory.parseSimpleClassName(ItemEventFactory.java:169) ~[?:?]

	... 10 more

Can you tell me how I can figure out, which item is causing this?
BTW: this looks like a similar error message as @oliviercommelarbre got in his post click

Edit 1: Just found out, that the thing isn’t showing up in the “Control” section of the Paper UI any more.

Thanks!
Jonathan

[AlexF (Alexander F)]

Hi @elektrolubach,

this is related to bug https://github.com/eclipse/smarthome/issues/5930.
In the first place you could stop using those channels of type Number:Dimensionless which do not have a unit. There should only be a few channels of this type.
I am not sure if the bug will ever be fixed so maybe I will be forced to implement a workaround. Otherwise those channels cannot be used.

BR
Alex

[elektrolubach (Jonathan Lubach)]

Hi @AlexF,

here some more experience information regarding the last post by me:
I found out that the following channels have been added as items of type “Number:Dimensionless” but are of type “Number”. I don’t know why this happened - maybe it was a wrong setting by me after midnight
nibeuplink:f730:mynibe:airsupply#43125 - Airflow reduction
nibeuplink:f730:mynibe:airsupply#43124 - Airflow ref.
nibeuplink:f730:mynibe:airsupply#41026 - EB100-Adjusted BS1 Air flow
nibeuplink:f730:mynibe:compressor#43416 - Compressor starts EB100-EP14

After having unlinked all items of type Number:Dimensionless and step by step re-adding the links and setting these items correctly to type “Number” everything works fine!

All settings have been done via PaperUI.

Regards
Jonathan