According to the API v2 announcement[1], the currently used version will expire in 2019-02-15. 1 - https://api.met.no/weatherapi/sunrise/2.0/documentation#version_2.0_released:_2018-11-19
*** Bug 14991 has been marked as a duplicate of this bug. ***
*** Bug 14989 has been marked as a duplicate of this bug. ***
are there any updates on this item? current version expires in one week. Is there any way a user can assist, user testing, etc. ? I would hate to loose this app. unbelievably - this report from another continent is more accurate than local sources !! !!
Unfortunately someone has to update the code to the new API. I tried but their API changed a lot, since my time for Xfce is very limited, parsing XML in C is a PITA and I don't even use this plugin, I can only help reviewing patches and perhaps making a release.
*** Bug 15132 has been marked as a duplicate of this bug. ***
*** Bug 15145 has been marked as a duplicate of this bug. ***
Software interface Sunrise Met.no reports that the version of the web service is outdated. This module must be adapted to use the new version, so the work used will be discontinued within a few months. Please, if no one has reported this error before you, report it to https://bugzilla.xfce.org I see that sign all the time. Soon shut off the API on site.
Created attachment 8318 Use the latest sunrise API This is patch in order to use the latest sunrise API (2.0). I modified the 'parse_timestring' function (in panel-plugin/weather-parser.c), because sometimes result was not valid time_t. I left moon_phase member in xml_astro struct, but this value is always empty. We need to use another service.
I forgot to mention, this update requires manual intervention, because cache and config files store new variable (offset).
Created attachment 8319 Use the latest sunrise API Fix sunrise, sunset, moonrise and moonset date. No need to compute, because they are already in local timezone.
Thanks for the patch Olivier, I still didn't review it thoroughly but seems to be working well, congrats! What do you mean by manual intervention? I just restarted panel, the offset variable was appended to ~/.config/xfce4/panel/weather-10.rc and the cache file looks good. Besides the moon phase being "Unknown", do we have another downside?
(In reply to Andre Miranda from comment #12) > Thanks for the patch Olivier, I still didn't review it thoroughly but seems > to be working well, congrats! > What do you mean by manual intervention? I just restarted panel, the offset > variable was appended to ~/.config/xfce4/panel/weather-10.rc and the cache > file looks good. Great, I thought cache file was not updated. > Besides the moon phase being "Unknown", do we have another downside? It's just feeling, but I feel like update of icon is very long. For example, this morning night icon still presents whereas sun was already up.
*** Bug 15173 has been marked as a duplicate of this bug. ***
Olivier, here are my remarks: 1 - At update_offset, shouldn't "dt" be unref'ed with g_date_time_unref? 2 - parse_timestring can be simplified, too many returns and if/elses 3 - At update_summary_subtitle, date_format is now always the same, any reason to keep that if/else? 4 - With regards the moon phase, there is the moonphase element under astrodata->location->time which is a number, representing: 0..25: "waxing crescent", 25..50: "waxing gibbous", 50..75: "waning gibbous", 75..100: "waning crescent". No need to use another service, we just need to translate that number into (translatable) strings. > It's just feeling, but I feel like update of icon is very long. For example, > this morning night icon still presents whereas sun was already up. Strange, did you notice this behavior right after the gtk3 port or just now with your changes?
(In reply to Andre Miranda from comment #15) > Olivier, here are my remarks: > > 1 - At update_offset, shouldn't "dt" be unref'ed with g_date_time_unref? You are right, it is mentioned in g_date_time_new_now and not g_date_time_new_now_local description. > 2 - parse_timestring can be simplified, too many returns and if/elses Feel free to update patch > 3 - At update_summary_subtitle, date_format is now always the same, any > reason to keep that if/else? It is just cosmetic changes. I don't know why with UPower support subtitle is different. > 4 - With regards the moon phase, there is the moonphase element under > astrodata->location->time which is a number, representing: 0..25: "waxing > crescent", 25..50: "waxing gibbous", 50..75: "waning gibbous", 75..100: > "waning crescent". No need to use another service, we just need to translate > that number into (translatable) strings. Yes, I know, but during my test, with the 1.1 API moonphase was more complete (first quarter, full moon and so on). Now with the 2.0 API we have only these 4 values. To get information about moonphase, we must use cgi-bin/event.pl script. For example, where I live latitude: 44.034928 and longitude=4.996873. I use the date: 2019-03-28, because moonphase changes. with the 2.0 API, URL is: https://api.met.no/weatherapi/sunrise/2.0/?lat=44.034928&lon=4.996873&date=2019-03-28&offset=+01:00&days=2 Moonphase node is: >moonphase time="2019-03-28T00:00:00+01:00" value="74.285228468" desc="LOCAL MOON STATE * MOON PHASE= 74.3 (waning gibbous)"/ It says "warning gibbous". If we use cgi-bin/event.pl result is different (eventId is for differents moonphases): http://astro.met.no/astro/cgi-bin/event.pl/?debug=1;eventStart=2019-03-15T10:10:10Z;eventSearch=1;eventVal1=44.034928;eventVal2=4.996873;event1Id=210;event2Id=220;event3Id=230;event4Id=240;event5Id=250; Moonphase is: > <Event Seq="4" Start="2019-03-15T10:10:10Z" Search="1" reports="1" Id="240" cost="0ms" Val1="44.034928" Val2="4.996873"><Report no="1" time="2019-03-28T04:29:23Z" repId="240" hint="2019/03/28 04:29:23 LAST QUARTER MOON (PHASE=75)"/></Event> We get "last quarter moon" (it's value is 75). So I don't think moonphase is revevant. > > > It's just feeling, but I feel like update of icon is very long. For example, > > this morning night icon still presents whereas sun was already up. > Strange, did you notice this behavior right after the gtk3 port or just now > with your changes? Only with my changes, but it is just feeling.
Created attachment 8343 Improvements to Olivier's patch Diff with my suggestions. Ok, we can address the moonphase later.
Andre Miranda referenced this bugreport in commit 24e0cdf990ca6552d83a1462d02aba13a5fbb398 Improvements to the previous patch (bug #14972) https://git.xfce.org/panel-plugins/xfce4-weather-plugin/commit?id=24e0cdf990ca6552d83a1462d02aba13a5fbb398
I've applied both patches as requested. The plugin starts up and seems to function correctly. I just want to confirm that the locationforecasttls API does not also need to be updated? I see both of these in the debug output (location query string removed) weather-Message: 02:30:32.669: getting https://api.met.no/weatherapi/sunrise/2.0/ weather-Message: 02:30:32.669: getting https://api.met.no/weatherapi/locationforecastlts/1.3/
(In reply to Sean Davis from comment #19) > I've applied both patches as requested. The plugin starts up and seems to > function correctly. I just want to confirm that the locationforecasttls API > does not also need to be updated? I see both of these in the debug output > (location query string removed) > > weather-Message: 02:30:32.669: getting > https://api.met.no/weatherapi/sunrise/2.0/ > weather-Message: 02:30:32.669: getting > https://api.met.no/weatherapi/locationforecastlts/1.3/ The latest API for locationforecastlts is 1.3, and no update is planned [1]. [1] https://api.met.no/weatherapi/locationforecastlts/1.3/documentation
I'm fairly certain that I've figured out the moon phase data. Check out this commit, and let me know if it works for you. https://git.xfce.org/panel-plugins/xfce4-weather-plugin/commit/?id=431eaa01cde4a675e369612e1fdc4924d2d69319
Marking this issue resolved, moon phase data seems valid.