I was really surprised to find some new infos here since I was trying to get this stuff running with openhab some 3 years back and gave it up.
Since I didn’t find a binary as well I tried to compile it myself, failed to do so (Maven build failed with the version from the github repo, and when I finally got it running with the current openhab master merged in the Binding wouldn’t load in openhab ).
So I started a new binding myself, ported the code from leaxi and finally saw some values from the air unit last night.
So the question is, how to continue? @leaxi are you still actively developing?
Otherwise I’d get the binding into a state which can be pushed to github and make a release for others to download.
When its tested we can send a pull reuquest to the openhab master.
@BlackAlpha: are you still interested in the binary? I could send you my current version in the meanwhile.
edit: see below for the github link including the binary of the binding.
I’ll try to get this stuff on github soon, basically it’s all leaxis code. @leaxi hope you don’t mind
I added a thing via configuration file, so that I can set the host parameter (didn’t find a way via Paper UI, i suppose the autodiscovery has to be changed to add the thing automatically).
danfoss.thing with just a single line:
Hi, @pravussum I don’t mind Thanks that you took the time to get it to a state that it can be shared with others.
I tried your binary as well, as I was never able to got mine working really outside of Eclipse. Unfortunately same result with your binary. In Paper UI I’m not able to add a “Danfoss thing”. The Binding is listed, but it doesn’t show any supported things. You probably have to review the xml again.
I didn’t try the config files, as I purely use openhab without config files and also my goal when writing the binding was full integration with paper ui configuration. So I had spend a lot time on discovery. The discovery itself was working well, but the integration with openhab framework was only working correctly inside eclipse.
I removed the thing configuration from danfoss.things and restarted openhab to reproduce your issue.
Apart from that I have just copied the jar to /usr/share/openhab2/addons directory in my openhabian installation.
In PaperUI under Configuration | Bindings | DanfossAirUnit Binding there is “Danfoss Air Unit” listed under “Supported Things” (just check it, nothing to do there)
Under Inbox | + symbol | Danfoss AirUnit Binding | Danfoss AirUnit I am able to type in the configuration parameters
(hey, at least now I know how this is supposed to work)
When I confirm, the thing is added and i can link all the channels to newly created items that are visible under “Control”…
I did no black magic to my openhab installation, just vanilla openab and the jar copied to addons.
Which version of openhab are you using? I changed the version of the bundle aka binding to 2.4 in the manifest.
Only the fan speed does not seem right. It stays always at 10 (%), even in boost mode.
I suppose some conversion issue. I’ll look into it as soon as I find some time, or maybe @leaxi you can take a more educated guess at what could be the reason?
the fan speed of the air unit ist available in certain registers with different meanings and units. I used the register, which allows setting the fan speed in manual mode. This register contains a byte with the values 0 to 10. 0 = OFF, 10 = 100%
As I coded this as a PercentValue state in OpenHab I had to add a rounding, when the user sets something like 53%. This value would bei rounded to step 5.
Question ist now wheter your air unit was running on step 10 or 1 or something else. You can check that in parallel using the air dial.
10 would simply mean a unit issue. 1 would mean correct. Any other would mean Something completely wrong.
But when you run the air unit in demand or program mode or with burst on, then reading the register of manual step setting doesn’t tell you the actual speed. This would be a different register, so you also should provide a second read only channel for this information.
I think you need the Info registers, they are not in the danfosshrv.java so far. Just add:
private static final byte[] FAN_SPEED_SUPPLY = { 0x14, 0x28 };
private static final byte[] FAN_SPPED_EXTRACT = { 0x14, 0x29 };
public PercentType getFanSpeedSupply() throws IOException {
return new PercentType(BigDecimal.valueOf(getByte(REGISTER_1_READ, FAN_SPEED_SUPPLY)));
}
and for extract accordingly.
And in the handler.java the update method need to be adjusted, the channels need to be added and probably a new group etc.
50% offtopic, but probalby the best chance here to get in contact with other users of danfoss air unit.
Which kind of mode you use most of the time? Personally I would like to use DEMAND, thus the automatic fan speed control. But often it doesn’t work as expected. In winter speed is often too high so humidity drops sometimes under 40%. On warm summer days speed is too high during the day and too low during the cooler night.
Why do I ask? When this binding would work well, we could add another “virtual” mode let’s call it “binding controlled”. In this mode I would try to add such a speedup and speeddown based on the daily temperature change. So it also would make sense to slow down the unit during cold nights and instead do some air exchange during the warmer day. So the algorithm would make use of the build in history of temperatures of the last days to extrapolate the temperature. This should be enough to find out whether it makes sense to run at different speeds during day and night.
Ah, I see. I’m running almost all the time in demand mode, so that makes sense. The actual fan speed channel should certainly be added. (Edit: just saw your edit with the registers. Thanks!)
Regarding your “binding controlled” mode: sounds reasonable. Actually I cant’t really tell what the air unit is actually doing, this is one reason I wanted to have it bound to openhab, to get some graphs and to know whats happening.
Another reason is that I want to have a switch in the kitchen to turn the air unit off while cooking (or do it automatically when the stove is on).
Btw, I get a lot of timeouts (self recovering, the binding goes back to online by itself), so we should make the timeout configurable as well. It seems to happen more if I lower the polling interval.
First off all. Thank you for this binding. It works great even through I am using the Link CC controller and not the airdial.
The Danfoss PCTool program is removes a lot of options when you are using the Link CC controller and I was worried it was because some of the controller logic has moved to the Link CC.
My limited testing so far points to that this is not the case and I can control the airunit just fine from this binding.
It would be nice to have the fan speed % readable in Demand mode.
I agree the the Demand mode is not perfect but It might be better too implement a custom mode as a template for a rule in Openhab instead. You might want some extra features like offsetting the intake/exaust balance when the Kitchen extractor or fireplace is on.
at first, great work, @pravussum. The Binding seems to work great for me!
If there’s something I could do to help you please tell me.
On starting openhab, an exception is thrown, but after this everything works fine:
2018-11-19 11:44:12.485 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: null
at org.openhab.binding.danfossairunit.internal.discovery.DanfossAirUnitDiscoveryService.discover(DanfossAirUnitDiscoveryService.java:70) ~[?:?]
at org.openhab.binding.danfossairunit.internal.discovery.DanfossAirUnitDiscoveryService.lambda$0(DanfossAirUnitDiscoveryService.java:52) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
For me, I don’t think an “virtual” mode is neccessary. I think this would be a problem if you use the air dial to manual change settings of the air unit. I would prefer to set the air unit to manual and change it’s parameters trough rules - so it is possible to change settings via air dial all the time, too.
Another very little thing I’m missing is a switch for night cooling.
Yeah, thats what I experienced as well (I use the state from the air unit to update the switch LED and it takes forever between pressing the switch and the LED lighting up).
You didn’t run into any timeout issues?
Let’s track bugs in Github and rather discuss the serious stuff here
Not until now. If you use wireshark to analyze the networktraffic between the Danfoss PC-App and the air unit you will see very heavy traffic. So I don’t think there will be any problems. Next I will try 1s…
Ok, sounds good. Send feature requests to github, too?
It appear to contain a complete list of all the registers that can be set and read on the airunit including the address.
The example above: FAN_SPEED_SUPPLY = { 0x14, 0x28 }; is in decimal 5160 and the row containing that number:
Step Supply Fan 0 5160 20/11-2018 20:35:35 20/11-2018 20:35:35 63 / 3F BYTE Writeable 2
BTW: To activate this mode edit C:\Program Files (x86)\Danfoss Heating Solutions\HRV PC-Tool\HRVPCTool.exe.config and replace ProgramMode line with:
Just uploaded a new prerelease with the fix for the autodiscovery, this is working now.
Delete any thing files from the configuration and please restart openhab to avoid any issues with two versions of the addon being loaded in parallel.
Then the Danfoss Air unit should automatically appear in the Inbox.
The current fan speeds for supply and extract fans are added as well. The old “fan speed” has been renamed to “manual fan speed”, so your item configs might need some adoption. @Asbjorn_Mejnertsen Thanks for the Google sheet, that helped a lot! The registers we assumed where not the right ones, but I found them and now we even have fan rotations in rpm and not just 10 steps.
At least now I know how the works
@leaxi There are different registers to read the result from (REGISTER_1_READ, REGISTER_4_READ constants in the code) … how do you know which one to use? There not in the Google spreadsheet I ended up trying and debugging…
I still have issues with timeouts, though. But the binding seems to recover most of the time.
I will make it configurable an play a little bit with the parameter and see, if it helps.
Btw, Eclipse is real pain to use. In the end I developed with IntelliJ and debugged in Eclipse, had some hard time to get this stuff working. But was worth it!
since 14 days the binding works fine with 1s refresh interval. Only one DateTimeExeption, but I’ve seen, you’ve fixed this bug already! Very very very good work!!!
Thanks that you took the time to get it to a state that it can be shared with others.
I ended up trying and debugging…