Comfoair: Change fan speed on WHR930

Hi,

I have installed the Comfoair binding version 3.1.0M1 on Openhab 3.1.0M1 and connected serial to a WHR930 Device.
When reading some values works great. Also reading out the actual fan speed and the speed setpoints for level 1, 2 and 3 works fine. But when is want to change the speed setpoints for level 1, 2 or 3 the binding report an error

“java.lang.ArrayIndexOutOfBoundsException: arraycopy: last source index 13 out of bounds for int[10]”

I want to change the speed from 40% to 50% so i write the value 50 to the configured item?
@boehan: Is this possible with the binding to change the fan speed and how to get this working?

Hi Bart,
seems to be a bug in the binding. I will try to reproduce the issue and fix the cause as soon as possible.

Many thanks to look at this issue. If i can help with testing. Please let me know.
Kind regards.

@BartVdP could you give some more information, which channel you are trying to send the command to? Tried with ventilation#fanIn3 (which would be the highest value in the command) and that worked fine for me. Could you possibly also provide a debug log when changing?

I think you try to write directly to the fanInPercent and fanOutPercent.
When you want to change the speed you need to use fanInX. X is a number depending on the level. Please use the userguide of your Comfo air to see which speed is in which level possible.

Sorry for this late answer but had some day’s off. The WHR930 doesn’t have level 3. It only has level 0 (away), level 1 and level 2. Tried to change the speeds on this three levels and all with the same error…
The configured items are:

Number	comfoairFanIn0			"Fan In Level 0 [%d %%]"			<fan_in>		(ComfoAir)			{channel="comfoair:comfoair:myComfoAir:ventilation#fanIn0"}
Number	comfoairFanIn1			"Fan In Level 1 [%d %%]"			<fan_in>		(ComfoAir)			{channel="comfoair:comfoair:myComfoAir:ventilation#fanIn1"}
Number	comfoairFanIn2			"Fan In Level 2 [%d %%]"			<fan_in>		(ComfoAir)			{channel="comfoair:comfoair:myComfoAir:ventilation#fanIn2"}

In the event log file you can see that the item is changing form 70% to 80% but gets back to its initial setpoint which is 70%?

2021-03-16 11:08:08.409 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'comfoairFanIn1' received command 80
2021-03-16 11:08:08.411 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'comfoairFanIn1' predicted to become 80
2021-03-16 11:08:08.415 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'comfoairFanIn1' changed from 70 to 80
2021-03-16 11:08:35.153 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'comfoairFanOutRPM' changed from 1286 to 1273
2021-03-16 11:08:35.355 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'comfoairFanInRPM' changed from 1307 to 1339
2021-03-16 11:08:36.160 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'comfoairFanIn1' changed from 80 to 70

In the openhab log file i get

2021-03-16 11:08:08.978 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.comfoair.internal.ComfoAirHandler@ebe2a6f': arraycopy: last source index 13 out of bounds for int[10]
java.lang.ArrayIndexOutOfBoundsException: arraycopy: last source index 13 out of bounds for int[10]
	at java.lang.System.arraycopy(Native Method) ~[?:?]
	at org.openhab.binding.comfoair.internal.ComfoAirSerialConnector.buildRequestData(ComfoAirSerialConnector.java:514) ~[?:?]
	at org.openhab.binding.comfoair.internal.ComfoAirSerialConnector.sendCommand(ComfoAirSerialConnector.java:175) ~[?:?]
	at org.openhab.binding.comfoair.internal.ComfoAirHandler.sendCommand(ComfoAirHandler.java:264) ~[?:?]
	at org.openhab.binding.comfoair.internal.ComfoAirHandler.handleCommand(ComfoAirHandler.java:85) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
	at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
	at org.openhab.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
	at com.sun.proxy.$Proxy490.handleCommand(Unknown Source) [?:?]
	at org.openhab.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:80) [bundleFile:?]
	at org.openhab.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
	at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
	at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:834) [?:?]

Oh, didn’t know that there are device types that have such a different configuration (and thus a deviation in the protocol). However, since the binding seems to work so far, I think this should be possible to be fixed relatively easy in the code. I couldn’t find any protocol description for the WHR930 so I would need a debug log from you when you try to change the value.
To enable debug logging for the binding, login to the openHAB console and use the following command:

log:set DEBUG org.openhab.binding.comfoair

(use DEFAULT instead of DEBUG to set back to default after capturing the log)

Hi,

Yes, the binding works fine on the WHR930. Good job!
Instead of using the DEBUG command I tried the TRACE command because in the debug only the pervious error came up. I also included the protocol manual which i have downloaded some year ago in case you didn’t already have :wink:
Hope you can work this out so I can regulate the fan speed in case the CO2 level raises to much…

If i can do some things more just let me know!

Comfoair.log (7.4 KB)
Protokollbeschreibung_ComfoAir.pdf (172.7 KB)

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.

@BartVdP one more question: did you ever use the OH1 binding? Did it work there?

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

In attach the trace of this issue.

Many thanks in advance!

Comfoair-filterreset.log (27.5 KB)

@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

Hi Hans,

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)

Hi Hans,

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! :+1:
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?

Hi Hans, In attach the requested 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!

Log_Comfoair.log (115.3 KB)

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.

@BartVdP I uploaded a new version with some more detailed logging. A TRACE log + OH event.log would be helpful for debugging.

Hi Hans,

Below you can find the requested log’s. I also included my items definition file for completeness :wink:
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”.

Comfoair_Eventlog20210410_FanIn.log (2.4 KB) Comfoair_Eventlog20210410_FanOut.log (2.7 KB) Comfoair_log20210410_FanIn.log (88.0 KB) Comfoair_log20210410_FanOut_FilterReset.log (162.5 KB) Comfoair_items.txt (5.0 KB)