Struggling with Weather... module

D3dl3g

@thgmirror I’d gladly try, but I’d need an API key, my friend.
without an API for that particular weather service, it will just come up with “loading” as the server will not give the info to you.

i saw the post of yours earlier, but as it didnt match my issue with UK Met Office weather service.

D3dl3g

@sdetweil said in Struggling with Weather... module:

you can do pm2 flush to empty the log and then start again (pm2 restart all)

kayakbabe

@D3dl3g if you get a free api key from openweathermap and then you can test with a known weather api that we all know works. (openweathermap works for me ). then you’ll narrow down the possibilities of why your particular setup isn’t working. 1) if it is the way you have installed the module, or 2) if the problem is with the weather endpoint you are trying to use. 3) maybe the uk weather api isn’t availble to you if you aren’t physically in the uk, 4) something else…

but getting the module working first in a known working configuration… will narrow down a lot of possibilities. it doesn’t mean that you can’t use the api you want later (unless that’s the issue).

sdetweil

@D3dl3g try lines=50

D3dl3g

@sdetweil
many restarts as i was modifying and testing layouts and features

couple of syntax errors, when i was playing around last night.

(blanked out sensitve info on calendar line)

sdetweil

@D3dl3g hm. should have had some info…

D3dl3g

@sdetweil
:grinning_face_with_smiling_eyes: always the way.

D3dl3g

@sdetweil

could it be *js file setup.

been poking around on the Met Office website

is this “request” something that could be used

GET https://api-metoffice.apiconnect.ibmcloud.com/v0/forecasts/point/hourly?latitude=52.################&longitude=-1.################
Headers:
Accept: application/json
X-IBM-Client-Id: e52######################
X-IBM-Client-Secret: *********

a “Header”

cache-control: no-cache, no-store, max-age=0, must-revalidate
content-length: 3634
content-type: application/json
expires: 0
pragma: no-cache
x-global-transaction-id: 9####################
x-ratelimit-limit: name=rate-limit-1,360;
x-ratelimit-remaining: name=rate-limit-1,358;

theres also a “Body” that starts

{
    "type": "FeatureCollection",
    "features": [
        {
            "type": "Feature",
            "geometry": {
                "type": "Point",
                "coordinates": [
                    -1.###,
                    52.###,
                    ###
                ]
            },
            "properties": {
                "requestPointDistance": 736.6499,
                "modelRunDate": "2022-06-28T13:00Z",
                "timeSeries": [
                    {
                        "time": "2022-06-28T13:00Z",
                        "screenTemperature": 19.6,
                        "maxScreenAirTemp": 19.6,
                        "minScreenAirTemp": 19.1,
                        "screenDewPointTemperature": 7.7,
                        "feelsLikeTemperature": 16.83,
                        "windSpeed10m": 5.1,
                        "windDirectionFrom10m": 200,
                        "windGustSpeed10m": 11.3,
                        "max10mWindGust": 13.42,
                        "visibility": 24714,
                        "screenRelativeHumidity": 46.06,
                        "mslp": 101420,
                        "uvIndex": 4,
                        "significantWeatherCode": 3,
                        "precipitationRate": 0,
                        "totalPrecipAmount": 0,
                        "totalSnowAmount": 0,
                        "probOfPrecipitation": 1

i hashed out sensitive info BTW, the Long/lat and API Keys

D3dl3g

in addition… looking at “ukmetofficedatahub.js”
API Base URL looks like this…
apiBase: “https://api-metoffice.apiconnect.ibmcloud.com/v0/forecasts/point/<hourly/3hourly/daily>”,

where as the next section down API URL is stated to be
“https://metoffice.apiconnect.ibmcloud.com/metoffice/production/api”

seems to be a mismatch although im still looking at where to test that theory…
i would have hoped which ever way the URL is structured its the JS info thats the important bit, not the structure of the URL

D3dl3g

I’m stumped!

As outlined here

ukmetofficedatahub.js is set to

        // Set the default config properties that is specific to this provider
        defaults: {
                apiBase: "https://api-metoffice.apiconnect.ibmcloud.com/v0/forecasts/point/daily/",
                apiKey: "<myID>",
                apiSecret: " <my secret>",
                lat: <my lat>,
                lon: <mylong>,
                windUnits: "mph"

(lines 50-55)

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

config.js set to

  		weatherProvider: "ukmetofficedatahub",
  		apiBase: "https://api-metoffice.apiconnect.ibmcloud.com/v0/forecasts/point/daily/",
  		apiKey: "<myID>",
  		apiSecret: " <my secret>",
  		lat: <my lat>,
  		lon: <my long>,
 		windUnits: "mph",
 		tempUnits: "metric",

(lines 20-27)

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

logs are clear… many server restarts…

i can curl required info and get something vaguely intelligent from the Met office Servers

curl --request GET \
  --url 'https://api-metoffice.apiconnect.ibmcloud.com/v0/forecasts/point/hourly?excludeParameterMetadata=false&includeLocationName=true&latitude=<my lat>&longitude=<my long>' \
  --header 'X-IBM-Client-Id:  <myID>' \
  --header 'X-IBM-Client-Secret: <my secret>' \
  --header 'accept: application/json'