Lighting systems....so confused ...Please Help

[DParker]

If you haven't already made a decision, I can say I have been with Hue an awfully long time, and it is flat out the best system out there. From a bridge that is locally controlled when you are home (no internet needed), and remotely controlled when you are away; to a great local API with superb documentation; lots of cool third party apps; 100% reliability; better support, more frequent upgrades, and new features, SDKs, Frameworks, devices coming all the time.

IMHO, Philips is the poster child for how to do smart lighting and the IoT right. No one compares at this point, and tieing your lights to something like the Wink or SmartThings hubs is like greasing your wheels LocTite. Yeah, they're a little pricier than some other stuff but worth every penny!

I'd agree with all that.  In fact the only hiccup I experienced (and it was a big one) when I was still using a Hue Bridge (before moving to SmartThings) was when Phillips pushed a software update out that intentionally broke the bridge's ability to work with GE Link bulbs, which are significantly less expensive than the Phillips' Lux bulbs.  But there was such an outcry from customers that they immediately realized what a bad PR move that was and quickly rolled back the update, restoring that ability to the bridge.

The real downside is that the Hue Bridge is not a general home automation solution, and is dedicated solely to controlling lighting...and even there you're somewhat limited.  Though of course that's only a problem if you end up wanting to control more than just basic lighting.

[Floridadomer]

Thank you for all of the advice. I ended up going with the Philips Hue starter kit with the two white lights and have bought two additional lights.
I did discover when using it in a lamp that if the lamp has a switch that you turn, Alexa can turn it off but not on. I also have a lamp that has a pull chain, and that one works both off and on with Alexa.

[fstbusa]

with smart bulbs, they have to have power to them all the time in order to connect to the network.

[Floridadomer]

I figured that one out when I had turned off a wall switch then asked Alexa to turn on a light. I thought when I turned the knob\switch and it turned it on, the the lamp would be in a power on state. Apparently that's not the case.

[dredigi0]

I'm running the Lutron Caseta system in my house...so far 6 switches installed and loving it (of course it works with Echo) I decided to go the switch route instead of bulbs because it semi permanent and unlike bulbs leaves your options open to turn anything plugged in on/off

$60 bucks pers switch but ti's really slick once you get it going, you create "scenes" with the system to have it light up rooms in set configuration or you can group them in alexa to turn areas on/off.

[DParker]

Thank you for all of the advice. I ended up going with the Philips Hue starter kit with the two white lights and have bought two additional lights.
I did discover when using it in a lamp that if the lamp has a switch that you turn, Alexa can turn it off but not on. I also have a lamp that has a pull chain, and that one works both off and on with Alexa.

I'm not certain that I follow the bolded statement above.  Are you saying that when you power on the lamp via its built-in switch, the Hue Bridge is able to turn the LED in the bulb off, but not back on again?

I figured that one out when I had turned off a wall switch then asked Alexa to turn on a light. I thought when I turned the knob\switch and it turned it on, the the lamp would be in a power on state. Apparently that's not the case.

Perhaps I'm misunderstanding what's happening here, but in the case of a floor/table/ceiling lamp with its own power control (not a wall switch), if you're losing control of the bulb after issuing an "off" command via the bridge then there's something wrong.  When you turn the knob/switch to the "on" position, indicated by the bulb lighting up, the lamp remains in an on state and the bulb continues to be powered even after the LED in the bulb is turned off due to a Zigbee protocol command from the bridge.  Implementation of commands from the bridge by the bulb have no effect at all on the powered state of the lamp.

[DParker]

I'm running the Lutron Caseta system in my house...so far 6 switches
:
{snip}
:
$60 bucks pers switch...

Ouch.  GE Link dimmer switches can be had for <$40 each in the Z-Wave flavor, and they even have a ceiling fan controller for just a few buck more (I have one of each for controlling the fan and its integral light in my family room).  Z-Wave dimmers from Linear are even cheaper, but I've had problems with those and can't recommend them.

[ScottinPollock]

The real downside is that the Hue Bridge is not a general home automation solution, and is dedicated solely to controlling lighting...and even there you're somewhat limited.  Though of course that's only a problem if you end up wanting to control more than just basic lighting.

