As of Tuesday, my Weather DIsplay does not connect with OWM

[ArtieRomero]

Dave, My Weather Display has been updating flawlessly for almost a year, but stopped updating on Tuesday (April 18).

I then took a spare Lolin D32 that had the weather display programmed onto it last summer and connected it via a cord to my computer running Arduino IDE and pressed the microprocessor's reset button. The serial monitor shows that the microprocessor's program properly accessed my WiFi, but immediately after this readout there is a message stating the following.

connection failed, error: connection refused connection failed (and this repeats several times). Then it goes into "deep sleep".

I went to my OWM account, and logged in to see my API key for my account and all looks normal. I then made a weather request using my internet browser using the URL method, including my APK key and I successfully obtained the weather details this way. So my API key is working properly it seems.

Yet I failed to obtain the weather data using either of these two separate approaches that use the microprocessor and the ePaper weather display code. Do you have any suggestions? Thank you.

[G6EJD]

I think we may be seeing the impact of OWM introducing their new API charging scheme as they have withdrawn API 2.5 for 3.0, they are the same but now they will charge for more than 1000 calls a day, you can set a daily limit but need to add a charging method to get access. I’ll investigate today. if you have an API key you should have received an email explaining the changes.

[ArtieRomero]

Yes; the migration to OWM 3.0 may be the cause. I checked my spam folder, etc. and have received no email notifications from OWM.

I also checked with someone living on the other side of the U.S. to whom I gave a duplicate of my Weather DIsplay and it stopped updating, too. Both of these non-working Displays use API keys generated from the same email account in OWM, but stopped updating days apart.

Interesting is that I have a small color TFT weather display created using Squix's code and it is still updating. This device's OWM API key was created many years ago using a different OWM email account. So the stoppage is not uniform.

[G6EJD]

Yes interestingly, I have a fairly old account and that's still working too.

All of the API calls are structures .../2.5/... so I expect everything to stop on or around June 2024, plus there is no documentation to advise as to whether .../2.5/... has to be changed to .../3.0/... which I suppose will be necessary (logically) and of course credit card details need to be added to the account even though it's still free.

I'll keep watching this and when required I'll update the codes accordingly.

[ArtieRomero]

Dave,

I am connected with someone at OWM to figure out what is going on. They responded with "Could you please send me the API call (url) you are trying to make, so I can further investigate the issue?:, but I am not sure what information to provide since:

1. I don't know what the Weather Display's generated API call looks like.... It appears to me that it might be generated by the "WiFi.h" library. (??)
2. I did try taking the text from the Example API call that you show near the top of the code, pasting into this my API key, and then pasted this entire string into my browser's box and hit Enter. In this case I successfully receive a text string showing the weather data for Melksham. [The Example API call I am referring to is: http://api.openweathermap.org/data/2.5/weather?q=Melksham,UK&APPID=your_OWM_API_key&mode=json&units=metric&cnt=1 ]
3. The result is that the Weather Display cannot make the connection BUT the URL method does work.

Does this make sense? Will the Weather Dislpay's generated API call look like your Example API call (but with a functional API key). If so, any idea why the URL method works but the Weather Display's call does not work?

On Fri, Apr 19, 2024 at 8:39 AM G6EJD @.***> wrote:

Yes interestingly, I have a fairly old account and that's still working too.

All of the API calls are structures .../2.5/... so I expect everything to stop on or around June 2024, plus there is no documentation to advise as to whether .../2.5/... has to be changed to .../3.0/... which I suppose will be necessary (logically) and of course credit card details need to be added to the account even though it's still free.

I'll keep watching this and when required I'll update the codes accordingly.

— Reply to this email directly, view it on GitHub https://github.com/G6EJD/ESP32-e-Paper-Weather-Display/issues/250#issuecomment-2066612308, or unsubscribe https://github.com/notifications/unsubscribe-auth/BBK2GRLR6HYLTGWGBC5K7K3Y6ENBRAVCNFSM6AAAAABGOKR222VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRWGYYTEMZQHA . You are receiving this because you authored the thread.Message ID: @.***>

[G6EJD]

There is an API example in the code in the credentials file all it needs is the API to be added s d then click on the line, it should return a lot of JSON text enclosed in many { text } brackets. I’ve just tried it all working ok. So could be an account issue, if too many calls in a day you’ll get an error response in json format

[ArtieRomero]

