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

[DParker]

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.

That doesn't make any sense at all as a response to what you quoted...and maybe not as a response to anything, depending on what it is that you're referring to.  My comment that you quoted illustrates the difference in protocol layers involved in a ST hub directly controlling a Zigbee bulb vs farming that job out to a Hue bridge.  For direct control, when a Smart Lighting rule or other automation event triggers a light on/off command neither the internet, TCP/IP nor WiFi/ethernet are involved.  The Smart Lighting app, which runs on the hub, drives the hub's Zigbee radio, which communicates directly with the target Zigbee bulb/switch (or possibly via another Zigbee device acting as a router/repeater, if the hub and target device are too far apart).

[ScottinPollock]

The Smart Lighting app, which runs on the hub

Only with a small number of stock, white listed deviceTypes, none of which are appropriate for me, plus I could never live within the confines of the smart lighting app.

[DParker]

The Smart Lighting app, which runs on the hub

Only with a small number of stock, white listed deviceTypes, none of which are appropriate for me,

A small number?  Here's the list of bulbs, specifically:

- Phillips Hue
- Phillips Hue Bloom
- Phillips Hue Light Strip
- LIFX
- Belkin WeMo Smart LED
- Cree Connected
- OSRAM Lightify, bulbs & strip
- Sengled Element Touch
- Sylvania Ultra iQ
- GE Link
- TCP Connected

Then there are the mamy switches, sensors, etc as well.

plus I could never live within the confines of the smart lighting app.

Remember that we're talking about i stances of temporary loss of internet service here, not the zombie apocalypse.  How often do you lose service, without also losing power, for extended periods of time?

[Floridadomer]

ScottinPollock and DParker, you're making my head spin....LOL 

[ScottinPollock]

A small number?  Here's the list of bulbs, specifically:

Remember that we're talking about i stances of temporary loss of internet service here, not the zombie apocalypse.  How often do you lose service, without also losing power, for extended periods of time?

Were also talking about the device types used for the triggers, of which practically all of mine are custom. Nothing runs locally on my hub.

