[OBSOLETE] Hue Advanced (Connect)

Hello again @claytonjn!

I’m using Hue Advanced for all my bulbs but having some problems with the ones in the bathroom. There are 6 spots and every time they come on at least one doesn’t. I think its a problem with my bathroom and some metal work somewhere as my wi-fi also really struggles to work well in there. Anyway i was going to see if using the original Hue Connect would make any difference and so started about testing it with one bulb. I removed it fine but then when i went to add it through Hue Connect i get an error deviceNetworkid must be unique. I’m guessing its a clash on adding the Hue Hub as its already been added when I’ve used Hue Connect Advanced and it carries the same Id. Is there any way around this i.e. renaming the Device Id from the IDE or is it one or the other and i’d have to remove all lights including the hub that i set up with Hue Advanced and then re-add using Hue Connect?

Cheers,
Adam

I just pushed an update to the development branch that should allow you to successfully add and control the individual sections or whole fixture, in addition to the individual bulbs. Like I said, I don’t have anything like this to test with, so please let me know how it works.

1 Like

Yes, you need to install that SmartApp in order to use the Circadian Daylight features. The option in Hue Advanced is only to display controls for Circadian Daylight, but you still need Circadian Daylight installed to utilize the functionality.

Yes, unfortunately you can only have one Hue SmartApp installed at a time. Hue Advanced is as close to the stock Hue (Connect) as possible, so it’s unlikely you would see any difference in behavior between them anyway. I would suggest testing the control of that bulb directly through the official Philips Hue app first. If there are control issues there, then nothing you do in SmartThings would be able to remedy it. If you always control those bulbs together, I would suggest creating a group and adding that in SmartThings, that should allow for more reliable control and less overhead.

1 Like

There’s an ongoing issue with the “popcorn” performance of the official hue integration in smartthings. Do you believe your version has any benefits over the official connection? It seems that since that increased polling of the status of the bridge we’re had reduced performance. Is it possible for your connector to control the frequency of this polling as a user option? Maybe this could help with some of the issues some of us are facing…

Actually, I found a way around this, sort of, when I was testing various Hue smartapps. If you just remove the Hue Bridge from your SmartThings devices and the individual lights you want to test with a different smartapp (and individual groups or scenes you want to test if the previous smartapp supported those) and re-add the bridge and individual lights/groups/scenes with the new smartapp, you will be able to control those. You might temporarily lose access to all your other lights/groups/scenes (sometimes they still worked for me), and you will break any automations that use the lights you removed until you either repair the automations or revert back to the previous smartapp and devices.

If you don’t like the new smartapp, you can revert back using the same methods above. Your results may vary, but it turned out to be the best way for me to try different smartapps by just testing them on a couple of my 28 lights before committing all of them to a different smartapp.

1 Like

I definitely think having the polling interval set as a user setting would be better than hardcoding a less aggressive setting because a few of us need the increased polling frequency because we use methods outside of SmartThings to control our lights. For example, we primarily use HomeKit, but I had to integrate SmartThings in order to use OSRAM Lightify dimmers (they are smart light switch covers). I’m even considering setting up my SmartThings on homebridge on my Mac so I can set up the dimmers as HomeKit triggers and just have my SmartThings CoRE automations paused unless my Mac goes down.

Can you explain this in more detail? This is the first reference I’ve seen about this issue and I’m not sure what you mean.

If I did go this route, I would almost definitely still maintain a 5 minute poll as the minimum time. As good as it is in theory to have more frequent polling, the fact of the matter is that this platform does not run locally and everything (virtually) hits many SmartThings servers. So any additional polling hits their servers harder. I completely agree that bulbs should update quicker, however I also appreciate the openness of the SmartThings platform and I don’t want them to decide to put hard restrictions in place due to people taking advantage. It would be one things to poll more frequently for a short period of time, but for something like this, that runs all day every day just dropping to 1 minute polling would be 1,152 extra hits, per person, per day. Plus, SmartThings has gone after SmartApps that hit their servers too hard. IMO, polling in general is always a “hack”. Communication between devices should never rely on any pre-determined interval, or if polling is the only option then the communication should always be in one direction for things to run smoothly.

