This may be submitted for AFHV…
I caught my vera having fun with itself this morning again while already hanging and delaying commands for over 5 minutes. The video shows openluup attempting to change housemode of the vera and failing because the luup engine was waiting and waiting… We are making progress everyday, running away from vera. I only have a few device issues and will be moving the housemode arming/disarming feature into scenes coded in lua in openluup.
I’m no Linux expert, so can’t easily help. I hope someone is able to chip in and sort things out, but in the meantime you could, perhaps, try one of the other two suggested ways of starting it up?
I will give it a shot.
You are trying to auto start openluup at boot using systemd.
I am surprised that you are not seeing any output of the systemctl enable.
Look into the file located in /etc/systemd/system/ called openluup.service. There is likely a mistake in it… most likely on line 10. If you post the content of that file, I can probably help you.
change line 10 to
ExecStop= /usr/bin/curl http://localhost:3480/data_request?id=exit
save and try again.
and what does the status say? It doesn’t look to me that you saved the change.
Yes indeed… it did no survive the reboot… I am SURE I save dit and checked it again.
Done it for the 2nd time:
And now it starts up:
Thank you Rafale!!
So till so far…
According to the manual:
I do see the scenes in aultui now but not “visible locally”? Although not able to see what the scene consists of?
Since al devices are clones… What is the point there?
And is it coorect to see that the “rooms” are not synced from Vera?
So up untill so far… what is the benefit of having altui “not” on Vera?
Edit: it feels like in the analogy of having Home Assistant and the Vera plugin, this is just another “viewer” with additional apps from the app store which can be used also as a “heart” in you automation but having Vera devices as zwave? just as if like one could use home assistant as the heart but with another zwave provider? Correct?
The idea is to use a very stable environment to run your code and leave the Vera as a zwave hub only. I have not completely offloaded my Vera because after all it’s stable (well, apart from the same zwave tardyness and company), but I’ll probably do, since I don’t like at the moment the new Linux fw and I want to protect the hours I invested in my setup. Others are doing this because they have major problems with zwave.
Pages 15 and 16 in the documentation have a pretty full explanation.
So, really, these types of scenes are not clones of the Vera scenes, but merely ways to trigger them remotely.
And also
VeraBridge also has an action GetVeraScenes which creates temporary local copies of Vera scenes as an aid in migrating automation to openLuup.
To make a scene permanent, use the ‘Copy’ button on the Scene and it will create a new scene, with a low scene number, called 'Clone of XXX’. Don’t forget to delete the original scene on Vera when you’re ready to use the new openLuup one.
These two mechanisms should give you the tools to migrate gradually from scenes on Vera to scene on openLuup.
This is really a caveat for plugin developers, but shouldn’t really impact an ordinary user. It is, in fact, a good motto for any device…management of their variables should be done by the associate implementation code through provided actions.
Remember our earlier discussion where you asked why not use HA instead of openluup?
You could and many of what you said is the whole point. You can seemlessly port your scenes to openluup with just a very easy device number change, cloning the vera’s device data structure.
For Home Assistant you would have to rewrite everything and relearn a new programming language and data structure. Some other people here have used Node-red as well which is yet another platform.
The whole point is to mimic the vera so that plugins and scenes can be reused and you can remove the burden from the overtaxed and unstable vera and eventually migrate away from it if so desired.
Update on Zway status:
-moved all my Alexa calls over to the zway bridged devices. The HomeKit ones will move on their own.
-Bridged devices:
143 nodes total.
My vera goes down for good tomorrow… Though the vera plugins, scenes and logic will live (and thrive) through openLuup. Could not have made it work without @akbooer. 
Okay, next thing… manual and live how to and your phone number for support 
I will be “vera-less” today too 
openLuup+zway!
Pretty sure such a post would get deleted based on the current track record…
Write it on a GitHub doc, and post a link here
Yes, I think if @akbooer he needs my help to write the readme.md, I could do that of the GitHub repo.
I’m also open to write some doc about how to use the RaZ+ser2net+socat to have a remote controller and having all the logic into a virtual machine!
Looks like everything is fixed now. I managed to reconfigure the couple of devices needed for Z-way and made the final edits to the bridge to make them all work. No turning back at this point.
A lot of enhancements vs Vera. I am able to now set my leviton controller LEDs in one zwave packet Vs one LED at a time on the vera. No “Got Can” nonsense. I have full visibility of the job queue and am able to see how they are (correctly) prioritized. No weird hangups or delays. No waiting to death caused by NONCE_Get flooding. No luup reloads.
All of the cloud craziness of “controller online/offline”, missing backups, spamming firmware pages, risk of bricking the device… all gone.
The risk now is that it works so well that over time I will forget how I made it work… 
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules
