In my quest for stability for my home automation system, I have arrived to a dead end with the vera. The number of absurd implementations in the vera luup engine and as I have dug deeper in particular on the zwave network management has lead me to explore and experiment with a number of alternatives. Paradoxically the zigbee implementation being less mature is actually much more stable on the vera and has rarely caused any luup reloads. The zwave… on the other hand, in UI7 is covered under so many layers of rigid and buggy designs, in its command queue and healing that it is practically unusable for anything beyond being a toy. Someone definitely forgot the old adage of “keep it simple and stupid” or “less is more”.
I was looking at home assistant and found that even home assistant had 2 different implementation of it’s zwave control. It has the “direct” zwave component which is an implementation of the the openzwave library but it also supports an implementation through zwave2mqtt relying on an mqtt bridge. I am now wondering if it was a viable alternative to bridge in the zwave devices into openluup. There is an mqtt client plugin which with some modifications potentially could work. Not sure if anyone has looked into this before…
The MQTT API is certainly well defined. I guess it all hinges on their implementation.
I’ve not tried MQTT myself, but it’s on the “to do” list. Anything I can do to assist with the plugin on openLuup, then let me know. I had toyed with the idea of a built-in MQTT bridge, but the plugin is a fair starting point.
As an aside, the openLuup console is now pretty functional, I just need to work on a native scene trigger mechanism (although the Reactor plugin handles things from that angle.)
I’m interested in this as well. I believe the current Vera MQTT plugin does not support QOS levels, and for me, the ability to receive confirmations is a real benefit of the standard Quality of Service. As well, Home Assistant uses a Bearer authorization token to access its API so openLuup would need to allow this authority header for any calls…
I think the first step is to be able to make openluup not just a client but also as the broker. I will need to dig deeper into this and am not yet sure if I have the skills to do this but definitely will dig.
I have now installed the luamqtt library and will be playing around with it. Since I am running HA on the side I probably will set it up as the broker or may set another broker instance somewhere on my network and will see if I can bridge the zwave devices in.
Got the zwave2mqtt up and running and it has a feature, sending some device information through mqtt making them auto discoverable by Home assistant. Now I am stuck at trying to trying to parse the mqtt messages from zwave2mqtt by something which would be like a verabridge which could then create the child devices to control the zwave devices. I guess that’s where I find my limit. I think I should be able to get the mqtt message out using the luamqtt library tapping into the broker (I used mosquitto)
Here is another project of interest which, with mqtt could potentially be added to openluup
Not so much of a problem per say as it is more of my skill limitation It would be quite a bit of learning for me. I need to learn the mqtt format and data content and see how to translate it into a json format or use the functions already in openluup to create the devices. I am not a coder by training or by trade but don’t mind learning. It will just take time.
I am also trying a variety of things and am looking at the domoticz plugin as an alternative solution in parallel.
I installed snap on my openluup instance (ubuntu VM) so it was literally a one line install.
If you want to test an MQTT device, I would suggest the zwave2mqtt if you have a zwave dongle laying around.
Easy way is through the packaged version
Then you will have the broker and one client which you can set up to link to the broker. They can be on the same machine. Now the next step is to get openluup to talk to it and that is through adding the lua library I linked above. I am building/installing a domoticz instance at the moment to try out and see if I could just use that and the domoticz bridge which could use some additional device type support and work with it. Ultimately the goal is to replace the vera luup engine completely.
It works just the same. It relies on the same zwave library. That’s actually exactly what I am using. I have a couple of them actually. The vera runs on a homeseer stick which I upgraded to the latest 6.81.06.
The zway uzb is still on 6.71.01 and is what I have been using for testing. It is a secondary on my network. I used zway, ozwcp, zwave2mqtt, domoticz, home assistant and even homeseer on it and all worked fine. As you can see, I am testing almost everything and the only constant is openluup.
The UZB from zway is a generic design using the same firmware as the sil labs but with a custom bootloader which contains the license key to lock for the zway software. If you don’t use the zway software it will behave like any other SD3502 USB stick (aka UZB500). I even have a UZB700 on hand which works on almost everything but the vera and zway since it uses the same serial API or close enough to it. It looks like the vera has a driver issue due to its archaic kernel. Humorously my vera emulator seems to work with it. Anyway I digress.
I have not looked at the console for some time. I have been very happy with openluup and have focused my attention on the weakest link of the entire system: the vera. After all the mods I made, I am down to the zwave implementation being the source of all the problems which is why I am looking for another zwave platform to bridge into openluup.
I did something similar (for the native Vera Luup, but I used OpenLuup for testing, so it should work anyway).
There’s no standard template format for a MQTT message, it depends on the device’s implementation. HomeAssistant uses a template-based approach, so you can map a message to a device and to actions:
See MQTT Sensor - Home Assistant to understand how to map other properties, such as battery level, wifi signal strength, last reboot and so on.
I wrote both the broker and the mapping code in C#, but it’s doable in LUA as well. You have to define a set of templates and how to map them to corresponding devices/actions. Since every broker/device will send its set of commands, it’s impossible to hard code the trasformation. I think an approach similar to the one used by HomeAssistant is the best to follow.
As I am finding out the zwave2mqtt still has some ways to go. It is very stable but it is not supporting every kind of zwave devices for discover yet in its messaging to home assistant. As a result a better implementation could be to use the home assistant built in zwave component and use HA as the mqtt client for openluup. Alternatively, I could look at the raw output from zwave2mqtt instead of the “discovery” section it has in beta customized for HA discover.
For now the broker seems to work so it is all about mapping the output in LUA.
So I looked at the console (My last merge dates from the end of July before you added the digest support to the wget since as you know I implemented differently on my fork), and it is pretty awesome. It is tending to want to replace ALTUI? It doesn’t update status real time though.
As for zway, I am finding out that the latest 3.0 version has different problems depending on the platform: the Ubuntu version is rock stable in terms of zwave radio and device handling. The API/remote access/zbw connect however is completely missing. On the rPi version, the API is pretty good with its zbwconnect installation from the Debian repo but… the zwave handling is buggy and tends to drop connection with its serial API with the interface being quite a bit slower. I will definitely keep zway as troubleshooting tool (the zwave expert interface is very nice) but I am not sure it would be a viable device bridge. Did you also notice that it has an MQTT client in its App Store?
There’s an awful lot that AltUI does which this will never do. It is, though, in comparison, very very small, and would be adequate for a minimal installation.
Not yet, although it turns out that I can use the same lazy polling request that AltUI does. Don’t need it for what I use the console for at the moment.
No, I haven’t looked. I’m just going to stand back and wait for you to tell us the best thing to do!
lol… ok I am travelling at the moment. The one thing that would be useful would be an MQTT plugin which would turn into a device bridge somehow. Almost every device interface I see actually have a plugin to talk to a broker. Zway would have to be the linux version since it is the one which is the more stable but I have not figured out how to make the zbwconnect work on it yet so no remote access or API. Homeseer looks really good on the pi but I do not like that it is so windows oriented even on the pi (it runs on mono which is pretty much an emulator). Hubitat I am sure has an MQTT app too and obviously so does home assistant. The latter two support zigbee as well unlike the former 2. Also one thing I don’t like about the openzwave based solutions (Home assistant) is the fact that it has to redo a lot of device query after each reboot before the zwave interface can be used. Granted that they almost never need to be rebooted unlike the vera but it is still an annoyance.
In regards to the plugin, parsing the MQTT messages and creating/updating devices from then as well as the ability to send messages to them will be the task…
It would be quite a bit of learning for me. I need to learn the mqtt format and data content and see how to translate it into a json format or use the functions already in openluup to create the devices. I am not a coder by training or by trade but don’t mind learning. It will just take time.