All that being said, if anyone really wants to poll more frequently they could write a simple SmartApp that calls refresh() on the bridge at whatever frequency they desire, or I’m sure CoRE could be used to do the same. There are not currently, and I have no plans on adding, and code that would lock out more frequent “manual” refreshes.

Maybe this is how it’s supposed to be, but I have noticed that if I avoid “Turn on” and “Turn off” commands and stick to setting levels to 100 (sometimes a reset beforehand is necessary) and 0, the status of the lights doesn’t matter. The drawback to this is that I can’t make my switches turn the lights back to their previous state (I haven’t taken time to master saving states). Anyhow, it’s working well enough for the rest of my family but I keep trying to tweak things.

Is there a reason the official Hue (Connect) doesn’t seem to have this refresh issue? Is there a way to force sending an on/off command to the Hue bridge regardless of what SmartThings reports as the status?

The official integration polls continuously, every few seconds. Is your app not the same? In the native integration if I change a setting in the official hue app the change propagates within a few seconds onto smartthings.

Can you elaborate? I’m not aware of the refresh issue. It seems that people may be having issues that I don’t know about? If so, please tell me so they can be addressed!

You can always call on(), off(), or any other command for any Hue device, regardless of the state. It just happens that the UI is a toggle rather than having distinct buttons.

This actually isn’t quite accurate. The official integration polls every 5 minutes. (If you look in the initialize() method, line 323 is runEvery5Minutes("doDeviceSync")) however as of relatively recent commits it also continuously listens to the communication from the Hue Hub, so if another device turns on the lights, when the Hue Hub responds that it was successful ST sees this and updates. So the actual polling which is directly asking the Hue Hub for the state of everything, still runs every 5 minutes, but this is just a backup for any missed responses from the Hue Hub.

Hue Advanced is as close to the stock Hue (Connect) as possible, and the polling, syncing, updating, etc. should be identical. If this is not the case I need to look into why, but I have not had any reports of this until now. From my own experience, I can say that statuses in ST update almost immediately in the rare event that I control a bulb outside of ST.

Please note, the listening to Hue Hub responses was added to the development branch in October, and just pushed to stable 4 days ago. If you haven’t updated which ever branch since then, then you’re still experiencing the older method of updating which relied solely on polling.

2 Likes

When I turn lights off and on via HomeKit, sometimes it updates nearly instantly in SmartThings, but often it takes more than 10 minutes to update. The official Hue Connect app didn’t do that l.

If the SmartThings UI shows a group as on, for example, and I issue off() from a physical button connected to SmartThings, it works fine and the UI updates instantly, but if I turn the group off via HomeKit, I can’t turn the group off via the off() function from the physical button until the SmartThings UI updates to show the group as on.

I am using the Development branch released today.

This has allowed me to add the groups with the Hue Beyond Pendant. Not at home at the moment, but I will let you know if it works as it should.

Many thanks!!

Daniel

When this happens, have you checked in the IDE to confirm that the SmartThings app matches the actual state in SmartThings? It’s a fairly widespread issue that sometimes the app won’t update with the proper state, even though the SmartThings platform does (likely due to caching?). Does a manual refresh result in a successful update? Is it the same both before and after the 5 minute threshold? Is the behavior the same regardless of the external control mechanism (HomeKit, Hue app, etc.)? It’s not unreasonable that SmartThings would occasionally miss the immediate update, but it should then update within 5 minutes. I’m trying to narrow down if the issue is that the 5 minute poll is not running at all, if the poll isn’t working properly, if the Hue Hub is taking a while to report the proper state, etc.

What are you using to “link” the physical button to the Hue lights?

1 Like

thanks. I have the device handlers witjh circanadian feature and this is set to ON on my bulb devices.
I also have installed the circanadian smartapp.
but I don’t see how it works. how can I check if it works or not ?

Basically it will slowly change the color temperature and or brightness of your lights throughout the day, depending on your settings.

To test color temperature, for example, you could set the color of a bulb (which should update the CD tile to off) then turn the tile on. CD should update the bulb to be a appropriate color temperature.

