Vera PushOver notification with image

[LibraSun]

@catmanv2 said in Vera firmware 7.32 beta:

What happens if you change modes manually?

C

Never a problem, but I will certainly investigate. For instance, I have MSR Rules in place which (after a brief pause) cause my ecobee thermostat to match its mode to the new House Mode, and vice versa. Very thoroughly tested, but never 100% above suspicion.

[toggledbits]

You might also try using 3.9 stable branch Reactor. It's got some different job control features specifically for 7.32. I've run that combination on my house Vera for months now and have few reloads.

[Pabla]

@toggledbits if I have reactor installed from the marketplace can I grab the files from GitHub and upload those to update? I did this once I remember and everything got thrown out of whack

[toggledbits]

That works fine. Just follow the procedure:

1. Go to the stable branch for the project on Github: https://github.com/toggledbits/Reactor/tree/stable
2. Click the green "Code" button and choose "Download ZIP". Save the ZIP file to your local HD.
3. Unzip the file.
4. Open the Vera UI and go to Apps > Develop apps > Luup files
5. Select all of the unzipped files (not the folder, the files as a group) and drag them to the "Upload" button in the UI.

The system will reload when the upload completes. You'll want to hard-refresh your browser as usual.

[LibraSun]

Following up since I made the above changes last week, and am happy to report NOT A SINGLE LUUP ENGINE RESTART YET!
Having minimal plug-ins installed and periodically rebooting Vera by power cycling seems to be a wise regimen to follow. I'm past thinking the "random restart" problem was induced by House Mode changes and/or too many commands issued at once, etc.

[toggledbits]

Yeah, I think I know where their locking bug is that causes deadlocks.

[LibraSun]

Guy on the old forum says 7.32 coming out of beta, posted a download link, but company strangely mum about it.

[Pabla]

IMO this beta needs a few more releases before general release but whatever. 7.31 for me is still the best build

[tunnus]

Beta discussion (or more of a silence) doesn't look very promising... and as a banned user cannot participate if I wanted to.

They don't seem to publish a production release, so I guess I have to bite the bullet and go for the latest beta, but the link given (Vera Plus) in the first post does not work, so anyone know from where to download?

EDIT: Found beta 4, which seems to be the latest one. I guess this is as solid as Vera can ever be?

[toggledbits]

@tunnus said in Vera firmware 7.32 beta:

. I guess this is as solid as Vera can ever be?

I think we have to assume that's the case. Clearly, they are overrun with their other efforts. They are now over three years since acquisition, on their way to four, and as we all have experienced, the last 20% of any project can take 80% of the time and effort. Worse, by my product math, if they have 80% of the project 80% complete, they've done 64% of the work necessary (0.8 x 0.8), so I predict mid-2023. I think they're spread so thin trying to get everything done that they claim they will have that there's no bandwidth for Vera firmware on their radar, but if it's going to take that long for the new firmware to be feature complete and stable enough (regardless of how they describe the release... alpha, beta, candidate, etc... customers will decide what it is, as they are doing right now)., they may be forced into the position of doing another release of Vera firmware to try to preserve that customer base. If they don't hold the Vera customer base and get a significant migration of customers, the purchase of Vera was an unnecessary waste.

Everything I have left on Vera now runs on 7.32, and it's pretty stable. Still deadlocks, still reloads, still Vera. If you go to 7.32 and you're using the Reactor plugin for Vera, I recommend updating Reactor to 3.9, which is on Github, not in the App Marketplace. Updates for my other plugins are (and always have been) on Github as well. Decoupling does appear to make it more stable.

[therealdb]

@toggledbits I 100% agree. My system is stable, and I've since removed 90% of my scenes to further improve it. I'm in the middle of choosing to completely migrate to Home Assistant (and start from scratch with the logic, a tough exercise, but probably a better investment), to MSR (but I want to write code :D), or to my own home-grown solution (which already runs 20% of my logic, TTS, weather, MQTT and many more things). We'll see.