The API example in the credentials file works when I incorporate my API key and request the weather conditions using the URL method.

So it is only the actual Weather Displays that suddenly stopped working. These two Weather DIsplays, both of which stopped updating Tuesday night, use this same API key, have been working for months and are located over 1000 miles apart. The total number of API calls/day are quite small and are way under the limit for a free OWM account.

Tonight I am going to register for a new OWM account using a different email address and obtain a new API key to incorporate into the Weather Display code to see if that solves the problem.

On Fri, Apr 19, 2024 at 11:36 AM G6EJD @.***> wrote:

There is an API example in the code in the credentials file all it needs is the API to be added s d then click on the line, it should return a lot of JSON text enclosed in many { text } brackets. I’ve just tried it all working ok. So could be an account issue, if too many calls in a day you’ll get an error response in json format

— Reply to this email directly, view it on GitHub https://github.com/G6EJD/ESP32-e-Paper-Weather-Display/issues/250#issuecomment-2066919550, or unsubscribe https://github.com/notifications/unsubscribe-auth/BBK2GRITZYYAQGB2WJDOIZ3Y6FB2HAVCNFSM6AAAAABGOKR222VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRWHEYTSNJVGA . You are receiving this because you authored the thread.Message ID: @.***>

[G6EJD]

So when you monitor the serial port do you see any data being received or an error message? It the ESP32 does t get time it will fail to receive the data.

[ArtieRomero]

I don't have the device with me, but the serial monitor indicates that it can log-into and connect to my WiFi transmitter, and then prints its ISP number. Immediately following this, the serial monitor prints something to the effect of: connection failed, error: connection refused connection failed (and this repeats several times). Then the serial monitor says that the Weather Display is going into "deep sleep".

This Weather Display has worked flawlessly for almost a year, updating every 30 min between 7 a.m. and 10:30 p.m. I am way under the limit for API calls for a free OWM account.

And finally, I have now checked with both of my kids, living in different parts of the U.S. who have cloned Weather Displays that I gave them last summer, each of which uses different API keys generated from my same OWM email account, and they all suddenly stopped updating on Tuesday night.

Interestingly, the API keys work when requesting the weather data by entering the API call into the internet browser's URL.

On Fri, Apr 19, 2024 at 12:11 PM G6EJD @.***> wrote:

So when you monitor the serial port do you see any data being received or an error message? It the ESP32 does t get time it will fail to receive the data.

— Reply to this email directly, view it on GitHub https://github.com/G6EJD/ESP32-e-Paper-Weather-Display/issues/250#issuecomment-2066972541, or unsubscribe https://github.com/notifications/unsubscribe-auth/BBK2GRNTFIV6YEH4ALTD47LY6FF23AVCNFSM6AAAAABGOKR222VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRWHE3TENJUGE . You are receiving this because you authored the thread.Message ID: @.***>

[G6EJD]

Which time server is being used, if specific move it up one level eg x.pool.ntp.org becomes pool.ntp.org

[ArtieRomero]

Ahhh. Good idea. All of these affected Weather Displays use the same time server. I will select an alternate time server when I get home tonight and make another attempt and see if the error message on the serial monitor goes away. I'll report back.

On Fri, Apr 19, 2024 at 1:59 PM G6EJD @.***> wrote:

Which time server is being used, if specific move it up one level eg x.pool.ntp.org becomes pool.ntp.org

— Reply to this email directly, view it on GitHub https://github.com/G6EJD/ESP32-e-Paper-Weather-Display/issues/250#issuecomment-2067129432, or unsubscribe https://github.com/notifications/unsubscribe-auth/BBK2GRKGPEPB2DKHFNVYPDTY6FSSNAVCNFSM6AAAAABGOKR222VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRXGEZDSNBTGI . You are receiving this because you authored the thread.Message ID: @.***>

[ArtieRomero]

David,

First, this is the error that I received on the Serial Monitor:

20:35:31.323 -> WiFi connected at: 192.168.1.223

20:35:32.821 -> connection failed, error: connection failed, error: connection failed, error: connection failed, error: Entering 1478-secs of sleep time

20:35:33.543 -> Awake for : 3.615-secs

20:35:33.543 -> Starting deep-sleep period...

--> However, I found the issue (below). I located the issue by using your Melksham, UK location and the code executed perfectly. It appears that OWM (or the ntp time server?) has modified the input format for the weather location and the format that I was previously using is now incompatible.

