@jdiben
Mine was not reporting correctly according to my zip code, and I know my hub’s location is set properly.
So, I went into the code, and replaced location.latitude and location.longitude with the appropriate numbers, and it seems to be working correctly for my location now.
Questions…
Did my edits actually fix it to my location, or doesn’t it work like that?
Is the only way of setting the location by either the method you suggested above through the hub’s location, or through these edits that I just did?
What if I want to have more than one ColorCast SmartApp for more than one location (like my folks’ place in a different state)? I know I could just install multiple copies of the main SmartApp into my IDE, but is there any chance you’d be willing to add that into the SmartApp itself, so we can just install multiple copies within the SmartThings Mobile App, name them appropriately, and set the location right there in the app (by zip code, coordinates, or whatever)?
Yes, I believe it does. I’ll post an update tonight. I’ll also have to reach out to darksky. Another of their requirements is that you can’t ask others to create their own developer api keys to use your software. So this app might be in violation of their updated terms. I hoping they’ll be ok with this one since it’s helping to spread their api to developers, but who knows. I may just need to embed my api key and when it exceeds the daily limit the app just stops working.
I’ll post an update with the new api location shortly. Mine is still working with the old one, but they may be phasing it out
Remembering the light state is a bit tricky since SmartThings doesn’t always know the current state of the lights, even when it’s set by SmartThings itself. Turning that option off will result in the light always turning off after displaying the weather. I actually stopped using the “remember” option myself because it just wasn’t as reliable as I want.
The only way I intended for the location to be set is by the location of the hub but your change should work to override it.
You can absolutly have more than one instance. I only use SmartThings at one location so I never considered an option to use alternate locations would be usefull. I’ll look into providing an option to chose a hub location. If it’s possible, I’ll add it in. At the very least I’ll add long/lat fields as a way to override the location for each instance of the app
I already changed the API URL in mine (as per the comments from Nick which @uacolon quoted above).
So, that’s working just fine.
[quote=“jdiben, post:77, topic:13874, full:true”]
You can absolutly have more than one instance. I only use SmartThings at one location so I never considered an option to use alternate locations would be usefull. I’ll look into providing an option to chose a hub location. If it’s possible, I’ll add it in. At the very least I’ll add long/lat fields as a way to override the location for each instance of the app[/quote]
Lights Being Left On
Mine is now always leaving the Hue lights ON after doing its thing. Any chance of adding in some kind of OFF command at the end of processing to make sure it actually turns them back off?
I know you said that the default is to turn them off, but it’s not working…on mine. I wonder if it has anything to do with which kinds of Hue lights we’re using. In my case, they are Hue Iris lights. Do you think it matters?
Add Switch as Trigger?
Any chance you’d be able/willing to add in one more trigger method to the app?
I like being able to click the SmartApp button to trigger the weather reports, and being able to do it from motion or a door opening is cool too, but I’d really like to be able to trigger this from an external action (e.g. clicking a real or simulated button, or turning a switch ON or OFF).
For now, I’m going to use either a simulated contact sensor, or an instance of @Mike_Maxwell 's uDTH (here) to accomplish this, and it works just fine either way, but just checking to see if it could be added into the app itself.
+1 on this one. I want to have it show just first thing in the morning and I can easily control this with a switch and some rules. Also, please consider adding the ability to turn off the SmartApp and the lights when the switch turns off.
Just found this app today, and I’m hoping I can use it to fill my needs. So far though I haven’t been able to figure out a way to make it work exactly how I want. The functionality of the app itself is great, what I"m having a hard time with is controlling when it turns on. What I want is for it to turn on during the week when I wake up around 6 AM, and stay on for about 30 minutes or so while I get ready for work.
From messing with the settings though, the only options I’m seeing are to have it always be on when I’m home, or to only turn on for 10 seconds at a time.
As of now, you can do this with virtual devices. Probably the best option is the uDTH from @Mike_Maxwell
Just a single instance of the uDTH can have a contact sensor on one side, and a switch on the other side. So, when you click the switch, the ColorCast SmartApp will see a door opening.
As for turning off the SmartApp, do you really mean that, or just that you want to prevent it from turning on the light?
If the latter, the uDTH method should work.
If the former, I have seen somewhere on the forum something about how to add disable SmartApp capability to a SmartApp. If you’re willing to dig a little, and up for some copy/paste coding, you may be able to figure it out.
With the method I just described above, you can pretty much do it however you like. You would just create the virtual device (recommending the uDTH), connect both of its ends, and create some rules (Pistons) in CoRE to make it do whatever you want, whenever you want.
I tried setting it up using the uDTH device handler, and set it up with a virtual switch that outputs as a motion sensor. The light turns on when the switch is activated, but the problem is it turns off after 10 seconds. I was hoping I could make the virtual switch trigger the light to turn on at a specific time, and that it would stay on until I turned the uDTH switch off 30 minutes later.
Oh ya. Oops.
So, we need to figure out whether it’s possible to do from the outside, whatever that option in the SmartApp is doing…the option to have it be Always On. I see now.
Is “Remember light settings” disabled? It’s under he light selection page. Disabling this should turn the lights off after the weather is displayed
I think someone else suggested this too. It’s a good idea. I haven’t had much time to devote to this is quite a while but it is something I’ll add when time permits
The weather is retrieved automatically every 15 minutes when the app is active whether the weather display is trigered or not. It originally only made the call when the display was triggered but it would cause a delay in the display if the api was slow to respond. You could reduce the number of calls by increasing the the time. If you look at the scheduler in the displayWeather method you should see where you can change 15 to 30 to have it get the weather every 30 minutes instead. Thats also an override I can add in the additional setting section in the future.
I think the ideal solution for me would be to figure out a way to have the smartapp enable and disable itself at specific times. That way I can leave the Always On setting enabled, but have the SmartApp itself only be enabled during the half hour window in the morning when I want the light on. That would also limit the number of API requests. As far as I can tell, that isn’t possible though.
The intent was to make use of modes in SmartThings. As such, the app can’t be scheduled directly. To give an example, for me, SmartThings changes to the “Wake Up - Weekdays” mode at 7:15 Monday-Friday. I have an instance of the app thats assigned to this mode that shows me the weather for the next 10 hours. When I leave the house, the mode changes to “Away” and the app is disabled. I have another version that only shows the weather for the next 2 hours when I get home from work and the mode changes to “Home”.
I realize this may not be the desired behavior for some and while I don’t have plans to implement this type of direct scheduling, I’d consider it if there were enough interest.
I tried implementing multiple Home modes like it sounds you use. I created a “Home (Morning)” mode and a “Home (Afternoon/Evening)” mode. I installed the smartapp and under the “Set for specific mode(s)” I chose only “Home (Morning)”. Even though the current mode is "Home (Afternoon/Evening), as soon as I finished setting up the smartapp the light turned on. Am I missing something, or shouldn’t it not turn on right now since I’m not in the “Home (Morning)” mode?
Awesome! Though, I actually kinda like the idea of using something like the uDTH to make this work for now, because it makes me feel like I know how to do something lol
Thanks. I will try that next…
Ya, and I think, rather than having the scheduling built into the app (lot of work), I think it would be better to just make its enable/disable capability exposed so we can interact with it from rules, etc.
I could use Modes if that were going to be IT, but to do so, I’ll need to modify my Modes. Not a horrible thing. I’m just wondering if it’s a logical split of a Mode into two smaller Modes in order to make this particular automation work, or if it would be better to wait for some configuration change in the SmartApp itself. Hmmm
I’m just about to test it as well. Thanks for the heads-up.
EDIT: I just set mine up with the longer time interval, and restricted to certain Modes. I will watch it for a couple days to see how much of a change that makes to my daily API Calls usage (it’s been right around 100 Calls every day I’ve had it running so far)…