I will not update my plug-ins and I will remove them from the app store anyway. It's sad, but I think eZlo will not build a viable solution for us enthusiasts and probably just focus on very simplicists users. Otherwise, I'm not explaining why, after 2+ years of development, the features offered by their hubs are very, very, very basic.

[wmarcolin]

@toggledbits and @therealdb

As I already commented in the other forum, it is clear that there is no more effort to fix FW problems, we are relegated to survive with what we have, and that is that.

For more than a year I have been frequenting these user forums, and I have tried to do everything that I understood to be good to reduce the tasks of the Vera hub, I no longer use, for example, Reactor and migrated everything to MSR, an excellent measure. I don't have any scene anymore, everything is in MSR.

Another very important topic that helped me a lot in the system performance, was @rafale77 explanation (https://community.ezlo.com/t/zwave-network-on-vera-explained/210661/3), I executed everything he recommended, increased the battery life, and helped in the performance.

However, despite having done all this, I still have a system that I find unstable. Without the slightest explanation, I get device failure messages that are waiting for a wakeup, and then I have to manually press buttons to get it working again. The device with S2 protection, a huge headache to include and work. Reading some posts above, when I change from Home to Night mode, it is crazy, everything gets an indication that is waiting to run, and of course, the system almost dies.

Before I take what I believe is the most radical step, buying a Hubitat Elevation to solve problems with S2, to have true support for ZigBee devices, I want to make three consultations with you who are super experts:

1. The procedure of decoupling the Vera from the mother ship (https://github.com/toggledbits/Vera-Decouple), I have read and re-read the instruction, besides the comments above, seems to me a great measure. The only thing that is not clear to me is, will the Vera APP on the phone, which allows us to control devices remotely, still work? Will I be able to continue turning things on and off through the APP, or will it stop working?

2. It seems clear to me that the mode shift made by the Vera hub is a problem. I can easily create actions in MSR to perform the actions, although I find it not very productive. Does setting the My Preset Modes panel to DEFAULT mean that the Vera hub won't do anything else when the mode is activated? It will not take any further action? Now when commanding everything from the MSR, I would have to put a time delay between commands, so as not to overload the hub, is that it? In summary, is it recommended to change everything to MSR or is there something to be done first?

3. Any thread that I'm missing recommendations for settings, cleaning, or changing the hub that might be helping too? Something to clean up space? Disable useless function?

The change from Vera to Hubitat is inevitable, however, what will I do to add new devices. Touching the installed base will mean having to reinstall more than 100 devices, search for a manual on the internet to do a factory reset, review a lot of MSR actions to go from one hub to another.

I'm using the latest version 1.7.5386 (7.32) for Vera, the the last MSR 21297.

Thanks.

[CatmanV2]

@therealdb said in Vera firmware 7.32 beta:

Otherwise, I'm not explaining why, after 2+ years of development, the features offered by their hubs are very, very, very basic.

My feeling is they already missed the boat. I would give them a life expectancy of <2 years, depending on how much Melih is prepared to bankroll it.

They have failed to deliver an improved Vera and (as far as I can tell) are failing to produce anything in the way of a usable Ezlo.

C

[Pabla]

Ezlo should've stuck with the old Vera FW and worked to give it more features and fix it since its already been used for years. They shot themselves in the foot by taking too long to get a proper working hub out, the home control market has already matured with some really heavy hitters from HA to Hubitat.

I was very close to switching to HA but that requires running a Rpi of sorts to run MSR which will need a pretty big overhaul of logic since it will need to work with all the new devices in HA and I will need to rebuild my Home Remote application. My VP on 7.32 runs pretty stable until a device randomly goes offline then sh*t hits the fan, I run minimal plugins to keep things stable. Had the Z wave network on Vera been better I would've stayed since I basically only have Z wave related issues.

[akbooer]

@wmarcolin said in Vera firmware 7.32 beta:

it is clear that there is no more effort to fix FW problems, we are relegated to survive with what we have, and that is that.

Ah! … so that would essentially be end of life, then?

[rafale77]

I have been mostly silent on this forum for some time now with the exception of the occasional notifications for questions addressed to me because I just moved to a new house and my system had been rock solid for over a year... mostly since I got rid of the vera.

I now have to re-build everything from scratch in my new house while I had literally zero reliability issues with my previous setup in spite of its complexity (200+ devices integrated running 3 different software platform interconnected between z-way for zwave, Homeassistant for AI/cameras and the rare cloud integrations or integrations not existing on openLuup/vera and openLuup for scenes/automation/control interface.)
I considered long and hard to sell my old home with the automation but at the end I decided to move as much as I could over mostly because I noticed an increasing trend of the industry to go towards wifi for ease of setup but which cannot scale to large installations and have to encroach into wifi bandwidth. It is getting a bit harder to buy zwave and even zigbee devices. I also didn't want to spend the time to go through the learning curve of hubitat which would have yielded no benefit to my setup.
Dumping the vera was the single biggest improvement to my system and please, no ezlo... They are cost reduced and downgraded controllers to the vera in every important practical aspect.

My new setup will be much lighter. Probably will not get to 175 zwave nodes, more likely <100 without the window coverings, fewer lights, fewer sensors. Heck I think I will dump the Phillips hue altogether too. I can't recommend enough migrating away from vera and go to openLuup or MSR in combination with Home Assistant for zigbee and integrations and z-way for z-wave while keeping devices as local as possible by avoiding all the wifi stuff which tend to be cloud dependent (with all their reliability and security disadvantages) and less efficient both in power and RF bandwidth. Still a new adventure...

[toggledbits]

@wmarcolin said in Vera firmware 7.32 beta:

...decouple... will the Vera APP on the phone, which allows us to control devices remotely, still work?

No. The Vera cloud regards the hub as offline, so you won't be able to connect to it from the app.

@wmarcolin said in Vera firmware 7.32 beta:

Does setting the My Preset Modes panel to DEFAULT mean that the Vera hub won't do anything else when the mode is activated?

Also no. The hub goes through all the devices looking at ModeSettings and sets the arming or other states according to its configuration. There are problems here, as you've noted. Setting to default means all security sensors will switch between armed and disarmed as appropriate to the mode (which it does by just setting the state variable, not by calling the SetArmed action -- a violation of their own UPnP rules). So the default actually causes a lot of activity.

@wmarcolin said in Vera firmware 7.32 beta:

Now when commanding everything from the MSR, I would have to put a time delay between commands, so as not to overload the hub, is that it?

MSR already has pacing for actions on the Vera hub. The default is minimum 25ms delay between commands. It's configurable. But, since there's been little issue that I've heard about this, it seems the default delay is adequate. I still have the bulk of my ZWave network on the Vera, and my morning and night tasks modify dozens of devices all at once, no problem.

[toggledbits]

@pabla said in Vera firmware 7.32 beta:

I was very close to switching to HA but that requires running a Rpi of sorts to run MSR

Just for clarity, you can run MSR on whatever hardware HA is running on.

[wmarcolin]

@toggledbits thanks as always for your clarifications.

But still, on the topic of disconnecting from the mother ship, I understand that it helps a lot, correct? Even if you lose external control.

Now, I understand that several people have made the disconnection, what have they done then to have external control of the house? The simple task of turning on and off a light remotely, how would it be done?

Thanks.

[toggledbits]

Disconnecting does seem to help stabilize the box. There seem to be quite a few conditions under which Luup will decide to reload in response to various network/cloud events. At one point, even the act of logging in using their remote access caused a reload, but I believe that was fixed. The major wins, though, I think come from relying on more resources within your own network, which makes the system more robust when there's an internet outage. The screen grab I posted above is my decoupled Edge system, as of this writing up without a reload for almost 72 days (about two hours to go).

I think a lot of people prefer VPN access to relying on Vera's cloud. It's what I do as well.