New Binding: Vallox MV ventilation unit series

@bjoernbrings Thanks for sharing your binding. I can confirm that org.openhab.binding.valloxonline-2.3.0-SNAPSHOT.jar installed as addon in my openHab 2.2 installation is fully functional with my ValloPlus 270 MV.

Finally I can get rid of that Vallox MX KNX module which never worked properly. This thing is not worth a cent.

1 Like

oooohhhh - finally !
I went from #1278 to #1281. Seems that did the trick as it finally removed all reminiscents of 9.3.15 bundle versions from my machine, now

openhab> bundle:list|grep -i vall
171 │ Active   │  80 │     │ ValloxMV Binding
openhab> list -s -t 0| grep
 77 │ Active   │  30 │ 9.3.21.v20170918       │
openhab> list -s -t 0| grep websock
 91 │ Active   │  30 │ 9.3.21.v20170918       │ org.eclipse.jetty.websocket.api
 92 │ Active   │  30 │ 9.3.21.v20170918       │ org.eclipse.jetty.websocket.common
203 │ Active   │  30 │ 9.3.21.v20170918       │ org.eclipse.jetty.websocket.client
1 Like

Nice, so there seem to be no more problems. So we “just” need someone to review the PR #2990 to get a broader audience … :slight_smile:

Yep, I commented there. But the code shows a conflict, please resolve that one.

I noticed that on binding startup it says to update values every 60 secs although I’ve changed that in the thing from the default value down to 10 secs.

Minimum update interval is limited to 15 sec in order to avoid polling again before results have been evaluated.


In case it is lower than 15 sec it is reset to 60 sec.
Maybe that restriction is a bit to harsh and can fall after I adapted feedback of htreu (he requested to change the whole scheduling).
For what usecase is it helpful to have 10 sec updates? To see the result of changes (maybe I could implement that into the new scheduling, but the change will take me some spare time…).

Yes, to see changes take effect and values to become visible in OH. Always irritating whenever it doesn’t work instantly.

I just changed the ventilation mode via Vallox’ web interface. The binding seems to have noticed that (the output below is that of the new state), but it didn’t update any of the items (nothing in events.log).
Any idea ?

2018-06-18 08:50:38.889 [DEBUG] [g.valloxmv.handler.ValloxMVWebSocket] - Connecting to: ws://
2018-06-18 08:50:38.891 [DEBUG] [g.valloxmv.handler.ValloxMVWebSocket] - Connecting to: ws://
2018-06-18 08:50:38.919 [DEBUG] [g.valloxmv.handler.ValloxMVWebSocket] - Connect: /
2018-06-18 08:50:38.943 [DEBUG] [g.valloxmv.handler.ValloxMVWebSocket] - Got binary message
2018-06-18 08:50:38.948 [DEBUG] [g.valloxmv.handler.ValloxMVWebSocket] - Response length: 1410
2018-06-18 08:50:38.951 [DEBUG] [g.valloxmv.handler.ValloxMVWebSocket] - Fan Speed: 23
2018-06-18 08:50:38.956 [DEBUG] [g.valloxmv.handler.ValloxMVWebSocket] - Status: 2 [State: 1, Boost timer: 0, Fireplace timer: 0]
2018-06-18 08:50:38.958 [DEBUG] [g.valloxmv.handler.ValloxMVWebSocket] - Print final
2018-06-18 08:50:39.938 [DEBUG] [g.valloxmv.handler.ValloxMVWebSocket] - Connect: /
2018-06-18 08:50:39.925 [DEBUG] [g.valloxmv.handler.ValloxMVWebSocket] - WebSocket Closed. Code: 1005
2018-06-18 08:50:39.958 [DEBUG] [g.valloxmv.handler.ValloxMVWebSocket] - Got binary message
2018-06-18 08:50:39.962 [DEBUG] [g.valloxmv.handler.ValloxMVWebSocket] - Response length: 1410
2018-06-18 08:50:39.964 [DEBUG] [g.valloxmv.handler.ValloxMVWebSocket] - Fan Speed: 23
2018-06-18 08:50:39.969 [DEBUG] [g.valloxmv.handler.ValloxMVWebSocket] - Status: 2 [State: 1, Boost timer: 0, Fireplace timer: 0]
2018-06-18 08:50:39.971 [DEBUG] [g.valloxmv.handler.ValloxMVWebSocket] - Print final
2018-06-18 08:50:40.941 [DEBUG] [g.valloxmv.handler.ValloxMVWebSocket] - WebSocket Closed. Code: 1005

