After much preparation, I just made the jump:
wiped my vera’s zwave chip (reset zwave network on the vera)
restored the networks data to the zwave.me uzb so that the uzb can be node #1
reconnected my uzb to the vera and re-established the serial port over up bridge
started my z-way-server on which I swapped info from nodes 1 and the former node where the uzb was.
reloaded openluup and voila… I am vera-less for zwave.
So why and what is lefton vera unit?
…but, to be clear, still very much in the Luup world, with all of the advantages but none of the disadvantages.
I’m starting to think that, when they will eventually abandon the luup engine, there will be people (like me, probably) making the same jump and still make it living, thanks to your wonderful work, @akbooer.
We’re probably be some sort of retro-homeautomakers, speaking of the good ol’ days, while everything around us will probably be wi-fi and cloud-only…
Correct me if I’m wrong, but you’re using UZB as the antenna, plus the Vera ZWave serial lib (to avoid the Zway license cost and use the internal one), and pushing via HTTP the serial API to another machine. Am I correct?
I’m starting to think about the possibility to make a similar route, but running openloop directly on the Vera itself. It must be compatible, I guess, and we can avoid the Zwave stuck this way. Can you please elaborate more? Thanks.
So… quick update on this and I am going to share status on the bridge:
It works quite well, very well even for sending commands through zway, any type of commands, supported and unsupported devices and command classes.
On the flip side I ran into limitations of using the vDev API (SmartHomeUI layer) with it not recognizing command classes or trying to be too smart at deciding which command class to connect to which virtual device (vDev) so reading back for some devices has been a challenge. @akbooer is working on moving to poll from the lower level ZwaveAPI (Zway actually has 4 different APIs!) which will address these problems.
To answer your question, I am using a UZB for which I bought a license for z-way. It came to be cheaper than a vera edge back then and arguably I need some platform to run it on so it maybe a hair more expensive. The UZB is humorously connected to a vera which I nuked (meaning I killed the luup engine and everything MIOS on it, preventing them from loading at boot) and on which I set up ser2net instead to forward the UZB serial signal and the zigbee signal to my VM.
You could potentially run openluup on the vera but I would be worried about the archaic OS on it not having all the dependencies and updated packages needed. Funny that I also noticed that zway has mipsel build… I didn’t try that.
Just a quick update for where I’m going with the help of @akbooer and @rafale77
I’m already having openLuup in a VM running Debian. I will use a raspberry pi as an extender to put either a RaZ hat or a UZB to handle the zwave traffic that I will send over into the VM running openLuup+zway bridge!
So after that, the only thing left in Vera will be the DSC plugin that I’m using on veraplus #2 and veraplus #1 will loose zwave job and will keep zigbee for the moment!
What I still do not understand… what is left on the Vera unit and why there and not somewhere else?
I don’t think that’s an issue. I used to run openLuup on an Arduino Yun board co-processor, and it was running a very basic version of OpenWrt.
For @DesT, he has a plugin and zigbee. For me, I am still testing so indeed I could in the role I described above replace the vera with anything including a raspberry Pi except for the zigbee radio which potentially could be another USB dongle.
That’s good to know. I said this only because I actually had to compile a few things myself for this OpenWRT barrier breaker kernel dated from 2014. I did not try running openluup directly on it though you would have to also bring z-way or some zwave intermediate layer to really replace LuaUPnP.
Have been lookin in to openluup…
Lets say I want to try… can I run/install this in a VM? And where do I start?
A few clicks from the page you were at
Thank you! That looks promising. Assume I am a lua virgin. Reading page 5 of that manual… what do I best choose to get that lua installation and openluup running on? Ubuntu server? And what command set out ouf the 3 do I need? Debian?
I am on ubuntu server but any linux distro would work. It’s a matter of personal preference. ubuntu is pretty ubiquitous so it is a fairly safe bet.
And what command set out ouf the 3 do I need? Debian?
Sorry had to open the link myself to understand your question.
Yes debian ideally. Note that raspbian is also debian based which is why it uses the apt package management as well.
@rafale77 @DesT @akbooer Thanks for all the great info. The picture is becoming a bit more clear now for me. Regarding the DSC plugin, I am also running that on my VeraPlus, giving me access to all the door sensors and smoke alarms. Does the DSC pluging also work in openluup or why are you keeping it on the VeraPlus @DesT?
@mikewop 'cause DSC plugin works half the time in openLuup… the plugin is having a “connection” issue with the DSC that is not stable.
I would need to take some time to troubleshoot it!
Ok some help appreciated… following the manual and the “auto start” part of page 21&22 of the manual. I have double checked all for typos. but keep getting this:
ubuntu@openluup:/etc/cmh-ludl$ sudo systemctl enable openluup.service
ubuntu@openluup:/etc/cmh-ludl$ sudo systemctl start openluup.service
Failed to start openluup.service: Unit openluup.service is not loaded properly: Exec format error.
See system logs and ‘systemctl status openluup.service’ for details.
ubuntu@openluup:/etc/cmh-ludl$ systemctl status openluup.service
● openluup.service - openluup and AltUI Server for Vera
Loaded: error (Reason: Exec format error)
Active: inactive (dead)Mar 07 17:26:15 openluup systemd[1]: /etc/systemd/system/openluup.service:10: Executable path is not absolute: curl http://localhost:3480/data_request?id=exit
Mar 07 16:32:23 openluup systemd[1]: /etc/systemd/system/openluup.service:10: Executable path is not absolute: curl http://localhost:3480/data_request?id=exit
Mar 07 16:34:32 openluup systemd[1]: /etc/systemd/system/openluup.service:10: Executable path is not absolute: curl http://localhost:3480/data_request?id=exit
Mar 07 16:34:47 openluup systemd[1]: /etc/systemd/system/openluup.service:10: Executable path is not absolute: curl http://localhost:3480/data_request?id=exit
Mar 07 16:37:10 openluup systemd[1]: /etc/systemd/system/openluup.service:10: Executable path is not absolute: curl http://localhost:3480/data_request?id=exit
I had the “altui” interface once until the manual says:
Quick update,
Right now, veraplus#1 is running only zigbee and NEST plugin. veraplus#2 only DSC plugin.
Having a raspberry with the zway HAT from zwave.me (razberry) but running ONLY raspbian as I’m sending the serial traffic from zway via network into one virtual machine running Debian with zway/smarthome and another virtual machine for openLuup! (for the moment it’s 2 virtual machine for testing and until smarthome can run on Buster instead of stretch)
So far, zwave network is way faster than with vera (having over 100 zwave node) that give me near 300 node/child on the zwave network.
All the “logic”, I mean scene/trigger/plugin are running in openLuup (like smartswitch. RulesEngine)
While migrating from vera to zway I also found device missing in the zwave network (one of the issue I told to Vera CS since the last 4 months)
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules
