Rather than a slider tile, there were two tiles to increment the transition time: -100ms and +100ms. [quote=“claytonjn, post:94, topic:48868”]
Basically, everything available in the API. Basically, you have: alert, colorloop, bri_inc, sat_inc, hue_inc, ct_inc, xy_inc on top of the typical things.
[/quote]
My mistake, it was a previous SmartApp that I was trying that had some more functions than I had seen before.
How would people feel about just moving the transition time into settings, and allowing the user to type in exactly the value they want? This would also clean up the main tile interface of each device. I never change transition time other than initial setup, but I don’t know how often other people change it.
Getting “An unexpected error occured” Live Log:
[Warn] - Device type Luminaire not supported
[Error] - java.lang.NullPointerException: Cannot invoke method initialize() on null object @ line 564
Fresh install - Tried with Circadian and without
Seems to be when adding a group that has my Hue Beyond Pendant…
Any ideas how I can fix this?
Daniel
Looks like the Hue Beyond Pendant is represented differently than other Hue bulbs, Friend of Hue lights, etc. due to having multiple distinct, controllable sections. I don’t have one of these devices to test with, but from what I’m reading in the documentation you should be able to control the entire light as a group, just the top, just the bottom, or the three lights that make up the bottom each individually. What type of control are you looking for?
By the way, did you have the Hue Beyond Pendant working with SmartThings through the stock Hue (Connect)? As far as I know that light wouldn’t even work with the stock setup.
Yes, it worked with the standard app (as individual bulbs) and OH MY (as a group) too. I can add the individual elements of the Hue Beyond Pendant as bulbs but, when I add the ALL group (which is the 3 lower and 1 upper), it errors same with the Lower (3 lower) group.
I am looking to control the light as a whole and the lower part and upper part independently if required.
Daniel
Hi,
I’ve finally managed to move all my 13 hue bulbs to the new hue advanced app and recreated my smart apps.
now there’s one question I could not answer to myself:
how can I use circadian light feature ?
Do I have to install anything from here :
I am using the circadian device handlers. but then how can I enable this feature
?
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.
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.
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.
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.
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?