Hmm, what did you change? From the log it doesn’t seem like anything has changed.
I tried that while developing the addon myself and didn’t have any problems. State and fan speed did adjust after changing it via web interface.

Hmm, I just noticed my thing does not have any channels any more. Dunno why’s that but for sure explains why my items don’t get updated.
Channels became available again now that I deleted/readded the thing, and guess what, it’s working now.
Sorry for bothering you.

Including your feedback and the feedback from PR #2990.
All values are updated after any channel (eg. state) is changed and code a bit refactored as requested by review.

Can be downloaded here

Thanks. Seems to be working and it feels to be pretty responsive.

Nice. Thanks for the quick feedback. Will push the version to git and then lets hope for the review to continue soon :slight_smile: .

2018-06-24 10:36:36.524 [ERROR] [.valloxmv.internal.ValloxMVWebSocket] - Error: null on every update poll.
Nothing else around that in log and (so far) no impact observed.

Hi Björn,

great job!
Your Binding is now also running on my OpenHAB and works great with my ValloPlus 510 MV!!

I dont’n know if it’s possible but changing the fanspeed via OpenHAB will be a great improvement for the binding end especially for me :slight_smile:

First step I’d like to change the fanspeed depending on humidity in our living room.
But with the new Bosch BME680 sensor (which meassures also air quality (VOCs)) I’ve ordered, it should be possible to change amount of fresh air depending on the air quality in our house.
So that will be a great improvement for my smarthome!!

So if you’ll find time to expand the binding regarding this feature and build a new version, that will be fantastic!!

Many thanks! (If its possible and you’ll do it :slight_smile:)
Best regards

The fan speed cannot be changed (once spoke to a Vallox engineer on that). All you can do is configure percentage values for every mode. Possibly the binding could be changed to allow for dynamically setting the % per mode, but that’s not how the system is supposed to be used (any mode should have a fixed percentage).
Using the binding, you do can set the operation mode (home, away, max). Usually that’s working reasonably well to set to max for a fixed number of minutes whenever your VOC or other sensor signals bad air quality, then back to home mode.

What you can also do is to wire a VOC or humidity sensor directly to the MV and configure it to automatically increase airflow itself.

Hi Markus,

ok, understood…

But, in the “Expert Settings” => “Fan Settings” you can globally change values for “Supply Air” and “Extract Air”.
Changing this two values results in an global, for every operation mode effective adjustment of general air flow.

For example, if there is only my family at home (4 persons) the “home” operation is totally sufficient.
But if there is a party, for example a birthdayparty with round about 20 persons in our hous, I only adjust the Fan-Settings a little bit and every thing is fine. No need to switch repeadly to “max”.

My guess was now, if it may be possible to adjust this fan settings by the binding, a better, smarter adaption of the existing circumstances will be possible.

It will be no problem for me to adjust both of the values seperately…

Best regards,

Hi Andreas,

usecase understood.

Implemented 4 new channels (extrfanbalancebase, suppfanbalancebase, homespeedsetting, homeairtemptarget). The first two should work as you expect, the two further are to manipulate the home profile. All 4 are readable and writeable.

As there seems to be a bug in Paper UI when it comes to change percent values (at least in my test enviroment) these channels are not properly tested by myself. So please take this new version as more beta than the rest of the binding.

Here is the download link.

Happy to get your and others feedback and the final realization of the implementation of the Bosch BME680 sensor. Considering myself of buying one but thinking of how to hide them in our house :slight_smile:

Now since we all can control the MV via the binding, there’s no real need to cable additional sensors to the air unit.
I’ve been using this sensor for two years now, I simply connected it to my openHAB Pi.
Yeah of course you can have vast discussions on sensor placement, but in the end it does not make that much of a difference. Air circulates anyway, and absolute values are not that important. Relative changes rather are.
On hiding, I’ve got a smoke detector hanging below one room air outlet, and the VOC sensor you could possible even place atop (inside in- or outlet).

Still seeing this (running on INFO log level, but note it’s an ERROR) after some runtime. It isn’t there from the start. Debug leftover or sign of a real problem ? (Didn’t notice any, though).