I’ve created a new Binding for my Vallox MV Series and wanted to share it.
I know that there is already a binding-PR out there for other (older(?)) Vallox machines (and a wish by @mstormi to support the MV series as well). But as there where quite some differences I was not able to merge it. Maybe a later project (maybe with support of @SuperOok) .
Hope it works for you as good as it does for me (with my Vallox MV 350).
I have only incorporated those channels that I found usefull. A full list of available fields with example values are included in reademe.
Bug Reports and Data requrements with use cases welcome.
I have a feature request that would help us to integrate it even more in our smart home:
In case it’s really cold outside, we shutdown/disable our Vallox via “MyVallox” UI. Would it be possible to support this also in this binding?
It would allow us to shut down the Vallox depending on the outside temperature.
Nice to hear that it work for other MVs as well.
I was instructed to not switch the MV off due to powder and tightness of the building so I have not included this feature before. Nevertheless as you want to use it -> included . On/Off channel is now writeable.
Download file has been updated (link is the same as before).
Btw: How big is your building? As I asked for a bigger MV I was told its useless for a one family household having something bigger than 350 MV.
Wow this was very fast, thank you very much!
It’s working smoothly on my end
Yes, we have a rather big house. It also contains a small flat for further use. That’s why we have a bigger Vallox.
They also told to me to let it running. But they also said to switch if off for some hours is not a problem.
I’ve done some investigations regarding performance. I’m using openhabian.
Over time the number of “WebSocketClient@xxx-scheduler” threads is increasing. On my system there are about 2000 in “java.lang.Thread.State: WAITING” since yesterday. Could this be related to the Vallox Binding?
Here one of the threads:
“WebSocketClient@9847646-scheduler” - Thread t@41986
java.lang.Thread.State: TIMED_WAITING
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <6ffadf> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Locked ownable synchronizers:
- None
And here two other threads (due to them I think I could be related to the vallox binding):
“WebSocketClient@32683688-scheduler” - Thread t@42240
java.lang.Thread.State: TIMED_WAITING
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <192e7d8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Locked ownable synchronizers:
- None
“WebSocketClient@32683688-42238” - Thread t@42238
java.lang.Thread.State: TIMED_WAITING
at java.lang.Object.wait(Native Method)
- waiting on <1e42379> (a java.lang.Thread)
at java.lang.Thread.join(Thread.java:1260)
at org.eclipse.jetty.util.thread.QueuedThreadPool.doStop(QueuedThreadPool.java:141)
at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
- locked <3821e> (a java.lang.Object)
at org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:142)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:160)
at org.eclipse.jetty.websocket.client.WebSocketClient.doStop(WebSocketClient.java:288)
at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
- locked (a java.lang.Object)
at org.openhab.binding.valloxonline.handler.ValloxOnlineWebSocket.close(ValloxOnlineWebSocket.java:82)
at org.openhab.binding.valloxonline.handler.ValloxOnlineWebSocket$ValloxOnlineWebSocketListener.onClose(ValloxOnlineWebSocket.java:350)
at sun.reflect.GeneratedMethodAccessor281.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.eclipse.jetty.websocket.common.events.annotated.CallableMethod.call(CallableMethod.java:71)
at org.eclipse.jetty.websocket.common.events.annotated.OptionalSessionCallableMethod.call(OptionalSessionCallableMethod.java:72)
at org.eclipse.jetty.websocket.common.events.JettyAnnotatedEventDriver.onClose(JettyAnnotatedEventDriver.java:139)
at org.eclipse.jetty.websocket.common.WebSocketSession.notifyClose(WebSocketSession.java:414)
at org.eclipse.jetty.websocket.common.WebSocketSession.onConnectionStateChange(WebSocketSession.java:445)
at org.eclipse.jetty.websocket.common.io.IOState.notifyStateListeners(IOState.java:184)
at org.eclipse.jetty.websocket.common.io.IOState.onAbnormalClose(IOState.java:219)
at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection$OnCloseLocalCallback.onLocalClose(AbstractWebSocketConnection.java:165)
at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection$OnCloseLocalCallback.writeSuccess(AbstractWebSocketConnection.java:155)
at org.eclipse.jetty.websocket.common.io.FrameFlusher.notifyCallbackSuccess(FrameFlusher.java:407)
at org.eclipse.jetty.websocket.common.io.FrameFlusher$Flusher.succeedEntries(FrameFlusher.java:242)
at org.eclipse.jetty.websocket.common.io.FrameFlusher$Flusher.succeeded(FrameFlusher.java:232)
at org.eclipse.jetty.io.WriteFlusher.write(WriteFlusher.java:332)
at org.eclipse.jetty.io.AbstractEndPoint.write(AbstractEndPoint.java:147)
at org.eclipse.jetty.websocket.common.io.FrameFlusher$Flusher.flush(FrameFlusher.java:153)
at org.eclipse.jetty.websocket.common.io.FrameFlusher$Flusher.process(FrameFlusher.java:217)
at org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:241)
at org.eclipse.jetty.util.IteratingCallback.iterate(IteratingCallback.java:224)
at org.eclipse.jetty.websocket.common.io.FrameFlusher.enqueue(FrameFlusher.java:382)
at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.outgoingFrame(AbstractWebSocketConnection.java:614)
at org.eclipse.jetty.websocket.client.io.WebSocketClientConnection.outgoingFrame(WebSocketClientConnection.java:85)
at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onConnectionStateChange(AbstractWebSocketConnection.java:489)
at org.eclipse.jetty.websocket.common.io.IOState.notifyStateListeners(IOState.java:184)
at org.eclipse.jetty.websocket.common.io.IOState.onCloseRemote(IOState.java:373)
at org.eclipse.jetty.websocket.common.events.AbstractEventDriver.incomingFrame(AbstractEventDriver.java:121)
at org.eclipse.jetty.websocket.common.WebSocketSession.incomingFrame(WebSocketSession.java:376)
at org.eclipse.jetty.websocket.common.extensions.ExtensionStack.incomingFrame(ExtensionStack.java:220)
at org.eclipse.jetty.websocket.common.Parser.notifyFrame(Parser.java:220)
at org.eclipse.jetty.websocket.common.Parser.parse(Parser.java:256)
at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.readParse(AbstractWebSocketConnection.java:679)
at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onFillable(AbstractWebSocketConnection.java:511)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.lang.Thread.run(Thread.java:748)
I have 2064.
I’m using openHAB 2.2.0-1 (Release Build).
Here what I’ve found in the logs, two days ago:
2018-01-01 16:18:27.889 [ERROR] [oxonline.handler.ValloxOnlineHandler] - Error: unable to create new native thread
I have updated one line in source code which could be the reason for a memory leak.
Debugging didn’t show anything. On my testserver there are 3 long lasting threads which open from time to time sub threads which get closed within a minute.
Please give it a try. Download link stays the same, content has been updated.
The threads are gone now but there still seems to be an memory leak on my end. I’ve to restart openhab every two days.
I’ve created a memory dump and there are 2176 objects of “org.openhab.binding.valloxonline.handler.ValloxOnlineWebSocket$ValloxOnlineWebSocketListener”:
Good hint. I tried to modify something in the way I close sockets.
After two hours (15 sec polling and some 10 changes to status) I had according to VisualVM 18 Websocket threads (most of them parked) and 2 ValloxOnlineWebSocketListener.
As stated in private communication, same for me (no threads but a smallish remaining leak).
Just updated to your most current fixed version, so let’s wait & see.
Currently I’ve some issues with the stability of my openhabian, it freezes from time to time (and I must restart the raspberry pi) but I don’t know why …
Anyway, the good news are this seems not to be related to your binding. But due to this issues I’m not able to test the Vallox binding over a longer period of time.
how can I update the Ventilation State by rule? Somehow it doesn’t work. I want to send a Control command (specific ventialtion state, e.g. 4) via the loxone binding to openhab and then via this binding to my vallox.
The states in the control panel of openhab are synced but my vallox doesn’t change the state until I confirm the state in the control panel (green hook).
Anybody who knows how to “skip” / automate this step?
You need to setup a rule.
Changing vent state is as simple as using item.sendCommand(4) in the rule with the item being mapped to the “state” channel.
There’s no such thing as “confirming”. You either use sendCommand from within rules, or you interactively use the UI (which one are you using, BasicUI ? What green hook do you talk about?)
Sorry, newbie here. I seem to have problems installing the addon.
I tried copying the jar file to the /usr/share/openhab2/addons directory. However, I cannot find the add-on in Paper-ui, to add a thing for the vallox device. Any help would be greatly appreciated.
) .
, Thanks!
. On/Off channel is now writeable.
