Phillips hue/ST integration bug

I give credit to @jnick for discovering this bug.

I did a quick search for this but didn’t find anything dealing with the Phillips bulbs and bridge.

System hardware:
ST v2 hub, 1st generation Phillips bridge, Phillips hue and lux bulbs (1st & 2nd gen bulbs), Amazon echo

System configuration:
ST and hue bridge integrated via hue connect smart app. ST and Hue linked to Amazon Alexa in Alexa app and in the ST app.

Bulbs are paired to the hue bridge. They are authorized for use by the ST hub. They are NOT authorized for use with Amazon echo from within the ST/Alexa smart app.
The bulbs are controllable by Amazon echo via the Phillips/echo link within the actual Amazon Alexa application.

Bug:
Turn on/off Phillips bulb via Amazon echo. ST app takes up to five minutes to update the status of the bulb.

Info:
Amazon echo is still able to turn on/off, dim, and otherwise control the Phillips bulb regardless of the status of the bulbs within the ST app.

Impact:
I have personally seen this but did not realize what the problem was until tonight. When a hue bulb is turned on/off via Amazon echo and a ST routine/rule/function is activated within a shirt time if the bulb state change; the Phillips bulb will not respond properly.

Result:
Failed routines and dissatisfaction

Repair:
I have not developed a rule machine work around at this time, I am working with @jnick to find one. I will post the resolution in this thread once found.

@slagle is this a known bug? Is there a repair in line?

I am submitting all of this to support.

Edit: support ticket #194177

This is not a bug. It is the polling timing which has been much discussed in the forums.

SmartThings polls the Hue Bridge approximately once every five minutes and gets the status of the bulbs at that time. This has been the known behavior for about a year.

If the bulbs are turned off by any means other then through the official smartthings connection, then it can take up to five minutes to see the updated status in smartthings. That’s all.

That includes turning them off via harmony, via echo, via a Phillips hue dimmer, via the official Hue app, via Beecon plus, via global cache, via a third-party app, etc.

It’s just how parallel means of control work with SmartThings and the Hue bridge.

Here is a link to one of the forum topics that discusses this.

JD,
I knew I could count on you to set me straight. Though, I still call it a bug fire the simple reason that an official integration should work seamlessly in its use.

This architecture can seriously limit the use of Phillips hardware, thus a bug.

Or, I suppose it would be better said like this, “an ST architecture programming failure”

Thanks.

Hue does not have an “event” api so we cannot get instant status no matter which way you shake it.

2 Likes

As a follow up, a fix for this would be controlling the hue bulb through the Smartthings echo integration instead of directly to the hue hub.

Limitation, not a bug. It’s a royal PIA to synchronize the state of Hue bulbs, or the state of most c2c integrations for that matter. Managing devices from ST is the best practice, but if that is not possible, I use virtual switches to update ST on the state of the device ( I do that with Wemo outlets, for example).

1 Like

If you read the linked thread, I think this one can be blamed more on Philips. Their API doesn’t offer a change in state notification.

You can see what support says. :sunglasses:

BTW, if you just want a workaround, add a virtual switch for each hue bulb. Then add each virtual switch and its hue to its own Echo group.

Then in SmartThings have that the Hue bulb follow its virtual switch.

The result is that each Hue bulb will get two instructions to turn on or off when you use echo, but that shouldn’t make any difference. And your SmartThings statuses will be up-to-date within a few seconds instead of five minutes.

There may be some similar way to do this with Rule machine, I’m not sure. I think you will still have to have the virtual switch so that echo can turn that on or off.

Back in my working days we used to call this a “shadow switch.” I think the technical term is “virtual representation.” But that’s too hard to say. :wink:

Anyway, it’s a little bit kludgy to set up, but it should work just fine to reduce the out of sync condition to a couple of seconds.

The problem with this is you then get multiple instances of the bulb in the Amazon Alexa app, and then there are problems controlling it via echo.

The workaround for that is to create a room in the Alexa app, place the multiple/same bulbs in that room and control them via the room name.

You’re right that adding the hue bulbs to Echo through SmartThings creates problems for Echo.

But if you use the shadow switches, you won’t have multiple instances. :sunglasses: You will have one instance of the Hue bulb, and one instance of the virtual switch. It’s up to you to remember to include the virtual switch in any echo group that includes its related hue.

But the Hues are added to echo only through the official Phillips app while the virtual switches (and not the hue bulbs) are authorized to Echo through SmartThings.

Ok, it’s late here and you lost me on this one… Plus it’s been a while since I authorized a Phillips bulb via ST to Alexa.

You’re not going to change anything about the Phillips bulbs at all. Just leave them the way they are. :sunglasses:

  1. You’re going to add one new virtual switch to SmartThings for each Phillips hue bulb. Then have Alexa discover those new devices.

  2. Add a new ST rule for each virtual switch to have its Phillips hue bulb follow it for both on and off.

  3. Go into the Alexa app (not the ST smartapp, I mean the official Amazon app for Alexa). Add one new echo group for each Hue bulb and include in it that hue bulb and its related virtual switch.

  4. if you had any echo groups that included more than one hue bulb add the associated virtual switch for each of those hue bulbs to that echo group.

