perfect, the TRACE log includes the relevant data. As expected, the read out data block from your device is shorter than it is for “4 level” devices. I will try to implement a fix over the weekend.
Just to confirm my interpretation of the data, am I correct that at the time you took the log, following values were set:
(Just if you remember. The data is actually pretty clear to me, so no need to read it out again in case you don’t remember.)
Fan Level 0 out = 40%
Fan Level 1 out = 70%
Fan Level 2 out = 100%
Fan Level 0 in = 40%
Fan Level 1 in = 70%
Fan Level 2 in = 100%
(Current Fan Level out = 40%)
(Current Fan Level in = 40%)
(Current Fan Level = 1)
(Inlet Fan active = True)
Of course I already knew the protocol manual you attached, since it seems to be the only such document for the devices (and it’s perfectly prepared and very detailed). However, unfortunately it didn’t cover the special case of the WHR930.
If there were more deviations from the “standard” (CA350) configuration, we could think about adding an dedicated thing type for the WHR 930, to prevent potential users from using non-available channels for their devices.
Yes, your interpretation of the data is correct.
A dedicated thing for the WHR930 is maybe the best option because the menu P9 also doesn’t exist on the device. If you like i can send you the manual of the WHR930…
No, Didn’t use the OH1 binding…
I also debug the binding a little bit feather and discovered also an issue when using item “filterreset”. When sending a command to the item with value “1” to reset the filtererror. a error is returned
2021-03-19 15:20:39.533 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.ArrayIndexOutOfBoundsException: Index 9 out of bounds for length 9
@BartVdP I have compiled a version that should fix both issues for you. I’m not sure why the second error is triggered on a filter reset, but it seems that your device doesn’t provide the error states that are listed as EA and A (high) in the protocol. The manual of the WHR930 could help to confirm this. But I’m not even sure what these error states are about since their description in the CA350 manual is pretty sparse as well.
If you could test the new version and confirm it works, I will prepare a PR for it (and maybe add a new thing type for the WHR930).
EDIT: A (high) errors seem to indicate issues with geothermal heat exchanger, cookerhood and after heater sensors. Don’t know if these options are available for the WHR930
Thanks for your effort already!
Could you tel me what i need to do with the .jar file? Just install/drop it in a directory and restart OH?
I use a Ubuntu system and installed OH3 with openhabian.
Hi Bart, I never tried myself with OH3, but this should get you there: Installation of Add-ons | openHAB (basically put the file into /usr/share/openhab/addons)
Uninstalled the previous version and put the Jar file in /usr/share/openhab/addons.
Restart openhab. Was a littlebit confused because i didn’t found the binding in de menu…
When looking in the console via the command bundle:list -s there i could see that the new binding was activated.
Changing the fan speed works great! Good job!
But had some error in the openhab.log:
Change comfoairFanOut0 to 10%
2021-03-26 21:02:52.885 [WARN ] [ng.comfoair.internal.ComfoAirHandler] - unexpected value for DATA: 0a 46 64 32 3c 64 0f 00 01 00
2021-03-26 21:02:53.693 [WARN ] [ng.comfoair.internal.ComfoAirHandler] - unexpected value for DATA: 0a 46 64 32 3c 64 0f 00 01 00
Change comfoairFanOut0 to 50%
2021-03-26 21:03:05.783 [WARN ] [ng.comfoair.internal.ComfoAirHandler] - unexpected value for DATA: 32 46 64 32 3c 64 2d 00 01 00
2021-03-26 21:03:06.591 [WARN ] [ng.comfoair.internal.ComfoAirHandler] - unexpected value for DATA: 32 46 64 32 3c 64 2d 00 01 00
Change comfoairFanOut0 to 100%
2021-03-26 21:03:18.584 [WARN ] [ng.comfoair.internal.ComfoAirHandler] - unexpected value for DATA: 64 46 64 32 3c 64 5f 00 01 00
2021-03-26 21:03:19.392 [WARN ] [ng.comfoair.internal.ComfoAirHandler] - unexpected value for DATA: 64 46 64 32 3c 64 5f 00 01 00
Change comfoairFanIn0 to 10%
2021-03-26 21:06:22.612 [WARN ] [ng.comfoair.internal.ComfoAirHandler] - unexpected value for DATA: 64 46 64 0a 3c 64 5f 00 01 00
2021-03-26 21:06:23.419 [WARN ] [ng.comfoair.internal.ComfoAirHandler] - unexpected value for DATA: 64 46 64 0a 3c 64 5f 00 01 00
Change comfoairFanIn0 to 50%
2021-03-26 21:06:35.123 [WARN ] [ng.comfoair.internal.ComfoAirHandler] - unexpected value for DATA: 64 46 64 32 3c 64 5f 00 01 00
2021-03-26 21:06:35.930 [WARN ] [ng.comfoair.internal.ComfoAirHandler] - unexpected value for DATA: 64 46 64 32 3c 64 5f 00 01 00
Change comfoairFanIn0 to 100%
2021-03-26 21:06:50.520 [WARN ] [ng.comfoair.internal.ComfoAirHandler] - unexpected value for DATA: 64 46 64 64 3c 64 5f 00 01 00
Filter reset
2021-03-26 21:09:38.845 [WARN ] [ng.comfoair.internal.ComfoAirHandler] - unexpected value for DATA: 01 06 ec 00 00 e9 00 01 09 00 00 00 0f 00 00 08 a1
Any idea?
If i need to do some more tests on my system, just let me know!
Hi Bart, good that setting the fan levels seems to work so far. The errors seem to indicate, that the fan values sent from the device cannot be interpreted correctly (even though I see no issues with the raw data). Could you provide a full TRACE log?
Don’t know if it is useful but give you the sequence of the send commands…I first send the command “Filterreset”, afterwards i send the command “comfoairFanIn0” to 50%, 100%,10% and back to 50%.
Good luck!
Hi Bart, sry I have somehow missed your response.
I just had a quick look at your logs but I can’t really figure out why this error is thrown. Especially, since the same responses are interpreted correctly at the beginning. Additionally, the error can only occur if the response can’t be parsed correctly (which obviously works at the beginning) or the item/channel is set up incorrectly (which I also don’t expect to have changed inbetween).
Does any of your items change it’s state to NULL or UNDEF when the error comes up (until the next update)? Are your item types set correctly (fan levels have to be Number not Number:Dimensionless or something)?
I will add some additional logging and provide you a new test version.
Below you can find the requested log’s. I also included my items definition file for completeness
What i see in the trace is that there are requests for ‘ventilation#fanIn3’, ‘ventilation#fanOut3’, ‘times#level3Time’… wish i haven’t defined in the items config nor on my graphic page’s…
I also triggered the filterReset command … the tracelog you can find in the file “Comfoair_log20210410_FanOut_FilterReset.log”.
Hi Bart, as I suspected the binding is still trying to update values (ventilation#fanIn3, ventilation#fanOut3), which are not valid anymore due to the recent changes. However, I’m not sure why this happens since the binding is supposed to only update channels that are linked to an item. AFAICS these items are commented out in your .items file and thus shouldn’t be linked anymore, if they aren’t defined anywhere else.
Could you have a look using following console commands, if there are any remaining links for these channels?
openhab:links orphan list
or
openhab:links list
if the former command doesn’t provide anything suspicious.
If any orphaned links are found, these could be deleted with
@BartVdP are you sure you used the latest version? This warning should look different since the previous update.
I recompiled and uploaded it again (same link) just in case the error was on my side.
@boehan Sorry, the problem was on my side. I thought just dropping the jar in the add-on folder and removing the previous one was sufficient…NOT
Just for the completeness:
When i looked in the console bundle:list | grep Add-on there where more instance’s of the binding than just one…
So stopped the bundle via the command bundle:stop ID where ID is the instance number and uninstalled the bundle with the command bundle:uninstall ID.
After that I restart OH and everything worked fine! No more comfoair binding issues
What I still need to test:
The Filter reset command
The Error reset command
Change the fanlevel, but I thing this wouldn’t work without a CCE-Easy interface… correct?
If I need to test some more, just let me know.
I have learned a lot with this try-outs! many thanks!
Not sure what you mean by this, but changing the fan level is possible with ventilation#fanLevel channel (but I think you’re aware of that, since it’s in your items file).
I’m still thinking about how to best implement a “restricted” thing configuration (for WHR930 and probably some more). Will try to figure this out at the weekend. However, it would be really helpful if you could go over the channel list (I know, it’s pretty long) and check which channels/datapoints are not available (technically) on your device. Otherwise I would have to guess based on a manual, which seems to be only available in a language I hardly understand (NL).
It took me a while to find some spare time to test the complete binding but i have found it…
I will write my findings in this document…
First of all the WHR930 Basic system is already 10years old and the manufacturer was Stork-air, as the type number is telling, this is the BASIC ventilation system.
Right now the manufacturer is Zehnder and there are probably some modifications done in the past…I have noticed that the menu P1 and P9 doesn’t exist on my system but have read in the new downloaded document from Zehnder that those menu’s are available…
In the tabel you can find the column “Findings” where i have wrote:
Readable => the item can be read (even if this is not available on the WHR930 Basic)
Not Readable => the item can not be read and is also not available on the WHR930 Basic
the column “WHR930 Basic” i have wrote:
not available => not available nore with an option module
not available on WHR930 Basic => not available on the WHR930 Basic but could be available as a option module!
Hi Bart, thanks for your efforts listing the available channels. I tried to work out an appropriate WHR930 thing based on that and what I could figure out from the manual (basically compared menu IDs with the CA350).
Some notes according to your findings:
That the ventilation symbol changes when changing the fan speed is a bit strange, but that shouldn’t be related to the OH binding. I would expect the same behaviour, if you change the fan speed on the original control.
According to the manual, GHX, heater and cookerhood don’t seem to be available options for the WHR930 so I removed them completely (with all related channels)
That freezeTime is always 0h could just mean that temperatures were never low enough to trigger the frost protection (dependent on your location)
That bypassTime stays 0h is strange, but could just mean that it never opens (in summer). Since it apparently works on my device, it could still be that your device uses a different command. Not sure if the actual time value can be read from the original control?
I would consider the P-menus available according to the manual so I kept them
bypassSummer has nothing to do with the actual bypass state. AFAIK it just tells, if the device switched to summer mode, which basically allows the bypass to be activated (this is an internal logic of the device, which is dependent on the ambient temperature over time)
L1/L2Switch just indicate, if according step switches are installed and have AFAIK nothing to do with the current fan level (although the described behaviour is a bit strange)
For the resets you have to send 1 an use a number item
According to the manual the enthaly option should be available, so I kept the channels for the WHR930
According to the manual there are no analog inputs for the WHR930 so I removed those channels
I still have to do some basic testing of the new thing type and update the documentation, but I think I will have a PR ready by tomorrow.
