It is currently September 21st, 2020, 12:31 pm

⭐ Weather.com - Parsing the V3 JSON - NEW!

Our most popular Tips and Tricks from the Rainmeter Team and others
User avatar
SilverAzide
Posts: 954
Joined: March 23rd, 2015, 5:26 pm

Re: ⭐ Weather.com - Parsing the V3 JSON - NEW!

Post by SilverAzide »

jsmorley wrote: August 24th, 2020, 9:49 pm Hm... So it looks like the propensity of WebParser to "keep" existing values when no values are returned on a subsequent update might be getting in the middle of this, since when there are no alerts, literally nothing is returned. I think "number" values are more susceptible to this in WebParser.

I think we might need to send a [!CommandMeasure MeasureName "Reset"] just before we go out to look for alerts each time, but I need to chew on where to put that to make sense. You can't !CommandMeasure a measure that doesn't exist, or you get log blight. So for the many folks who don't use the Alerts .inc file, that becomes a factor.

I will explore a bit, but this tends to lead me to think that the .inc for Alerts might need to actually go out to the site itself, rather than just depending on the "super parent" contained in WeatherComJSONMeasures.inc. Then I can safely have a "super parent" measure that first does a "reset" on the "not as super parent" alert measure, followed by an "update" of that parent. In effect starting fresh and clean on each iteration of UpdateRate.
Could something like a new bang like [!CommandMeasureGroup MeasureGroupName "Reset"] help here (i.e., where you could group all the alert child measures)?

I kind of like the fact that the super parent grabs everything; with my crappy internet connection, I'm liking how fast the new JSON API is.
Gadgets Wiki GitHub More Gadgets...
User avatar
Yincognito
Posts: 2565
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: ⭐ Weather.com - Parsing the V3 JSON - NEW!

Post by Yincognito »

jsmorley wrote: August 24th, 2020, 9:49 pm Hm... So it looks like the propensity of WebParser to "keep" existing values when no values are returned on a subsequent update might be getting in the middle of this, since when there are no alerts, literally nothing is returned. I think "number" values are more susceptible to this in WebParser.

I think we might need to send a [!CommandMeasure MeasureName "Reset"] just before we go out to look for alerts each time, but I need to chew on where to put that to make sense. You can't !CommandMeasure a measure that doesn't exist, or you get log blight. So for the many folks who don't use the Alerts .inc file, that becomes a factor.

I will explore a bit, but this tends to lead me to think that the .inc for Alerts might need to actually go out to the site itself, rather than just depending on the "super parent" contained in WeatherComJSONMeasures.inc. Then I can safely have a "super parent" measure that first does a "reset" on the "not as super parent" alert measure, followed by an "update" of that parent. In effect starting fresh and clean on each iteration of UpdateRate.
SilverAzide wrote: August 24th, 2020, 10:13 pmCould something like a new bang like [!CommandMeasureGroup MeasureGroupName "Reset"] help here (i.e., where you could group all the alert child measures)?
I'm not quite familiar with the topic and all, but if it's about number values that are kept in the WebParser children, wouldn't disabling that child measure and updating it (optionally enabling it as well) afterwards clear the number in the child to 0? I just tried in my own WebParser child measures and it does the job (doesn't clear the strings though, as per the manual, but as far as I read they're not a problem here). My WebParser children use StringIndex and StringIndex2 - hopefully it isn't any different from your own measures in terms of the desired effect...
User avatar
jsmorley
Developer
Posts: 21376
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: ⭐ Weather.com - Parsing the V3 JSON - NEW!

Post by jsmorley »

I think disable / enable of the child measures would probably work, although I'll have to test that in this context. The trick is when and how to execute that. The child measures only get one bite at the apple on each actual WebParser update of the parent measure, the parent measure "pushes" the data to the children, and if we aren't careful about when we disable / enable the measures, they can end up with no value at all. It simply cannot be on a FinishAction on the parent measure. That will just yank the rug out from under them. It can't be at some arbitrary time, as you don't want the values to change to zero when the parent hasn't even updated yet, as that will not work. It needs to happen JUST BEFORE the parent measure updates the values. I'm not sure yet how to do that that makes the most sense.

My gut reaction is a leading WebParser measure that does something, something really simple and certain, and then put a FinishAction on that which disables / enables all the alert measures, then forces an update of the actual parent measure. Need to be careful that a second, redundant update of the parent alert measure is not caused, as while it doesn't go out to the web, it does cart around a lot of data from the super-parent, and I'd like to avoid having it even just "read" that amount of data out of memory if I don't need to.

The easiest thing is to put a FinishAction on the overall super-parent that does the enable / disable, but that can't work, since many, if not most folks won't be using the alerts .inc file, and that would just cause errors in the log.

In addition, I think this has no advantage over the "Reset" command, which would have to be implemented with the same timing considerations. I could argue that "Reset" is in fact more certain and reliable in this case.
User avatar
Yincognito
Posts: 2565
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: ⭐ Weather.com - Parsing the V3 JSON - NEW!

Post by Yincognito »

jsmorley wrote: August 25th, 2020, 2:52 amIt can't be at some arbitrary time, as you don't want the values to change to zero when the parent hasn't even updated yet, as that will not work. It needs to happen JUST BEFORE the parent measure updates the values. I'm not sure yet how to do that that makes the most sense.
I don't follow. To me "when the parent hasn't even updated yet" is pretty much the same as "JUST BEFORE the parent measure updates the values", since children are a function of the parent. I understand the subtle difference in what you said, but from a practical point of view, it shouldn't make any difference: once that child measure is 0, it can't be set back to the "past" value of 4 or whatever if we're talking about a leftover from the previous WebParser update, can it? I mean, unless that non zero value is set (or kept) because it remains there in the weather.com source itself (which would be unfortunate), the following parent update will just skip both the number and the string value of the child measure since "if there are no alerts present, no child measures will be populated", like you said earlier.

