Hi, How can I get this Binding? Thanks 
Hey, latest version can be found here:
Thanks!
What is the status of this binding. I have just installed it from the alpha location that was updated last december. Is that still the most recent version?
Hey there, Iām only able to work very sporadically on this binding but have it running since a year now.
I updated it only last week trying to fix this issue (https://github.com/pravussum/openhab2-addons/issues/8). This seems to fix it for me, but I havenāt prepared a release yet. I can upload one next week (Iām on vacation)ā¦ Thats the only difference to the version from last december.
You can also try the old version - if your air dial battery and the connection to the air unit is ok, you shouldnāt run into it anyway.
1 Like
Cool 
I am on vacation also (EfterĆ„rsferie?) I have installed the āoldā version and it seems to work just perfectly.
Managed to upload the current one (VPN 
)
2 Likes
Awesomeā¦ Iāll soon try and install it
Now Iām getting 0Ā°C room temperature permanently. 
@BlackAlpha check the connection to the Danfoss Air remote unit. If the batteries are dead or the connection are otherwise lost I get 0 degrees room temperature also.
@BlackAlpha Iāll try and add both of the channels (room temp & room temp calculated) and add some fallback logic (like disallowing temps below -273) - actually I already programmed it, but itās quite some hassle to get the build to work when not using Eclipse and even then, they changed the whole build process in 2.5 which I expect to release in the near future. So, it might take some time (got some other projects, too 
)
I might come back to you with a debugging version of the binding, because my air unit behaves differently: my remote unit is dead since a while (the batteries), but I still get a value for the (calculated) room temp.
Until then I think the best for you would be to use the version before (alpha 4) with a remote with full batteries.
And here is the next alpha release, I finally managed to build this monster.
Feel free to test it.
I reintroduced the room temperature from the air dial (āRoom temperatureā), but kept the calculated temp which works without the air dial for me (āCalculated room temperatureā).
Note that the binding structure is updated to build against openhab 2.5, which might or might not work with the current stable 2.4. Anyway, I expect 2.5 to be out very soon.
Please let me know if there are any issues & if this fixes https://github.com/pravussum/openhab2-addons/issues/8 for you @BlackAlpha.
@pravussum I have a small feature request now that you have code open.
Could you add some rounding to the output numbers, mayby all the way down to one decimal digit? Anything below 0.1Ā°C change does not give any new information and only adds to the noise on the eventbus.
danfossairunit_extract_temp changed from 20.549999237060547 Ā°C to 20.520000457763672 Ā°C
I might be the only only one annoyed by this. In this case please ignore my request.
Also mayby add the supply/extract fan tuning variables? I would very much like to lower my extract when the kitchen extractor hood or fireplace is being used.
Otherwise great work! I really love this binding.
Yeah, can do so.
About the āsupply/extract fan tuning variablesā - can you point me to a line number in your Google Sheet so that there will be no misunderstanding of which variable you mean?
That is a very good question There seem to be multipe candidates.
My best guess is line 21,22 but line 28,29 and 78,79 are also candidates.
28,29 looks like currently selected steps(%). The values corresponds to 100% speed balanced by the values in 21,22.
78,79 is CCM v1 whatever that means in practice.
@pravassum a suggestion from an outsider.
The desired feature here is obviously good, no domestic temperature sensing ever needs to more than one decimal place, and reducing event bus traffic is desireable.
General thoughts; simply reducing changes does not take away update events. How often are you guys polling? If frequently, you might look at Modbus binding for a technique to reduce updates.
There is a updateUnchangedValuesEveryMillis parameter for each channel. When default/zero, every polled data is passed as an update.
Otherwise the binding caches polled data. When the data changes, it is always passed as update.
But if data not changed since last poll, it only gets passed as update (to same value) every NN milliseconds, as set in the parameter.
Feature was added to binding just to reduce event bus traffic from frequent polls - that has other benefits too where people might have persistence on every update etc.
You would need to think about how it should work where you are rounding values - should it be caching raw or rounded data?
Unrelated really, but taking away user choice by forcing the same rounding scheme on everyone may not be the best approach. For many bindings, it is possible to include a transform into the channel parameters that operates on data before it is passed to channel and Item.
Allowing users to do whatever rounding they liked - or any other conversion - might be preferable.
Just suggestions.
1 Like
Hey rossko, thank you for the hints, Iāll definitely have a look into it. Right now, weāre updating everytime which indeed seems not like the best idea. The polling interval is configurable at least.
The old Modbus-1 binding had a similar but simpler updateUnchanged feature, no timing involved. When selected, it just passed every change, but never passed updates-to-same.
The drawback of that simpler approach was that you had no way (in rules etc.) of determining if some device was alive or broken or just stuck.
Bearing in mind Modbus is general purpose, but you are device specific here - if there are other ways to know the Danfoss is alive and responding, then the simpler way might do.
The bonus of the more complicated timed method is that you can ensure an update at least once a day for example, useful for statistics, keepalive confidence, graphs etc.
And another (alpha)release:
- added the rounding of temperatures (I decided to not make it configurable per channel transformation, that would have been overkill & Iād like to have this working out of the box)
- added the value cache suggested by @rossko57
- hardended the thread handling & exception handling
@BlackAlpha I removed the network cable from my running air unit, watched it going offline in Openhab, waited a couple of minutes and plugged it back in. Both the 2.4 and the 2.5 version came back online without issuesā¦
I closed https://github.com/pravussum/openhab2-addons/issues/9 ā¦ should you still run into issues, feel free to open the ticket again.