Weather Skins Not Working

[SilverAzide]

Well, in my opinion, better would be to say it's Documents\Rainmeter\Skins\<your-weather-skin-or-skin-suite>\@Resources. Because in many cases the Documents folder is places not in the C:\Users\<your-user-name>.

Yes, that's why I used the word "Typically". https://www.lexico.com/en/definition/typically

[Yincognito]

Ok, here is another alternative to the \uNumber Unicode escaping issue in the weather.com page source. It is probably equally uncomfortable as having a long substitute like I posted earlier, because it involves creating additional "duplicate" measures just to handle the problem, but it works, so I'll post it here just for reference:

Code: Select all

[Variables]
FakeWebParserString="This simulates an Unicode escaped string: \u0219"

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
BackgroundMode=2
SolidColor=47,47,47,255

---Measures---

[MeasureFakeWebParser]
Measure=String
String="#FakeWebParserString#"
RegExpSubstitute=1
Substitute="(?si)\\u([0-9A-F]{4})":"[\x\1]"

[MeasureFinalResult]
Measure=String
String="[&MeasureFakeWebParser]"
DynamicVariables=1

---Meters---

[MeterFinalResult]
Meter=STRING
X=0
Y=0
FontFace=Consolas
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
FontSize=16
AntiAlias=1
MeasureName=MeasureFinalResult
Text="Final Result = %1"
DynamicVariables=1

Result:

Unicode Escaping Alternative.jpg

So, what one would need to do is:

1. Apply the simple "(?si)\\u([0-9A-F]{4})":"[\x\1]" Regexp Substitute to whatever WebParser child measure he regards as possibly having those \uNumber Unicode escape bits (e.g. Location, City, Phrase, etc.) - one can even append it to the CommonSubstitute variable in jsmorley's implementation
2. Create an additional String measure that has String="[&WebParserMeasure]" among its options, where WebParserMeasure is just the reference to the measure I talked about at point 1.

As I said, this involves creating additional String measures so that Rainmeter can replace the character variables with the actual Unicode characters, but at least the additional measure format is very simple and only requires adjusting the referenced WebParser measure accordingly, and no huge sustitute is required.

P.S. This works if using additional variables instead of additional measures, by the way. Just add an OnUpdateAction=[!SetVariable SomeVariable "[&WebParserMeasure]"] to the WebParser measure and use the variable instead of the measure further down the line. Each of these variants has its pros and cons.

[jsmorley]

Ok, here is another alternative to the \uNumber Unicode escaping issue in the weather.com page source. It is probably equally uncomfortable as having a long substitute like I posted earlier, because it involves creating additional "duplicate" measures just to handle the problem, but it works
....

Before you spend a lot more time on this particular issue...

We will be doing a beta of Rainmeter, probably a bit later today, that addresses this in WebParser, with a new "DecodeCodePoints" option for child measures, which will automatically decode Unicode references like \u0034 and such. In the meantime, I would deem it a HUGE favor if we could leave this discussion out of this thread. I am NOT going to fix, nor support going forward, parsing the "embedded" JSON in the HTML of the weather.com site. There is a small possibility that I will regret it, but I'm going to go after the JSON from the API. I don't think it does anyone any favors to have them scratching and clawing to get the current .inc files working, as doing that is only going to set them up for being entirely orphaned the "next time" that something in the JSON feed changes and I have to tweak the .inc files.

I am almost done with this, and will certainly be doing a massive post just a bit later today that should be the starting point for addressing this weather.com issue.

[Yincognito]

Before you spend a lot more time on this particular issue...

We will be doing a beta of Rainmeter, probably a bit later today, that addresses this in WebParser, with a new "DecodeCodePoints" option for child measures, which will automatically decode Unicode references like \u0034 and such.

Oh, ok then, this changes things for the better - I wasn't aware of your plans. I'm glad you followed on my suggestion earlier, albeit in a different form though.

