Plug-in for Vallox ventilation machines

I have Vallox MV ventilation machine (Vallox ventilation units) which has heat recovery and automatic fan control based on humidity among other features.
The machine has network connection based on websockets. It is possible to read values and send commands through it. One example of using the API with python can be found here

Would it be possible to create plug-in for Vera? For minimum there should be temperatures and humidity shown on the device card and then buttons for selecting on/off, home/away/boost/fireplace modes. And ability to use machine as part of scenes and other automations.
If someone wants to make it, that would be great! Other alternative is that if someone could provide some initial help or template, I could then try to develop it.

I’m not sure Vera has a stable websockets implementation - I never checked this.

But if I was you, I’d probably start with a raspberry PI or similar, put this python script and write a bridge, updating the Vera interface. Since those machines seem to be like a HVAC, you can use any virtual thermostat plug-in. I did something similar with a couple of external devices for WAF and I’m ok with that.

The problem with this kind of devices is that the protocol is proprietary and not so common, so you need to be a developer (and one yourself) in order to write a proper plug-in.

I could do that, but that’s not what I want to do. One of the benefits I see for Vera is to have everything in one box.

For such complex tasks, Luup engine is not the best. Plus, Lua engine is not updated and a couple of things are missing. Good luck with that.

I did some testing during weekend and got proof of concept working. I made small websocket client with lua and then created the simplest plugin to see if it can be run within Vera. All it does for now is to copy values from websocket message to string displayed on device.
The next step would be to make UI looking better, add control functionality and add parameters for user e.g. ip address, poll rate etc.


Great job!
Best thing you can do is to use standard service and device files, using children.

Temperature and humidity are separate devices and you can try to reuse a thermostat to send command.

Some progress with development, I got the UI to satisfactory level and user can set main parameters needed for operation. Still need to attach actions to buttons to make control working.
Attached screenshot for current development version.


As I suggested, reusing existing device templates whenever possible is better, because you can support mobile devices or external integrations (ie imperihome, home assistant, etc).

I would say that “better” in this circumstance only means better in the sense that Vera’s lack of support for their own flexible UI specifications (the static JSON files) may force you to use the existing templates. However, this generally comes at a cost: Vera’s own device templates can be very limiting, and in the screen shot @Vpow shows here, the elegant layout of six pieces of data and four buttons would likely require 7 separate Vera devices, six using existing templates to represent the temperature and humidity values, and one custom for the action buttons that have no analogue on Vera. And the action buttons would still therefore be inaccessible in the mobile applications. That’s not a great step for usability, and much more complex for the plugin.

It is also the case that some of the existing templates have exceptions coded directly in UI7 for particular devices, and the templates don’t even work properly when you attempt to use them for devices that are not part of the native Vera implementation.

So, while your statement is certainly correct, it is only so for the moment, and we should not at all relieve the pressure on Vera to correct this omission. It is, IMO, a huge failure of their mobile apps that do not at least minimally support their own flexible user interface model for devices by presenting and managing the controls designated for display on the dashboard card in the web UI (and triple bonus points for what is usually the “Control” tab). I have to believe it complicates their life as well in adding new devices or device classes/types, for all the same reasons.

I doubt they will invest in the current generation of the engine, but they will instead provide a web only experience in the future. That’s what I see in the market. In the meantime, using a custom template when you could just use standard ones (and standard actions) has an impact and your device could be useless in such circumstances. I have developed very custom templates myself, only to find that it’s impossible to control a device like that. Sure we have to aspire to automate everything and use manual control the less we can, but we know it’s not always possible.
I agree with you, but I was suggesting a more practical solution to a current problem.

That’s understood, and you are absolutely correct. We have to work with what we’ve got today. But even the “standard” device templates can have some pretty annoying little omissions (like units, labels, timestamps, or messages on pretty much any sensor type), or awful hard-coded exceptions for device/manufacturer/model that prevent them from being fully serviceable for any devices other than Vera’s natively-supported ones (I’m looking at you, thermostats). And for devices for which there is no Vera analogue, we’re SOL.

My primary requirement (as stated in first post) was to have one device card which shows machine values together since for this kind of heat exchanger unit it’s necessary to see all values to understand how unit is performing. I don’t mind following standard practices, but if it in this case means spreading all values in different cards then it the requirement is not fulfilled.

It might be that these Vera UI device cards are mainly meant to display single values. There seems to be no way to properly control layout. I first did like in many examples, put variable names (IndoorTemperature, ExhaustTemperature, etc.) into json file and then updated them from lua. This resulted in complicated json file and I still could not get layout easily right. I then took totally different approach considering card kind of line display by creating one variable per row (UIrow1, UIrow2…). In this case there are five rows, row 3 is set empty to match height of four buttons. These UIrown variables are then updated in lua the way I want and no need to touch json again. This approach means that there are then two sets of variables, one for UI (UIrow1, UIrow2, …) and one for “real” (IndoorTemperature, ExhaustTemperature, …). These real variables can be then used in my logic control in normal way (Reactor). Sure, the UI values are visible there as well but can be easily distinguished.

With the above approach I can now fulfill my requirements, one card with all values and possibility to use device in automations. So if I get previous replies right, this now prevents using the device in third party applications which want one value at time. Elaborating the idea, would it be possible to add also these on top of my two variable sets? For example if plugin had a user selectable setting “publish standard data” per variable and plugin would then create value also in standard format. This way there would be best of both worlds; custom card with all information and selected signals available for whoever needs them.