I live in Wildwood, Missouri (abbreviated as MO) and there are several Wildwoods in the U.S., so I previously used "Wildwood, MO" as my location in the Credentials and it worked. [Way back, before using this, I verified that it returned my local weather by manually entering this into the OWM website.]

Now, when I replace "Wildwood, MO" with "Wildwood", the program successfully returned my local weather. I don't know how it selected my particular Wildwood, but it works. I played around and entered a few other U.S. cities without their state information and they all worked.

This also explains why the Weather Displays that I shipped to my kids stopped working since I also used similar location styles for them (e.g. "Seattle, WA", and "Denver, CO". This must be a recent change at OWM. Interestingly, these three Weather DIsplays stopped working days apart from each other, so OWM must have made changes in some sort of rolling fashion.

Thanks for your help!

On Fri, Apr 19, 2024 at 1:59 PM G6EJD @.***> wrote:

Which time server is being used, if specific move it up one level eg x.pool.ntp.org becomes pool.ntp.org

— Reply to this email directly, view it on GitHub https://github.com/G6EJD/ESP32-e-Paper-Weather-Display/issues/250#issuecomment-2067129432, or unsubscribe https://github.com/notifications/unsubscribe-auth/BBK2GRKGPEPB2DKHFNVYPDTY6FSSNAVCNFSM6AAAAABGOKR222VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRXGEZDSNBTGI . You are receiving this because you authored the thread.Message ID: @.***>

[G6EJD]

Good news, there’s always a reason! But wouldn’t it good if OWM advised everyone on their website that they are making a change, it’s actually very strange that they didn’t do that. It suggests a lack of experience in whoever runs the service.

[ArtieRomero]

David,

With additional sleuthing, I have the issue(s) figured out for why several Weather Displays that I gave to family members distributed across the U.S. stopped working after almost a year.

In the owm_credentials.h page:

1. I live in Wildwood, Missouri (a.k.a. Wildwood, MO). I entered "Wildwood, MO" as my city and this worked for the past year. Similarly, the Weather DIsplays that I made for my kids, living in Seattle, WA, and Denver, CO, all worked fine for the past year. But with close reading, I saw that OWM requires that the city and state be separated only by a comma and there is not a space following the comma. My inclusion of the space did not create a problem until the past couple of weeks when all of these Weather DIsplays stopped updating. When I edited (e.g.) my city and state to "Wildwood,MO" without the space, the program worked and updated my Weather Display. I then played with the code, removing and reinserting the spaces in "Seattle,WA" and "Denver,CO", this caused the Weather DIsplay to update and then not update, repeatably. In short, it appears that OWM tightened-up their formatting stringency for the API call.

2. It also appears that some smaller cities dropped off of their GeoCode look-up list. As I understand it, OWM uses Lat and Long to fetch the local weather, but as a convenience, has a city look-up service with a list of ~200k cities worldwide so that the user can name the city and OWM will look up the Lat and Long as it begins the weather fetch. I have a fourth Weather Display that I made for my brother who lives in Myrtle Grove, NC that also stopped updating. Unlike the above, I could not get the code to work when removing the space to read "Myrtle Grove,NC". But I then used the name of a larger city nearby and entered "Wilmington,NC" and the display updated. So it appears that the town of Myrtle Grove has fallen off of the OWM GeoCode look-up list. or there is some special formatting that the two-word "Myrtle Grove" now requires. I tried "MyrtleGrove,NC" and "Myrtle_Grove,NC" and neither of these work. But for the past year, I was able to fetch weather for Myrtle Grove

As an aside, I also previously used "U.S." for the country code and this worked, but after this episode, I changed to the ISO 3166's "US" to avoid a possible future issue.

Cheers

On Sat, Apr 20, 2024 at 3:51 AM G6EJD @.***> wrote:

Good news, there’s always a reason! But wouldn’t it good if OWM advised everyone on their website that they are making a change, it’s actually very strange that they didn’t do that. It suggests a lack of experience in whoever runs the service.

— Reply to this email directly, view it on GitHub https://github.com/G6EJD/ESP32-e-Paper-Weather-Display/issues/250#issuecomment-2067607604, or unsubscribe https://github.com/notifications/unsubscribe-auth/BBK2GRPBZOQRH2LSLRPE3Y3Y6IT7VAVCNFSM6AAAAABGOKR222VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRXGYYDONRQGQ . You are receiving this because you authored the thread.Message ID: @.***>