New Binding: Vallox MV ventilation unit series

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 :slight_smile:
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 :tada:

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.

Thanks for the feedback re. the refactoring. Memory usage should be decreased.

Functionally I didn’t change anything. No command should be ignored (as I remember that were only some “refresh” commands which are fired at startup which I initially ignored).

Honestly I did only test to change the ventilation mode on command side as I didn’t want to switch of my productive system. I’ll do some proper testing.

Hi Björn!

Thanks for this binding. I now use it for my Vallox MV510 and it works great!
Today i find out you also added the “homeairtemptarget (= Zieltemperatur Anwesend)”.

One question: Is it a big deal to make this also work for the other states (Abwesend, Stosslüftung)?
With this feature I could manage some automatic cooling and heating functions, also when I’m not at home (“Abwesend” for example")

Thank you very much for the great job!

Hey Mario,

first of all thanks for your feedback and happy to see more (in this thread) silent readers using it.
Honestly I haven’t had a usecase so far (as you could just update the at home profile … :slight_smile: ).

Anyways no big deal to implement. Code is public so anyone could do it :wink: .
I guess I will manage to implement it over the next weeks.

There you go :slight_smile:

Implementation was quite straight forward.
If your test is successful (mine was) I will create a pull request to get it in the nightlies.

Hallo,
Kann mir einer Behilflich sein? Wie muss ich das Binding installieren?

Hi Björn,

thanks for this awesome work! The binding works great with my ValloPlus 270 MV. I am using the channels for:

  • switching on/off
  • changing the state (Anwesend, Abwesend, Stoßlüftung)
  • displaying temperature and humidity

Do you think it is possible to implement a channel for the next filter exchange date?
If not, it’s not a big deal. Then I will create a caldav calender for this :wink:

Best regards

There is some information on filter exchange available. But as I haven’t used the functionallity the data for my unit is just crap here.

What would you need? Last exchange date or next exchange (is there any calculation?)