Nibe uplink binding

Thank you again Alex for the custom channel datatype switch to number. I’ll integrate and test asap.

Concerning the status channels there could be a misunderstanding in the way i described the current behaviour.
As a matter of fact, these status channels defined as String do not report anymore the strings ‘Yes’ or ‘No’ nor any other lexical labelling in the case of a choice list. What is currently returned instead is the raw number itself (an integer) represented in a string, that is the string ‘0’ or ‘1’ or whatever other integer directly turned into a string. This happens since the change you have applied consisting in translating directly the RAW value (which i understand would be on March 28, looking at the related post). In other words, the former representation in earlier versions were indeed returning lexical string statuses such as ‘Yes’ or ‘No’ but these are no more returned, now we get ‘1’ or ‘0’. this is the reason why i was suggesting to make it all consistent with using number type directly.

In fact, on this subject i realised the following in the meantime: Before being uploaded to NibeUplink, all the nibe equipment parameters are also published/accessible via the Modbus40 interface. As a matter of fact, the Modbus protocol does not support strings but integers. This could explain why the RAW value, which is probably the native representation of these parameters in the equipment, is always an integer number (then to be scaled by a given factor when it is to represent a floating-point). What i’m saying is that all these parameters that NibeUplink publishes through the API are also the so-called Modbus ‘registers’ that can be published locally by the equipment (through the Modbus40 box), and so the native datatype of all parameters is most probably Integer since the start.

Sorry for this long post but i realise it could explain better what i observed and tried to summarise in the previous post.

Hi have you already tested the new build. i had problems old version starts as shuld be but the new version says about to initialize but nothing happens. I have checked from build:list that new version is active. is there something that i can reset or is there some sort of cache. Normally everything has worked out of the box.

@Mikko_Jokinen:

Yes, I have tested it both in my dev environment and in my productive environment. Since the version changed from 2.3.0-SNAPSHOT to 2.4.0-SNAPSHOT make sure you uninstall the old one while openhab is running by deleting the jar from the addons folder. Then put the new version into the addons folder. In the last step restart openhab. This ensures that the old version gets uninstalled. Otherwise it might happen that multiple versions of the binding are running at the same time.

@oliviercommelarbre:
I think I understand what you want to say. But setting everything to number type will also remove the possibility to map the numbers to strings automatically. So for example “temporary lux mode” will then be a number between 0 and 4. You then need to know, that 0=off, 1=3h, 2=6h, 3=12h and 4=once. As there are many of those “list types” it will be hard to remember this for each and every channel.
Every user who wants to use those string will then be forces to create the native number item and a virtual string item and an update rule which will set the string whenever the native number is updated.
So I do not think this is a good idea.

BR
Alex

i tried all what i can imagine. i added DEBUG/TRACE flags for this bundle and i did see that the values are fetched. i have cliked them from interface but those items are not updated.
2018-06-05 23:53:07.747 [DEBUG] [k.internal.model.GenericDataResponse] - Channel 40004 updated to: 94 (9.4°C)
2018-06-05 23:53:07.748 [DEBUG] [k.internal.model.GenericDataResponse] - Channel 40067 updated to: 105 (10.5°C)
2018-06-05 23:53:07.748 [DEBUG] [k.internal.model.GenericDataResponse] - Channel 43005 updated to: -685 (-68DM)
2018-06-05 23:53:07.749 [DEBUG] [k.internal.model.GenericDataResponse] - Channel 43009 updated to: 240 (24.0°C)

i did uninstal, did smarthome:links clear and things also any ideas?
Linked items show in paper ui but no values. i test and try more in fev days

@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 finally list it again to check that it did update:

openhab> bundle:stop 10
openhab> bundle:update -r 10 /usr/share/openhab2/addons/org.openhab.binding.nibeuplink-2.4.0-SNAPSHOT.jar
openhab> bundle:list 10
START LEVEL 100 , List Threshold: 50
ID | State    | Lvl | Version            | Name
---+----------+-----+--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
10 | Resolved |  80 | 2.4.0.201806051257 | NibeUplink Binding

finally you start the new version:

openhab> bundle:start 10
openhab> bundle:list 10
START LEVEL 100 , List Threshold: 50
ID | State  | Lvl | Version            | Name
---+--------+-----+--------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
10 | Active |  80 | 2.4.0.201806051257 | NibeUplink 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 you place in the transform directory of your config (e.g. in /etc/openhab2/transform). Let’s call it TemporaryLuxMode.map with the following content:

0.0=off
0=off
1.0=3h
1=3h
2.0=6h
2=6h
3.0=12h
3=12h
4.0=once
4=once
-=invalid     

