Avamander
commented
1 year ago GB delivers 2 temperature values to the watch, the first is the current temperature with an expiry time of 6h, the 2nd is called 24h forecast, has an expiry of 24h
Keep in mind that both expiricy times are fairly arbitrary because GB doesn't get that information with the current WeatherSpec. This could be raised with GB devs as a potential change.
is generated by adding the daily high and low temperatures together then dividing by 2, to give an average(ish) temperature for the day
This could be split up into two different values, making min/max work more predictably. Though it is not known how often this data is pushed and it might consume too much memory.
My first instinct is to simply remove the 24h forecast from the data GB delivers to the watch, via a PR against GB to remove lines 779-804 of the above file.
There is however no guarantee that GB will receive other WeatherSpecs at all. Which can result in ignoring the only weather data available.
We could modify the getCurrentTemperature function to pick the entry which has a shorter expiry time, but that feels like working around the issue rather than fixing it.
It is intended that the timeline can contain overlaps for the same type of data. Choosing data that expires sooner would probably be better on average than not, but it wouldn't guarantee being always correct.
One other option would be to ignore the long-lasting forecast in the PTS watchface. Some other components might still want to display it, possibly with more text/explanation.
qualimock
Verification
What happened?
When the phone was displaying 25 degrees, the watch shows 20 degrees.
What should happen instead?
The watch should show the same temperature as the phone
Reproduction steps
Install InfiniTime 1.13, select PineTimeStyle, enable weather. Install GadgetBridge, install TWFG, enable weather integration. Refresh Weather. Check temperature displayed on your phone Check temperature displayed on your watch Be disappointed they don't match.
More details?
I'm opening this issue because I'm not sure what the right solution is and it's entirely possible I've misunderstood something.
Currently, on each weather refresh, GB delivers 2 temperature values to the watch, the first is the current temperature with an expiry time of 6h, the 2nd is called 24h forecast, has an expiry of 24h, and is generated by adding the daily high and low temperatures together then dividing by 2, to give an average(ish) temperature for the day. Details here
The issue is that the watch has no way to know which of these 2 temperature values to pick, so it does so at random, more often than not it displays the wrong value.
My first instinct is to simply remove the 24h forecast from the data GB delivers to the watch, via a PR against GB to remove lines 779-804 of the above file. This means we will only have 1 temperature value in the timeline per timestamp which should mean that the watch shows the same current temperature as the phone. Hopefully we can then work towards handling longer forecast data by creating multiple events with separate timestamps and expiries so the temperature updates even without new data being supplied, but in the short term the temperature should display something somewhat valid for 6h, and if new data is received that will be displayed instead.
We could modify the getCurrentTemperature function to pick the entry which has a shorter expiry time, but that feels like working around the issue rather than fixing it. Whatever the solution we probably need to also modify this function to handle overlapping entries (if GB sends a 6h forecast every hour for example)
Version
1.13
Companion app
Gadgetbridge