SC1 watch face worked fine for years - now won't load, tried everything besides full factory reset

Brilliant, my last attempt to reply threw website errors.  I will try this now with a new API 3.0.  Will report back.

So I test now, trying your above FR935 method I didn't get the watchface to display.  Same symptoms; it flashes up for a millisecond, then has the "IQ!" error screen.  I did this with the watch in airplane mode, and let it rest for 30min.

I then subscribed to Openweathermap and got a One-Call-API3.0 plan, limited the calls to 999, and generated a new API key. 

However reading the docs briefly, the API3.0 call format is different?  This might still throw an error?

Still need Stavs Dev to chime in and update this lovely SC1 watchface.  The API 2.5 depreciation was October 7th, which I think was when my watchface stopped working - so I'm pretty sure you are correct the Openweather API calls are causing the issue.

Thanks so much for your ground work looking into this.  Either way I can not get the Dev's attention. 

Also, another huge Home Assistant fan here!  That link was perfect!  :) 

Oh shoot you're right, the urls have changed obviously. Idk why I would've assumed you could literally use a different API without changing the requests

openweathermap.org/one-call-transfer

So I test now, trying your above FR935 method I didn't get the watchface to display.  Same symptoms; it flashes up for a millisecond, then has the "IQ!" error screen.  I did this with the watch in airplane mode, and let it rest for 30min.

Yeah it's strange. What you're seeing makes more sense than what I'm seeing, since there's no good reason I can think of that an exception should be thrown on FR955 and not FR935

Perhaps the network request is failing on the FR935 at a different point, and the resulting error is being handled gracefully the app.

EDIT: SC1 still hasn't crashed on my FR935. I literally cannot do anything to make it crash

TL;DR actually, supported watches (like 945 LTE, 955 and Fenix 7) will apparently also use garmin weather in SC1 as a fallback, and the actual crash is caused by a change in Garmin weather for 955, Fenix 7, and devices of the same generation, but not 945 LTE.

935 doesn't crash (tries to use OWM and just fails normally) and doesn't display weather because CIQ apps for 935 don't support weather from Garmin

945 LTE works fine (displays weather and does not crash) bc it can use Garmin weather and it doesn't have the change.

955 and Fenix 7 crash bc they can no longer use OWM *and* they try to use Garmin weather, but they can't handle the change

--

So, I tried SC1 on a 945 LTE (yes, I have *another* fairly recent forerunner :/), and it works fine. The correct weather is displayed in the lower left circle, and the name of my city is displayed in the lower middle, above the sunrise/sunset values. It doesn't crash.

On my 955, just before SC1 crashes, the correct weather is displayed, but the city name is blank.

On my 935, SC1 doesn't crash, but no weather info is displayed at all, just "GPS OK" and "No data".

This actually confirms a suspicion I had before: newer watches aren't just trying to use the OWM API, they will also try to use weather from Garmin, which is not available for 935.

So here's what I think is actually happening:

- 935 is trying to use OWM API, and failing because the API has changed, but it doesn't crash

- 945 LTE uses weather data from Garmin successfully.

- 955, Fenix 7, and other watches of the same generation are using weather data from Garmin and crashing. Previously, they were able to use weather data from OWM without any problems, but they can't anymore. I think they are crashing because of a somewhat recent firmware change where the location name (observationLocationName) from Garmin weather is no longer populated (it's now null), and some apps are not written to handle this situation. This only happened a few months ago:

https://forums.garmin.com/developer/connect-iq/f/discussion/384956/observationlocationname-issue-on-api-5-0-1

https://forums.garmin.com/developer/connect-iq/i/bug-reports/cannot-get-location-of-garmin-weather-for-fenix8-series-devices

As I wrote in the bug report:

Seems to be a lot of reports of CIQ watchfaces crashing due to this change. I realize that this is entirely down to incorrectly written apps, but I wonder if it would’ve been better to return an empty string. (Yeah, I realize that would have consequences for apps that actually handle the null case properly, but probably aren’t expecting an empty string.)

It’s probably a no-win situation here — I have a feeling that there will be some old/unmaintained watchfaces that will be permanently broken (but hopefully they all have the ability to turn off the weather feature so users can continue to use the watchface without experiencing constant crashes.

Further evidence of this theory:

- SC8, from the same dev, was updated in Sep 20, and it the What's New section says:

So actually, Garmin has the ability to "fix" this problem by changing the device firmware to return a blank string for observationLocationName instead of null, but they probably won't.

To be fair, it's not their fault, as observationLocationName has been documented to return Null for a long time, so devs should've written code to handle that eventuality.

EDIT: I double checked old SDKs and observationLocationName has been documented to return Null since early 2021, at the same time that type checking was introduced in Monkey C. (SC1 was last updated in 2022)

If devs using observationLocationName had enabled type checking, they would have been forced to handle the case where it would be Null. To be fair, enabling type checking for projects that started out without type checking is a huge pain, as lots of code may need to be changed to resolve all the resulting type checking errors (some of which may not impact functionality.)

Thanks heaps for looking into this Flow State, pinpointing the issue definitely helps the Dev fix it in a timely manner, now we just need to get his attention.  Or source code.