Note: there is apparently a bug/limitation with this map transform (when using persistence services for the Items if i remember well) such that that it is recommended to define both the decimal x.0 and integer x translation. I found this hint in another post.

Now, having defined the transform, you can recall it in your items definition file:

Number TemporaryLuxMode "Temporary Lux Mode [MAP(TemporaryLuxMode.map):%s]" {channel="nibeuplink:f1145:nibe:hotwater#48132"}

The advantage besides the translation being cleanly defined in a .map file is that you get both representations to coexist. The Item will be automatically displayed (e.g. on the sitemap) with the string translated value (i.e. with its label ‘off’, ‘3h’, ‘6h’, etc) while it can be stored with its native number type in the database (when you use openhab persistence), and this without having to use rules to translate between representations.

You can also access either representations in rules, for instance:

val mode = TemporaryLuxMode.state as Number // this sets the variable mode as a Number 0,1,2,3, etc
val modeStr = transform(“MAP”,”TemporaryLuxMode.map”,TemporaryLuxMode.state.toString) // this sets the variable modeStr as the String equivalent representation of the mode (using the MAP defined transform). i.e. if the state is 1, then modeStr will be set to the String '3h'
TemporaryLuxMode.sendCommand(transform(“MAP”,”TemporaryLuxMode.map”,”3h”)) // this sends the command 1 (translated from the map file)
TemporaryLuxMode.sendCommand(1) // this does the same

So in this way i think you get what you would want while using the concepts embedded in openhab with the transform approach to play with the item representations.

