kejadlen Posted November 18, 2014 Share Posted November 18, 2014 (edited) I couldn't find any forecast workflows that were quite to my liking, so I whipped one up that gets a forecast from forecast.io: Note: requires at least Mavericks. Not tested on Yosemite. Download: https://github.com/kejadlen/dark-sky.alfredworkflow/releases GitHub: https://github.com/kejadlen/dark-sky.alfredworkflow Edited October 15, 2016 by kejadlen Updating to Dark Sky frankspin, vdesabou and Tom Hightower 3 Link to comment
Tom Hightower Posted November 23, 2014 Share Posted November 23, 2014 (edited) @kejadlen Its working at 99.9 % on Yosemite 10.10.1 The install instructions and getting the API keys all were very well written. No issues at all getting it setup in less than 5 minutes. I obviously compared it with other weather services to see if the correct data was being returned. Using the 2 locations, I am currently working at, it functions very well. The correct data and locations are displayed. The only issue, I saw and its minor in my opinion. If you type in a location and press enter it will take you to a web page. That page is not loading for me in the Aviator, Safari, Chrome, or Opera browsers. It is however opening correctly in FireFox. So I was wondering ? If its something that can be fixed. If not, its no huge deal for me. I just set up a rule in Choosy (browser chooser) to process the URL and send it to Firefox every time. Nice addition to my collection. ps. I said 99.9 % due to Safari is installed with all Macs and Firefox is an additional download. Also having said that most of us know how flakey Safari can be at times. Hence the reason for keeping multiple browsers around. Edited November 23, 2014 by thightower Link to comment
kejadlen Posted January 2, 2015 Author Share Posted January 2, 2015 @thightower That behavior is really fascinating! The URL should be ""http://forecast.io/#/f/47.6062%2C-122.3321". This might be an Alfred bug, since the comma character should be unescaped within a fragment. (Although it looks like Firefox correctly handles this case anyway!) Link to comment
kejadlen Posted January 6, 2015 Author Share Posted January 6, 2015 Released 0.0.7, which fixes the browser bug: https://github.com/kejadlen/forecast.alfredworkflow/releases/tag/0.0.7 Link to comment
Anoxy Posted January 6, 2015 Share Posted January 6, 2015 Not working for me on Yosemite. Says 'retrieving location/weather' then just goes to this: Link to comment
kejadlen Posted January 6, 2015 Author Share Posted January 6, 2015 @Anoxy: There is some configuration that's needed: https://github.com/kejadlen/forecast.alfredworkflow, did you do that? Link to comment
turkeyphant Posted January 7, 2015 Share Posted January 7, 2015 Also it didn't work with both API keys set until I chose a default location. Link to comment
kejadlen Posted January 8, 2015 Author Share Posted January 8, 2015 In v0.0.7, I removed the DEFAULT_LOCATION config in favor of getting the location by checking your IP. Link to comment
MattKneale Posted January 12, 2015 Share Posted January 12, 2015 Love this, thanks for your work. My Alfred is getting much smarter by the day! Link to comment
davidhq Posted May 29, 2015 Share Posted May 29, 2015 I have some problems with Google API key and thus current location... I tried this: http://cl.ly/image/172b043z111b but my current location is not retrieved correctly from Alfred Help? Link to comment
davidhq Posted May 29, 2015 Share Posted May 29, 2015 I enabled Google Maps Geolocation API and Geocoding API in the project... Link to comment
kejadlen Posted May 29, 2015 Author Share Posted May 29, 2015 Did you set the API key in the workflow by using "forecast-config"? Link to comment
kejadlen Posted May 29, 2015 Author Share Posted May 29, 2015 Can you describe what you're doing and what happens? On entering "forecast" into Alfred, it should use your IP to do geolocation (using ipinfo.io) and automatically pull the weather for that location. The Google API is only used if you enter "forecast" with a location, like "forecast NYC". Link to comment
davidhq Posted May 29, 2015 Share Posted May 29, 2015 hmm now it works... before there was no location found, just "," and when I clicked on the link I saw it was weather for new york... Now I get Vienna correctly... will test some more tomorrow, not sure why it suddenly workd... thank you for clarification regarding google key Link to comment
deanishe Posted May 30, 2015 Share Posted May 30, 2015 Great workflow. Love the forecast details. Unfortunately it doesn't work so smoothly for me because I connect to the Internet via a VPN. The workflow gives me the weather for the location of the VPN endpoint, not where I actually am (obviously). It'd be great if I could set a default location (my computer doesn't move) instead of having to enter the location by hand each time. Link to comment
kejadlen Posted May 31, 2015 Author Share Posted May 31, 2015 Ironically enough, that functionality was taken out when I added IP geolocation. I'm planning on re-adding it, but in the meantime, you should be able to download 0.0.6 and use that instead with setting DEFAULT_LAT_LONG (ex: 13.23,-12.45) and DEFAULT_LOCATION (just used for the name of the location). Pretty much nothing else has changed between 0.0.7 and 0.0.6, so you won't be missing anything else (aside from a minor bugfix for opening the website in the browser). Link to comment
deanishe Posted May 31, 2015 Share Posted May 31, 2015 Thanks for the tip. As I'm not interested in the geolocation, I just replaced Location.from_ip with Location.new(…) for my city instead. It seemed the simplest solution. Link to comment
davidhq Posted May 31, 2015 Share Posted May 31, 2015 Now I have problems again, location is not found: When I select it, it takes me to New York.... So yesterday it worked, now this issue I experienced in the start is coming again... maybe it cannot determine my location for some valid reason? Link to comment
deanishe Posted May 31, 2015 Share Posted May 31, 2015 Try going to http://ipinfo.io/ and see if it tells you the correct location. Link to comment
deanishe Posted May 31, 2015 Share Posted May 31, 2015 (edited) Fiddlesticks. If, like me, you don't move around much, you could hardcode your location instead. It's a hack, but it'll get you your damn fine weather forecast for the right place until there's a non-hacky solution. You could change line 49 of forecast.rb from: location = (query.empty?) ? Location.from_ip : Location.new(query) to: location = (query.empty?) ? Location.new("Wien", 48.2, 16.366667) : Location.new(query) Then if you don't specify a location, it will default to Vienna instead of an IP address-based location. AFAIK, you can use "Wien" or "Vienna" or "Home" or "Daheim" or whatever for the first argument. Perhaps @kejadlen can clarify if that's actually okay or if I'm talking nonsense? Also: lol @ "City: Austria" Edited May 31, 2015 by deanishe Link to comment
kejadlen Posted May 31, 2015 Author Share Posted May 31, 2015 @deanishe Yup, that's right - the first argument is only used for displaying the name. I uploaded a new release that supports config options DEFAULT_LAT_LONG and DEFAULT_LOCATION: https://github.com/kejadlen/forecast.alfredworkflow/releases/tag/0.0.8 Link to comment
dmydlarz Posted November 2, 2015 Share Posted November 2, 2015 How to call `forecast-config` from the workflow ? Link to comment
kejadlen Posted November 2, 2015 Author Share Posted November 2, 2015 My apologies, I broke that functionality in 1.0.0. Just released 1.0.1 which should have "config-forecast" back as a keyword! Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now