thanks for your feedback. I have already implemented the scale correction for my Nibe VVM320. It works fine.
So I think that this is still missing for your model. Could you please give me a feedback which model you own?
If you are 100% sure that your logic described above applies to all channels I could then adopt it. Otherwise you must give me the scale correction factor for each channel.
Regards
Alex
Hi @AzraelMasters,
I have the same indoor + outdoor unit. The binding works fine and runs stable for several month.
But not all channels which are provided via modbus are available via NibeUplink. In my setup the channel 43086 does not provide any data, too.
There is a special technical channel which is encoded as bitset but I was not able to fully reverse engineer the bits. It is channel ‘40892’. The channel has even more information. What I am sure to be true is:
bit 1: GP6 active ???
bit 5: outdoor unit active
bit 7: heating mode
bit 8: hot water mode
bit 12: additional heater active
bit 14: unknown but always set.
bit 15: cooling mode
bit 18: vacation mode active
There are still lots of bits missing / unclear so I did not start to implemet a bitset decoder. It is quite complicated as well as most bits are not exclusive but can be combined with others.
BR
Alex
Hi Alex,
Thanks for your quick feedback. The model i own is a tri-phase F1145 (it operates on a ground geothermal source with two ~100m deep probes).
I can confirm that the scaling i described is consistent on all channels i use. Unfortunately i cannot say whether this applies across all possible channels but it is very likely.
For all the ones i use, all is consistent with the following rule:
/10 for temperatures (to get to degree C, i use 40067, 40004, 40008, 40012, 43009, 40071, 40033, 44270, 40014, 40015, 40016, 40017, 40008, 40018, 40019, 40022)
/10 for degree-minutes (i use only channel 43005, i don’t know if others use this DM unit)
/10 for electrical current (to get to Amperes, i use 40081, 40083, 40079)
/100 for electrical power (to get to Mega Watt, i use 43084 and 47212)
no scaling for pump speeds (raw value directly translates to percent as an integer from 0 to 100, i use 43439 and 43437)
no scaling for operating times (all given directly in integer number of hours, i use 43420 and 43424)
no scaling for all others i use which are basically boolean statuses
Maybe you could apply it in a generic manner for a start on the basis of these default rules, and then foresee may be a second level specialisation per channel, if someone comes with an actual exception to the rules for one or a set of channels. In this way you would have the default easily implemented which is likely to be exact for most channels, while still leaving the possibility to customise the factor for specific channels that would not follow the default. what do you think?
I have fixed the scaling for model F1145. As each and every channel needs to be defined individually it does not make sense to implement a scale guessing algorithm. I just added the scale definition to the channel definition. It should now work for you. Please report back if anything is still wrong.
BR
Alex
Hi Alex, good point. Thank you very much, i will try asap and feedback
Hi Alex, i’ve tried and all works great and with the right scaling, thank you very much. i’ve now switched definitely to the new version.
here a quick feedback concerning data types with some suggestions:
I have noted that since the use of the raw value, the status channels (yes/no) or the mode channels (choice1, choice2, etc) actually resolve to a number (e.g. 0 for no, 1 for yes, or the coded index 0,1,2,3 for choice lists). At present these channels however are defined as String type which gets the raw number coded in a string of characters. As a suggestion, it would be more straight forward that they resolve directly with Number type so as to avoid the need for translation rules.
I would think also that in general all Nibe uplink parameters either resolve to a number or have a number equivalent representation, so the custom channels could be better defined directly with Number type, again still to avoid having to systematically use translation rules. The ideal would even be that the scaling factor can be optionally defined through the Thing definition (using a syntax like for instance “… , customChannel01=44270/10, customChannel02=40015/10, customChannel02=43165/1 …”). That would make it really seamless to integrate.
again thanks and cheers
Hi
I have same issue with 750. Atleast temperatures and compressor frequency is 10x value.
I would also like to set
https://www.nibeuplink.com/System/xxxxxx/Manage/2.1 Temporary Lux
https://www.nibeuplink.com/System/xxxxxx/Manage/1.2 Ventilation
https://www.nibeuplink.com/System/xxxxxx/Manage/4.7 Holiday setting
Hi @Mikko_Jokinen:
I will fix the scaling issue. But I need feedback regarding two channels:
What is the correction factor? 1, 10 or 100?
Thanks
Alex
Air Supply/Exhaust Sensors
trending_upBT20 Exhaust air temp. 1 226.0 °C
trending_upBT21 Vented air temp. 1 57.0 °C
trending_upAirflow ref. 1882.0
trending_upEB100-Adjusted BS1 Air flow -32768.0
Shoudl be 22.6, 5.7, 188.2 186,5 the last value is the weirdest
i would say that 10 but the last value is some kind of offset.
aslo trending_upHeat Meter - HW Cpr EP14 23750.0 kWh should be hotwater, compr. only. EP14 2375.0kWh so there is 10x multiplier too so is Degree Minutes (16 bit).
does this make any sense or shuld we have some sort of spredsheet or file for these.
I will keep the status channels as string. Otherwise there is no convenient way to resolve it to a readable string. I believe most users will like to see a string rather than a cryptic number. However if you need a numeric representation you could define that channel as custom channel. I have changed that, so now all custom channels resolve to number.
I did not yet define a “scaling-by-configuration” for those custom channels but in general it is a good idea.
Thanks for the quick reply. Regarding the write access. There is currently no channel defined for the fan speed. So first of all I need the channel before I can enable write access. My VVM320 has channel number
47260 “Selected Fan speed” for this.
BR
Alex
i have custom channel 43108 that shows value 0,1,2,3,4 depending on the setted value.
is that what you menioned.
i found that value from https://github.com/openhab/openhab1-addons/blob/master/bundles/binding/org.openhab.binding.nibeheatpump/src/main/resources/Nibe%20F750%20variable%20information.csv
Channel added, please check and report back if any issue occours.
The updated 2.4.0-SNAPSHOT version should be available in a few minutes
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.
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.