I don't see how that is a down side when Hue's bridge API/SDKs/Frameworks has allowed for support from SmartThings, IFTTT, Wink, and practically every other IoT/HA platform. They are the major player in smart lighting, and tools they provide devs means it is usually one of the first integrations you will see on virtually any device/platform; Echo included.

What I actually see is an upside. That having the bridge, means local control if other platform connectivity (SmartThings, Internet, etc.) goes down. I can put up with a lot of issues with SmartThings, but losing control of my lights is not one of them.

[DParker]

I don't see how that is a down side when Hue's bridge API/SDKs/Frameworks has allowed for support from SmartThings, IFTTT, Wink, and practically every other IoT/HA platform. They are the major player in smart lighting, and tools they provide devs means it is usually one of the first integrations you will see on virtually any device/platform; Echo included.

What I actually see is an upside. That having the bridge, means local control if other platform connectivity (SmartThings, Internet, etc.) goes down. I can put up with a lot of issues with SmartThings, but losing control of my lights is not one of them.

It's a downside because if you're using a more comprehensive solution like ST, adding the Hue Bridge into the path between ST and your lighting represents an unnecessary additional device (and associated cost), internet-based account, configuration, etc.  Granted, the Hue Bridge gives you some failover capability in the event of an internet outage....though as of v2 of the ST hub the "Smart Lighting" app was modified to run locally on the hub, so at least it continues to function and control all Zigbee/Z-Wave lights even if you yank the ethernet cable.  As for the rest, I can just manually operate switches in the event of a temporary outage.  Honestly, if my internet goes down I have all sort of other stuff that are going to be a much bigger annoyances to me.

[Floridadomer]

I figured that one out when I had turned off a wall switch then asked Alexa to turn on a light. I thought when I turned the knob\switch and it turned it on, the the lamp would be in a power on state. Apparently that's not the case.

Perhaps I'm misunderstanding what's happening here, but in the case of a floor/table/ceiling lamp with its own power control (not a wall switch), if you're losing control of the bulb after issuing an "off" command via the bridge then there's something wrong.  When you turn the knob/switch to the "on" position, indicated by the bulb lighting up, the lamp remains in an on state and the bulb continues to be powered even after the LED in the bulb is turned off due to a Zigbee protocol command from the bridge.  Implementation of commands from the bridge by the bulb have no effect at all on the powered state of the lamp.
[/quote]

Yes you have it correct. There isn't a wall switch that controls it. The odd thing is that I have no other issues with the other connected bulbs turning off/on or dimming. Thank you for all of your input!

[ScottinPollock]

It's a downside because if you're using a more comprehensive solution like ST, adding the Hue Bridge into the path between ST and your lighting represents an unnecessary additional device (and associated cost), internet-based account, configuration, etc.

You and I think very differently about this. I don't own a SmartThings thermostat; I have one with an open API that I integrated with SmartThings. I don't have a SmartThings remote control; I have iTachs with an open API that I integrated with SmartThings. I don't have a SmartThings computer... well, you get the idea.

I don't see lighting any differently. It is (and I prefer it that way) another switch on the network.

While my Hues are integrated with SmartThings, Alexa talks to them directly; as does my scene controller (a Mac Mini). SmartThings can talk to them as well, but so does Tasker and iRule.

