It is currently August 10th, 2020, 4:07 pm

Weather Skins Not Working

Help with creating, editing & fixing problems with skins
DougS2K
Posts: 13
Joined: July 26th, 2020, 6:33 pm

Re: Weather Skins Not Working

Post by DougS2K »

jsmorley wrote: August 1st, 2020, 3:30 pm I don't know, you will need to contact xxenium about this. That particular skin you are using is not using the @Include .inc files I developed, and yeah, to use them would require a complete re-write of the skin for sure.

One thing that everyone needs to be aware of is that we haven't yet figured out how to get some of the information like "hourly forecast", "air quality", "pollen levels" from the API yet, and that stuff won't be available in the short term.
Ok thanks anyways. The worst part is I just finished this skin about a week ago. :lol: I may try to rewrite the skin or just wait and see if xxenium fix the regexp in the near future.
User avatar
jsmorley
Developer
Posts: 21235
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Weather Skins Not Working - This is the only allowed thread about this

Post by jsmorley »

SCR wrote: August 1st, 2020, 3:35 pm Wow, you sure have been busy. I downloaded your new Weather.com skin, I like to make the changes to the WeatherComJSONVariables.inc there so I have a way to check my skin, copied all the needed *.inc files in to my skin and everything worked perfectly with one exception. I had to add two measures to my SpecialMeasures.inc file. The [@CurrentVisibilityDistance] was showing a result of 10.0000. I passed it through a calc measure and it's now showing 10.

Here is the code I added:

Code: Select all

[Visibility]
Measure=WebParser
URL=[@CurrentConditionsParent]
StringIndex=18
RegExpSubstitute=1
Substitute=#CommonSubstitute#

[VisibilityDistance]
Measure=Calc
Formula=Visibility
Thanks to you and everyone else that has contributed to this on going project. Obviously it's something I would never be able to do. I appreciate all your hard work.
Using a Calc measure like:

Code: Select all

[MeasureRoundDistance]
Measure=Calc
Formula=Round([@CurrentVisibilityDistance],0)
DynamicVariables=1
Will give you complete control over how many, or none, decimal places you want to show.

I see NO good reason to "overload" the measure [@CurrentVisibilityDistance] with that [Visibility] child measure you have. I would lose that measure entirely. When you "overload" a measure in the skin .ini, you are going to want to use either a String or Calc measure to manipulate the string or number values returned, or to add "tests" like IfCondition or IfMatch. There is just no good reason to prompt WebParser to return the child measure value once again. It's already there and available in [@CurrentVisibilityDistance].

The danger in what you are doing there is that I may change the StringIndex number that returns the current visibility distance from the JSON tomorrow, and the point of all this is that is transparent to you and your skin. If you start going after the RegExp in the skin itself, that can only lead to tears.

Note: Be aware that unless you play a trick where you Disabled=1 this Calc measure, and only !EnableMeasure or !EnableMeasurGroup it as a OnFinishAction on the WebParser parent measure, you might get at least one initial error in the log, something like "syntax error" or "extra operation in formula". In general, if you are using Calc or Time measures that reference the child measures from WebParser, you are going to want to disable them until WebParser is finished, or you can get a few errors.

I think you can simply add Disabled=1 to the Calc measure, and add Group=Parents or Group=Times to it as well. I already have OnFinishAction's on the WebParser parents that enables those groups when they are done.

Code: Select all

[MeasureRoundDistance]
Measure=Calc
Formula=Round([@CurrentVisibilityDistance],0)
DynamicVariables=1
Group=Parents
Disabled=1

Note: While using Round() in a Calc measure will restrict the number of decimal places, it is "no more than", not "exactly". What I'm getting at is that if you use anything other than "0" as the rounding factor, say "1", a string of "10.000" will return "10", not "10.0", and in fact a string of "10.009" will still return just "10". If you really want a consistent number of decimal places, again, say "1', you would probably want a String measure instead:

Code: Select all

[MeasureRoundDistance]
Measure=String
String=[@CurrentVisibilityDistance]
DynamicVariables=1
RegExpSubstitute=1
Substitute="^([\d]+)(\.)([\d]{1}).*$":"\1\2\3","^([\d]+)$":"\1.0"
Now that is "truncating", not "rounding", (or adding a ".0" to the end of a whole number) but it is the only way I can see to get a consistent number of decimal places other than zero for a value that could in theory be 10.000 / 10.9 / 10.09 / 10.009. If the concern is consistency in "width / real estate", this is how I would go.


