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.
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
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
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?
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
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?
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
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
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
Hi,
I see that the F2120 is not supported currently, but what would be the steps to support it? Or could I just try with some other configuration and hope they are similar?
Cheers,
Andres
Hi you could try another model which is similar to yours.
Hey Alex,
I find a error (Version: org.openhab.binding.nibeuplink-2.4.0-SNAPSHOT):
The response of nibeuplink:f750:id123:compressor#43123 is 12 Hz.
The real value is 120 Hz.
Hi,
channel 43122:
The Openhab value 2 Hz.
I think the original nibe value must be 20 Hz.
Yes, the scaling is wrong.
I have fixed this, could you try the latest version?
Hi Alex,
yes, you fixed it! The new version works great.
Thank you
Hi there Alex,
I’ve noticed that the channel base#10012 does not work. I’m using it on a F1145 but i think it does not matter since it is defined in a common group of channels for all models.
I’ve put the log in DEBUG on and i think i found a possible culprit: Although the channel is defined as “base#10012”, the channel that gets updated is like it used to be in a former version “compressor#10012”.
Here the log i get:
2018-11-19 15:35:35.960 [DEBUG] [k.internal.model.GenericDataResponse] - Channel 10012 updated to: 0 (no)
...
...
2018-11-19 15:35:36.036 [DEBUG] [ternal.model.DataResponseTransformer] - Channel compressor#10012 transformed to OnOffType (0)
...
...
2018-11-19 15:35:36.683 [DEBUG] [nibeuplink.handler.UplinkBaseHandler] - Channel is to be updated: compressor#10012: OFF
It would be great if you could check
thanks!
PS: i forgot to say that i’m using the last version i found on the server, i.e. 2.4.0.201811031309
openhab> bundle:list | grep NibeUplink
119 │ Active │ 80 │ 2.4.0.201811031309 │ NibeUplink Binding
fixed it.
–> https://github.com/openhab/openhab2-addons/pull/4252
As soon as this is merged it will be part of the official 2.4.0-SNAPSHOT build.
thank you Alex
i take the opportunity before this next build is generated, could you please add these channels in the F1145 config that are still missing. i really think they are very very relevant to an F1145:
i repeat them again here:
40015 Number °C /10 EB100-EP14-BT10 Brine In Temperature
40016 Number °C /10 EB100-EP14-BT11 Brine Out Temperature
43439 Number % EP14-GP2 Brine Pump Status EP14 (Brine Pump Speed)
43437 Number % Supply Pump Speed EP14 (Climate supply water pump)
44270 Number °C /10 Calculated Cooling Supply Temperature S1 (equivalent of general#43009 but for cooling as opposed to heating)
43103 Number HPAC state (state of the HPAC cooling accessory)
the three first (40015, 40016 and 43439) are to monitor the brine system which is where the heat comes from in an F1145 setup (the underground geothermal pipe is called the brine), the fourth one (43437) is to monitor the heat supply and i see you have already put it in the VVM310 / VVM 500 and VVM320 / VVM325 configs, but it would be also needed in the F1145 config at least.
Then then 5th (44270) is the equivalent of the base#43009 bit for the cooling mode of operation (43009 is for heating, 44270 is for cooling). Again you have put it in the VVM310 / VVM 500 and VVM320 / VVM325 configs but it would be needed as well in the F1145 config.
then the last one (43103) is also very useful (at least) for an F1145 to know how the connected HPAC should be operating (e.g. free cooling, active cooling, heating, etc) as there is no other way to distinguish for instance between active and passive cooling. I think also the use of an HPAC with an F1145 is very common, so monitoring the HPAC state is very relevant.
for each one i’ve provided you in the table the scaling to apply (and the corresponding dimension unit after the scaling is applied). A blank is the column following the unit column means no scaling should be applied.
please tell me if you have anything against putting these in the F1145 config and i’ll not bother you with this anymore!
thanks
I have seen you requested these channels already a few months before. Well I missed this, somehow.
I will add the channels but as this is not a fix but additional functionality I am in doubt that those changes will be included in the official 2.4.0 version.
Also this requires several files including documentation to be changed this takes more than 10 minutes…
Finally it should be tested before getting this integrated into the master.
BR
Alex