Thanks Alex for this, i will test it with more time after Easter.
Concerning the current channels BE1-BE3 they do respond according to any power activity (not only on additional heater activity) on my setup (a tri-phase F1145). I think that however there needs to be some specific installation for it to work (probes to be installed around the power lines).
Hi there Alex,
Sorry i have to edit this post, i had a typo in my item config which is the reason why it was not working.
Please ignore!
previous post (to ignore):
here is a channel i find does not update with the DEV version. I wonder i you could also add this one in the default list for the F1145 (and probably F1155 which is very similar as far as i understood)
param datatype unit name 40022 Number °C Compressor Suction Gaz Temperaturethanks
Hello Alex,
I tried to add the current Status of my VVM320 & F2040 to my sitemap, but I doesn’t seem to work.
It Returns the value = -32768
Thing
nibeuplink:vvm320:NibeF2040-8 [ user="MyName@myDomain.com", password=“myPassword”, nibeId=“myId”, pollingInterval=300, customChannel01=43086 ]
Item:
String Nibe_43086_HeatingAction “NIBE - Aktueller Modus [MAP(nibeuplink_43086.map):%s]” {channel=“nibeuplink:vvm320:NibeF2040-8:custom#CH01”}
MAP:
10=Standby/Aus
20=Brauchmwasser
30=Heizung
40=Pool
41=Pool 2
50=Transfer (?)
60=Kühlung
-=N/A
Do I miss something? By the way it seems the current DEV-Plugin Returns old values and Freeze them.
Hi Alex
i’ve been testing the new DEV version (the one you advertised in your post of Mar 28) and wanted to provide my feedback. Unfortunately i’ve had to revert to the previous version (see reasons after), I’ll wait for your feedback first.
One of the changes from the previous version is the use of the raw value, which has the side-effect of rendering the values with a wrong scale that no more corresponds to the expected unit. For instance, all temperatures are multiplied by 10, degree minutes also, and power channels (normally in kW) get multiplied by 100. I noticed it is not the case for the new current channels you had just added (40079, 40081 and 40083) that are given with the right scale in Amperes.
Nibe is pretty consistent however on the scale they apply on the raw value depending on the unit (i.e. temperatures are always scaled with factor 10, power with 100, degree minutes with 10, and so on), so i was wondering whether you could apply it before rendering the value.
The alternative is unfortunately quite cumbersome as it requires to systematically define temporary items and rules to rescale the value from the temporary to the final item, otherwise items get stamped in DB (through persistence) with their wrong unit.
I did not find any easier way to scale on the fly (e.g. the generic transformation services act only for display on the UI but not on the item value itself). However there are some bindings (see for instance the modbus binding) that allow rescaling on the fly the raw value before attaching it to the item (by reusing the generic openhab transformation concepts and syntax). You could alternatively follow a similar approach, however while i find it makes sense for Modbus (as modbus is actually always carrying integers), it would make little sense for nibeuplink as i see very little use case of wiling to apply a different scaling than the right one.
Looking back to the fact that the new BE1, BE2, BE3 current channels you have added indeed apply the /100 scaling to get to the right number in Amperes, i suppose that your intention is indeed to provide directly the scaled value and that you may have forgotten to do it for the previous channels.
looking forward to your feedback!
cheers
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