That should do it. You can keep all your existing ST rules and routines for your HuE bulbs and they’ll work just the way they always did.

When you want to turn bulbs on or off with echo, say the name of the echo group, not the name of the individual bulb. That way echo will request that the Phillips bridge turn the bulb on and will request that smartthings turn the virtual switch on. Then because of the rules you set up in 2), smartthings will try to turn on the bulb because the virtual switch just turned on. That will get the status back in sync.

The bulb won’t care that it gets two on requests in a row.

It’s still theoretically possible that you might encounter an out of sync condition in those few seconds between the time when echo tells the Hue bridge to turn on the bulb and then smartthings tells the bridge to turn on the same bulb, but at least it should happen a lot less often than with a five-minute polling period.

Or just forget the hue hue bulbs in the Alexa app and add the Smartthings hue bulbs that’s what I have done and I do not have this issue and the bulb only shows up once for Alexa. :slightly_smiling:

2 Likes

Can I ask a very simple question regarding the polling cycle? Its bandied about that polling is every 5 minutes or less frequent, this part I understand to avoid over polling the device however I have modified my hue integrations actions (on, off, setcolor etc…) to run the poll immediately after the action. This gives pretty immediate bulb updates. provided you don’t go stupid with switching the bulb on/off very frequently (why would you anyway) this works well and keeps polling to a minimum

Understood this might never come out the door in official integration, however for those like myself with a large number of unsupported devices (I like to write my own device types) who don’t use local processing, then you won’t lament the loss of your updated hue integration being unable to run locally.

Simple solution to this annoyance - use Pollster

Works a treat for me with a number of polling based devices i.e. hue, Sonos

I think there is no fix not even a good workaround at the moment everything just leads to more issues - bring a dimmer switch into this and you will find out that I assume Echo can still toggle but doesnt have the current state - same for ST as it catches up every 5 minutes - this is exactly what I am facing here - I cant use routines that depend on time with an external source changing the condition of the bulb without getting an update on all devices when the change occurs which is more than annoying really - I have used pollster to poll more frequently - every 45seconds which causes the ST hub to work unreliably over time … the hue dimmer switches dont work directly with ST as not fully supported, though they work perfectly fine when attached to an Osram bridge …

not sure who to blame here but surely this needs revisiting how to manage these kind of things - my solution would be if there are limitations on the external connected device make it work on ST … that is the only solution I would say

Even a quicker and easier solution, is refreshing one bulb using an ‘expert’ Rule and you’re done. One refresh command updates all bulbs. I have mine triggered by motion, so I don’t poll constantly.

2 Likes

Excellent solution Bobby! Imagine my surprise that it’s a feature of Rule Machine that again poses a community solution.

Thanks!

2 Likes

Wow…I can’t believe all the works that’s gone into this over the last few hours! Thank you @bamarayne for creating this topic and thank you to everyone for the possible work arounds (@slagle, @JDRoberts, @SBDOBRESCU).

@JDRoberts My initial problem was I have a dining room fixture with 4 Hue bulbs. I have them auth’d to Alexa through native Hue -> Echo integration. I have placed all 5 bulbs into an Alex group called ‘Dining Room Lights’.

As stated, I realized a problem when routines tried to run shortly after I used Alexa to control the switches due to the polling lag. The lights would state they were already off/on, even though it was the opposite.

To get around this, I attempted to create a virtual switch called ‘Dining Room Lights’. I then told ST that the virtual switch controls the 5 bulbs. Then, inside of RM, I tried to “sync” the bulbs to the switch…IE:

a) If any of the 5 dining bulbs are on, turn on the VS, otherwise turn off if this is false
b) If the VS is on, turn the 5 bulbs on. Otherwise, everything is off if it’s false

This created a loop in some capacity as the bulbs just constantly turned on and off, non-stop! This is where I reached out to the RM thread for help on creating a rule to sync the VS to the bulbs, and this is where Jason jumped in to help!

In regards to your solution, I’m confused slightly. In this case, do I need FIVE virtual switches, one per bulb? Or does one VS suffice as it’s all technically just one light fixture?

@SBDOBRESCU - Thank you for this! I’m going to try and adapt this to my setup. I don’t have motion however I’m sure a VS will work just fine!

I’ll keep everyone updated!

You could do it like I do with my kitchen lights.

I have a virtual switch called “kitchen lights”. I then have a rule that when the vsVS is on, all kitchen lights turn on and vice versa.

You could set yours up the same way, plus the rule I pm’d you their morning.

You could include in the vs rule in both actions for true and actions for false to ruin the rule actions of the refresh rule. That way the bulbs are refreshed as soon as they are turned on and off.

1 Like

It just depends on how you have everything set up. You need one virtual switch for each thing that you test in SmartThings to see if it’s on or off.

If you’re already treating the lights as a group in SmartThings so that they’re all following one bulb, then you only need one virtual switch to represent the master bulb. Or if all the bulbs are already following one virtual switch in smart things, then that’s the switch you would include to echo.

At our house, we don’t have any multi bulb fixtures. So “kitchen lights” includes three separate bulbs, but they might also each be turned on individually. So we would need one virtual switch for each bulb.

1 Like