@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”.
