I was actually just chatting with Tim from SmartThings about this, he looked over the code and everything seems right, so unfortunately it sounds like it’s an issue on your end. It seems like the options now are to either contact support and see if they can do anything on your end, completely remove Hue Advanced and all devices and set up again, or uninstall the SmartThings app from your phone and reinstall it.
I wish there was something else I could tell you, I know those options aren’t great. I would just start with whatever you think would be easiest based on your setup and work from there. Definitely let me know if you get it working.
EDIT: Do you only have the SmartThings app on one device? Is there any other device you could install it on to test?
How do other people feel about this? I appreciate the contribution, my only hesitation is that this is not the default Hue behavior so I’m not sure everyone will want this. Would an option in Hue Advanced (Connect) SmartApp be best?
I have implemented a fix for the forthcoming Grails platform update. Although the update is delayed, the fix is backwards compatible and if you don’t have the new code before the platform update happens you’ll loose control of your Hue lights through SmartThings. Therefore, I recommend everyone update. Only the SmartApp is changed and you shouldn’t need to reconfigure or change anything - just update the code and save/publish.
@AlmostTan I just verified this morning and a bulb that was turned on outside of SmartThings correctly polled and updated its state in SmartThings, so polling is working, at least for me.
That being said, if you’re setting state withing SmartThings itself, using ANY SmartApp, state should be updated immediately and does not require any polling, which is what hitting refresh does. If the bulbs are turning on but not changing state that means one of two things: either the on() function is not executing fully (due to execution time timeout or other platform issues) for the on() function is fully executing but sending the event change is not working (again, this would be due to platform issues).
I have noticed a couple instances of devices in general not matching their current state, but it has spanned multiple device types and SmartApps sending the commands, so I’m reasonable confidant that it’s being caused by platform issues. Unfortunately that means that my best advice at this time would be to wait it out, or contact support. If you want to send me some logs from Live Logging I would be glad to look over them, but to be honest you would probably just be wasting your time.
Clay as a follow-up to the previous problem relating to the device page not showing the state of the Circadian Color being enabled or disabled on bulbs.
I did attempt a reinstall of the app on my iPhone which didn’t work. I also migrated from a V1 hub to a V2 hub and rebuilt my entire SmartThings system.
As another check I recently (today) side loaded the SmartThings Moble app on a Fire Tablet and it seems that when I tap one of the buttons on a device page using the fire tablet the device first shows “Working” and then shows it as off correctly on the app device page.
It seems as though this is only a problem with my iOS device.
It is strange that it doesn’t work on my iOS device but seems to work just fine running on Android.
I don’t have any iOS devices. Can anyone with an iPhone confirm whether they are or are not experiencing the same behavior as @scottashell? (Circadian Daylight buttons in a device not showing proper state)
I just pushed a big update to Hue-Advanced-Developer beta branch. This update is a merge of the recent major changes to the native Hue (Connect). The big change is that the device state gets updated based on the confirmation from the Hue hub, rather than from ST sending the command. This means that there’s a longer delay from states updating (i.e. turning a light on keeps the state as “turning on” until the hub actually confirms that the light is on), but the ST state will more accurately reflect the state.
It shouldn’t be necessary, but it would be a lot cleaner to remove all Hue devices and Hue Advanced (Connect) before updating and adding them back so I strongly suggest doing so.
Anyone testing, please let me know if you have any issues because there were major code rewrites.
I was using the old version of hue-adv and circadian. I removed all the apps and handlers, and installed by hand the ones on the dev branch of your github. Unfortunatelly, I end up with and “unexpected error” at the last step of the hue-adv install. I manage to find and link the bridge, add a couple of bulbs, but the last error doesn’t let me pass through.
I wonder if this has to do with the fact that I am on a UK hub. It’s a pity, because I love your app. I tried to debug a bit, but as the simulator does not find the bridge, I can’t use it.
Let me know when you come up with an updated version, or if you have any tips in how to debug my error.
Any time the mobile app shows an error there should be errors in Live Logging in the IDE. Can you open up live logging and try running through the setup in the app until you get the error, then send me whatever errors show up in live logging? That should show exactly what’s causing the problem.
You shouldn’t have any issues being in the UK, I’ve kept things as close to the stock Hue (Connect) as possible for that exact reason.
I’m having the same problem, 8:46:25 AM: error groovy.lang.MissingMethodException: No signature of method: script14785082235651100475799.setupDeviceWatch() is applicable for argument types: () values:  @ line 411