Native support for Philips Hue
-
Any plans to add native support for the Philips Hue Bridge / API to control Hue lights / Zigbee 3.0 devices.
I'm currently using the Alt Hue plugin on Vera but that might not be the case forever.
And I know it's EOL but support for the Harmony hubs would be handy also. Starting / stopping Harmony actives and being able to send commands to IR devices like with Renee's Harmony plugin for Vera and the http API it creates.
-
This jibes with my response to your recent reply on the Vera/eZLO forums. I'm not a Hue or Harmony user, but there is nothing to prevent someone who is from writing and supporting the interface for MSR. It's probably not appropriate for me to do it, because I'm not a user of these devices, so I would not only face the expense of sourcing the hub and what could be a significant mix of common devices, but also the learning curve that others have already overcome. Someone who is an enthusiastic user of these devices that also has the necessary programming skill is probably already out there, and is really the right choice, and that model pervades all of the platforms we work on (the plugins on Vera, the components in Hass, the device drivers and apps in Hubitat).
Also remember that a big reason MSR exists is to give you the flexibility to choose the best platform for the device you want to use. If the Vera support is a little clumsy or thin for a device, it may be that Hass or Hubitat is better (all my Zigbee stuff is on Hubitat at the moment, for example). Sure, it would be ideal to have a direct interface, and that's definitely part of the plan, but the shortcut for today may simply be to move your Hue or Harmony support to Hass or Hubitat and let MSR access it there.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
As I commented on the other forum, and after having already bought several lights and none worked with Vera due to Zigbee incompatibility, I followed what @cw-kid recommended, and bought the Hue hub, to finally have lights that can be controlled. As soon as it arrives I will install it, and then use the Vera plugin, but I am one step away from buying a Hubitat, because the recurrent problems of Zigbee having many devices available and nothing talking to Vera, and recently every new z-wave device that has the S2 security protocol is a huge headache to work with Vera, I am thinking of really going for a new hub. And of course, I will not make the mistake of being an ezlo.
-
This jibes with my response to your recent reply on the Vera/eZLO forums. I'm not a Hue or Harmony user, but there is nothing to prevent someone who is from writing and supporting the interface for MSR. It's probably not appropriate for me to do it, because I'm not a user of these devices, so I would not only face the expense of sourcing the hub and what could be a significant mix of common devices, but also the learning curve that others have already overcome. Someone who is an enthusiastic user of these devices that also has the necessary programming skill is probably already out there, and is really the right choice, and that model pervades all of the platforms we work on (the plugins on Vera, the components in Hass, the device drivers and apps in Hubitat).
Also remember that a big reason MSR exists is to give you the flexibility to choose the best platform for the device you want to use. If the Vera support is a little clumsy or thin for a device, it may be that Hass or Hubitat is better (all my Zigbee stuff is on Hubitat at the moment, for example). Sure, it would be ideal to have a direct interface, and that's definitely part of the plan, but the shortcut for today may simply be to move your Hue or Harmony support to Hass or Hubitat and let MSR access it there.
If a user could give you remote access to a device such as the Hue hub, might that be of interest to you, to program against?
-
This jibes with my response to your recent reply on the Vera/eZLO forums. I'm not a Hue or Harmony user, but there is nothing to prevent someone who is from writing and supporting the interface for MSR. It's probably not appropriate for me to do it, because I'm not a user of these devices, so I would not only face the expense of sourcing the hub and what could be a significant mix of common devices, but also the learning curve that others have already overcome. Someone who is an enthusiastic user of these devices that also has the necessary programming skill is probably already out there, and is really the right choice, and that model pervades all of the platforms we work on (the plugins on Vera, the components in Hass, the device drivers and apps in Hubitat).
Also remember that a big reason MSR exists is to give you the flexibility to choose the best platform for the device you want to use. If the Vera support is a little clumsy or thin for a device, it may be that Hass or Hubitat is better (all my Zigbee stuff is on Hubitat at the moment, for example). Sure, it would be ideal to have a direct interface, and that's definitely part of the plan, but the shortcut for today may simply be to move your Hue or Harmony support to Hass or Hubitat and let MSR access it there.
@toggledbits as I’ve already said, I think mqtt could be a better investment than ezlo hubs support (used by 100 people). There are plenty of libraries doing something-to-mqtt, so this could let people add more things very easily.
-
MQTT work is already under way, as is ZWaveJS. Since those are "drop-in" features, they are not version-dependent, so I don't have any urgency around getting them done in time for the 1.0 release, but MQTT will probably make an appearance in preview form (at least) in late Summer or early Autumn.
-
T toggledbits locked this topic on
