weather: Add location, last updated, and sunrise/sunset display

[vkareh]

This change splits the weather screen into 3 pages:

• Current weather conditions
• 5-day forecast
• Sunrise/sunset times

Note: This requires #2100

Here are some screenshots of the full app:

And this shows the sun times animation:

The idea for showing the sun position arc was taken from Breezy Weather, which is the provider I use for Gadgetbridge:

[github-actions]

Build size and comparison to main:

Section	Size	Difference
text	385720B	2940B
data	944B	0B
bss	22640B	8B

Run in InfiniEmu

[vkareh]

I've made this a draft since #2100 is not merged and may still get some protocol changes.

I'm also playing with different ways of representing this data, especially the sunset/sunrise. For example, this iteration:

• the arc is empty when it's before sunrise
• the arc is full when it's after sunset

But I have another version that inverts the entire thing:

• After sunset, the sun and moon icons swap places and it shows a blue arc with the progress for the night
  The problem with this approach is that before midnight we don't have tomorrow's sunrise time, and after midnight we don't have yesterday's sunset time, so the arc shows an approximation using the available data (assuming that the difference between one day and another is only a few minutes and so not visibly different).

Before midnight (but after sunset):

After midnight (but before sunrise):

But in any case, I'm exploring different paths and would like people's opinion on what they want to see and how they want it presented.

Also could be fun to add more data to the protocol, like wind speed/direction, phase of the moon (can use another arc to show the moonrise/moonset times, as well as an icon of the moon phase), etc.

[mark9064]

Redesign looks great visually!

The sun time one is tricky. Not sure what I prefer, the empty arc when the sun is down is certainly good enough IMO but doing more might be nice. I think my biggest feature request would probably be by-hour weather for the next few hours. But not sure if that's practical space wise.

[vkareh]

Hourly forecast might be fine if we only include limited info. The sunrise/sunset times may be included in the daily forecast.
I think this can look like this:

Current Weather:

 - [0] : Message type = `0`
 - [1] : Message version = `1`
 - [2][3][4][5][6][7][8][9] : Timestamp in local time
 - [10, 11] : Current temperature (°C * 100)
 - [12, 13] : Minimum temperature (°C * 100)
 - [14, 15] : Maximum temperature (°C * 100)
 - [16]..[47] : location (string, unused characters should be set to `0`)
 - [48] : icon ID
 - [49, 50] : Sunrise (16 bits, number of minutes elapsed since midnight)
 - [51, 52] : Sunset (16 bits, number of minutes elapsed since midnight)

Daily Forecast:

  - [0] : Message type = `1`
  - [1] : Message version = `0`
  - [2][3][4][5][6][7][8][9] : Timestamp in local time
  - [10] Number of days (Max 5, fields for unused days should be set to `0`)
  - [11, 12] Day 0 Minimum temperature (°C * 100)
  - [13, 14] Day 0 Maximum temperature (°C * 100)
  - [15] Day 0 Icon ID
  - [16, 17] : Day 0 Sunrise (16 bits, number of minutes elapsed since midnight)
  - [18, 19] : Day 0 Sunset (16 bits, number of minutes elapsed since midnight)
  - [...] all other days, repeating from bits [11 - 19]

Hourly Forecast:

  - [0] : Message type = `2`
  - [1] : Message version = `0`
  - [2][3][4][5][6][7][8][9] : Timestamp in local time
  - [10] Number of hours (Max 5, fields for unused days should be set to `0`)
  - [11, 12] Hour 0 Minimum temperature (°C * 100)
  - [13, 14] Hour 0 Maximum temperature (°C * 100)
  - [15] Hour 0 Icon ID
  - [...] all other hours, repeating from bits [11 - 15]

Doing this adds 160 bits for sunrise/sunset (or 32 if we're stingy and only provide space for next day, which is the one we need), and 280 if we add hourly forecast for the next 5 hours (each hour is 40 bits, plus 80 bits of header) - this would still require assuming which hour it refers to, basically take the timestamp and add 3600 seconds for the first hour, 3600*2 for the second hour, etc. Alternatively, we round up to the next whole hour. What I don't want is to necessarily add a new timestamp (64 bits) for each next hour - we should do that calculation in Gadgetbridge instead.

[mark9064]

I think for each hour we only need to store one temperature, having a minimum and maximum per hour seems overkill

Yeah agree, having a timestamp per hour would not be great. We could have one timestamp for the first hour and compute the rest? Might be a good compromise and avoids problems if a weather update is delayed due to a bad BLE connection or something