Hey everyone, I now have first-hand experience working through the nuances of a device integration and thought I would share my experiences here because I’m not sure everyone truly appreciates what is involved, especially if the device departs from the zwave or zigbee standard, so here is a story that is a testament to the people involved, the results and the products.
Bottom line, it was an enlightening journey but thanks to the hard work from the Ezlo and iBlinds team, the iBlinds product performs really well and iBlinds is offering a huge Black Friday sale [broken link removed] on the v3 iBlinds actuator that pairs using smart start, uses the latest zwave 700 chip, adds manual control, is configurable via zwave parameters, supports OTA firmware upgrades, has better battery life, is faster, quieter, just plain better. If you want to automate existing blinds, then you should buy iBlinds (shameless plug). If you also want to learn more about the result of great people from Ezlo and iBlinds working together, continue reading.
I have been a long-time Vera and iBlinds user and I have installed ten iBlinds v1, 2 vBlinds v2 and 1 iBlinds v3 controllers that worked “fairly well” with my Vera Plus (V+).
When I say, “worked fairly well” on the V+, I found that the open set-point for some of the blinds would drift once in a great while so periodically I had to recalibrate the blinds but it was infrequent enough that I some sort of intermittent edge case. That said, I am fortunate enough to be on the Ezlo beta program and have been testing both the Ezlo Plus (E+) Linux hub and the Ezlo Atom2 (A2) RTOS hub. My real-world test mantra is to first move all completely-automated (autonomous) devices and scenes from the Vera to the Ezlo so my blinds and landscape lighting fell squarely into that category.
I moved 4 of my 10 iBlinds to an E+ and found that the set point drift, as I call it, was much more frequent and quite frankly, to the point that the blinds basically didn’t work. I asked the Ezlo team if they had any ideas what might be different between the V+ and E+ hubs but there wasn’t anything obvious because iBlinds was a pretty standard z-wave window covering device integration. At this point I asked the iBlinds team if they had any ideas and sure enough, it turned out that a certain z-wave command sequence could interrupt the iBlinds processor causing the motor to stop before reaching the target set point and therein lied the problem. The reason it was so much worse with the Ezlo hubs is because Ezlo’s new highly-optimized z-wave stack is so much faster that it consistently fired off the culprit z-wave sequence without breaking a sweat (unlike the V+ firmware). It is important to note that the culprit z-wave sequence is part of the z-wave standard, so the problem was with the iBlinds controller but manifests itself more with a high performance z-wave hub /controller.
The good news is that the iBlinds and Ezlo teams jumped at the opportunity to collaborate and work closely together on the integration so at this point @Oleh (AKA Oleg) from Ezlo was working directly with Eric Barnett (the CTO of iBlinds).
The Ezlo team sent a couple Ezlo hubs to the iBlinds team and the iBlinds team sent an iBlinds v3 controller in a test-jig with a real blind to Ezlo and they also sent an iBlinds v3 controller to me for beta testing.
In addition, the Ezlo team immediately implemented an iBlinds-specific device integration change to avoid the problematic z-wave sequence. Think about this at scale guys, what if every device Ezlo wants to support has some nuance that has to be discovered, analyzed, assessed and implemented only to potentially change when the device manufacturer releases a firmware update or product revision? I believe @MCakan and team do this daily but I digress…
Ezlo Cast is one of the differentiated features of the Ezlo firmware stack. Ezlo Cast multicasts device commands so, in the case of blinds, they should open and close simultaneously but this wasn’t working. In fact, in order for the blinds to even work correctly, I had to add a 1-second delay between each blind open / close action in a scene otherwise the blinds simply wouldn’t respond during scene execution. It turns out that this was due to a general multicast bug in the Ezlo beta firmware that the Ezlo team fixed.
With the multicast fix installed, all of my iBlinds would open and close except for the single v3 iBlinds controller however the v3 blind responded reliably manual commands. It took a bit to understand the root cause but Eric of iBlinds made quick work of fixing it and sent an iBlinds OTA firmware update to me that resolved the multicast on v3 problem.
But even with the Ezlo and iBlind multicast bugs worked out, the blinds would close in unison but still wouldn’t open in unison. This isn’t actually a bug but a manifestation of the fact that I want all blind slats to be perfectly flat when “open”. For some blinds, open is 55%, for others it might be 54% or 56%. Well, you can’t multicast different open target levels simultaneously! iBlinds already accommodates this variance with a z-wave parameter that enables the user to set the open target that the blind should move to when sent a z-wave “on” command. The iBlinds team has recommended device-integration changes to the Ezlo team that enables multicast open that @Oleh and others are mulling over.
As you can see, it has taken quite a bit of time and energy from Ezlo and iBlinds to reach this integration point and there is still more to do to make it perfect (i.e. @MCakan has not added iBlinds to the list of supported devices yet). Throughout this @melih has reminded me countless times that users shouldn’t have to endure this when automating homes and that their vision and goal is to fix this systemic automation-market dysfunction - he says “all smart devices should just work together”.
So as I reflect upon this journey as we approach the US Thanksgiving Holiday, I am thankful that Ezlo bought Vera and that they are working tirelessly to develop and market high-quality automation products. New federated hubs integrated with a myriad of smart devices orchestrated by reliable cloud and local services like Meshene all under the mantra of “All smart devices should just work together” - it ain’t easy for those of you who think it is. I am also thankful for companies like iBlinds, and Eric in particular, who conceive, develop, market and support devices that address a real market need.
Cheers,
Bruce
that you are experiencing the opposite.
Still no action…