Seeing
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 
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 )
Best regards
Andreas
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,
Andreas
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
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).
Hi Björn,
thank you very much for the fast implementation of the new channels, however only three of them working as writeable…
Luckily the two, i’ve asked for, working perfectly
The homeairtemptarget only works as readable…
If I change the value in OpenHAB, after a short period of time, the slider jumps back to its old value.
Best regards,
Andreas
Hi Andreas,
happy that it solves your problem. If you need anything else, just let me know
Strange though that the target air temp doesn’t work for you as it was the only one I could test successfully via PaperUI in my test environment …
@mstormi: Strange, that error never appeared in my environment. It could be a timeout (1 sec) between your openHAB and your vallox device, strange though (especially as the error is null …)
Best regards
Björn
The PR has been accepted and the binding should be therefore included in nightly builds and every upcoming release 
3 Likes
The error seems to correlate with the MV unit thing to go offline, then keeps appearing on every poll until I restart the binding (and the thing comes back online). Haven’t seen a reason though when/why the thing goes offline.
Possibly network problems - will you try reconnecting to the MV in such a case ?
Happened again, the thing went offline at 10:12:30. The binding tried to connect at 10:12:15 but finally failed 15 seconds later. That’s obviously the trigger for the Error: Null messages to appear.
Does the binding try reconnecting if it fails to ?
2018-08-12 10:11:43.752 [DEBUG] [.valloxmv.internal.ValloxMVWebSocket] - Connecting to: ws://192.168.178.26:80
2018-08-12 10:11:43.778 [DEBUG] [.valloxmv.internal.ValloxMVWebSocket] - Connect: /192.168.178.26
2018-08-12 10:11:43.788 [DEBUG] [.valloxmv.internal.ValloxMVWebSocket] - Got binary message
2018-08-12 10:11:43.797 [DEBUG] [.valloxmv.internal.ValloxMVWebSocket] - Response length: 1410
2018-08-12 10:11:43.799 [DEBUG] [.valloxmv.internal.ValloxMVWebSocket] - Fan Speed: 48
2018-08-12 10:11:43.890 [DEBUG] [.valloxmv.internal.ValloxMVWebSocket] - Print final
2018-08-12 10:11:44.820 [DEBUG] [.valloxmv.internal.ValloxMVWebSocket] - WebSocket Closed. Code: 1005
2018-08-12 10:12:15.756 [DEBUG] [.valloxmv.internal.ValloxMVWebSocket] - Connecting to: ws://192.168.178.26:80
2018-08-12 10:12:30.762 [DEBUG] [.valloxmv.internal.ValloxMVWebSocket] - Error: Connect Timeout
2018-08-12 10:12:47.759 [ERROR] [.valloxmv.internal.ValloxMVWebSocket] - Error: null
2018-08-12 10:13:17.763 [ERROR] [.valloxmv.internal.ValloxMVWebSocket] - Error: null
On the second occasion, the network to the MV unit was down.
I restarted the binding while the MV unit did not answer to pings, this resulted in
2018-08-12 18:14:42.724 [DEBUG] [ng.valloxmv.internal.ValloxMVHandler] - Start initializing!
2018-08-12 18:14:42.728 [DEBUG] [ng.valloxmv.internal.ValloxMVHandler] - Schedule vallox update every 30 sec
2018-08-12 18:14:42.731 [DEBUG] [ng.valloxmv.internal.ValloxMVHandler] - Connecting to ip: 192.168.178.26
2018-08-12 18:14:42.735 [DEBUG] [.valloxmv.internal.ValloxMVWebSocket] - Connecting to: ws://192.168.178.26:80
2018-08-12 18:14:45.873 [DEBUG] [.valloxmv.internal.ValloxMVWebSocket] - Error: Keine Route zum Zielrechner
2018-08-12 18:16:02.574 [ERROR] [.valloxmv.internal.ValloxMVWebSocket] - Error: null
2018-08-12 18:16:02.580 [ERROR] [.valloxmv.internal.ValloxMVWebSocket] - Error: Destroyed container cannot be restarted
2018-08-12 18:16:32.586 [ERROR] [.valloxmv.internal.ValloxMVWebSocket] - Error: null
2018-08-12 18:17:02.590 [ERROR] [.valloxmv.internal.ValloxMVWebSocket] - Error: null
2018-08-12 18:17:32.592 [ERROR] [.valloxmv.internal.ValloxMVWebSocket] - Error: null
2018-08-12 18:18:02.594 [ERROR] [.valloxmv.internal.ValloxMVWebSocket] - Error: null
…
I came to think it might be a valuable addition if we were able to define the target temperature (that’s a per profile parameter).
The MV unit will automatically select the proper heat exchanger mode (bypass, heat or cold recuperation) depending on the difference of tempinside temperature and target temperature (taken from the current active profile).
So if someone wanted to use the MV for heating/cooling (or at least coordinate it to work well with the heating), we might need to be able to change that value (to e.g. match the target temperature of the heating system).
Does the binding try reconnecting if it fails to ?
New connection should be made with every request
I came to think it might be a valuable addition if we were able to define the target temperature (that’s a per profile parameter)
Already implemented, but only for profile home (Anwesend): homeairtemptarget (= Zieltemperatur Anwesend)
No. Once it’s in that ‘error mode’, it does not. I ain’t seeing any more ‘Connecting to …’ debug output.
Please check that piece of code again.
Btw, can I take the binding from the snapshots ? I think that in order to deliver another version for me or others to test, you would still put them up here so they don’t need to go through review until they work, wouldn’t you ?
Ok, will have a look.
Btw. why does this happen in a fixed environment (of course it could and should therefore be handled properly)
“this” = Connection loss ?
My MV is connected via a WiFi repeater, so there’s a multitude of possible reasons, some of which are even perfectly valid use cases (e.g. I don’t but there’s people to switch off their WiFi at night).
As you said, the binding should properly handle all of those situations.
I used to run the ‘test’ binary available for download here.
Now that I switched to the version included with 2.4 snapshots, I haven’t encountered this any more since.
Don’t know if that’s any different w.r.t. reconnecting, so will keep watching.
There shouldn’t be any difference w.r.t. reconnecting behaviour.
Sorry, for keeping you waiting with some kind of bugfix and good that it doesn’t harm you too much. Have to simulate network disconnects in my test environment and then see where a problem may be.
Current code (incl. recent changes to appear in 2.4.0M7) seems to work well.
But I just tried to switch on/off via item and that didn’t work. You once mentioned commands are artificially ignored. Is that still the case ? I have not seen a benefit in ignoring it (don’t worry you don’t shutoff the binding’s access that way) and would like to use this capability now to temporarily reduce airflow to 0.