-
Does anyone have a quick way to delete multiple devices without having to do a reload between each delete? I have about 20 child devices to get rid of and it will take forever to delete them all one by one with a reload in between.
-
This is just a note for anyone who wants to delete the duplicate child devices the Vera likes to create. In my pervious experience when I would delete a child device (duplicate or not) the parent device would get deleted too.
What I now have discovered is that if you go into AltUI and clear the value set in the attribute for the child device called id_parent you can simply delete the child device without the parent device getting deleted.
I am unsure if the new FW recently added the ability to delete child devices like this, but now I went from 30+ child devices down to the expected 4. Hope this helps someone out!
-
First I want to say thank you to this group. You have given me ideas and help along the HA path for a long time.
I'm an old Vera user and planning to decouple from MIOS cloud now or after 7.32 but I'm stuck at how to push messages out.
I'm using Reactor and Scenes for Vera native messaging. What's a good solution going forward?Also want to mention that after reading the Decoupling document I have built a NTP GPS server on a Pi3B and enjoyed learning more about Linux along the way. I have it stabilized after learning 100 different ways.
Thanks
-
Anyone installed the new beta f/w on their Vera unit and liking it?
Read https://community.ezlo.com/t/7-32-vera-firmware-beta-release/217060
-
Hello @therealdb , I have updated to the new vera FW and cant seem to get your plugin working. I keep seeing "install jq package" on the device itself and when I reset everything and got a new cookie file I see this in the device's Latest Response variable: ERROR: missing argument for -d /storage/alexa/alexa_remote_control_plain.sh [-d .
I have used the code to reset the cookies, added a new cookie file, added the OTP, updated the plugin (did this first actually) and still cant get it working.
Testing some TTS commands I see this response in my logs:
"Say", {Text="Hello from Vera Alexa", Volume=50, GroupZones="Bar Echo", Repeat = 3}, 632)) <0x6bc41520> 08 03/14/21 10:57:57.179 JobHandler_LuaUPnP::HandleActionRequest device: 632 service: urn:bochicchio-com:serviceId:VeraAlexa1 action: Say <0x6bc41520> 08 03/14/21 10:57:57.179 JobHandler_LuaUPnP::HandleActionRequest argument Repeat=3 <0x6bc41520> 08 03/14/21 10:57:57.179 JobHandler_LuaUPnP::HandleActionRequest argument Text=Hello from Vera Alexa <0x6bc41520> 08 03/14/21 10:57:57.180 JobHandler_LuaUPnP::HandleActionRequest argument GroupZones=Bar Echo <0x6bc41520> 08 03/14/21 10:57:57.180 JobHandler_LuaUPnP::HandleActionRequest argument Volume=50 <0x6bc41520> 50 03/14/21 10:57:57.180 luup_log:632: VeraAlexa[0.9.0@632]:addToQueue: added to queue for 632 <0x6bc41520> 01 03/14/21 10:57:57.181 LuaInterface::CallFunction_Job device 632 function SVeraAlexa1_VeraAlexa1_Say_run failed /etc/cmh-ludl/L_VeraAlexa1.lua:89: bad argument #3 to 'format' (string expected, got nil) <0x6bc41520> 50 03/14/21 10:57:57.181 luup_log:0: ALTUI: Evaluation of lua code returned: nil <0x6bc41520> ``` -
Hello Everyone -
Can someone point me in the proper direction of doing a Vera (Secure) backup?
Specifically, I'm worried about a controller failure and unable to source a new one where I could just use the included backup facilities.
I'm considering staying on Vera a little longer to see what happens with Ezlo (especially around easy migrations).
I know I can manually run backups from the UI but wondering if there's a more "standard" method that would allow me to move to another platform if required. This would require me to pull my (important definition, I feel. This shouldn't be a secret) encryption key off of the Vera as part of the backup - so any pointers there would be helpful as well.
-
I use the ROKU plug-in from Vera's app repository. It seems to constantly add Log entries every 5 seconds or so, to the point where my LuaPnP log is just littered with page-long reports about the status of my Roku TV. My Log is 75% "Roku" status!
The only pertinent setting I see under Advanced > Variables is "PollingEnabled" (default: true) which when set to false does indeed stop the logging altogether. But I fear this also completely stops the plug-in from checking TV status which otherwise would update variables that happen to trigger some of my MSR routines. (More testing needed here...)
But do you guys know of any way -- up to and including editing the D_, I_ or L_ files of the plug-in itself! -- to simply stop or slow a running plug-in from writing to the Log??
Also, is there any harm (other than mild annoyance when I have to review the Log for unrelated things) in allowing Vera to write so vigorously to the Log all day long??
THANKS!
-
I regret my decision to click "Configure Node Right Now" on an otherwise working device (a Fibaro RGBW LED dimmer control) while it was "Off". Doing so seems to have caused all of its "children" devices (RGB(R), RGB(G), etc.) to disappear from my Vera UI, and I have no idea how to get them back.
Meanwhile, the parent device keeps reporting "Device Failed to Configure" (in red)** and cannot be controlled by Vera any longer. Nor do the attached LEDs go "On" in response to other Scenes.
How do I undo this innocent mistake? Restarting the Luup engine and hard-refreshing my browser/UI has not helped.
THANKS!
P.S. What does that button DO!??!
EDIT: Now the affected device reports (in light blue) "Please wait! Getting the manufacturer...", then "Setting special association", etc. Then 8 unnamed devices magically appeared in the affected room...
I am hoping these are good signs? -
Seems as though during my testing of the Vera Mobile app, I set up a couple of Scenes (now deleted) which never worked anyway.
But MSR's "Entities" tab still shows the presence of two waypoints (with Vera ID's like vera>geo_1625761_1) which I have no clue how to delete.
I've searched high and low in the app (Settings, Users, etc.), and can't think of anywhere in the Vera Plus UI to look for these - not even sure what to call 'em - to Delete them.
Any clues?
-
I just peeked into my Vera Plus > User and Account Info > Other Users and much to my astonishment (and horror?) found a little surprise waiting for me, an account called "LinuxTest".
Seems it magically has the highest possible authority ("Account Administrator") within my Vera Plus, along with a contact email of linuxtest@mailinator.com
Does this appear on anyone else's 7.32 (beta firmware) Vera unit?
(In case it matters... no, I've never requested or authorized Customer Support on this unit, at least not in the past 10 years.)
Hmm. - Libra
-
I have a VeraPlus and would like to purchase a second z-wave controler. Is it possible to build a second z-wave network next to an existing z-wave network? Slowly I want to move devices form Vera to the new z-wave network. Is it more advisable to install the second z-wave controller as a slave controler?
-
Updated to 7.32 beta and it made all my Zooz switches act up, finally got everything back to normal except one device. Its a Zooz zen21 switch and prior to updating it had an associations group set on it (was trying to associate two switches, didn't work) and after the update I tried removing the associations but the switch is failing at purging associations.
Before I repair the switch does anyone know of a way to either force an associations purge or get rid of the error?
-
Before I give up completely, and lose my entire mind, can someone please tell me I'm following the correct steps to get the LED of my NodOn Soft Remote configured through Vera?
-
Dusted off my mothballed Vera 1 unit, which I thought was broken -- that's why I bought a Vera Plus a few years ago -- and she's evidently working perfectly.
Haven't attempted any Z-Wave inclusions yet (though the dongle, also surprisingly, appears functional).
ANY REQUESTS? Want any files copied, or for me to perform any experiments using Multi-System Reactor on the Vera 1?
-
I have a Sensative strip that is in Vera twice. Each one has a different Device number and ID. Have tried to delete one and it will not go away. How can I remove one without loosing the other?
-
So, after more than 10 years and 4 Vera's, my vera forum account is suspended.
I think the monkey of the company, called melih is not man enough te have any critic. In the topic about the "great to come app" I responded to the topic (not off topic!) that a subscription can also be seen (financially) as buying a box, run it for 2 years and come to market with a better one (in better wordings).
That means that if you as a company hast a box of 50USD cost, sell it at 250USD would give him a monthly subscription of 200/24=8.33 USD... Users that would last 5 years would pay a monthly of 3.33USD.But... the monkey on the rock has bolded his fists and said: ban him! He just can't take any criticism.
To be honest! I am not even sad! It was a very rough journey with Vera. The journey stopped when Ezlo and the monkey took over the name.
After that it quickly went downhill...
Goodluck all! (except the monkey).
Edit:
Aug 16, 2020 MiOS Application - early Beta enrollment MiOS Application - early Beta enrollment
The topic:
are you serious? would I become a cost? that is, customers who periodically replace the control unit and are happy with the service praise the Vera system and therefore also free advertising but, the new “company” decides to charge less to bind the customer with a subscription … But the genius...
The post:
The point you are missing is:If the hardware would “cost” around 50USD, and you sold it for 250USD, an average life span of 5 years would mean 200/(5×12)=3.33USD per month. Thats how Vera used to do it.
Then release a faster/better “beast” every 2 years gives you 200/(2×12)=8.33USD per month. That’s how vera used to do it.
And that’s how I did it for around 8 years and 4 veras with them untill you bought the company.
This is just a matter of how you look at it and explain it.
I dont frikking care how you do the maths, I only liked a working product and a close user community (like it was).
Now all I see on this forum is a lot of “we are going to” and “we are working on”, “keep them coming guys”. But the reason for ever considering to buy a new vera every 2 years is gone…
No clear migration path, no clear compatibility path and no clear integration path…
That’s why I started to look for alternatives…
-
So ... I am trying to do the following:
Current setup:
Vera Plus (1.7.4955) Zwave only -> HASSIO VM (full control via Vera Integration)Future Target:
HASSIO VM (leveraging zwave.me UZB1 dongle via USB)I have done the following so far:
Updated UZB1 dongle (via RPi SmartHome) to latest 5.39 FirmwareI followed the following steps to try and migrate my existing Z-Wave NW (currently on Vera) onto the UZB1 dongle following the steps listed here:
Problem:
Steps 1-3: went fine (although the dumps are labeled as dongle.6.1.dump.x)
Step 4: went fine and the UZB1 was recognized as it should be (per dmesg)
Step 5: updating the port to /dev/ttyACM0 went fine, although I didn't see any indication of luup reload (or a save button for that matter when updating the port mapping)
Step 6: I did the touch for dongle.restore, but wasn't sure where to trigger a luup reload (I assumed it was Z-Wave Settings > Advanced > Reload Engine). I believe I got an error message when trying to do that step
Step 7: verify dongle.restore.go I don't recall being in the directions when I was going the test, but I rebooted
Post Reboot: None of my previous z-wave devices were listed. I also checked dmesg via ssh and noticed the following items:
[ 4.328000] Unsupported Device! [ 4.328000] Vendor=658 ProdID=200 [ 4.328000] Manufacturer= Product=I saw that item a couple times which almost seems like Vera is blocking the UZB1 or at least complaining about it.
I ended up switching the Z-Wave back to the embedded controller, and restoring configuration from backup.
Any suggestions what I did wrong??
-
Anyone have a way of killing this? Delete plugin? Install files manually? Desperate to get set up on the rpi.
-
Current Hardware: Vera Plus, HA in Synology Docker
Firmware: v.7.0.31
Available SW / HW: Multiple RPi's, Z-Way UZB w/lic, Z-Way Razberry board
ZWave Devices: 30-ish early gen GE/Jasco light switchesIssue: I've gotten myself into a spot that I'm not quite sure how to safely get out of, and I'm hoping someone on this forum can help me. I would ultimately like to get to a point where I'm using Home Assistant in Docker on my Synology as my UI for turning on/off lights, but I've read the "Pyramid" post and am open to other options. I can currently ssh to my Vera Plus, but cannot access the web UI (get a 403).
How I Got Here:
Back in Feb'19, I followed @rafale77's instructions to take my Vera off the grid. At the time, it looks like I was running version 7.0.26. This worked great.
I installed HA in Docker w/socat on my Synology NAS, and things were running perfectly for a long time, but I was forced to upgrade HA in tandem with an upgrade to the iOS app. So, I chose to use a Docker build that already had socat built in.
Then, I saw that there was a new version of firmware for Vera, and decided to upgrade to Firmware v.7.0.31 around Apr'20. This was a mistake in a big way, and I sought help on the new version of the Vera forums, which eventually led me here. I also re-ran @rafale77's mod files on the newer firmware version, and I think I shot myself in the foot there. I knew it was gamble, and take full responsibility. I've learned a lot and have benefitted greatly from his work.
I tried to run the Nuke Vera script, as that sounded exactly what I needed my Vera to do - take commands from HA and nothing else. This seems to be working, but I'm unable to control my network with HA.
Additional things I've done / tried / worry about:
Validated that HA is sending and receiving responses via socat from the Vera in the HA openzwave logs. I see logs that seem to indicate that a message is sent, and a message comes back from the Vera, but lights don't turn on/off. I've clicked the Heal Network, Test, Network, and Soft Reset buttons in the HA UI too.
I purchased a razberry. Then, I ordered a UZB, after seeing this post about migrating, assuming that it was best to try to follow that guide verbatim and not have to exclude / include a bunch of devices. I'm leaning towards completely divorcing myself from Vera.
I'm not 100% sure I have a valid backup of my zwave config. There are no dongle.dump files in /etc/cmh whch may make sense, as I was using after an external drive w/extroot. I do have some in ./mnt/sda2/etc/cmh/. It looks like I've got extra, actually, as it looks like I probably made backup copies some where along the way.
I shutdown the Vera and removed the extroot drive, reversed all of the changes Nuke-Vera made to the init.d start up files, and rebooted. I did this because the migration guide mentions to set the path of the z-way UZB in the UI settings, and I couldn't find how do this over ssh. I also don't know how to backup the zwave config from the CLI and was going to do this via the UI. As mentioned previously, I'm getting a 403 "Access Denied" message. Looking at logs and the config for lighthttpd, I think it is trying to follow some symbolic links that no longer exist, but I'm hoping I can get out of the mess I've made without troubleshooting and solving the HTTPD issues. I think I just need to know how to follow the steps to clone the Vera to the UZB via the CLI?
I found a command online method that allows me to view the zwave keys with hexdump. The keys on the device are different than the keys in on the drive that i was using for extroot, and that concerns me a bit.
If you've made this far, thanks for your time! Does anyone know the best way for me to get myself out of the mess I've got myself into?
All the best,
Michael -
Dear Experts!
In January 2020, I decided to get involved in automation as a complete beginner.
I purchased a Vera Plus device controller.I built the network gradually, at the cost of overcoming no small problems .....
Since I am a beginner I have had a lot of problems.For example: I had 6 multisensors that sometimes got stuck with motion detection (lights stayed on) and also created ghost devices.
I knocked everything out of the system, the system stabilized a lot after that. (many red lines disappeared from luaupnp ....)Over time and with the help of the experts (Eg: AKbooer was a great help to me in netatmo which I thank again) I managed to solve most of the errors.
I only use a reactor to control the logic and execution.
The logical composition of my reactor is not very complicated in my opinion.My DSC alarm (with plugin) controls the house modes, cameras, each room has a separate reactor sensor (18 sensors in total) which control the automatic lighting and shutters.
I tried to improve the conditions and scenes in the reactor to perfection. (don't have executions, delays and reservations at the same time, I record the states with the "time from reactor" group state, just like the motion and opening detections from another sensor.
The situation is that the system does not always work reliably.
I experience Lua recharges at completely unpredictable intervals, about 1-3 per day
times.
Because of this, unfortunately my scenes slip, (or don't happen)
For simple things (tablet charging in) there is usually no problem.However, if I am not at home for several hours and return home, the alarms will turn off, and the luup recharge(90%).
If you approach the afternoon when more times are set in the time reactor then recharging will still occur but not always.For the past 10 months, I feel tired of the constant error search and still not good. I'm starting to doubt Vera's abilities.
Therefore, I would have the following questions:
Are the conditions set in the reactor loaded on the vera without action?
Can the Vera be stable and well-functioning without an unexpected lua reload?
If so, what do I need to add? (I'm a simple user, not a programmer, I don't know lua and linux programming languages and I don't want to learn because of vera)
I don’t want to deal with this too much anymore, so I still spent more on it than I deserve.Is there another controller that works safely and well on the z-wave platform?
In what direction should I move away from the vera, which will not disappoint me?
Have you heard of a controller called comfortclick? (I was now offered this instead of vera)
Thank you in advance for your help.
Krisztian
Instant regret after clicking "Configure Node Right Now" on device
-
I regret my decision to click "Configure Node Right Now" on an otherwise working device (a Fibaro RGBW LED dimmer control) while it was "Off". Doing so seems to have caused all of its "children" devices (RGB(R), RGB(G), etc.) to disappear from my Vera UI, and I have no idea how to get them back.
Meanwhile, the parent device keeps reporting "Device Failed to Configure" (in red)** and cannot be controlled by Vera any longer. Nor do the attached LEDs go "On" in response to other Scenes.
How do I undo this innocent mistake? Restarting the Luup engine and hard-refreshing my browser/UI has not helped.
THANKS!
P.S. What does that button DO!??!
EDIT: Now the affected device reports (in light blue) "Please wait! Getting the manufacturer...", then "Setting special association", etc. Then 8 unnamed devices magically appeared in the affected room...
I am hoping these are good signs? -
UPDATE: Yes, I was a fool. But at least Vera slowly brought each of the child devices back into the UI, albeit with vastly changed Device Numbers. Fortunately, MSR kept track of the old dev# for each, and I was able to systematically go back and update the
idfor each, rename them correctly, place them in appropriate rooms, etc.PHEW! Disaster averted.
-
- Undo = recover from backup so always backup before any configuration step.
- The configuration process is a disaster on the vera because it is much too device specific and because of the insane chattiness of the z-wave network created by its stupid and destructive "maintenance features". A lot of retries and luck are necessary to capture a time window where the messages go through (at least on larger networks and even more so with security class devices). Also the fact that the configuration are unnecessary linearly sequenced makes it restart from scratch every time... Z-way is night and day in all of these respects.
- There is a profound design issue on the vera whereby the term "configuration" confuses parameters stored on the vera and the ones on the device. Other platforms give you a choice to read or write the device parameters on either list... not so on the vera which has the tendency to want to rewrite everything on the device by default according to its device specific configuration which is not always correct.
-
If you're on 7.32, run this:
dbochicchio/vera
LUA Scripts for the eZlo Vera Platform (UI7). Contribute to dbochicchio/vera development by creating an account on GitHub.
-
Many thanks, Gents! A comfort knowing that I am neither the first nor last to spazz in this manner.
-
@librasun said in Instant regret after clicking "Configure Node Right Now" on device:
Many thanks, Gents! Nice believing that I am neither the first nor last to spazz in this manner.
Radical thought, but you could move to Openluup
Then all these problems would vanish...like tears in the rain......
C
-
@catmanv2 said in Instant regret after clicking "Configure Node Right Now" on device:
Radical thought, but you could move to Openluup
Too true! It's time. I've intentionally been putting off the move for years, principally because I struggle to "remain stock" for the sake of other non-tech savvy users.
That mission hasn't paid many dividends, up to and including getting booted from the old Forum despite being in the Top 10 Contributors column, LOL.
Promise I'll give it a try as soon as I'm done beta testing MSR!! (One thing at a time, eh?)
-
Can't speak enough praise of openLuup but you already would expect that. I chuckle these days at my initial reaction to @akbooer's long post about his experience on the vera, introducing openLuup and my dismissive attitude: "another one complaining... I am not seeing these problems (yet), I am sure they are overstated and just take a little more experimenting to make the vera work..." Gosh how wrong was I! I did try though.
openLuup takes all the things done right on the vera, fixes a number of wrongs and demonstrates that the vera platform (lua engine, luup, API, plugin concept) could have been more than viable and scalable. To this day, I still prefer writing my automation and plugins on lua in openLuup over home-assistant (which I am finding horrible at this with all kinds of jinja templating and yaml mix) or in java (I used iobroker for some time) or Groovym the language used by hubitat. -
While I greatly admire the "roll your own" set, I've promised my significant other that -- if I die -- everything Vera and Alexa do to run our home will be maintainable by a normal mortal. Hence my clinging to stock setups, with minimal round trips through IFTTT (gone from the mix now), Stringify (dead), Google Scripts, etc. Would not even touch PLEG due to this philosophy!
It was not until I discovered Reactor that I began delving into fancy automations, still click-and-play, very little coding. And it was not until I realized what ezlo's endgame TRULY was (despite 1-2 years of obfuscation, deception and outright lies) that I began "thinking outside the box" and planning a move toward another controller. (FYI, owing to your recommendations, Hubitat is at the top of my list, with the ISY994i close behind!)
And it wasn't until @toggledbits came along with MSR that the door began to really open, to where I will feel comfortable jumping ship entirely. Whatever I do, it's gotta have significantly higher reliability and WAF than ever before. That's why I haven't left the house in nearly 3 weeks of testing MSR down to the bare metal; it's my lifeline of the future. All bets are in!
If OpenLuup helps me oil the hinges of that door, all the better!!
P.S. I'm not saying I want ezlo to fail; if they achieve even 80% of what has been promised, theirs too will be controllers well worth considering (and I already own two of them!). But that is clearly years down the road, if ever, and I ain't got time for that!!
-
@librasun I totally understand your philosophy and tried to stick with stock setups as well but who has the time and patient to wait for Ezlo to accomplish a fraction of what is available already today.
That said, I'm so thrilled I started migrating to openLuup and MSR, best decision ever! Sure it's not going to be easy for anyone to take over this setup but the possibilities and stability is totally worth it.@akbooer and @toggledbits you guys rock!!
Homebridge is the key for Apple devices regarding manual control for WAF.
-
@librasun said in Instant regret after clicking "Configure Node Right Now" on device:
While I greatly admire the "roll your own" set, I've promised my significant other that -- if I die -- everything Vera and Alexa do to run our home will be maintainable by a normal mortal
Just think about how a normal mortal would look at this most recent experience.......
C
-
@librasun said in Instant regret after clicking "Configure Node Right Now" on device:
everything Vera and Alexa do to run our home will be maintainable by a normal mortal.
I also applaud the sentiment, but rather doubt this.
Whilst I'm (somewhat) invested in openLuup, I've begun simplifying and standardizing my HA environment, gradually weeding out Vera (not quite done yet), RPi (in favour of a Synology NAS), Zwave (in favour of Philips Hue and Sheelies.) Even then, I have no doubt that the final result will be for my survivor to call an electrician and rip everything out.
-
@akbooer said in Instant regret after clicking "Configure Node Right Now" on device:
@librasun said in Instant regret after clicking "Configure Node Right Now" on device:
everything Vera and Alexa do to run our home will be maintainable by a normal mortal.
I also applaud the sentiment, but rather doubt this.
Whilst I'm (somewhat) invested in openLuup, I've begun simplifying and standardizing my HA environment, gradually weeding out Vera (not quite done yet), RPi (in favour of a Synology NAS), Zwave (in favour of Philips Hue and Sheelies.) Even then, I have no doubt that the final result will be for my survivor to call an electrician and rip everything out.
Only when it stops working, though. Which of course it will.
But ours, right now, just works. So much so that on the very few occasions Alexa stops, I'm damned if I can recall how to control it manually.
Worse, even though I documented all my Reactors with notes in every instance, I still have to reverse engineer what happens when I do something different.C
-
Without openLuup and the excellent Ezlo Bridge, my Ezlo Plus would just annoy me and make me want to go somewhere else, as they kind of hinted with the ban raid.
Big thanks to @mrFarmer ! for making use of the very beta product they shipped. -
@crille said in Instant regret after clicking "Configure Node Right Now" on device:
Without openLuup and the excellent Ezlo Bridge, my Ezlo Plus would just annoy me and make me want to go somewhere else, as they kind of hinted with the ban raid.
Big thanks to @mrFarmer ! for making use of the very beta product they shipped.Indeed, The capability to support all the wireless stacks and offering an API to control the stack should have been a day 0 pre-release requirement. I am glad they got there and kind of wished they stuck with the vera API to ease the transition but certainly @mrFarmer 's work made up for it.
@librasun said in Instant regret after clicking "Configure Node Right Now" on device:
While I greatly admire the "roll your own" set, I've promised my significant other that -- if I die -- everything Vera and Alexa do to run our home will be maintainable by a normal mortal. Hence my clinging to stock setups, with minimal round trips through IFTTT (gone from the mix now), Stringify (dead), Google Scripts, etc. Would not even touch PLEG due to this philosophy!
This is the philosophy that most people who migrated away to hubitat have had in mind. Prioritizing ease of management over capability and flexibility and even then, some learning curve is required. Just keep in mind though that any cloud dependency will defeat that in a whiff. Anytime you will have a cloud dependent integration (IFTTT, google, ecobee, alexa) you are exposing yourself to the life and decision of that company. Any time they change something on their cloud or if they go bankrupt or get bought, you will need a great amount of expertise to make the changes/maintenance if that is even possible. I took this goal to an extreme where I am no longer afraid of going through very complex setup so long as it works without maintenance. The only way to do this is to make everything run independent from the cloud. The only maintenance which would be required on my setup would be to change batteries... Everything else just self starts and syncs up without anything ever being exposed to cloud server disruptions, changes or quirks all within a single machine: My QNAP NAS. Near 0 maintenance required...
None of my cameras are connected to the cloud, no image processing, no voice commands recording, No TTS commands... Absolutely nothing. All is processed within the house and all the data remains here in one machine which turns on with the push of a button. And indeed, everything runs a lot faster too.
So it is a trade off of short term ease of setup and maintenance (maybe) with lower level of capability vs. much more capable setup with a larger amount of setup work upfront resulting in nearly no maintenance... I understand the experience with the vera though which can be traumatizing and leading to the thought that complex implementation leads to complex maintenance. This doesn't have to be true. In most cases, it is actually the opposite. It is only true when they break all the time... vera style.
