IP Devices Integration feedback (split)

I’m intrigued by (and for the moment, essentially on board with) the recommendation by @Odysee that IP-based appliances be treated like another native class of supported devices on ezlo firmware.

However – not to be a Debbie Downer – MCV’s track record of maintaining even the most basic plug-ins for non-Zwave components was abysmal, and I think that has as much to do with the nature of IP appliances as it does the quality of their programmers. Their plug-ins became as stale as week-old French bread.

Unlike a Z-Wave device, which comes out of the box with pretty much 100% of its feature set baked in and ready to integrate, IP-based consumer products like Sonos, Roku, Ecobee, LG, SmartLife, FireTV, etc. are constantly adding features, modifying their client API, and tweaking how the hardware behaves to suit shifting consumer demands.

Thus, to me, this is a case of “Be careful what you wish for!”

In the past, and even today, we’ve seen how these frequent updates were best managed by continual revision to 3rd party Vera plug-ins (ecobee, Sonos, etc.), created and maintained by enthusiasts, not in-house ezlo staff (nor have they ever offered to do so). Even when those codebases went stale, someone else with the gumption and know-how (legendary devs like @amg0, @rafale77, @rigpapa, @akbooer, @therealdb, etc.) picked up the flag and ran with it.

I seriously doubt a non-enthusiast – even someone on the ezlo payroll with this sole responsibility – would (or could) devote the same energy to maintaining the breadth of functionality engendered by IP devices. And I’m even more reluctant to suggest they try, because then the OS/fw becomes a single point of (potential) failure, and we in turn become beholden to “the company timeline/roadmap” for fixing those things when they break.

Conversely, when – for example – one popular TTS provider dropped its free API, leaving lots of Sonos setups mute, @rigpapa quickly stepped in and pivoted to another (free) TTS API almost overnight. When ecobee botched its authentication protocol or began returning spurious data through their API, @rafale77 pounced on the problem, updated his (adopted) Github repo and kept us all moving along.

I’d make the same arguments for HTTP-based services out there, like the ever-shifting public API’s from Dark Sky Weather and its ilk, who (by virtue of becoming popular and useful) constantly get sold and monetized to our collective detriment (APIs get closed, platforms get dropped, etc.). If ezlo were to have those services baked into their firmware, how quickly (if at all) would the necessary modifications be made to suit its users??

tl;dr
Z-Wave, Zigbee, Bluetooth, WiFi, etc. YES
IP, HTTP, UPnP, API, etc. MAYBE?
Exceptions: Alexa, Google Assistant, Siri, IFTTT, etc. MUST!

4 Likes

This. +1000 for this.

A succinct statement of the problem and the reality that solutions in this space will come from, and have come from, dedicated users creating and supporting plug-ins. IP based devices will always be subject to any changes the vendor makes in API, security, authentication, etc.

It’s a moving target that can shift at any time.

1 Like