I would deem it a HUGE favor if we could leave this discussion out of this thread. I am NOT going to fix, nor support going forward, parsing the "embedded" JSON in the HTML of the weather.com site. I don't think it does anyone any favors to have them scratching and clawing to get the current .inc files working, as doing that is only going to set them up for being entirely orphaned the "next time" that something in the JSON feed changes and I have to tweak the .inc files.

Ok, got it. As long as there is a solution in the making for this, it's obvious that I won't have a reason to try to look for alternatives myself or post them here - so I'll keep my mouth shut as advised, LOL. Not a fan of silencing people on the "only thread regarding weather.com issue" (I wasn't off topic this time, by the way), but then, as I said, I had no idea that you were working on a (much better) solution to address the issue.

[jsmorley]

Oh, ok then, this changes things for the better - I wasn't aware of your plans. I'm glad you followed on my suggestion earlier, albeit in a different form though.



Ok, got it. As long as there is a solution in the making for this, it's obvious that I won't have a reason to try to look for alternatives myself or post them here - so I'll keep my mouth shut as advised, LOL. Not a fan of silencing people on the "only thread regarding weather.com issue" (I wasn't off topic this time, by the way), but then, as I said, I had no idea that you were working on a (much better) solution to address the issue.

I'm not criticizing you in ANY way, trust me. I am forever in your debt for all the help and advice and pushing that you have done on this issue.

[Yincognito]

I'm not criticizing you in ANY way, trust me. I am forever in your debt for all the help and advice and pushing that you have done on this issue.

I know - but you don't have to be in my debt for anything, I was just trying to help, like everybody else. Let's say it was a bit of lack of communication involved, and forget about it.

If anything, we the users should be in your debt for having Rainmeter in the first place.

P.S. I think the new option you are working on will be very useful in other situations as well, not just in the matter of weather.com. I saw that type of escaping on other sites as well.

[jsmorley]

One last thing Yincognito...

I note that the one thing from the old "embedded" JSON that isn't available in the API JSON is the abbreviated time zone code, ala EST. I see no way to get or derive this at all from the data, as the only place I see it is in the weather "alerts", and those are not certain to exist at any given time.

Just wondering, are there any more useful additions to the URL for the API that you are aware of, that might include information like "units of measure" and "timezone" and some other things that are specific to the "request", not specific to the "location"?

I'm not particularly concerned about units of measure, as that is a required "input" now, so that doesn't need to be retrieved from the data. Timezone is not critical, but was nice little bit of information. I can easily get the "offset" from UTC from the data, but that isn't the same as the time zone name.

[Yincognito]

One last thing Yincognito...

I note that the one thing from the old "embedded" JSON that isn't available in the API JSON is the abbreviated time zone code, ala EST. I see no way to get or derive this at all from the data, as the only place I see it is in the weather "alerts", and those are not certain to exist at any given time.

Just wondering, are there any more useful additions to the URL for the API that you are aware of, that might include information like "units of measure" and "timezone" and some other things that are specific to the "request", not specific to the "location"?

I alluded to this issue earlier in this thread. What happens is that the DateTime section can't be obtained (or at least, I'm not aware of any way of doing it, and I've tried a LOT, believe me) in the aggregated form of the URL. BUT, it is available in the "normal" (i.e. non aggregated form) of the URL - which means a second poll to get another small JSON with it would be required. I'll post a sample URL regarding this in a moment.

[jsmorley]

I alluded to this issue earlier in this thread. What happens is that the DateTime section can't be obtained (or at least, I'm not aware of any way of doing it, and I've tried a LOT, believe me) in the aggregated form of the URL. BUT, it is available in the "normal" (i.e. non aggregated form) of the URL - which means a second poll to get another small JSON with it would be required. I'll post a sample URL regarding this in a moment.

Cool... I really hate Daylight Saving Time, it is the devil.

[JohnBurns]

I appreciate all the work being done in here. In the meantime, for those users who are not tech-literate, like me, I have found some of my skins still work. These are: Advansity, Glass, IDWS, Resizeable, Weather HD Station, Weather Timebar HD, and Zone. Hope this helps some of you in the interim.