Throwing away all decimal places is probably fine with a units of measure of "e" (Imperial) as I think visibility is always returned in whole miles. When you are using "m" (Metric) I think it is far more likely that you will get a number that contains a fractional number of kilometers, as presumably it is converted from miles using a formula in the API, and that is pretty much never going to result in whole kilometers. So it's up to you how you handle this. It depends a bit on the design of your skin (width) and your target audience... I'd be tempted to show at least one decimal place.

This behavior by the API is a bit puzzling really. I don't really understand why they return a string of "10.000", when that is clearly just 10. While I consider this bad programming, I'd be less confused by it if Wind Speed did the same thing, but it doesn't... mph and km/h are both in whole numbers.
User avatar
jsmorley
Developer
Posts: 21235
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Weather Skins Not Working

Post by jsmorley »

DougS2K wrote: August 1st, 2020, 3:37 pm Ok thanks anyways. The worst part is I just finished this skin about a week ago. :lol: I may try to rewrite the skin or just wait and see if xxenium fix the regexp in the near future.
My advice is to re-write it. Use this:

https://forum.rainmeter.net/viewtopic.php?f=118&t=34628

As the starting point, then write your skin around the @Include .inc files I provide. I don't know what route xxenium is taking as he fixes the skins he distributes, but from my own personal perspective, I can only recommend that all weather skins that want weather.com consider using the .inc files I provide. To each his own, and there are more ways than one to skin a cat, but I can't help at all with any other approach. Only the author can do that.
User avatar
Yincognito
Posts: 2223
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Weather Skins Not Working

Post by Yincognito »

jsmorley wrote: August 1st, 2020, 3:30 pmOne thing that everyone needs to be aware of is that we haven't yet figured out how to get some of the information like "hourly forecast", "air quality", "pollen levels" from the API yet, and that stuff won't be available in the short term.

"hourly forecast" I think I see how to get, and will likely create a new .inc file at some point for that information. The others are still a mystery.
Once again, the mystery is unravelled... 8-)

Air Quality (just use EPA for <scale>, as I have no idea what that is):

Code: Select all

https://api.weather.com/v3/wx/globalAirQuality?geocode=<latitude>,<longitude>&language=<language>&scale=<scale>&format=json&apiKey=<ApiKey>
Pollen Forecast (unfortunately not a v3 option for the moment, it seems):
- tried but came out empty (I believe it needs some time interval to show the data, or maybe the file name is different):

Code: Select all

https://api.weather.com/v1/geocode/<latitude>/<longitude>/observations/pollen.json?language=<language>&apiKey=<ApiKey>
- tried and was successful:

Code: Select all

https://api.weather.com/v2/turbo/vt1PollenForecast?geocode=<latitude>,<longitude>&format=json&language=<language>&apiKey=<ApiKey>
I have no idea if this is what you want, as I never used (and will never use) these myself, but you should check here for a TON of info on pretty much everything (what I already had on the subject, although enough for my needs, is nothing compared to what's there, LOL). Just stumbled upon this today, while trying one more time to be of some help and fill the blanks for air quality and pollen. I suggest saving the important / most used bits from that link, as you never know when (and if) it gets deleted and such.
User avatar
pul53dr1v3r
Posts: 398
Joined: July 30th, 2014, 10:30 am

Re: Weather Skins Not Working

Post by pul53dr1v3r »

i feel like information such as AirQuality... Hope it's somewhere in the api site with a different name, but seems that nobody knows for sure.

Also, i noticed that the data usage of the Weather skins based on the api is barely 25 KB vs. ~1000 KB with standard site based JSON... Simply outstanding. :thumbup: :bow:
User avatar
jsmorley
Developer
Posts: 21235
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Weather Skins Not Working

Post by jsmorley »

Yincognito wrote: August 1st, 2020, 5:40 pm Once again, the mystery is unravelled... 8-)

Air Quality (just use EPA for <scale>, as I have no idea what that is):

Code: Select all

https://api.weather.com/v3/wx/globalAirQuality?geocode=<latitude>,<longitude>&language=<language>&scale=<scale>&format=json&apiKey=<ApiKey>
Pollen Forecast (unfortunately not a v3 option for the moment, it seems):
- tried but came out empty (I believe it needs some time interval to show the data, or maybe the file name is different):

Code: Select all

https://api.weather.com/v1/geocode/<latitude>/<longitude>/observations/pollen.json?language=<language>&apiKey=<ApiKey>
- tried and was successful:

Code: Select all