Anyway, maybe I don't know all the details here, so I might be very well mistaken. The way I approach these things (although it never happened to me to need a "clearance" of past values of a WebParser, I only use "Reset" to hopefully save some memory in my Feeds skin) is to make a measure just before the WebParser parent, updating at the same rate, and do all I need there before the parent updates. Another solution that I think it could work (though I'm not sure) is to do what you need in the OnUpdateAction of the WebParser parent. This should happen close to the moment you want to, but the update of the WebParser parent must in this case be controlled from the UpdateDivider instead of the UpdateRate (the latter will just be set to 1) - and yes, I've done that already, it works, but I'm not sure if it will be the exact moment you want to (let's say I'm just 75% sure).

P.S. Maybe the fact that I didn't have such problems (can't speak about this case though) is because I always set my WebParser children with an UpdateDivider of -1, so, apart from the first "default" update at skin refresh which is a bit tricky to avoid normally (unless the parent measure is intially disabled), the children are only updated from the FinishAction of the parent.
User avatar
jsmorley
Developer
Posts: 21376
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: ⭐ Weather.com - Parsing the V3 JSON - NEW!

Post by jsmorley »

Yincognito wrote: August 25th, 2020, 3:43 am I don't follow. To me "when the parent hasn't even updated yet" is pretty much the same as "JUST BEFORE the parent measure updates the values", since children are a function of the parent. I understand the subtle difference in what you said, but from a practical point of view, it shouldn't make any difference: once that child measure is 0, it can't be set back to the "past" value of 4 or whatever if we're talking about a leftover from the previous WebParser update, can it? I mean, unless that non zero value is set (or kept) because it remains there in the weather.com source itself (which would be unfortunate), the following parent update will just skip both the number and the string value of the child measure since "if there are no alerts present, no child measures will be populated", like you said earlier.
Yeah, what I'm saying is that if you have some measure that is unrelated to the parent measure for the alerts, you need to be careful when it does the enable/disable or "Reset", as you don't want all the child measures to display as "zero" while they wait for the alert parent measure to actually execute. What I'm saying is that you really want one single process that:

1) Reset all child values to an empty string and a zero number.
2) Update the parent measure
3) The parent measure will populate all the child measures

I don't see any way to have that be a single, connected series of actions, that ensures they are done in the right order at the right time.
User avatar
Brian
Developer
Posts: 2062
Joined: November 24th, 2011, 1:42 am
Location: Utah

Re: ⭐ Weather.com - Parsing the V3 JSON - NEW!

Post by Brian »

Just to chime in here. It looks as if the old Webparser plugin would default the "number" value to 0 on every update. This was omitted (probably by accident) when we converted the plugin to a measure.

Took a few years to catch!

If you look at the committed code from when we switched the plugin to a measure, you will see the plugin used to default the "number" value to 0.
https://github.com/rainmeter/rainmeter/blob/6ae599238785dcd5676db1b0b16b3f954ecd167a/Plugins/PluginWebParser/WebParser.cpp#L759-L827

However, in the same commit, you can see the "new" measure code does not default the number value to "0".
https://github.com/rainmeter/rainmeter/blob/1f8b3e0434eef8a0fa196e4510accf2d27e18939/Library/MeasureWebParser.cpp#L378-L441
This will be fixed in the next beta.

-Brian
User avatar
jsmorley
Developer
Posts: 21376
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: ⭐ Weather.com - Parsing the V3 JSON - NEW!

Post by jsmorley »

Brian wrote: August 25th, 2020, 4:49 am Just to chime in here. It looks as if the old Webparser plugin would default the "number" value to 0 on every update. This was omitted (probably by accident) when we converted the plugin to a measure.

Took a few years to catch!

If you look at the committed code from when we switched the plugin to a measure, you will see the plugin used to default the "number" value to 0.
https://github.com/rainmeter/rainmeter/blob/6ae599238785dcd5676db1b0b16b3f954ecd167a/Plugins/PluginWebParser/WebParser.cpp#L759-L827

However, in the same commit, you can see the "new" measure code does not default the number value to "0".
https://github.com/rainmeter/rainmeter/blob/1f8b3e0434eef8a0fa196e4510accf2d27e18939/Library/MeasureWebParser.cpp#L378-L441
This will be fixed in the next beta.

-Brian
Ah great. I'll get that out later this morning. That's good news actually, as the "work around" for this behavior was a bad Rube Goldberg. The mouse kept getting out of the trap...
User avatar
jsmorley
Developer
Posts: 21376
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: ⭐ Weather.com - Parsing the V3 JSON - NEW!

Post by jsmorley »

Beta r3404 is out to address this.
User avatar
Yincognito
Posts: 2565
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: ⭐ Weather.com - Parsing the V3 JSON - NEW!

Post by Yincognito »

jsmorley wrote: August 25th, 2020, 1:13 pm Beta r3404 is out to address this.
It seems changes in weather.com result in an increased number of Rainmeter updates and fixes - who would have thought? ;-)
User avatar
SilverAzide
Posts: 954
Joined: March 23rd, 2015, 5:26 pm

Re: ⭐ Weather.com - Parsing the V3 JSON - NEW!

Post by SilverAzide »

As of this moment there are 9 simultaneous weather alerts in Lake Charles, LA. I've never seen that many at once. I had to tweak the JSONAlerts file to get them all. Time to get out of town, folks! On the upside, Beta r3404 is working perfectly now.
WxMeter Alert Severe 9a.png
WxMeter Alert Severe 9.png
You do not have the required permissions to view the files attached to this post.
Gadgets Wiki GitHub More Gadgets...