And it isn't internet service, it's the SmartThings cloud, which is the closest thing to a zombie apocalypse I have seen in quite some time. (c;

[DParker]

Were also talking about the device types used for the triggers, of which practically all of mine are custom. Nothing runs locally on my hub.

What bulbs are you able to control with your Hue Bridge that require custom device types in SmartThings?

[ScottinPollock]

Were also talking about the device types used for the triggers, of which practically all of mine are custom. Nothing runs locally on my hub.

What bulbs are you able to control with your Hue Bridge that require custom device types in SmartThings?

Not the bulbs, the triggers (switches, sensors). Then of course there are the smartapps, none of which are supported locally.

[DParker]

Not the bulbs, the triggers (switches, sensors). Then of course there are the smartapps, none of which are supported locally.

I thought we were talking about what having a Hue Bridge buys you in terms of reliability due to its local operation.  Specifically, what switches/sensors can the Hue Bridge communicate with under circumstances where the ST Hub couldn't?

[ScottinPollock]

I thought we were talking about what having a Hue Bridge buys you in terms of reliability due to its local operation.  Specifically, what switches/sensors can the Hue Bridge communicate with under circumstances where the ST Hub couldn't?

I feel we are simply going round in circles at this point so let's just agree to disagree. I have many scenes recorded in shell scripts that talk directly to the bridge. This is the only way I can instruct Hues to use the transitionTime property. The scenes are triggered from custom switch types, whose physical devices control no load, and rotate through scenes based on multiple on presses, sending commands via a custom smartapp to a server that executes the scripts.

Moreover, I communicate directly to that same server via Tasker and iRule from my android devices, Indigo, BASH scripts on both desktop and laptop computers, and Alexa via custom virtual device types. I also use third party apps such as Hue disco to control my Hues based on sound in the room... really like this one for taking a long jacuzzi while listening to music.

I also have a smart app that controls the timed transition of color on hues that executes when the shower is turned on. When they reach orange from blue, I know the shower has come up to temp.

My server also handles all lighting schedules, and timed/delayed actions 'cause, well, face it, SmartThings hasn't got that right in years.

None of this is possible without the bridge.

[DParker]

I feel we are simply going round in circles at this point so let's just agree to disagree.

I'll certainly agree to disagree that we've gone in circles.  Quite the contrary, we've gone in a straight line from a claim that having a Hue Bridge in addition to a ST Hub provides the capability of hub-local light automation functionality that ST allegedly lacks...to finding out that isn't true (in addition to multiple other claims that turned out to be equally untrue).

My server also handles all lighting schedules, and timed/delayed actions 'cause, well, face it, SmartThings hasn't got that right in years.

Really?  They work correctly in my rules.

None of this is possible without the bridge.

Actually, it's all quite possible using existing custom ST device types (including at least one that supports the transitionTime property).  It's just that the methods you've used to accomplish these things are dependent on the bridge.

[ScottinPollock]

Really?  They work correctly in my rules.

Lucky you.

And here is your next circle...

we've gone in a straight line from a claim that having a Hue Bridge in addition to a ST Hub provides the capability of hub-local light automation functionality that ST allegedly lacks...to finding out that isn't true... it's all quite possible using existing custom ST device types

And there goes your local operation.

[ScottinPollock]

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.

And how does Tasker, iRule, and your PC communicate to your lights locally again?

[DParker]

And here is your next circle...

we've gone in a straight line from a claim that having a Hue Bridge in addition to a ST Hub provides the capability of hub-local light automation functionality that ST allegedly lacks...to finding out that isn't true... it's all quite possible using existing custom ST device types

And there goes your local operation.

What you've done here is to take two comments about two different things, pulled them from their context and edited them together as though they refer to the same subject.  The first refers to your claims that ST lighting control is dependent on cloud connectivity, which means that you lose the ability to control your lights in the event of cloud/internet failures, which is untrue.

The second refers to the claim that it "isn't possible" to do things like access the Hue transitionTime property without the Hue Bridge, which is also untrue.

Circle avoided, especially when you remember what this entire line of conversation was about:  Whether or not buying, configuring and using a Hue Bridge in addition to a ST Hub provides any value in general, not for your bridge-dependent setup specifically.  For the majority of people...who don't don't have any use for colored lights (save for on the tree and the outside of the house at Christmas time) and whose lighting automation wants/needs consist of having lights turn on/off at certain times of the day and/or in response to sensors triggering, the bridge adds nothing but complexity.

And how does Tasker, iRule, and your PC communicate to your lights locally again?

I'm not an Apple user, so I don't know anything about iRule and did not make any claims about it.  My PC communicates via Zigbee and Z-Wave USB dongles.  I also didn't claim that Tasker communicates with my lights locally.  I said that the ST Hub does, just like "all those things" do.  But now that you mention it, I see this note from AutoHue (the Tasker plug-in for Hue):

"Hue Note: For the Hue lights the app only works on your local (WIFI) network, this is currently the case due to a restriction in the Hue API."

So, local access...but ONLY local access.  Bummer.

By the way, I find it interesting that you've gone from this...

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.

...to an argument that's centered on just how much you've built up around and are dependent on one specific controller:  The Hue Bridge.

[ScottinPollock]

What you've done here is to take two comments about two different things, pulled them from their context and edited them together as though they refer to the same subject.  The first refers to your claims that ST lighting control is dependent on cloud connectivity, which means that you lose the ability to control your lights in the event of cloud/internet failures, which is untrue.

The second refers to the claim that it "isn't possible" to do things like access the Hue transitionTime property without the Hue Bridge, which is also untrue.

To me it is the same thing. I can't use Hues the way I want with the SmartThings hub locally. You can take it apart for the sake of argument by saying the car will still go without gas. But I don't just want to go downhill.

I'm not an Apple user, so I don't know anything about iRule and did not make any claims about it.  I also didn't claim that Tasker communicates with my lights locally.

So "Ditto all of those things and my ST Hub" was just an oversight. See, you are fallible. (c;

But now that you mention it, I see this note from AutoHue (the Tasker plug-in for Hue):

"Hue Note: For the Hue lights the app only works on your local (WIFI) network, this is currently the case due to a restriction in the Hue API."

So, local access...but ONLY local access.  Bummer.

While I don't use the plugin, all Hue API access is local. If I need remote I use the Hue app or SmartThings, but there is usually no need for remote access to lights.

By the way, I find it interesting that you've gone from this...

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.

...to an argument that's centered on just how much you've built up around and are dependent on one specific controller:  The Hue Bridge.

Shouldn't be all that interesting. I use what works best; in this case the bridge. In fact, the SmartThings hub almost never talks to the Hue integration (I think I have one app that shuts them down after a power failure - but that could easily be moved to a shell script - and probably will now that I think about it). The only reason I keep Hue Connect around is for remote access, and I can't recall ever using it. Frankly, everything I could pull from SmartThings I have. Only the Echo has refreshed my interest in it as a means to get commands to my server via virtual devices.

SmartThings has been a mess for an awfully long time. Why just this morning, after the big platform fix rollout, automated things weren't automated due to my morning routine not executing. I have seen these types of glitches regularly for the past two years. So my conclusion is that it is not reliable, and I don't want my lights dependent on it, especially since "I" can not achieve local operation due to me having my own code. Add to that I believe Samsung will eventually ruin it, or kill it in its current form.

I suppose if all you want is to turn white lights off and on, what you have is fine. But most Hue users I have met prefer color, and do creative things with them. I have dozens of scenes involving dozens of lamps, and I like to change things up. Compare editing a shell script to having to change those same settings in the mobile app (yuk).

So, the things I do with Hue, are far simpler to achieve using the local API, and far easier to control using various tools on mobile that can communicate with it directly as opposed to oAuthed endpoints on the physical graph. To me, having the bridge offers up way more than not having it. Folks who go your route cut themselves off from much of the Hue echosystem including Tap and third party apps (and who knows what else is coming), and effective mobile control. I see little merit in the downside you site, and feel strongly that the average Hue user won't either.

Anyway, feel free to have the last word... ScottinPollock has left the building. (c;

[DParker]

To me it is the same thing. I can't use Hues the way I want with the SmartThings hub locally. You can take it apart for the sake of argument by saying the car will still go without gas. But I don't just want to go downhill.

That's a horrible analogy.  The primary function of controlling lighting via these gizmos is the automation rules we create.  My rules continue to function the same whether my hub has internet access (the "gas" in your your analogy) or not.

So "Ditto all of those things and my ST Hub" was just an oversight. See, you are fallible. (c;

I'm extremely fallible....but this isn't an example of an oversight or other error on my part.  Let me try it a third time/way:  "Ditto all of those things and my ST Hub" was a response to your listing things that access Hue directly.

While I don't use the plugin...

OK, then Tasker was irrelevant.

Shouldn't be all that interesting. I use what works best; in this case the bridge. In fact, the SmartThings hub almost never talks to the Hue integration (I think I have one app that shuts them down after a power failure - but that could easily be moved to a shell script - and probably will now that I think about it). The only reason I keep Hue Connect around is for remote access, and I can't recall ever using it. Frankly, everything I could pull from SmartThings I have. Only the Echo has refreshed my interest in it as a means to get commands to my server via virtual devices.

Still, a great deal of build up and dependency on a single platform.

I suppose if all you want is to turn white lights off and on...

Which is the vast majority of what lighting automation does.  Most people aren't using this stuff to run night clubs.

But most Hue users I have met...

Ah, but see...that's the thing.  I'm not a "Hue user".  I'm a user of smart lighting.  Hue just happened to have been one of the companies whose hardware I used (that is, until I gave the bridge and the two bulbs that came with it to my daughter, after replacing them with ST and much cheaper...but no less reliable...GE Link bulbs and switches).

Folks who go your route cut themselves off from much of the Hue echosystem including Tap....

How in the world am I cut off from Tap?

Anyway, feel free to have the last word...

[/quote]

Oh, c'mon now.  This is just a friendly exchange of strongly-held opinions.  There's no need for that sort of thing.