https://api.weather.com/v2/turbo/vt1PollenForecast?geocode=<latitude>,<longitude>&format=json&language=<language>&apiKey=<ApiKey>
I have no idea if this is what you want, as I never used (and will never use) these myself, but you should check here for a TON of info on pretty much everything (what I already had on the subject, although enough for my needs, is nothing compared to what's there, LOL). Just stumbled upon this today, while trying one more time to be of some help and fill the blanks for air quality and pollen. I suggest saving the important / most used bits from that link, as you never know when (and if) it gets deleted and such.
Ah yes. This is very useful indeed! Thanks a million!
User avatar
Yincognito
Posts: 2223
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Weather Skins Not Working

Post by Yincognito »

jsmorley wrote: August 1st, 2020, 5:43 pm Ah yes. This is very useful indeed! Thanks a million!
No problem. Have fun checking out those docs. ;-)
User avatar
jsmorley
Developer
Posts: 21235
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Weather Skins Not Working

Post by jsmorley »

Here are a few I have uncovered from various places...
https://api.weather.com/v3/wx/conditions/historical/hourly/1day?language=en-US&apiKey=6532d6454b8aa370768e63d6ba5a832e&geocode=38.723249,-77.069950&units=e&format=json
https://api.weather.com/v2/astro?apiKey=6532d6454b8aa370768e63d6ba5a832e&geocode=38.723249,-77.069950&days=15&date=20200801&format=json
https://api.weather.com/v3/wx/almanac/daily/5day?apiKey=6532d6454b8aa370768e63d6ba5a832e&geocode=38.723249,-77.069950&units=e&startMonth=04&startDay=24&format=json
https://api.weather.com/v3/wx/conditions/historical/dailysummary/30day?language=en-US&apiKey=6532d6454b8aa370768e63d6ba5a832e&geocode=38.723249,-77.069950&units=e&format=json
https://api.weather.com/v3/wx/forecast/hourly/1day?apiKey=6532d6454b8aa370768e63d6ba5a832e&geocode=38.723249,-77.069950&units=e&language=en-US&format=json
https://api.weather.com/v3/location/near?apiKey=6532d6454b8aa370768e63d6ba5a832e&geocode=38.723249,-77.069950&product=pws&format=json
https://api.weather.com/v3/location/near?apiKey=6532d6454b8aa370768e63d6ba5a832e&geocode=38.723249,-77.069950&product=airport&subproduct=major&format=json
https://api.weather.com/v3/wx/globalAirQuality?geocode=38.723249,-77.069950&language=en-US&scale=EPA&format=json&apiKey=6532d6454b8aa370768e63d6ba5a832e
https://api.weather.com/v2/indices/pollen/daypart/15day?geocode=38.723249,-77.069950&language=en-US&format=json&apiKey=6532d6454b8aa370768e63d6ba5a832e
I will take a look at using 1-Day Forecast Hourly, Current Air Quality, Forecast Pollen, and maybe adding just tons of Moon and Sun data with "astro".
SCR
Posts: 60
Joined: April 15th, 2015, 11:13 pm

Re: Weather Skins Not Working - This is the only allowed thread about this

Post by SCR »

jsmorley wrote: August 1st, 2020, 3:39 pm Using a Calc measure like:

Code: Select all

[MeasureRoundDistance]
Measure=Calc
Formula=Round([@CurrentVisibilityDistance],0)
DynamicVariables=1
Will give you complete control over how many, or none, decimal places you want to show.

I see NO good reason to "overload" the measure [@CurrentVisibilityDistance] with that [Visibility] child measure you have. I would lose that measure entirely. When you "overload" a measure in the skin .ini, you are going to want to use either a String or Calc measure to manipulate the string or number values returned, or to add "tests" like IfCondition or IfMatch. There is just no good reason to prompt WebParser to return the child measure value once again. It's already there and available in [@CurrentVisibilityDistance].

The danger in what you are doing there is that I may change the StringIndex number that returns the current visibility distance from the JSON tomorrow, and the point of all this is that is transparent to you and your skin. If you start going after the RegExp in the skin itself, that can only lead to tears.

Note: Be aware that unless you play a trick where you Disabled=1 this Calc measure, and only !EnableMeasure or !EnableMeasurGroup it as a OnFinishAction on the WebParser parent measure, you might get at least one initial error in the log, something like "syntax error" or "extra operation in formula". In general, if you are using Calc or Time measures that reference the child measures from WebParser, you are going to want to disable them until WebParser is finished, or you can get a few errors.

I think you can simply add Disabled=1 to the Calc measure, and add Group=Parents or Group=Times to it as well. I already have OnFinishAction's on the WebParser parents that enables those groups when they are done.

Code: Select all

[MeasureRoundDistance]
Measure=Calc
Formula=Round([@CurrentVisibilityDistance],0)
DynamicVariables=1
Group=Parents
Disabled=1