The other important thing i wanted to highlight in my previous posts is that in the current 2.4 and the last 2.3 versions, and although the status channels are indeed defined as String type, you actually don’t get the string equivalent. I have not checked for the temporary lux mode channel, but for instance for the channel ‘Compressor Status Blocked’ (channel ‘compressor#10012’) which is defined as String:

I have defined the Item consistently with String type as required:

String NibeCompressorStatusBlockedTmp "Compressor Status Blocked" {channel="nibeuplink:f1145:nibe:compressor#10012"

and this is what i see in the events.log when the item initialises after startup:

2018-05-31 16:59:21.419 [vent.ItemStateChangedEvent] - NibeCompressorStatusBlockedTmp changed from NULL to 0

A query from the Karaf console is also consistent with this:

openhab> smarthome:status NibeCompressorStatusBlockedTmp                                                                                                                                                                    
0

you will note i don’t get ‘No’ or ‘Off’ which would have been the string representation. What i get is the String ‘0’. I’m not sure this is what you would be expecting from what you explained in your posts, as we should have rather expected to have the item state get the string value ‘No’ (or ‘Off’). So overall i would think that giving directly a Number type in this case (the number 0 or 1) would be more consistent and as well more convenient.

Please don’t hesitate to shout if I miss something

Hi

i installed new blank 2.4 snapshot with 2.4.0 snapshot binding. No data for F750. Is there any possibilities that something has gone wrong when added new channels. No data with automatic linking or manual. I can see that data is fetched OK but it does not go to item value. There is nothing in events log for Nibe. when i change back to 2.3.0 Snapshot everythin works exept there is no fixed channels and multipliers.

1 Like

I can confirm this issue and for F1155.

1 Like

Is there any error in the logs?
I have not yet tried the openhab 2.4 but I am using openhab 2.3 + the 2.4 version of my binding

BR
Alex

@oliviercommelarbre:

You are right, using those map files seems to be a good idea. Users still have to define those maps on their own because I do not know any way to include them in the binding.
But at least it is possible to translate the status values to your own language. :slight_smile:

I will put this change on my list but first I will focus on the issues which currently exist.

@Mikko_Jokinen, @Giedrius and @AlexF: for info if it can help, i still use openhab 2.2.0 with the new version 2.4 of the snapshot and it works like a charm on my raspberry pi, the Nibe is an F1145.
Another info, sometimes things in openhab resolve miraculously after applying the procedure advertised in this post: . I have not had to use it in my case when switching from 2.3.0 snapshot but you never know… it has solved many other problems for me in the past, especially after i had awkward symptoms similar to what you have described.

I tried this with my old stable installation and all new installation in another laptop without other bindings. The 0.2.4 version is not working and 0.2.3 works. Il try to catch errors or log. No visible errors in openhab.log with default logging.

1 Like

Hi @AlexF

indeed there is the added value you spotted for specialising the statuses in your own language (which i realise is a really important one)
Thanks for that, will be looking forward to the future change. No rush for me, as said 2.4 already works for me with a few workarounds via rules handling type translations.

I take the opportunity to record the parameters of the F1145 that i would ideally like to see in the default list of channels. All are i think very relevant to the general monitoring of an F1145, operating a brine underground water system as the heat energy source (or sink when cooling), the 2 last ones for general monitoring of the cooling process. Probably all are equally relevant to an F1155.

These are:

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)

I have added a column to map the parameter scaling when applicable.
it would be great if you could add these to the default list!

cheers for now!

Same here. I’ve got a VVM320+F2040-8.
With Version 0.2.3 it works, with 0.2.4 it doesn’t.
I can see in the Debug Logs that die Bindung gets some new values for my Items.
But the values doesn’t seem to be published to the Items.

As I stepped back to Version 0.2.3 (Source: http://friese-de.eu/openhab2 ) it lost the availability to control my VVM320. Seems to be, that the 0.2.3 isn’t the same as the old one.
Could that be?

Hi @AzraelMasters

This is really weird, because you have exactly the same setup like me. I also have the VVM320+F2040-8.

I reverted back to version 2.3 and everything works again. There are no errors in Debug logs for 2.4. The only difference in Debug logs is that in case of 2.4 logs ends on “Handling channel update” and in 2.3 it continues with each channel details:

[DEBUG] [euplink.handler.GenericUplinkHandler] - Handling channel update.
[DEBUG] [euplink.handler.GenericUplinkHandler] - Channel is to be updated: general#44302: 0
[DEBUG] [euplink.handler.GenericUplinkHandler] - Channel is to be updated: compressor#43136: 0
[DEBUG] [euplink.handler.GenericUplinkHandler] - Channel is to be updated: general#44304: 0

@Giedrius: Thanks for your hint. There is indeed a slight change in code where the channel update takes place. Still a little bit weird becuase this is the same for all models and I do not have any problems. But this is also related to the custom channels. I will check the code once again.

BR
Alex

Well I did not find any issue. I improved the logging, “Handling channel update” now announces the number of channels to be updated. In your case I guess it is 0.

This is what my log looks like. In my DEV the logging is in general set to a high level so I get a lot of messages from openhab itself, e.g. the ItemStateEvent.

2018-06-12 17:20:53.093 [DEBUG] [.o.b.n.i.c.GenericStatusUpdate:153  ] - JSON String: {"Values":[{"VariableId":40004,"CurrentValue":"19.4°C","CurrentIntValue":194,"IsLoading":false},{"VariableId":43005,"CurrentValue":"0GM","CurrentIntValue":0,"IsLoading":false},.....]}
2018-06-12 17:20:53.094 [DEBUG] [.n.i.model.GenericDataResponse:67   ] - Channel 40004 updated to: 194 (19.4°C)
2018-06-12 17:20:53.094 [DEBUG] [.n.i.model.GenericDataResponse:67   ] - Channel 40067 updated to: 185 (18.5°C)
2018-06-12 17:20:53.094 [DEBUG] [.n.i.model.GenericDataResponse:67   ] - Channel 43005 updated to: 0 (0GM)
...
2018-06-12 17:22:53.524 [DEBUG] [n.handler.GenericUplinkHandler:180  ] - Handling channel update. (70 Channels)
2018-06-12 17:22:53.524 [DEBUG] [n.handler.GenericUplinkHandler:190  ] - Channel is to be updated: general#44302: 13820
2018-06-12 17:22:53.525 [DEBUG] [n.handler.GenericUplinkHandler:190  ] - Channel is to be updated: general#44304: 0
2018-06-12 17:22:53.525 [DEBUG] [n.handler.GenericUplinkHandler:190  ] - Channel is to be updated: compressor#44700: 99
...
2018-06-12 17:23:53.253 [INFO ] [smarthome.event.ItemStateEvent:51   ] - NIBE_HM_COOL updated to 1382.0
2018-06-12 17:23:53.253 [INFO ] [smarthome.event.ItemStateEvent:51   ] - NIBE_VENT_BT23 updated to 19.1
2018-06-12 17:23:53.253 [INFO ] [smarthome.event.ItemStateEvent:51   ] - NIBE_VENT_BT20 updated to 25.3
2018-06-12 17:23:53.253 [INFO ] [smarthome.event.ItemStateEvent:51   ] - NIBE_OUT_TEMP_AVG updated to 18.5
2018-06-12 17:23:53.254 [INFO ] [smarthome.event.ItemStateEvent:51   ] - NIBE_COMP_STARTS updated to 11130.0
...

One additional remark:
If you are using custom channels keep in mind that those channels are now numbers. I would expect at least a warning in the logs if there was a mismatch…

Last line in logs is now this:

2018-06-13 09:17:55.068 [DEBUG] [euplink.handler.GenericUplinkHandler] - Handling channel update. (40 Channels)

To be on safe side I also removed 2 custom channels I had. Still result is the same.