Putting all of your eggs in a SmartThings basket (or any kind of singular controller) makes for fewer options (why open the painfully slow SmartThings app when I can just tap a shortcut on my phone's home screen), and a complete teardown/rebuild should something go unsupported. I myself have learned over the last several decades that one protocol/device is the wrong way to go, and that integrating individual, open API based systems gives you a much more versatile and future proof design. One of SmartThings biggest advantages over its competitors is being able to easily integrate various subsystems; it be a shame to ignore it.

The added cost is a drop in the bucket in the grand scheme of things, and as far as unnecessary, is every drop on your net connected to the same switch? Every WiFi node connected to the same AP? Of course not; every well designed network has branches. And while I suppose you could deem them as unnecessary, they have purpose.

[DParker]

You and I think very differently about this. I don't own a SmartThings thermostat; I have one with an open API that I integrated with SmartThings. I don't have a SmartThings remote control; I have iTachs with an open API that I integrated with SmartThings. I don't have a SmartThings computer... well, you get the idea.

That's not really any different from the way I view the system as a whole.  Let' see why:

I don't see lighting any differently. It is (and I prefer it that way) another switch on the network.

Here's where there's some difference between us.  Your (and my) thermostats and similar devices are interfaced with via proprietary API abstraction layers because those devices don't support any standard, open protocols for directly exposing their functionality.  While I also view lighting as "just another switch on the network" I realize that the bulbs themselves ARE network elements that implement and are accessible via an open API and set of protocols (Zigbee), and that operate as "End Devices" (and perhaps also as "Repeaters"/"Routers") subordinate to a "Coordinator" (the role filled by the bridges/hubs).  Since the ST Hub includes that Zigbee Coordinator function, as well as all of the automation capabilities of the Hue Bridge (and more) the Bridge is a superfluous additional layer.  If the protocol(s) between the Hue Bridge and the lights was/were proprietary, required some special software extension be added to the ST environment or was/were subject to change by Phillips on their own whim then using the Bridge as an abstraction layer, so as to insulate your architecture from suddenly introduced incompatibilities would make sense.  But Zigbee (and Z-Wave, for that matter) is an open set of network protocols, just like 802.11, and having the ST Hub fulfill the roll of Zigbee Coordinator not only eliminates a pointless (in my view) additional layer (and set of communications hops, and one additional device to malfunction, etc), it also strips away the limitation of being able to use only those device features that the Hue API chooses to expose, and in only the way(s) that it chooses to allow you to use them.

In short, my Z-Wave and Zigbee mesh networks ARE a type of subsystem that ST is interfacing with.  Adding the Hue Bridge as yet another abstraction layer to that architecture just doesn't buy my anything that I deem to be of any value.

My ST Hub also interacts directly with other Z-Wave & Zigbee devices as well (motion sensors, switches, etc.)  Would there be any point in similarly inserting some other company's Controller device between them and the ST Hub?  I don't see one.

While my Hues are integrated with SmartThings, Alexa talks to them directly; as does my scene controller (a Mac Mini). SmartThings can talk to them as well, but so does Tasker and iRule.

Ditto all of those things and my ST Hub.

Putting all of your eggs in a SmartThings basket (or any kind of singular controller)...

But that's not at all what I'm doing.  It is not a SmartThings architecture.  SmartThings is simply filling one role (controller/coordinator) in a HA ecosystem that consists of devices that implement various interface protocols, some open...some proprietary.  Having ST interface with them as directly as practical means that I have fewer places that I need to go, and steps to go through, to add new devices to that ecosystem.  Since the ecosystem is based on open standards I can use a different controller at a future date if I need to, or add more to it if there's some compelling reason to.

makes for fewer options (why open the painfully slow SmartThings app when I can just tap a shortcut on my phone's home screen)

I almost never use my ST phone app to control anything.  I have automation rules, Echo, etc for that.  The app is used for making configuration/rule changes.  The speed of starting the app is a complete non-issue for me.

and a complete teardown/rebuild should something go unsupported.

I'm not sure how having a Hue Bridge makes any difference there.

I myself have learned over the last several decades that one protocol/device is the wrong way to go, and that integrating individual, open API based systems gives you a much more versatile and future proof design.

I've been a software engineer for ~30 years, and I learned that lesson decades ago myself...which is why I'm most definitely NOT building my HA on "one protocol/device", and am also "integrating individual, open API based systems".  The only difference here is that I recognize my Zigbee mesh network and the lights that are a part of it as an open API based system.

One of SmartThings biggest advantages over its competitors is being able to easily integrate various subsystems; it be a shame to ignore it.

I agree.  That's why I'm not ignoring it.

The added cost is a drop in the bucket in the grand scheme of things

Yes, the cost of the Hue Bridge is a very small part of the overall cost of a HA system.  But it's a cost that doesn't buy me anything I want/need, and as such represents a bad value.

and as far as unnecessary, is every drop on your net connected to the same switch? Every WiFi node connected to the same AP? Of course not; every well designed network has branches. And while I suppose you could deem them as unnecessary, they have purpose.

Are you talking about a home TCP/IP network, or one set up to handle a substantial business?  I have one active WiFi router in my house (with a spare in the closet in case of a malfunction) that handles all internet traffic, and several devices that communicate directly with one another via WiFi, Bluetooth, Zigbee and Zwave.  I'm automating a home as a fun hobby, not building the next Space Shuttle.

[ScottinPollock]

Adding the Hue Bridge as yet another abstraction layer to that architecture just doesn't buy my anything that I deem to be of any value. Yes, the cost of the Hue Bridge is a very small part of the overall cost of a HA system.  But it's a cost that doesn't buy me anything I want/need, and as such represents a bad value.

I certainly don't see the Hue bridge as being more of an abstraction than bouncing back and forth with the physical graph in order to turn on a light bulb. And unless you have created your own device type, which would facilitate that, you're leaving color cycling, alerts, and transition times off the table (the latter two of which are important to me).

My ST Hub also interacts directly with other Z-Wave & Zigbee devices as well (motion sensors, switches, etc.)  Would there be any point in similarly inserting some other company's Controller device between them and the ST Hub?  I don't see one.

Actually, now that you mention it, I would much prefer an agnostic controller for those devices, separated from the brains of the system. Much like we had powerLinc modems in the insteon days that could be driven by any brains we chose to implement.

While much of the SmartThings platform is open, the back end is decidedly closed. Good luck with your directly connected Hues when that is acting up. If possible, I will always have more than one way to cook dinner if the power is out, or if I forgot to fill the propane tank.

The thing I dislike most about SmartThings, is that I can't tell it to control its devices without traversing the cloud. Don't get me wrong, the cloud presents clear advantages for notifications and non-local control, but that should be in addition to local control and not in lieu of it. Philips got this right... obviously SmartThings didn't (or at least hasn't up 'til now and for the foreseeable future).

[DParker]

Adding the Hue Bridge as yet another abstraction layer to that architecture just doesn't buy my anything that I deem to be of any value. Yes, the cost of the Hue Bridge is a very small part of the overall cost of a HA system.  But it's a cost that doesn't buy me anything I want/need, and as such represents a bad value.

I certainly don't see the Hue bridge as being more of an abstraction...

Point of order:  I didn't say it was "more of an abstraction" than anything.  I said it added "yet another abstraction layer" to the architecture, which it most certainly does.  And it adds MULTIPLE protocol layers (and this is a simplification):

ST <-> Zigbee Protocols <-> Bulb

vs.

ST <-> Hue Bridge REST API <-> HTTP <-> TCP/IP <-> HTTP <-> Hue Bridge REST API <-> Zigbee Protocols <-> Bulb

...than bouncing back and forth with the physical graph in order to turn on a light bulb.

I'm not sure what you mean here, but accessing your bulbs via the Hue Bridge doesn't result in less of anything when it comes to turning on a bulb.

And unless you have created your own device type, which would facilitate that, you're leaving color cycling, alerts, and transition times off the table (the latter two of which are important to me).

Again, I'm not sure what you're saying here.  I couldn't care less about color cycling (I have no use for colored bulbs), and I don't know how I'm leaving alerts and/or transition times "off the table" (or what that means in this context).

Actually, now that you mention it, I would much prefer an agnostic controller for those devices, separated from the brains of the system. Much like we had powerLinc modems in the insteon days that could be driven by any brains we chose to implement.

How is that different from/more beneficial than the hub controlling lights via an open standard protocol suite like Zigbee?  You're just substituting one abstract API for another.

While much of the SmartThings platform is open, the back end is decidedly closed. Good luck with your directly connected Hues when that is acting up. If possible, I will always have more than one way to cook dinner if the power is out, or if I forgot to fill the propane tank.

You have your Hue bridge controlling your oven?  As for the lights, I have these sophisticated backup systems called "physical switches" I can resort to if need be.

The thing I dislike most about SmartThings, is that I can't tell it to control its devices without traversing the cloud. Don't get me wrong, the cloud presents clear advantages for notifications and non-local control, but that should be in addition to local control and not in lieu of it. Philips got this right... obviously SmartThings didn't (or at least hasn't up 'til now and for the foreseeable future).

Here we (and most of the ST customer base, as far as I can tell) see eye-to-eye.  Using the cloud as a way to expand access to your system is great.  But reliance on the cloud for basic functionality sucks.

[ScottinPollock]

ST <-> Zigbee Protocols <-> Bulb

vs.

ST <-> Hue Bridge REST API <-> HTTP <-> TCP/IP <-> HTTP <-> Hue Bridge REST API <-> Zigbee Protocols <-> Bulb]

You do understand that with my setup, the overwhelming number of Hue commands never leave my LAN, while all issued from the SmartThings hub traverse the Internet via encrypted traffic.