It is currently April 27th, 2024, 7:24 am

Open-Meteo Weather API

Weather skins
emp00
Posts: 83
Joined: October 7th, 2022, 8:08 pm

Re: Open-Meteo Weather API

Post by emp00 »

Every time loading/reloading both Open-Meteo Weather_1.2024.01.24.rmskin and/or Open-Meteo Win10 Widgets Weather_1.2024.01.24.rmskin (out of the box, unchanged) I get a ton of errors in the Rainmeter log. Is this normal and ok?

Note that the first error in the log is this one (not visible in the screenshot):
!WriteKeyValue: Illegal path: D:\Tools\Rainmeter (Open-Meteo Win10 Widgets Weather\Weather-Large.ini)

Is this the root cause of the following errors? Actually, it's true that this is an illegal path: On my system I have Rainmeter installed in "D:\Tools\Rainmeter (Desktop Skins)" ... It's been like this forever and never been a problem with any skin. Can this be fixed?

Image
User avatar
eclectic-tech
Rainmeter Sage
Posts: 5407
Joined: April 12th, 2012, 9:40 pm
Location: Cedar Point, Ohio, USA

Re: Open-Meteo Weather API

Post by eclectic-tech »

A known issue...

The first time the skin loads, there is no data available for the JSONParser until the web parser finishes reading the site. The JSONParser is trying to read data doesn't exist yet until the parsing is done, that is what generates the messages. The messages are not really errors, more of a warning, and will not repeat after the first load.

I tried disabling the JSONParser measures and use a FinishAction on the webparser to avoid this, but the plugin does not support disabling as far as I know. The messages still appear and sometimes crash Rainmeter :x ...
So for now, I ignore them in favor of a stable skin.
emp00
Posts: 83
Joined: October 7th, 2022, 8:08 pm

Re: Open-Meteo Weather API

Post by emp00 »

eclectic-tech wrote: March 16th, 2024, 7:24 pm So for now, I ignore them in favor of a stable skin.
OK, Thank you. I am trying to learn how you set up this (great!) skin. As you have seen in my other posting, currently I'm trying to get specific hourly weather data (esp. irradiance for my PV-project). As far as I can see, your skin actually already pulls certain hourly data via the api call but unfortunately it can only process and display daily values as of now.