That’s what I was suggesting: a master device showing everything you want, and child devices to implement standard device services and actions. You can get the best of both. Since you have temperature and humidity, Vera needs separate devices for each values. For commands, I will probably try to use thermostats as a base. You can combine different services (I have a wind and rain sensor based on a custom wifi device) and I have two different devices showing their values, and then I also implement security service, in order to simply trip and untrip a device based on fixed thresholds. This simplifies the routines linked to shades, sprinklers and so on.

We’re all thinking alike here, I think.

I think the (current) more “Vera standard” practice is to make monolithic devices so you can have a unified UI for all the components, but @therealdb is correct, a better device architecture is to push the individual components out to separate child devices. It would be a very useful enhancement to the Vera UI to be able to create a unified device interface from parent device and all its children combined. This would also more easily allow a default UI when the device type is not known: the presenter can simply go through the parent and child devices presenting the UI elements it does know (as if they were separate devices, but again, in a more unified presentation). This is the same idea as @Vpow expressed in describing the “one variable per row”–I’m saying it should be more expansive: one device per row.

Basically, too many devices in the Vera world are built around the “is a” thinking rather than the “has a” thinking.

Since @therealdb mentioned thermostats, let’s take that example. The current model in Vera is to try to describe all the capabilities and inconsistencies of all makes and models within one device type (the “is a” approach). This has led to UI7 itself contains device/make/model-specifc exceptions, a horrible breach of encapsulation that has ultimately led to a set of interface objects and controls that are difficult (and in a few instances impossible) to make work properly for a non-Vera device (plugin), even when using all-native types–the UI’s exceptions don’t apply. The overuse of device type as inference data for device capabilities is a flawed premise as a long-term strategy.

Now, let’s imagine the “has a” approach: A thermostat is a container that provides coordinated control over a set of devices: it has a temperature sensor, and by comparing the reading of that to a setpoint is has, it can turn on or off the air handling unit it has. Simplest thermostat: there is a heating unit (on/off), a temperature setpoint, and a temperature sensor (for reading ambient). That would be four devices (the master and three children), each having its own very simple, basic UI. A heating/cooling system would simply have either an additional air handler for cooling, or a combined heating/cooling type as appropriate to its implementation. If the thermostat has separate heating and cooling setpoints, it would have an additional setpoint device. If it had humidity sensing and a humidifer, it would have additional child devices: a humidity sensor and a humidifer control (probably just a binary switch). The mix and match expresses the capabilities of the device, not the device type. Then, if the Vera UI allowed the specification of a unified UI for the thermostat, that would be used, presumably drawing on the child devices. If no custom unified UI was created, however, the Vera UI could still present a unified dashboard card by presenting, piece by piece, the standard UI for each child. Temperature sensors already have a standard UI. Switches already have a standard UI. The focus of building a UI for the device shifts away from specifying inidividual controls to choosing devices as components (higher level).

As we all recognize, you can do the parent-child relationship today. We could start building better devices immediately. The cost of that today, though, as I said earlier, is in the absence of a mechanism for creating (or self-generating) that unified parent-child UI, you force your customer to deal with the myriad devices that the parent-child relationship creates.

But… Vera’s does not need to be the only UI… (cough… hint… @amg0)…

I agree. I dream of a composable card layout as in home assistant, plus the mobile apps support. It’s very flexible right now, but as you said they started to hard code behavior and completely lost the flexibility in mobile apps. That’s unfortunate, since the layout system is in theory designed for this, but they eventually lost it during a very lazy tenure that we all know about. I hope the new platform will be built with that in mind.

The plugin has now progressed to a point that it has all the functionality which was planned and in internal testing all seems to work. Especially thanks to @rigpapa for development tips!

Therefore I will make the plugin available on github:

Anyone interested can have a look and test and send feedback. If nothing major shows up I can then push it to marketplace as well.


Before releasing the plugin I wanted to add possibility to use it as trigger for Vera notifications and scenes. Found out that this can be done by adding eventList2 structure to json file. Found out also like other developers before me that this is not so good way since user might want to trigger with some other condition than provided. Anyways, the events are now there and github updated.

Started looking also how to include those standard services mentioned earlier in this thread, but found out that it is not needed. There are other plugins (VirtualSensor) which can be used to create needed sensors and setup to pull data from my plugin.

BTW, how to setup changelog on top of this thread, can I pin somehow a message or just need to edit the first message?

Version 1.0 is now released in github and sent to MiOS marketplace for approval :partying_face:

Version 1.1 is now released in github and sent to MiOS marketplace for approval.

Version 1.1 (released 2020-01-21)
-Add Fault variable and show FAULTED in UI if the ventilation is in fault state.
-Add Mode variable which tells whether unit is switched off (i.e. standby). UI will show STANDBY and values are not shown.
-Fix communication socket timeout value which could cause plug-in freeze.

Version 1.2 is now released in github and sent to MiOS marketplace for approval.

Version 1.2 (released 2020-03-01)
-Add action to write to any variable. Single or multiple variables can be written in one command.
-Add action to activate programmable Extra profile.
-Add action to switch unit on or off.