If you have any more Circadian Daylight specific questions please ask in that thread. Although it’s integrated with Hue Advanced, all functionality is handled by the Circadian Daylight SmartApp and people in that thread will likely be more help. Plus, not everyone who uses Hue Advanced utilizes the Circadian Daylight functionality.

1 Like

I’m still looking into this. It might take me a few days to get back to you.

Just to let you know, this worked flawlessly!!

I can now add and control grouped elements of my Hue beyond Pendant

Thanks for sorting this so quickly!!

Daniel

1 Like

So, the whole updating fiasco got too confusing for me because the results were never the same throughout the day. Sometimes SmartThings would update within seconds of a Homekit command and other times it would take several minutes. That said, I found the solution to my problem in another thread. When using CoRE, it optimizes commands by default by skipping commands it doesn’t think are needed. So, for example, if a bulb or a group of bulbs appear to be in the “On” state, it will skip the command to turn it on. To resolve this, in each Piston, you can scroll down to the bottom, tap “Advanced Options” and turn on “Disable command optimizations” and tap Done to save the change. Works much better now!

1 Like

Hi,

I see on the live logging warnings from Hue advanced as below. They are quite frequently.
What are the reason for them ? how can we solve the issues ?

b0a9c521-4876-4404-93c9-d5ad6fa7be99  9:07:32 AM: warn Input color missing
b0a9c521-4876-4404-93c9-d5ad6fa7be99  9:07:31 AM: warn Input color missing
b0a9c521-4876-4404-93c9-d5ad6fa7be99  9:05:42 AM: warn Error returned from Hue bridge, error = [address:/lights/11/state/effect, description:parameter, effect, is not modifiable. Device is set to off., type:201]
b0a9c521-4876-4404-93c9-d5ad6fa7be99  9:05:16 AM: warn Error returned from Hue bridge, error = [address:/lights/11/state/sat, description:parameter, sat, is not modifiable. Device is set to off., type:201]
b0a9c521-4876-4404-93c9-d5ad6fa7be99  9:05:16 AM: warn Error returned from Hue bridge, error = [address:/lights/11/state/hue, description:parameter, hue, is not modifiable. Device is set to off., type:201]
b0a9c521-4876-4404-93c9-d5ad6fa7be99  9:05:16 AM: warn Error returned from Hue bridge, error = [address:/lights/11/state/effect, description:parameter, effect, is not modifiable. Device is set to off., type:201]
b0a9c521-4876-4404-93c9-d5ad6fa7be99  9:05:15 AM: debug BODY: {"hue":25559,"sat":254,"on":false,"alert":"none","transitiontime":10}
b0a9c521-4876-4404-93c9-d5ad6fa7be99  9:05:15 AM: debug PUT: 192.168.254.244:80/api/v8iTEYrP91zQKvstKIyeBSn61h6WAHtL1BUBWB4z/lights/11/state
b0a9c521-4876-4404-93c9-d5ad6fa7be99  9:05:15 AM: trace Bridge: 0017882F03CF - Host: 192.168.254.244:80
b0a9c521-4876-4404-93c9-d5ad6fa7be99  9:05:15 AM: debug Executing 'setColor([transitionTime:2, hue:39, saturation:100, switch:off])'
b0a9c521-4876-4404-93c9-d5ad6fa7be99  9:05:15 AM: debug BODY: {"effect":"none"}
b0a9c521-4876-4404-93c9-d5ad6fa7be99  9:05:15 AM: debug PUT: 192.168.254.244:80/api/v8iTEYrP91zQKvstKIyeBSn61h6WAHtL1BUBWB4z/lights/11/state
b0a9c521-4876-4404-93c9-d5ad6fa7be99  9:05:15 AM: trace Bridge: 0017882F03CF - Host: 192.168.254.244:80
b0a9c521-4876-4404-93c9-d5ad6fa7be99  9:05:15 AM: debug Executing 'setEffect(none)'
b0a9c521-4876-4404-93c9-d5ad6fa7be99  9:05:11 AM: warn Input color missing
b0a9c521-4876-4404-93c9-d5ad6fa7be99  9:05:11 AM: warn Input color missing