Do you have issues with running two z-wave networks in one space? I have a large network running on Vera and have considered running a few devices on Ezlo. I wasn’t sure if it would create radio interference.
1 Like
I currently have a Vera Plus, Vera Lite (to support some devices that haven’t worked since UI5), Ezlo Plus, and, occasionally (for firmware updates) Ezlo Atom all running in the same space. Although there is some physical separation between the units, they all cover the same area, and have devices in the same area. There are no issues with this that I have been able to determine.
2 Likes
DSC plugin is not ‘yet’ available.
Could you help me with more details about how you use each one of these in your automation pls
iPhoneLocator
NetMon
Heliotrope
Darksky
as well as more info on how to find them (I would like to pass it to our new plugin team).
Have you tried http://ezlogic.mios.com/ to see if it satisfies your rule creation needs pls? (if there is some rule you can’t create, please tell us which rule so that we can expand EzLogic).
Like many others I also use the DSC plugin via an EVL4 and cannot migrate without this support. I also have numerous Reactor automations which would need to be migrated. Perhaps @rigpapa would be willing to support Reactor on Ezlo if the company could ever get its act together. He already committed to a multi-system version, but why write for a product clearly not ready for prime time.
I thought/hoped things would be different after Ezlo bought Vera Control - three years ago -, but the sadly the gating issues appear to continue as before. The only real change I see is the hardware is prettier.
1 Like
There is a version of Reactor that works with eZLO hubs and others today (and more on the way). It really is the ultimate flexibility, because it lets you choose the controller with best integration for every purpose/device, and since this new Reactor itself has a plugin architecture, it’s possible for it to directly support devices if the need arises, not just through the device support of a hub (I’ve working on MQTT and ZWave-JS direct integrations). There is an importer to bring in rules from the Reactor plugin for Vera, to smooth that transition, and of course, the new Reactor shares a lot of functionality and UI with that of the Vera plugin, so while there are differences, it’s not (IMO) a steep learning curve between them. The eZLO integration lets you do the basic things that eZLO hubs can do, but there are still many things people are used to doing on Vera that are not possible today with the eZLO hubs.
2 Likes
We have a new Plug in team, with a brand new Plug in framework. DSC plugin is one of the first plugins we will develop along with the launch of new Plugin framework including a marketplace ( I can provide a date in 2 weeks time but the initial launch will be this year)
As @rigpapa mentioned he already has Ezlo integration with his system that runs on a separate computer .
We also have a native rule engine called EZLogic that doesn’t require you to run another computer for automation. You can see some of its capabilities here
Yes, EZLogic for now has some functionalities missing compared to Reactor. EZlogic has a different architecture to provide these kind of functionalities in a different way very soon and add more capabilities that doesn’t exist in Reactor like being able to connect in a ready and easy to use way with “any cloud” app (not released to public yet)
This also comes with integration to other “hubs” like “Smartthings”
or
Honeywell, Netatmo or Openweather (much more being integrated)
We believe “Automation” should be provided “Natively” for our users, without having to require them to use another computer or third party plugins, we also believe our Platform should work with “any” home automation system out there.
2 Likes
FYI, I have my Multi-Hub Reactor running on an eZLO Plus. Not with it, on it.
1 Like
Great to hear!
I guess that means we got our act together 
Given that Reactor (Multi-Hub) runs on the Raspberry Pi 4, it wasn’t much of a stretch to get it running on the Ezlo Plus (same CPU architecture/family, less RAM, open source operating system).
Unfortunately, that really doesn’t move the ball forward for users much anyway, as the limitations of the current firmware and device support are the real factors people care about, I think, and where Reactor runs doesn’t change those. The fact that Reactor can work with other hubs to expand device support to the superset of all of them is far more relevant to user success. Nonetheless, I look forward to the future when Ezlo has completed that work, because more options for users is always better.
Also, going back to your original comment, many users have a NAS or other systems already running in their homes these days, and even desktop PCs running Windows can run Multi-hub Reactor, so it’s not like additional (and even more capable) CPUs are exceptional any more. Certainly for now that’s probably not your best talking point anyway, as current EZlogic is served from your cloud, and it’s hard to get more “running on a separate computer” than that.
2 Likes
Configuration is done in the cloud, but whole logic runs locally on Ezlo.
Once you set your rules using Ezlogic web ui, then the whole thing is downloaded to Ezlo Hub and runs there locally without requiring any other computer or cloud.
I am glad you have got Reactor to run inside Ezlo and does not require external computer for rules in Reactor.
I remember you said in our conversation in the past that automation should be provided natively and you would be happy to see us provide it natively. One step at a time, we are getting there.
I remember it well and I stand by it, and I am very pleased to see the progress you’ve made (and that it looks so familiar, because as they say, imitation really is the sincerest form of flattery). Indeed, Home Assistant, Hubitat, and others, all have their native automation engines, and Ezlo could not be the exception and be viable in the market. And all of those platforms also have third-party alternatives, which as I’ve said, is great for users because it gives them choice.
I also stand by my position that this isn’t an adequate solution. Ezlo has to get to the point where all of the logic engine, including its UI, is usable from a local (hub-served) UI without Internet access or cloud dependency of any kind. I think the community as a whole, not just me, has been very clear about that from the beginning.
5 Likes
Thank you.
Didn’t realize you invented Query Builders?
Indeed, just like you, we too used a standard query builder component for now in EZLogic.
With the launch of the new plugin framework and marketplace, the opportunity will exist to have many different flavors of everything.
1 Like
@rigpapa - Thanks for your reply. After struggling with PLEG for a number of months, I discovered Reactor. Perhaps it is my past (long ago) as a programmer, but Reactor immediately clicked for me. Reactor allows me to do many things that were impossible before. For example, I have one Reactor script that manages our KOI pond. It controls the water pump based upon not only time of day, but also water levels in both the pond and pump well. If the water level in the pond drops too low it opens a special zone valve and turns on the Rachio-based irrigation system to refill the pond. If the level in the pump drops too low, indicating a clogged filter, Reactor shuts off the pump to prevent burnout and sends a message to clean the filter. (Thanks also for the Rachio plug-in.) I doubt I could have ever accomplished this with PLEG. Does the Ezlo version require separate hardware for Reactor? If so, what are the hardware and OS requirements? Does this architecture version work with Vera as well?
2 Likes
The team is working hard to fix what we have in-house, but it may differ from your device’s version. I see that the manufacturer has stopped producing this and there isn’t a commercial version available anymore. this makes our job difficult. I can also recommend you to get the newest model of this device because it has been released in many different versions with firmware updates.
Do yourself a favor and stay away from the Ezlo plus for now - and that is coming from a ten year+ Vera fan.
I don’t know how they are allowed to sell a product that is not ready, or at least cover it in warnings to let the buyer know beforehand that the software is nowhere near ready.
I wrongly assumed it would be an upgrade to Vera (and maybe one day it will be), but I am now stuck buying another controller as the Ezlo plus cannot do most of what my old Vera 3 can. No plugins, no device-specific notifications (i.e., which user unlocked the door) no configuration for Modes (home, away).
Contracted support a few times, nice guys, but there is nothing they can do.
Truly disappointed.
3 Likes
The Ezlo version runs on the Ezlo (Plus); it should also run on the Secure. This is an experimental thing at the moment, so I haven’t released it as an official build. All supported versions of Multi-Hub Reactor support all controllers that Multi-Hub Reactor can support. So it can work with a Vera and control its devices, but it doesn’t run on a Vera (the OS that Veras run is too old). I don’t have a feel for ratios of users on the various platforms currently, but I know many users have NAS systems in their homes and run it there; Windows systems are also common and a popular option. Raspberry Pi’s are relatively cheap and are also a common platform. At least one user is running it on an Android device. It will run on pretty much any current Windows, Mac or Linux system.
1 Like
I’m currently running Mutli System Reactor on a £25 HP Thin Client I got off ebay under Linux Debian.
Multi System Reactor is extremely powerful logic engine and easy to use compared with PLEG so very happy with it.
If I ever migrate my Z-Wave devices to an Ezlo hub? I’ll likely continue to use MSR.
Still on my Vera Plus for 99% of my devices as Ezlo platform not ready yet when compared to the old Vera hubs. But getting there slowly…
4 Likes
I get that your expectations were not met here but this does not mean that we should all stay away from ezlo. Only Pizza makes us all happy.
1 Like
@BenjaminB I’m not sure what your strategy is explicitly, but I can tell you what I’ve observed and therefore assume as an outsider, and why I think you need to change what you’re doing.
From the beginning, the Vera community’s expectations were set that the eZLO firmware would support all of the devices that Vera supports. This is a reasonable position, as the team would have access to the library of devices used to develop, test and maintain the Vera firmware, as well as all of the knowledge gained from developing for and testing with those devices. Acknowledging that some of the devices may go defective over time, the Vera team nonetheless had/has all of device responses to ZWave interviews contained in its own data and code, so at least sufficient to make a good effort at getting the devices working even if they could not be explicitly tested.
The strategy now seems to be for eZLO to support only what is currently commercially available. So right from the start, you are asking many users to replace existing, working (physically and with the Vera firmware) devices. This usually comes at a substantial expense, often much more than the hub itself (so you’re effectively asking users to look at other existing, mature solutions). In some cases, as evidenced by your earlier post above, you are even asking users of more recently-purchased, still current devices to upgrade to newer versions of them. This is adding insult to injury, for sure. And worse, since all of this now widens the gap between what Vera supports and what eZLO supports, the customer has no bridge whereby both systems could be viable together and a gradual transition be made: you are forcing them into the position of upgrading all of their devices to what is currently supported by eZLO (which does not currently cover their needs) to get to eZLO. The problem for many users is that without the plugins necessary to support the non-ZWave/ZigBee devices that fall under your 90-day device support guarantee (i.e. there is no guarantee for when the plugins will be available, or even if they will be available), even total replacement of their ZWave/ZigBee to what eZLO supports doesn’t get them where they need to be. Some users, like @cw-kid , are nonetheless trying to get there, and my Multi-hub Reactor (aka MSR) is, as planned, facilitating that migration by allowing them to continue to use their Veras with the existing devices and plugins and bring in the eZLO hubs for a gradual transition with the two working together.
I don’t know if you are adequately using the data available to you, but from my outside perspective, it seems not. Were I running this project, I would be pressing the team do to the following:
- Find all of the devices used to develop and test with the Vera firmware and make them all run on the eZLO firmware. This seems obvious, and should have been done, but claims by customers and affirmations by eZLO that devices working/supported on Vera and not on eZLO suggest otherwise.
- For any Vera-supported device for which a working example cannot be found, examine the Vera firmware code and data files that build the Vera device from its ZWave interview responses and take a shot at getting them supported in the eZLO firmware. It’s better than nothing. There will be misses and errors here, but you have a willing customer base using these devices that can provide you additional data for troubleshooting and tuning. Since Veras upload logs and backups to your cloud, you likely already are sitting on a gold mine of such data. You can even modify the Vera firmware to collect and report additional data if needed. Which leads to…
- In the eZLO firmware, ask for permission and collect data on every device that is being used in the field; grab the inventory responses and send them to your cloud. I’m pretty sure a majority of users would gladly agree to that data collection and use. When users include a device that doesn’t work, give them a place to report it that you’re team jumps on. With your existing facilities and remote access capability, you can probably do development/tuning directly on a beta tester’s hub remotely (if not, you’re technically not far from it, I’m sure). Have the cloud actively alert you to any device that doesn’t match a known signature, or new versions of a known device… there’s a ton you can do here. It will not only give you the data, but it will give you metrics on popularity of/demand for those devices, which will help you triage and prioritize your work.
- When I was working with the firmware team, I was told they were doing sprints and builds every two weeks. That does not seem to be translating into rapid succession of updates in the beta/live domain – firmware releases have been few and sporadic. Device support is coming too slowly the way things currently are. If the above is going to work, you need to either speed up the release process (reliably and to a regular, frequent schedule), or abstract more of the interview and device mapping out of hard code in firmware and into data-driven methods, where the driving data files can be published separately from the firmware, and more frequently, to update device support.
You may not need to buy and have every device, or every version of every device, to support that device adequately. If you lock yourself into that thinking, it will be years before eZLO’s device support is considered “current”.
10 Likes
I would add to this that in some cases the devices are irreplaceable. For example, my Wayne-Dalton WDHA-12R (which, in all fairness, hasn’t worked properly since UI5-I keep a VeraLite running UI5 to support it) to link my CarLink buttons in my car to my home automation system - there is no other device like it available.
To add insult to injury, the device is still available at https://smile.amazon.com/gp/product/B001HL3CS8/ref=ppx_yo_dt_b_search_asin_title, but even so when I put in a device integration request for it, said request was quickly closed with a " it is not a type of device we accept for integration" message.
1 Like