Change in Plans (Don't Panic)
-
My unwillingness to base my own HA on eZLO is what delayed this eventuality, so I completely understand. There's a community that needs this, though, and they are my community from the Vera days. While we may be of the same mind with respect to the future, it's clear that a great many people are still clinging to hope. If they want to stay and wait it out (now nearly three years in the making and not near completion, IMO), at least I can throw them a lifeline to make straddling the Vera-eZLO divide less painful.
-
I have to say my Ezlo Plus is extremely fast as far a Z-Wave communications are concerned. I don't have many Z-Wave devices directly paired to the Ezlo hub yet, but the ones that are, are very quick !
I setup a Z-wave door contact sensor on a walk in cupboard door and a Z-Wave light bulb and two scenes created on the Ezlo Plus, one for open and one for close.
The bulb turns on instantly and I mean instantly as soon as I open the door even just a little bit when it breaks the door contacts connection.
Yes the Ezlo software is still very lacking and buggy and all still being developed.
But we have MSR support coming for Ezlo hubs soon and Bill the Home Remote dashboard app developer told me only yesterday he is still planning to support Ezlo hubs and it will hopefully happen this summer. So with MSR and Home Remote what other interfaces do you need?
The Ezlo hub can act just as a Z-Wave radio as my Vera Plus does now today.
I am in no rush to replace my production Vera Plus but I will likely one day migrate all the devices to the Ezlo hub, especially if it works also well with Zigbee 3.0 devices, which Vera hubs do not.
-
I have to say my Ezlo Plus is extremely fast as far a Z-Wave communications are concerned. I don't have many Z-Wave devices directly paired to the Ezlo hub yet, but the ones that are, are very quick !
I setup a Z-wave door contact sensor on a walk in cupboard door and a Z-Wave light bulb and two scenes created on the Ezlo Plus, one for open and one for close.
The bulb turns on instantly and I mean instantly as soon as I open the door even just a little bit when it breaks the door contacts connection.
Yes the Ezlo software is still very lacking and buggy and all still being developed.
But we have MSR support coming for Ezlo hubs soon and Bill the Home Remote dashboard app developer told me only yesterday he is still planning to support Ezlo hubs and it will hopefully happen this summer. So with MSR and Home Remote what other interfaces do you need?
The Ezlo hub can act just as a Z-Wave radio as my Vera Plus does now today.
I am in no rush to replace my production Vera Plus but I will likely one day migrate all the devices to the Ezlo hub, especially if it works also well with Zigbee 3.0 devices, which Vera hubs do not.
-
Exactly replace it with what?
I've used Harmony remotes for longer than I can remember.
The Elite is the best remote they ever made.
-
Everyone, I've had a change in thinking.
As many of you know, I had decided to not build an MSR interface for eZLO's new controllers, for multiple reasons, not the least of which was that I had chosen not to use an eZLO hub in my future HA. I am currently straddling three hubs: Vera, Home Assistant, and Hubitat. I am actually very much enjoying the flexibility this has provided. But these three hubs are enough for the moment, and when the venerable Vera Plus on which my house has operated since 2017 dies, I will likely just move the rest of my ZWave devices to the other hubs and reduce by one.
Another reason for my previous decision was the risk of fluidity/instability in the eZLO APIs. Since this is first generation work, and even now as they approach the three-year mark on development and are still in "beta" with much functionality still incomplete or missing altogether (plugin UI framework?... anyone? anyone?), it stands to reason that, like all projects in this phase in particular, choices are made that need to be revisited. To be fair, Hass and Hubitat are not immune from this either, even as much more mature products with greater market penetration. In any case, I've demurred because of the high perceived risk of change and breakage, and didn't want to put myself (again) on the critical path of my own user base waiting for me to catch up. I accept now, however, that events like this are just part and parcel of the environment in which I've chosen to work. As I said, if it's not eZLO changing something, it's going to be Hass, or something else. I haven't had a breaking change hit from the Hubitat side yet, but it's probably just a matter of time. Just as I seek to improve my work, they must seek to improve theirs.
The upshot is that I've decided to write an eZLO interface, and I've been working on that for a few days and now have a working prototype running. It works with the few devices I have available for it, and there's a lot that's assumed and untested about all the others. Think back to March, when MSR was first released -- the process of going through and stabilizing these interfaces under all the different external conditions, with devices in your environments that I don't, and sometimes cannot, have -- it takes time. Drilling out all of the details of device behaviors and data, and how each hub handles them differently, takes time. But it's going to be a reality. Aside from this, reading the other forums makes me realize just how much this is needed, if only because there appears as yet to be no articulated concrete plan (e.g. words beyond a promise with no date) to support easy migration from a Vera to an eZLO. MSR touts itself as a tool to assist such migrations between hubs. An eZLO interface must exist.
To set expectations: you'll see the first version of this interface in a build in the next couple of weeks. It will be an add-in. Like MSR itself, I will be limiting the initial audience, and those of you that participate in the early use and testing will be asked to provide lots of diagnostics and feedback (so please don't ask/participate if you're not willing and able to put in the time). It's brand new, unfinished work; there will be lots of bugs, and lots of holes, and it's going to take a lot to get them all squashed and filled, respectively.
Based on what I've learned so far from this project, I also want to forewarn you that it may include access to my cloud infrastructure for automatic logging (to make our mutual efforts to examine problems easier and faster), at least during the early stages. At the moment, MSR has no hard Internet-access dependencies, so this is a change for this interface work.
Also, I probably will ultimately be charging a modest monthly or annual subscription for the eZLO interface, which is a change from policy and practice to date. The amount of effort the project has demanded and can demand in future makes it necessary that I consider a business model. I know that gives some pause, but it should also give you confidence that I am thinking of a long-term future. But, those of you who, as of this writing, hold active accounts on the MSR bug tracker and have participated so valuably in the testing and improvement of MSR, are grand-fathered in to a perpetual (personal/non-commercial use) license to MSR and this interface (no fees, at least for what parts are produced by my hand; I cannot control what others may choose to do if/when third party development takes root). I am considering extending that benefit to everyone who has donated to my projects from the start to date; that is, including those who supported Reactor for Vera, without which MSR would never had been born.
I can probably predict from these forums and others who the active eZLO users are going to be, but if you want to work with me on it, please let me know by reply here. I will be relying on you heavily, because I am not going to be a big consumer of the hub, so a lot of the work will require data collected from you and your hub and investigative work on that evidence, rather than first-hand experience and witnessed events in my own environment. But I'm confident it will work, as much gets done this way already, and investing in more and deeper troubleshooting tools is always a good investment.
Thanks to all of you who have supported this project. Onward...
@toggledbits said in Change in Plans (Don't Panic):
when the venerable Vera Plus on which my house has operated since 2017 dies
No… don’t say that ! (Don’t jinx it !!)
While i didn’t think it would get much better than my Vera 3 (way back when) I’d be sad to see my VeraPlus go…
-
@librasun I actually have a pretty big fist full of controllers myself. It's not really controllers I'm wanting for, it's devices and environments. The more hands this touches that aren't mine, the more things break, and the better things get for it. Hold on to them!
@librasun said in Change in Plans (Don't Panic):
Who knows, it might be the first/last thing I ever do with eZLO hardware, which otherwise is going in the trash at some point.
I absolutely doubt most users of the Atom or PlugHub would be a user of MSR (except in some fringe cases, like for an out-building). But those eZLO Plus's (in full or prototype/skeletal form) could be useful. They seem to have a similar architecture to the Raspberry Pi 4. Maybe once I get the ZWaveJS interface fleshed out (that's also been in the works), I can just publish an MSR replacement firmware for the Plus hardware. You know, for science.
@toggledbits said in Change in Plans (Don't Panic):
Maybe once I get the ZWaveJS interface fleshed out
Curious about progress on this. I was just messing around with ZwaveJS today and was thinking of utilizing it to move all my zwave devices from openluup+zway to HA+ZwaveJS. Obviously a direct ZwaveJS interface to MSR would be optimal.
Also is there any plans of a tool that might allow us to swap an entity reference in the rules? Moving zwave devices to ZwaveJS would require going through all MSR rules one by one and remapping to reference the ZwaveJS entity instead of the openluup entity.
-
T toggledbits locked this topic on