Note: While using Round() in a Calc measure will restrict the number of decimal places, it is "no more than", not "exactly". What I'm getting at is that if you use anything other than "0" as the rounding factor, say "1", a string of "10.000" will return "10", not "10.0", and in fact a string of "10.009" will still return just "10". If you really want a consistent number of decimal places, again, say "1', you would probably want a String measure instead:

Code: Select all

[MeasureRoundDistance]
Measure=String
String=[@CurrentVisibilityDistance]
DynamicVariables=1
RegExpSubstitute=1
Substitute="^([\d]+)(\.)([\d]{1}).*$":"\1\2\3"
Now that is "truncating", not "rounding", but it is the only way I can see to get a consistent number of decimal places other than zero for a value that could in theory be 10.000 / 10.9 / 10.09 / 10.009. If the concern is "width / real estate", this is how I would go.


Throwing away all decimal places is probably fine with a units of measure of "e" (Imperial) as I think visibility is always returned in whole miles. When you are using "m" (Metric) I think it is far more likely that you will get a number that contains a fractional number of kilometers, as presumably it is converted from miles using a formula in the API, and that is pretty much never going to result in whole kilometers. So it's up to you how you handle this. It depends a bit on the design of your skin (width) and your target audience...
I replaced my measures with your first example although I did not have an error in the log. I rarely ever use a calc measure to round. All my other special measures are String=[MeasureName]. I did try to use Round but I didn't include the [ ] or the,0 My bad. :oops:

As to my target audience, it's just me for now. Perhaps I will learn enough to attempt to release something in the future when my coding ability can make sense without lines of notes to remind me what it does and why. In addition to all that my skin is entirely way to big, 7513 lines, and I am learning ways to shorten the Meters. I am currently working with Styles which will cut it in half or more. There are a lot of meters to change and I am still adding more meters as the additional data as it becomes available, yeah, it's going to have it all. Then there is Languages. It would have at best a very limited use because I don't know how long I could support the inevitable changes at my age.

To be honest there are a lot better weather skins out there then mine could ever hope to be. But I like it.

Your very informative notes are greatly appreciated. I have copied the post in to my Rainmeter notes files for future reference.

Thank you
User avatar
Yincognito
Posts: 2223
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Weather Skins Not Working

Post by Yincognito »

jsmorley wrote: August 1st, 2020, 5:49 pm Here are a few I have uncovered from various places...
...
I will take a look at using Forecast Hourly, Air Quality, Pollen, and adding just tons of Moon data with "astro".
Yep. So, to conclude (<format> is generally json, as xml doesn't seem to be used much):

For V1, the standard URL format is (<filename> can be observations, <numberofdays> can be 7 or 15):

Code: Select all

https://api.weather.com/v1/geocode/<latitude>/<longitude>/<filename>.<format>?&units=<units>&language=<language>&apiKey=<ApiKey>
or, for forecasts

Code: Select all

https://api.weather.com/v1/geocode/<latitude>/<longitude>/forecast/daily/<numberofdays>day.<format>?&units=<units>&language=<language>&apiKey=<ApiKey>
For V2, the standard URL format is (<sectionname> can be vt1Loc, vt1Observation, vt1CurrentDateTime, vt1DailyForecast, vt1PollenForecast, etc.):

Code: Select all

https://api.weather.com/v2/turbo/<sectionname>[;<sectionname>...]?geocode=<latitude>,<longitude>&format=<format>&units=<units>&language=<language>&apiKey=<ApiKey>
For V3, the standard URL format is (<sectionname> can be observations, forecast - subsections daily or hourly with their own subsections like Ndays where N is a number, dateTime, location - subsections point or near, conditions - subsections historical with its own subsections like hourly or dailysummary again with subsections like Ndays where N is a number, almanac - subsection daily, globalAirQuality, etc.):

Code: Select all

https://api.weather.com/v3[/wx]/<sectionname>[/<subsectionname>...][/<numberofdaysforforecasts>]?geocode=<latitude>,<longitude>&format=<format>&units=<units>&language=<language>&apiKey=<ApiKey>
or, the aggregate form

Code: Select all

https://api.weather.com/v3/aggcommon/v3[-wx]-<sectionname>[-<subsectionname>...][;v3[-wx]-<sectionname>[-<subsectionname>...]...]?geocode=<latitude>,<longitude>&format=<format>&units=<units>&language=<language>&apiKey=<ApiKey>
Note that [somethinghere] means optional, ... possible repetition of the text inside the current square brackets, and for some sections, the units=<units> part must be excluded from the URL.