Stupid question, see below your Measure @CurrentUVIndex as an example:
  • The number "0" in Query='hourly.uv_index[0]' obviously means "current day" and 1, 2 [...] in following measures mean day 1, 2 [...] - that's clear. However, the api string "uv_index" (see snippet below) contains the complete hourly data for 7 days * 24 hours, right?
  • In "hourly":{"time" I can also see the hourly date/time array fitting to these hourly.uv_index values, right?
  • Can I already access these hourly values somehow e.g. via hourly.uv_index[0,1] for "current day, hour 1" and [0,2] for hour 2 and so forth? Does your JsonParser have a query possibility for this hourly data? What's the correct syntax?
I would like to use your skin as a basis for my project - but I really need the hourly data. If you can tell me how this works for the UV index I can probably transfer this to the irradiance-values I'm interested in. Thanks for your time and help!

Code: Select all

[@CurrentUVIndex]
Group=WeatherData
Measure=Plugin
Plugin=JsonParser.dll
Source=[MeasureWeather]
Query='hourly.uv_index[0]'
DynamicVariables=1
Logging=NoMatch:0,EmptySource:0
"uv_index":[0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.40,1.20,2.10,2.90,2.90,3.15,2.20,1.70,1.55,1.35,0.50,0.05,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.05,0.15,0.65,2.15,1.70,0.30,0.35,2.80,2.20,1.30,0.50,0.05,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.05,0.45,1.25,2.20,2.95,3.35,3.60,3.45,2.80,2.25,1.30,0.50,0.05,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.05,0.45,1.25,2.10,2.80,3.45,3.80,3.50,3.00,2.15,1.25,0.50,0.05,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.05,0.45,1.20,2.35,3.25,3.95,4.20,4.00,3.35,2.35,1.20,0.50,0.05,0.00,0.00,0.00,0.00]
User avatar
eclectic-tech
Rainmeter Sage
Posts: 5407
Joined: April 12th, 2012, 9:40 pm
Location: Cedar Point, Ohio, USA

Re: Open-Meteo Weather API

Post by eclectic-tech »

emp00 wrote: March 17th, 2024, 8:36 pm {snip}
Stupid question, see below your Measure @CurrentUVIndex as an example:
  • The number "0" in Query='hourly.uv_index[0]' obviously means "current day" and 1, 2 [...] in following measures mean day 1, 2 [...] - that's clear. However, the api string "uv_index" (see snippet below) contains the complete hourly data for 7 days * 24 hours, right?
  • In "hourly":{"time" I can also see the hourly date/time array fitting to these hourly.uv_index values, right?
  • Can I already access these hourly values somehow e.g. via hourly.uv_index[0,1] for "current day, hour 1" and [0,2] for hour 2 and so forth? Does your JsonParser have a query possibility for this hourly data? What's the correct syntax?
I would like to use your skin as a basis for my project - but I really need the hourly data. If you can tell me how this works for the UV index I can probably transfer this to the irradiance-values I'm interested in. Thanks for your time and help!
{snip}
Sorry for the late reply...

You are correct about the bracketed number in the query line; it represents the item number of the source array.

The way the JSON is formatted determines how you can query it.

In this case the API provides individual values for each requested item: time, cloud cover, etc. at an 'hourly' interval (UV_Index should have been added to that 'hourly' list). Then all items in the 'hourly' list are correlate; 1st time, 1st cloud cover, and 1st UV_Index numbers are related to each other.

The syntax to query each would be a single bracketed number:
Query='hourly.time[0]'
Query='hourly.cloudcover[0]'
Query='hourly.uv_index[0]'

This obtains the first set of data, then repeat for each array item as often as needed. There is no limit to the number of indexes in JSONparser; unlike the limit of 99 captures (excluding using StringIndex2) in the Webparser.

Because each array contains unique values you would only specify the index of each item in your query [0] to [x] (x=number of indexes in the arrays).

I am still a rookie when it comes to using the JSONParser, but hopefully this helps you.
emp00
Posts: 83
Joined: October 7th, 2022, 8:08 pm

Re: Open-Meteo Weather API

Post by emp00 »

eclectic-tech wrote: March 20th, 2024, 1:41 am You are correct about the bracketed number in the query line; it represents the item number of the source array.
[xxx]
Because each array contains unique values you would only specify the index of each item in your query [0] to [x] (x=number of indexes in the arrays).
Confirmed! :D
  • My skin working basis is your "OpenMeteo Win10 Widgets Weather" skin using the default measures in "OpenMeteoAPIMeasures7Day.inc"
  • Tested with the example measure [@CurrentUVIndex] findings as follows
  • Query='hourly.uv_index[X]'
  • [X] = hour in an array of 7 days, from 0 to 167 !!
  • Whereby for Today X=0 to 23 // Day1 X=24 to 47 // Day2 X=48 to 71 // Day3 X=72 to 95 // Day4 X=96 to 119 // Day5 X=120 to 143 // Day6 X=144 to 167
This means I can really use your skin as a basis to query the HOURLY weather data for certain parameters (my project = irradiance trend for PV power production predictions)! EXCELLENT --> this is much easier and more robust than using RexExp! Am I on the right track?

Ok, my first goal is to display a trend graph of this 7 day hourly data. However, is it true that I now have to write 167 (one-hundred-sixty-seven?!) measures copy/pasted "only" counting up the X and setting up unique measure names? This seems super-inefficient, ism't there a more simple way to query the complete array in one measure and then use this single array-measure in a meter drawing the trend line graph and also for calculating e.g. the daily peak or daily sum of irradiance etcpp...?

Yes, I know that practically all weather skins are actually using such series of unique measures for such purposes, but maybe there is a better way thanks to the JSON parser or other tricks? I mean in any other programming language you'd write a simple loop to "cover it all".

Everythings possible, right? Thanks for any hints... :???:
User avatar
eclectic-tech
Rainmeter Sage
Posts: 5407
Joined: April 12th, 2012, 9:40 pm
Location: Cedar Point, Ohio, USA

Re: Open-Meteo Weather API

Post by eclectic-tech »

Well, you "hit the nail on the head" ... Rainmeter is NOT a programming language.

To display the amount of data you have would require you to consider how it is displayed. Perhaps breaking it into days at a time or max/min for each day.
It is entirely up to you to decide how it is presented, but you would need measures for each item you want to display and either meters or references to those measures in a shape meter as demonstrated by Yincognito in another thread.

Lua may help, but I have not ventured into "Lualand" very far (getting too old and obstinate :D ).
User avatar
Yincognito
Rainmeter Sage
Posts: 7175
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Open-Meteo Weather API

Post by Yincognito »

emp00 wrote: March 20th, 2024, 8:20 pmHowever, is it true that I now have to write 167 (one-hundred-sixty-seven?!) measures copy/pasted "only" counting up the X and setting up unique measure names? This seems super-inefficient, ism't there a more simple way to query the complete array in one measure and then use this single array-measure in a meter drawing the trend line graph and also for calculating e.g. the daily peak or daily sum of irradiance etcpp...?

Yes, I know that practically all weather skins are actually using such series of unique measures for such purposes, but maybe there is a better way thanks to the JSON parser or other tricks? I mean in any other programming language you'd write a simple loop to "cover it all".

Everythings possible, right? Thanks for any hints... :???:
Very good question. Actually, there is, but you won't like it. The reason is simple: given that, even with the help of Lua (which does have very fast arrays, called "tables"), Rainmeter just doesn't have an "array" type of variable (everything in Rainmeter is "single instance"), the only way to have multiple "values" into one variable is to manipulate strings, which basically translates to ... prepare yourself ... the mighty regex, lol (attention, I'm not talking about the WebParser's RegExp option!). Or, you can build the string in Lua, but you'd use Lua's own form of regex, called "patterns". Heck, even the JsonParser uses some form of "regex" (i.e. string finding and manipulation) to do its thing, the only difference is that it does it internally, saving the user the trouble of doing it himself. To put it in a simple way, regex is for strings what is math for numbers.

You won't get away with a single measure though, you'd have to have at least two or maybe four, since you have 2 graphs (precipitation and irradiance), but yeah, you could end up with the entire code in a one or two Notepad++ pages if done properly. The only reason I didn't mentioned this approach in the other thread was that I thought you needed individual values for some individual displaying / mouse actions on the values (which many users insist in doing), but now that you asked, yes, it can be done in a much shorter way, but you won't escape regex. The idea would be to take the entire precipitation and irradiance sets / arrays / strings in the json response, and build the precipitation and irradiance Paths based on that. In essence, replacing the , between those values with | LineTo (the rest of the graph formulas here) in order to build the Path's string value, then using the outcome as the value of the Path's options. So, you'd "automatically" build the graph based on the array string extracted from the site's response.
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
emp00
Posts: 83
Joined: October 7th, 2022, 8:08 pm

Re: Open-Meteo Weather API

Post by emp00 »

Yincognito and eclectic-tech, thanks for the explanations. I get what you mean with using strings and RegExp to reduce the number of measures dramatically. Still, in my case, I would probably just keep it simple and copy/paste the measures in order to "get things done". I agree it's very rewarding if you succeed with the approach you described, but this is for experienced professionals like you. You have all my respect for this - as promised, this weekend, I will have a close look at your RegExp intro in the other thread and then build my project. I'm quite sure I will achieve what I'm thinking about - and by the way, using mouseover for showing single values is a great idea, I did not have on my list so far (thanks for this inspiraton!! I will show the day of week and maybe more data on mouseover, in the 7 day trend line graph) ...

Whether I will use JsonParser or the classical RegExp working the OpenMeteo api output, we'll see. Since eclectic-tech has already built a complete skin with many more measures that I partially also need, I tend to use this approach even though I hate the Log entries at skin startup. Using JSON queries is much more straightforward - thinking about sking modifications to be made e.g. in half a year, much easier to get back into the code. It all depends on preference and experience I guess. I will make up my mind by trying it out. Next weekend. Wouldn't have been able to achieve my goal without your guidance (note that I'm already talking past tense, that's called "full confidence", riight?). Thanks guys. It's possible.

:bow:
User avatar
Yincognito
Rainmeter Sage
Posts: 7175
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Open-Meteo Weather API

Post by Yincognito »

emp00 wrote: March 21st, 2024, 8:53 pm I get what you mean [...]
Sure thing, feel free to choose what you think it's best - I only enumerated the possibilities, since you asked. Assuming you want both the time, precipitation and irradiance like the site graph you screenshot in the other thread, there are 3 main ones:

- copy paste 168 × 3 measures under different names, for roughly 5000 lines of code; low difficulty, long time, if done manually (irrespective if you use RegExp or the JSONParser)
- copy paste 3 measures under different names, for roughly 70 lines of code; medium difficulty, short time (must use regex substitutions, won't work for the JSONParser, unless it can retrieve entire arrays at once)
- the same 3 measures and a Lua one to get data and build paths, for roughly 70 lines of code and 3 lines in Lua; medium difficulty, short time (no need for the JSONParser, as Lua can do the same via tables aka arrays)

As you can see, the more automation, the less time needed for it. The difficulty level is not that high, not even when it comes to the regex substitutions, in both the 2nd and the 3rd variant it's only about the single (and short) line of code building the Path string according to the coordinates formulas.
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth