I get the following error trying to install any of the devices in the IDE “No signature of method: script14618801762161494519971.metadata() is applicable for argument types: (script14618801762161494519971$_run_closure1) values: [script14618801762161494519971$_run_closure1@3a059b7] Possible solutions: getMetadata(), getState(), setState(java.lang.Object), metaClass(groovy.lang.Closure)”
Hello, can anyone help out a complete noob in creating this smartapp? I understand how to make a new smartapp from code, but in the instructions when it says “also add each devices type you can find under HueDevices folder” I have no idea what to do. Does it mean copy the code from the folders into the HueReconnect code? Or create new smartapps with the code from the folders? If anyone could help me out it would greatly appreciated! Or if anyone knows of a step by step walkthrough/guide that would also be great.
Anyone else having an issue with GE bulbs not properly reporting their status in the app?
This was apparently resolved in the official SmartThings DTH for the GE Link bulb, but since (Re)Connect substitutes it’s own DTH for the bulbs which does not have the polling code needed to address this issue, the problem persists. @CyrilPeponnet do you think you can address this in your DTH for the bulb, please?
This has been a long standing problem with the GE bulbs. It is not the dth, it’s the actual bulb firmware.
This is the reason that I have transitioned away from them. The Phillips white bulb are now practically the same price.
If you’re using the Phillips bridge, I can’t recommend enough to change over.
I’m having a problem that my hue br30s turn on always at 13% I can’t see anywhere I am setting that, so I have no idea what the problem is. Is anyone else having that problem?
A " device type" is the same thing as a “device type handler” (DTH). The following should help clear up the confusion:
Is there a way to use this SmartApp to slowly fade lights from their current level to OFF after a routine is triggered?
Thanks in advance!
Yes, you can create a new hue scene that has a transition time which decreases the level of brightness in a scene. You would simply call that new hue scene in your routine.
Thanks! Do you know if this will be overridden/interrupted by a circadian daylight command if it’s ramping down/up at the same time?
I tried this several months ago and the circadian app did override all light states. Unfortunately, that why I uninstalled it.
Damn, I had a feeling!
that’s why I uninstalled it
Uninstalled circadian daylight or (Re)Connect? Please don’t tell me the first!
Do you know of any other way to get Hue bulbs to slowly ramp down to OFF from their current state? Seems like such a basic HA task with one of the most popular bulbs on the market!
Yes, you can use the new CoRE smartapp to accomplish a software fade based on conditions or triggers in your home. Just search for CoRE in the community. It is a very robust rule engine designed for nearly all tasks that you could conceive to run.
I just saw your other post in the CoRE thread…you seem pretty well versed, would you mind helping me? The documentation surrounding CoRE seems pretty light.
I created a Basic Piston called “Good Night Lights” so that:
If: Good Night Routine is run
Then: Fade to Level, Start Level (blank), Target Level (0%), Duration (120 seconds)
Every time I execute it it doesn’t do anything to my lights. Is that conflicting with circadian daylight too, even if it isn’t receiving a command at the time of execution?
If I recall correctly, circadian daylight is constantly sending updates (for the time appropriate circadian rhythm) to all included hue bulbs. You can watch live logging in the Graph API to see what I am talking about. It will most definitely interrupt any commands that you are attempting to send to the Hue bridge.
I know a couple of people who put most of their bulbs on circadian pattern, but keep one or two near the bed that they use for good morning and good night transitions. So that’s another approach that works for some people.
As far as core, it’s definitely very complex. You can get peer assistance in the following thread on that.
Yeah you’re definitely right. I thought it was setting temperature in 15 minute increments but I see that you’re 100% correct.
Thanks. That seems like the best solution I’ll probably find. The lights closest to the bed IMO are the most important to be on a circadian schedule - I think I’ll leave one excluded in the corner and have that dim with CoRE good night routines.
Thanks for your help!
Regarding Circadian Daylight (this may be better off discussed in it’s thread, here):
As far as I know (and definitely since I’ve taken over the project) since Circadian Daylight switched to a scheduled method rather than being event-based, it updates your bulbs every 15 minutes. But, if that 15 minutes falls within a bulb transition it will override the bulb.
That being said, Circadian Daylight allows for multiple setups with different options. Previously this was by simply installing a new instance, but with the version that I just bumped from beta to stable, it uses a Parent/Child configuration making setting up multiple configurations even easier.
If you want your bulbs to dim to off as you fall asleep, you have multiple options while still being able to use Circadian Daylight on those bulbs (and others). For example, if you put SmartThings into a specific mode when you go to sleep you could create a separate child setup with just these bulbs and select all modes except your sleep mode for Circadian Daylight to work in. That way, as soon as you enter this mode, you can begin dimming your bulbs and Circadian Daylight will never touch them. If you want to use the sleep features in Circadian Daylight, while still allowing the bulbs to dim to off initially, you could use a virtual switch that is turned on only while the bulbs are dimming, and have that selected as a switch for disabling that child setup.
If you guys have any questions about this, please bring them up in the Circadian Daylight thread. I’ve made HUGE changes recently, and added pretty much all requested features. Definitely post in there before just deciding you can’t use it for your setup because chances are there’s already a way to make it work and if not I will most likely update it to work for you!
Tried to get this working to no avail. The SmartApp and devices installed fine. Found my Hue Hub just fine and found my Lightstrip. I was able to add groups, no problem. But for the life of me, I could not get it to discover scenes. I went into the native Hue app and triggered my scenes both on and off. Still would not discover them. I only have three that I’ve built so far. I was able to test the bulbs and the group settings. I was able to trigger everything so I knew that I had the deviceTypes installed correctly.
Reading through the app there was mention of the Philips API debug tool. So I went into that and checked my scenes. Looked fine. So I deleted the smartapp and devicetypes and re-added.
The only thing I did not do was add on_0 to the end of my scenes because 1) I wasn’t sure where to do it from (Hue app or Debug API) and 2) I wasn’t sure if I would need the same scene named on_1 or something like that.
Again everything but the scenes were discovered just fine. However, this time I could not turn the bulbs off or on or anything else. At that point I called it a night and re-installed the Native ST Hue Connect app and for now I’ll have to remember to turn off routines in there when I am not at home.
Disappointing because I wanted the ability to schedule scenes based on my presence. I’ll probably play with this more. I just didn’t want to keep deleting the Hue hub and re-adding into ST.
Any ideas what when wrong?
Stacy, I had the same problem. I created a new scene using the format: short name + on + 0 (e.g. “scenea on 0”), and it worked. It is the only scene of approximately 15 on my system that can be successfully discovered . I’m in the process of renaming and testing others. Give it a try, and let me know if this cures your environment 100%.