Having tried a few of the other solutions like Hue (Re)Connect, Hue Advanced (Connect), and Hue B Smart, was running into trouble with issues of inconsistent conversions between SmartThings values (hue, brightness, etc) and Hue values, difficulties identifying color vs color temperature mode, etc., I adapted my own.
My goals were:
As little deviation from the stock SmartThings Hue integration code as possible
Work with groups and (native Hue) scenes, with scenes including the " in the room" part of the name
Clear identification of color temperature mode (so I can mirror a group to a light, which was one of my aims)
In case anyone else is looking for similar, my code is up at:
Features are:
Based on the latest published native Hue (Connect) code
Group device handler, with an interface just like the hue bulb
Scene device handler, which acts as a momentary push button
Bulb and Group conform to the “Color Mode” capability, so you can tell via currentValue(“colorMode”) whether you are in color temperature mode (“colorTemperature”) or not (“color”)
Polling occurs every one minute, and updates bulbs and groups with color info (including color mode). Groups are counted as “on” if any bulb in the group is on, and their color info is determined by any bulb in the group – all of this as directly aligned with the Hue API as possible.
The code includes a smartapp as well as device handlers for hue bridge, bulb, white ambiance bulb, group, and scene. I didn’t bother to convert over the other types (Bloom, Lux bulb, etc) because I don’t use them, but it would be trivial to do if anyone needs it.
I’m sure people will appreciate the scene and color temperature improvements.
Are you using actual polling rather than checking the Hue Bridge heartbeat? That’s a huge load on the system. Is there a reason you can’t just use the regular integration status check? That’s checking the heartbeat, and it does so about every five seconds. I wouldn’t think you’d need to add your own on top. This is an area where smartthings has much improved over the last year or so.
So, I made as few changes to the latest pre-“Super LAN Connect” version of the SmartThings smartapp and device handlers as possible, from their GitHub page. That version had an every-five-minute poll, which I changed to every one minute.
I haven’t been able to find any documentation on receiving the hue bridge heartbeat or the “regular integration status check,” but if you can point me toward any ST documentation on it, I’m all ears! It does sound like a better way.
If your integration is entirely just a custom SmartApp, you do not have “access” to the heartbeat, which is only a part of the Java and iOS SDKs (if ST does this, I’m guessing it’s because they secretly use the Java SDK on the backend for their integration, whereas we writing custom SmartApps are just stuck with whatever Groovy we can get to run on the hub/cloud). Using the REST API, you have to ask the bridge each time: https://developers.meethue.com/things-you-need-know
That being said, I can’t imagine the difference would be that significant for SmartThings. The heartbeat is just a cache that the SDK uses to make it easier on the Hue bridge. Of course, repeated polling will create more LAN traffic (minimal since it’s just a bunch of text) and Internet traffic (because it’s a custom app and needs the ST cloud), but either way there’d be work to be done (though in the heartbeat case it can be kept mostly local to the ST hub–but it’s still a cache of data it ultimately gets from the bridge). Do we know that one-minute polling of the Hue bridge has the potential to be a huge problem?
FWIW, the Hue integration in Hubitat is apparently done via the REST API, with 1-minute polling. That’s all local to your LAN, but it doesn’t seem to be causing any huge problems on at least the Hue side for anyone, though I wish changes from Hue were faster to update on the Hubitat side sometimes (also my problem with custom Hue “connect”-style apps on ST).
That was my understanding as well. The every-minute polling is just one GET request to the Hue hub (I request the root directory, which in one transaction gets the status of all lights and groups). So that should be well below any threshold that would interfere with the hub itself. (Internally, I’m sure it uses its cache.)
The only thing I don’t know for sure is whether it puts a particular load on SmartThings to then process the result every minute, send events to update the local device status, etc.
In my case it seems to be working fine, and I prefer to have the minutely updates given some of my automations, but others might have a different opinion.
If you’re getting it all in one get, that is coming from the heartbeat log. (developer access to the log is limited to those using the SDK, but the bridge itself will use the heartbeat log to respond to an “everything” status request rather than polling each individual device.)
Since you’re going through custom code, you are increasing the amount of work that the cloud is doing for you. It’s non-trivial, But if you’re not seeing any issues in your QOS, it’s your choice for now up until the time SmartThings tells you you are using too many cloud resources. You won’t be able to do it the same way once everything is shifted over to the new platform, but that may be a long way away.
Things that might be impacted by that level of polling would be stuff like the Alexa or Google integration, where the voice assistant might start telling you that they couldn’t do something because the response message didn’t get through in a timely manner. That’s not because of traffic on the Wi-Fi network, that’s because the hub is busy processing the polling requests. But again, if things seem to be working fine, that’s not an issue.
( also, no one but me cares about the following, but there is no “hue hub”. So I assume you meant the bridge.
Is there a reason you can’t just use the regular integration status check? That’s checking the heartbeat, and it does so about every five seconds. I wouldn’t think you’d need to add your own on top. This is an area where smartthings has much improved over the last year or so.
(developer access to the log is limited to those using the SDK, but the bridge itself will use the heartbeat log to respond to an “everything” status request rather than polling each individual device.)