The issues to add the Danalocks v3 were reported to our Developer team, there is a Jira ticket created for this problem, our developer team in working to find a solution to this problem in a future firmware release.
Thanks for your feedback and patience. Our team is working hard to resolve this.
I’ve had some hickups along the way, but for the most part, pairing devices is pretty straight forward and quick. I’ve set an Ezlo Plus up for my sister and was blown away by the speed when compared to my current Vera Plus. Her installation is quite simple and very straight forward.
Being that I’m building a new house, I wanted to play with the the Ezlo Plus and purchased one for myself. I’ve found that Lowes sells these Eaton ZWave Plus dimmers, and in which so far I like. But they do not work 100% with the Vera(S2). I wanted to settle into some switches that if they failed, I could generally run to the local Big Box store and get a replacement.
So I purchased one Eaton Dimmer and one Accessory Dimmer. Come to find out that there is no way to set associations within the Mobile app. Then to find out that there is no web UI.
THEN, the biggy!!! After all the press releases/articles about how Ezlo would retain MiCasa Vera’s business model. I now read that to keep remote support(WAN), you now have to pay for a subscription(Anywhere Access)!!!
So now I’m thinking that I’ll just stick to my Vera… Well, how long do you think it will be supported, now that they are pushing Ezlo and their subscriptions. Then I thought, I’d just forward a port and use my mobile browser, while that may work for awhile on the Vera, it most probably never will on the Ezlo…
I was so excited to have a plan for the new house, but now that’s a toss… Luckily I did wire the house through the nose with CAT6… Or at least, IF I still want ZWave, I guess I’m heading back to HomeSeer
I do not like subscriptions at all… It’s one thing if it where a music streaming service… But this is my house… One that I’ll probably live in until I die, and I just can’t justify paying money(until I die), to keep it functioning. I know Ezlo has to make money, but there are alternatives…
You want firmware updates, which requires paying Engineers’ salaries constantly
You want a cloud access, which requires paying Engineers’ salaries constantly
You want Mobile apps to be maintained, which requires paying Engineers’ salaries constantly.
How should we pay for these if you don’t pay us on ongoing basis?
If you don’t want updates for the above, lets say after 3 years of your purchase for any of these, there is no subscription you need to pay for!
I could not find the words "Membership, “Subscription” or “Pay” anywhere on Ezlo’s “Hub Comparison Chart”, so perhaps that would be a helpful category to add?
So that customers can compare apples to apples, both short- and long-term.
P.S. There are also lots of errors in the chart itself, such as Vera’s ability to “Migrate Between Different Hubs With All User Data” or “Execute Lua scripts as action in Scenes” both showing as “FALSE”, or the VERA hubs lacking 500-series Z-Wave chips (which I believe some do).
The tickets that we opened by the end of May to integrate and fix bugs with the devices that you own are already being worked on. Keep in mind that we receive hundreds of integration requests constantly, and our engineers are doing the best they can to evaluate each request and proceed with the integrations. This process takes time, but we’re getting there.
Your tickets are already assigned to an engineer, and we’re working to have your devices fully integrated.
We just need to wait for the future firmware releases and be aware of the release notes that we’ll post here for you to know whether the devices are integrated with that firmware release.
What is it about “device implementation” that requires the company making the controller/hub to accommodate certain devices in such a deliberate and tedious way?
I had always imagined - perhaps naively - that the whole point of Z-Wave certification was for every manufactured Z-Wave device to adhere to a pre-defined “class” or “type”, which automatically grants it features that any Z-Wave capable controller would recognize, honor and integrate once paired.
Is this where things don’t go according to plan? Manufacturers not adhering to published protocols? Adding unusual features? Devices being unresponsive?
I’d love to know where the roadblocks arise in this process, since otherwise I would tacitly assume “a handshake is a handshake is a handshake” in terms of CERTIFIED interoperability.
And also because otherwise, I’m left with the feeling that ezlo is being forced to (a) locate a source for each requested device, (b) obtain a working unit, ( c ) attempt to pair with it, and (d) laboriously work out the kinks. This strikes me as an excruciatingly costly and perhaps not-at-all sustainable process.
It also suggests that older (EOL) and hard-to-find, rare devices may never make it onto the “Works with Ezlo” list, even if they originally worked with Vera. And if that’s the case, I’m left pondering why the earlier implementations cannot be directly ported over somehow to the ezlo ecosystem. (Isn’t an “implementation” just a snippet of JSON code, after all?)
When Z-Wave was first introduced over 20 years ago, it was easy to think back then that all Z-Wave devices should be able to communicate effectively with each other, and that remains true nowadays for simple On/Off devices like switches and dimmers, but it becomes a whole different story when more complicated devices with lots of features and command classes where introduced (door locks, thermostats, multisensors, etc).
That is indeed the Z-Wave Alliance’s goal when it was first developed and introduced, but the real world turns out to be a different game. We do our best at adapting, as any other Z-Wave hub manufacturer out there.
That pretty much sums up what the process is when working on integrations of new devices with the platform. The company has to get units of those devices and yes, this means dedicating a lot of resources and, unfortunately, time, sometimes much more than expected.
For simple On/Off devices, they will likely work even if not integrated, but for legacy devices that are more complex and are no longer commercially available, it is most likely a no-go for integration.
Thanks for the detailed explanation(s)! I take it then from this last statement that there’s no room for independent developers or serious hobbyists to create the “implementation”** needed for a particular legacy/complex device?
Prior to your reply, I would have bet money that it’s possible to reverse engineer or port over things of this nature that “worked before on Vera” … now, I get the impression that ezlo hubs are just “too different” from Vera in that way.
**isn’t an “implementation” just some kind of basic text file?
What I mean is that if a device is not commercially available and therefore no units can be procured for the integration teams, they cannot proceed. That being said, if a customer has the know-how to integrate those legacy devices on their own, the options to access the system via SSH and the API are still there to be taken advantage of.
They are very different platforms indeed, so there is no straight way to just port a JSON or XML file from Vera to Ezlo to achieve the integration of the device those implementation files belong to, so it needs to be done from the ground up.
Running 220.127.116.115.1 on an Ezlo Plus, using the iOS App version 3.54(13). I’m trying to add a Aeotec Wallmote Quad. I think this worked fine previously when I did some tests, but this time I get stuck.
I have a lingering device in the app, with status ‘Device failed to communicate’. Whatever I try, I cannot delete this device. Not by straight deleting it, not by unpairing it, not by reloading the hub. The device properties match the device properties of my Wallmote Quad.
Adding my Wallmote Quad gives no result, after the pair proces, I get stuck in the pairing screen and it never gets to screen where I can name the device.
To me, it seems the lingering device is matched with the to-be-paired device and this creates this situation. How do I delete the device that’s still visible in the app?
For those interested. We managed to clear the failed device for @jouked and after several more attempts he managed to get it paired with the hub. Since it is currently not listed as integrated with the Ezlo Plus and Ezlo Secure (only Vera, Atom, and PlugHub), I have created an integration request for it:
The pairing wizard usually shows this on the app, it shows the percentage of the pairing process. The API will also show you the status of the pairing process if you need more details of what the hub is doing in the background.
Yeah, I’ve seen it happen too, not frequently, but it does. Hopefully the devs can figure out why it happens and get it sorted out.