Yeah, I didn’t mean to go off on a tangent. It might be better to split it. I still need to have the battery reporting issue addressed by Vera. I gave them all my information and I’m still waiting for feedback.
The scenes logic in Vera was much too basic when I started on Vera many years ago. I started with PLEG, which, worked but was cumbersome to code. When I started using Reactor, it was amazingly;y simple to use, and I proceeded to migrate all my programming over to Reactor, often improving functionality.
While I completely agree with @Tim88’s sentiment of not wanting multiple boxes running, I’ve gotten so accustomed to Reactor that I think switching to EZLogic and Meshbots, although not impossible, would be a hard sell for me, especially if I would need to use MSR for some functions anyway.
I think in the long run, I’d prefer to move away from Vera, as I feel they’ve pretty much stopped any development, and I want to get off of their cloud computing and get it local wherever possible for stability and speed.
OK I spilt the thread out.
I used PLEG for many many years also.
Believe it or not I never used the Reactor plugin for Vera.
I jumped straight from PLEG to MSR and totally skipped the Reactor plugin.
No doubt MSR is very good. Meshbot’s it kinda replicating a lot of its functionality though.
I have over 100 rules in MSR currently !
That is true of the old original Vera hubs and firmware yes.
However as I said for the new replacement Ezlo platform there is massive amounts of work and development going on.
Vera hubs on the whole ran locally.
Ezlo hubs on the whole run locally also.
However their new web UI is cloud based. It may I hope go fully local at some point.
But as I said their Meshbot’s rule engine is all local for the most part, as far as the rules running.
It just doesn’t sound to me like it’s a finished product yet, especially if there are weekly software releases.
Hopefully the mesh bots will give me the functionality I currently have.
I’ll just have to be patient and wait for it to mature a little more.
2 Likes
My 2 cents.
Long time Vera user but never crossed the chasm to PLEG or Reactor. After reading this I wish I made the effort.
Ezlo has issues in the ZWave area still. I don’t find it as stable as Vera. I think they are missing a number of error handlers particularly related to fringe signal nodes. I also find the iPhone app shows a device as off when the device is in fact on and vice versa. You can’t have that ambiguity if you are controlling a home hundreds of miles away. So maybe some missing handshaking on how the ZWave state machine works and is reported outwards. Also probably need a periodic (background) audit function to double check the actual state at the node versus what Ezlo thinks the state is.
I was disappointed that there was no virtual switch capability, but then learned to my delight there is one without a 3rd party plug in. It still falls a bit short as it a tad cryptic to install a virtual switch but Ezlo claims they’ll add a easy to create one from the client in the next release. I like many others use virtual switches to allow user input to a temporary condition and also as a binary value with timers for setting up evaluation windows of certain conditions.
I do see promise with Ezlo so I give them the benefit of the doubt. Meshbots are much more feature capable than traditional scenes. Perhaps PLEG/Reactor users aren’t as pleased but as I said I don’t have that comparison base.
I do question some of the priorities at Ezlo though. I wonder if the balance between bug fixing and new features is a bit off. My sense they are keen to add new things when just getting some of the base capability rock solid is equally as important (ie Z-Wave rock solid, no regrets operation). I also question Ezlo Pi as a product as that is surely a resource drain and yet another code base/branch to support and ultimately it cannibalizes their own hub sales. Seems an ill conceived strategy to me. Sometimes doing less really well, is better than doing more only 70%.
I have 60+ ZWave devices on my main home Vera Plus and I won’t move that to Ezlo yet. My Ezlo Plus is at a summer home and is a very modest Z-Wave network. I can afford to have some instability there.
Hopefully by next summer Ezlo will be noticeably more stable and feature rich and then I’ll get an Ezlo controller and migrate my main home over. It will be a job to move all the Z-Wave devices so I need assurance it won’t have nasty side effects before I take that on. A way for Ezlo to pull in a Vera backup file and configure a virgin Ezlo Plus controller would be cool. Much like when you get a new iPhone but you want to migrate all you apps and data over. I gather this is more difficult than I suggest.
Lastly I don’t seem to be seeing the 3rd party community jumping in with Plug Ins. Has Ezlo stunted progress there by not publishing the API, user guides, and tool kit to get these creative sorts off and running?
So a mixed bag with Ezlo for now. I am going to hang in there. Hopefully a year from now the situation will be that much stronger.
1 Like
I agree with that. Get the basics working rock solid first. New features are nice and all but if devices are falling off your network or not being controlled correctly 99% of the time then…
They banned most of the active 3rd party devs, they aint here anymore and move on. Cant comment on the quality of their help docs and resources for devs as I not a dev.
1 Like
all the APIs are public and available.
https://developer.mios.com/api/hub/devices/
https://apitool.ezlo.com/dashboard
Re: Bug fixing: With each release Bug fixing takes priority over features…So anyone has any bugs, pls report so that it can be fixed quickly… Any issues you know re: Zwave pls report asap so that we can fix.
Virtual Switch: We do have it (as a plugin we developed it btw…) however we will be releasing a version soon supporting this natively…
Software cycles is not about maturity but the speed of the operations…
there are many mature cloud based systems that also delivers weekly basis. On its own Software release cycle doesn’t speak to the maturity of the product imo.
So look at it this way, because bugs take priority, it means this team can fix bugs very quickly thanks to their fast software release cycles! You just have to report it 
In my personal opinion it feels like to me its more of a beta product then a finalized polished product for end users. I’ve seen in the past people lose confidence in software when it has too many issues and it takes a long time to regain that confidence.
For me it’s not the right time to migrate to the Ezlo platform. I know I’ll be a bit behind but I don’t want to expose myself to the frustration of a product that is still in what feels like the development cycle.
It also seems that NuCAL is a bit of a ‘band-aid’ for functionality that used to exist with local plugins.
While I’m sure it has great flexibility it also comes with some drawbacks like having to hit the mothership. I’d be curious what kind of security is embedded in these calls.
I look forward to one day being able to upgrade from Vera to Ezlo. It seems as if its going to be a pretty decent system. It would also be great if there would be a migration path so that you don’t have to rebuild your entire system from scratch. I will stay tuned to the progress on this site.
Regards,
Tim
1 Like
Can’t fight with feelings 
only with real reported bugs
Of course, whenever you are ready…no rush…
NuCAL is like IFTTT…doesn’t replace Local Plugins we already have… Local Plugins solve a different problem than what NuCAL does, hence they are not comparable. (Security wise, happy to answer any specific questions you may have…I do have an extensive Cybersecurity background and happy to answer )…
Of course we would love to have you onboard…but we also understand it will only happen when you are ready…till then we are here for you!
I agree with @Melih Nucal and cloud integrations have a place, as do plugins and locally connected integrations.
Some cloud based platforms may need cloud integrations such as the cloud APIs for things like Tuya Smart Life and eWeLink Wifi devices. I hope these get added to Nucal in the future.
There are plenty of services and devices that are only cloud based.
I’d rather have some Nucal cloud integration for these types of wifi devices than none at all.
If a direct local connection / plugin is possible also? Then all the better, but that might not always be the case.
I try and avoid such cloud based wifi devices and products generally like these, but I do have some of these types of devices.
Even on some of my Ezviz consumer grade cameras, I can only control some aspects of their features by IFTTT currently.
But the pro Hikvision cams have a local http API so I’d like a local plugin or use my own knowledge of their API and some of Ezlo’s new tools and plugins like the Wifi Device Generator, to be able to add some basic switch devices on to my Ezlo hub.
In fact today I used the Ezlo Wifi Device Generator plugin, to create a switch to send on / off http commands to IFTTT web hooks, to control the privacy mode on my indoor Ezviz PTZ cam and also I created another Wifi Device Generator plugin switch device, to send local http commands on my own LAN, to a Hikvision cam to control its motion detection event on / off setting.
So Ezlo are providing me some of the tools I need to more easily create virtual devices on the Ezlo hub to send http commands to both cloud based and local devices / services / API’s.
And talking about eWeLink they recently changed and updated their cloud APIs and the integration in both Node Red and Home Remote dashboard app are now broken and none functioning.
So even when you had some cloud integration it can break any time that end point company changes their API’s.
Guess the same is true for local http APIs also, if a company changes their API framework. Like when Kodi changed their local http API, it broke lots of my integrations, till I redid them for their new http calls.
And I do get some manufactures are very limiting in how you can interface with ‘their’ devices. Even though once they are paid for they are mine. Still annoys me I can’t turn the camera status light off on my Nest camera anymore because google decided to make a change and it had to always be on. I know a piece of tape solves that problem.
In my opinion local control should always be the first in the hierarchy and cloud should be secondary and for remote connectivity.
Its concerning that so many manufactures are pushing configurations through the cloud. There are very few router companies that have a local configuration page. For some of the home automation where you have home/away status lock status window status its opening the door bad things.The more that’s in the cloud the more we are at risk for our security to be compromised. Which cyber attacks seem to be more an more of a problem. Apple dropped Back to My Mac, I’m guessing because it was a major security risk. I’ve read that they are seeing companies embedding malware in some devices and as soon as you connect bluetooth or wifi you get compromised. And as an end user I’m not sure what some of these companies are doing to protect us?
Sadly thats not always true especially if those devices rely heavily on a cloud back end infrastructure.
I agree and so does the owner of Ezlo.
I have spoken to him in length and I know if they can do things locally then they will.
My biggest gripe currently is their new (beta) web UI is cloud based unlike the old Vera UI7 web UI.
But I expect it will be made local and to run locally on the controller hub eventually.
So lets hope they hold true to some of the reassurances they have said.
A lot of the aspects of the Ezlo system are local. “Local” Meshbots logic rules run, well locally as you’d expect.
The Vera mobile app can connect locally to the Ezlo hub rather than via cloud portal relay servers.
If you turn off certain settings the Ezlo’s hubs HTTP server API can then be local and you can send local http calls from your LAN directly to the Ezlo hubs http server API.
You can thank me for that last one.
I installed MSR today on my home server, and aside a path issue for Node in my Fedora (reactor.yaml had a different path for node than Fedora installed it into), install was quick and easy. What I was really surprised by was how quickly and easily MSR imported everything from Vera.
I confirmed that MSR has all the functionality I got from Helitrope built in, so one less plug-in to worry about.
Also MSR has a built in config for OpenWeatherMap, so once I got the API key, configuring into into MSR was again simple. Now I don’t have to worry about Dark Sky going dark on me. So that’s two plug-ins down.
So, that leaves me only with a few Vera plug-ins that were on my “must” list. Nest is one, but it’s not even working properly on Vera, thanks to Google killing the Works with Nest program. I can access Nest through Homebridge, so if there is anyway to get MSR and Homebridge to talk, then that problem would be solved
Edit: I found this post that shows Nest Thermostat and Nest Protect can be accessed from NuCAL, so that can be crossed off my list . That alone might make me move to Ezlo sooner.`
Google Calendar integration. I know you mentioned Google Sheets through NuCAL, so maybe Google Calendar is possible.
Edit 2: Google Calendar is indeed integrated with NuCAL. Even though I don’t have Ezlo yet, I was able to sign into ezlogic.mios.com, and I can create NuCAL integration from my Google Calendar.
Geofencing appears that it will work using Vera and the iPhoneLocator plug-in that I currently use. Again, long run, I don’t want to keep both Vera and Ezlo up, but I wouldn’t loose any functionality while migrating.
I think my next step is to start migrating my Reactor for Vera rules over to MSR. Once that is completed, I can think about adding Ezlo into the mix, and migrate my Zwave devices one by one. I believe most of them will migrate without issue, but I’m guessing a handful will not. I know Ezlo has a giant list of devices they have confirmed to work, but I don’t know if they have the “Generic Z-wave” type that Vera does, for those not on their list. I also know they say they will get a device integrated with 90 days of receiving a request, but for devices not currently on the market, that means sending that device in for them to integrate.
This is not a correct statement.
Yes we do.
Also we do have 3 different Weather providers already built in in EzLogic (MeshBots)…
Ezlo Weather is the one we provide natively without requiring any API key for any provider.
Okay, so on that note, I have Bali roller shades in one of my rooms. They are powered by Somfy CSZ1 Zwave controller. I don’t see it on your compatibility list. Is this something that is on your roadmap?
You can use the Wifi Device Generator (its for any IP based HTTP devices actually) and control IFTTT based devices and I notice that Somfy is already part of IFTTT… @cw-kid can give you a pointer or two on how to use IFTTT using this plugin He creatively used this plugin to control IFTTT devices…so all credit goes to him!
So this is one way to use it now…
They’re not WiFi based, it’s Z-wave