dimfalk / netatmo.weather Goto Github PK

https://api.netatmo.com/api/getpublicdata?lat_ne=51.534212512933&lon_ne=7.13765569051402&lat_sw=51.3475823924406&lon_sw=6.89433840876147&required_data=temperature&filter=false --> single element:

{
	"_id": "70:ee:50:04:ce:cc",
	"place": {
		"location": [
			7.03422676517418,
			51.44927292647
		],
		"timezone": "Europe/Berlin",
		"country": "DE",
		"altitude": 114,
		"city": "Essen",
		"street": "Steeler Straße"
	},
	"mark": 1,
	"measures": {
		"02:00:00:34:01:d2": {
			"res": {
				"1649874836": [
					19.3,
					61
				]
			},
			"type": [
				"temperature",
				"humidity"
			]
		},
		"70:ee:50:04:ce:cc": {
			"res": {
				"1649874841": [
					1016.3
				]
			},
			"type": [
				"pressure"
			]
		},
		"05:00:00:00:bc:26": {
			"rain_60min": 0,
			"rain_24h": 0,
			"rain_live": 0,
			"rain_timeutc": 1649874830
		},
		"06:00:00:01:ca:5e": {
			"wind_strength": 1,
			"wind_angle": -1,
			"gust_strength": 2,
			"gust_angle": -1,
			"wind_timeutc": 1649874836
		}
	},
	"modules": [
		"02:00:00:34:01:d2",
		"05:00:00:00:bc:26",
		"06:00:00:01:ca:5e"
	],
	"module_types": {
		"02:00:00:34:01:d2": "NAModule1",
		"05:00:00:00:bc:26": "NAModule3",
		"06:00:00:01:ca:5e": "NAModule2"
	}
}

https://github.com/r-lib/httr2

Major differences:

• You can now create and modify a request without performing it. This means that there’s now a single function to perform the request and fetch the result: req_perform(). req_perform() replaces httr::GET(), httr::POST(), httr::DELETE(), and more.

• HTTP errors are automatically converted into R errors. Use req_error() to override the defaults (which turn all 4xx and 5xx responses into errors) or to add additional details to the error message.

• You can automatically retry if the request fails or encounters a transient HTTP error (e.g. a 429 rate limit request). req_retry() defines the maximum number of retries, which errors are transient, and how long to wait between tries.

• OAuth support has been totally overhauled to directly support many more flows and to make it much easier to both customise the built-in flows and to create your own.

• You can manage secrets (often needed for testing) with secret_encrypt() and friends. You can obfuscate mildly confidential data with obfuscate(), preventing it from being scraped from published code.

• You can automatically cache all cacheable results with req_cache(). Relatively few API responses are cacheable, but when they are it typically makes a big difference.

https://httr2.r-lib.org/articles/wrapping-apis.html#secret-management

loop over seq and perform sf::st_intersection(stations, gem) %>% dim() %>% head(1)

& make use of {progress}

https://blog.r-hub.io/2021/01/25/oauth-2.0/

match.arg()?

<sf> %>% dplyr::group_by_all() %>% dplyr::distinct(GN) %>% class() != "sf" "data.frame"

instead: "sf" "grouped_df" "tbl_df" "tbl" "data.frame"

<sf> %>% unique() %>% class() == "sf" "data.frame" works generally but omits duplicates because of deviations in time_server making rows not completely identical

via sf::st_bbox() ?

# optional progress bar:
if(progbar) lapply <- pbapply::pblapply

svMisc::progress()

pb = txtProgressBar(min = 0, max = length(ind), initial = 0) 
setTxtProgressBar(pb,i)
close(pb)

progress::progress_bar()

https://github.com/dafenner/CrowdQCplus

e.g.

p1 <- get_period()
get_measure(device = "70:ee:50:6b:34:74", period = p1, par = "pressure")

actual modification takes place in gpd_json2sf() now accepting a meas = TRUE argument.

e.g. rrapply(content(out)$properties$data, how = "bind")

or jsonlite::fromJSON(x, flatten = TRUE)?

do the objects even share a common index? seems like they do: all time series ending on 2022-05-10 21:09:56.

pro:

• ?

neutral:

• indexing works: xts[, 99]
• column-wise operations work: colSums(xts)

cons:

• plot(zoo::index(xts), zoo::coredata(xts) fails due to differening lengths between x and y --> / dim(xts)[2] ?
• lack of unique xts attribute assignment
• identical approach to rstack2xts::create_xtslist()
• performance: microbenchmark: list(xts) wins.

As of today, when you refresh an Access Token using the associated endpoint https://api.netatmo.com/oauth2/token, Netatmo servers respond with a couple of tokens : an Access Token and a Refresh Token.
If the previous Access Token is still valid, the newly returned access token is identical but its expiration time is extended for 3 hours.
In any case, the refresh token is not renewed.
Starting from the 17/04/2023, this behavior will change to to be compliant with the recommendations of the RFC of the OAuth2 Authorization Framework (section 10.4) and improving the security of the data of our users.
When refreshing tokens, Access Token and Refresh Token will be automatically renewed and former tokens invalidated.

What does it means for me ?
If you were already updating the tokens provided when refreshing your tokens, this change will not impact you.
If you do not update the refresh token when refreshing your Access Token, your users will be disconnected after 3 hours as the former tokens will become invalidated.
To fix it, you need to update the tokens as soon as you get the newly generated ones.

resp$status_code == 403

$error
$error$code
[1] 3

$error$message
[1] "Access token expired"

c.f. #18

https://github.com/falk-env/netatmoR/blob/e7b12f0a5e4492743b441c0478adb788cde55193/R/2_getmeasure.R#L68-L69

decrypt token to /netatmo.weather/, not to /netatmo.weather/tests/testthat/.

as an alternative, also look for token in /tests/testthat/?

does this undocumented option also apply to other parameters?

https://github.com/ropensci/vcr

https://github.com/ropensci/webmockr/

https://github.com/r-lib/mockery

https://github.com/nealrichardson/httptest

https://github.com/nealrichardson/httptest2

dimfalk/kostra2010R#25

(*): Does not seem to be available to the public via /getmeasure since this is essentially private indoor data?

(**): Precipitation values except from "sum_rain" seem to be useless - what's the point of min/mean/max of individual data samples, when you're interested in the integral over time? - especially at higher resolutions. Intentionally ignored to prevent confusion, c.f. #25.

(***): All these timestamps can be derived from the original xts objects and are therefore ignored for now, c.f. #33.

if queried e.g. type = "min_temp" and type = "max_temp", are these absolute min. and max. values or just min. and max. means, which can be replicated easily via xts::period.apply() using values of highest resolution with resolution = 5min?

to put it in other words: is this idea of a statement variable even meaningful?

using match.arg()?

period = _

• "recent": last 24 hours
• c(from, to)
• is.null() defaults to e.g. max. allowed n

Error in character(n_stations) : invalid 'length' argument

dim(r_json$body)[1]
NULL

compare

get_measure(stations, parameter = "rain", resolution = "5min") %>% xts::period.apply(., endpoints_daily, sum)

with

get_measure(stations, parameter = "rain", resolution = "1day")

attribute variables are assumed to be spatially constant throughout all geometries.