The Bip 6 widget shows "open Zepp to get weather" when our v5 response
omits or empty-stubs any dataset the firmware asked for. Fixes three gaps:
- Implement createDailyAirQuality with a 7-day skeleton (placeholder
AQI 50, level "good"; real ingestion gated on WeatherSpec extension).
- Replace EmptyResponse "{}" for hourlyAirQuality and dailyTide with
populated shape stubs (metadata + empty items list).
- Add a defensive else branch for unknown dataset names that returns a
metadata+empty-items skeleton and logs the key at WARN, so future
firmware additions surface in logs without silently dropping keys.
See docs/bip6-weather-widget-research.md for the diagnosis.
Source: https://github.com/PeterXMR/Gadgetbridge
(cherry picked from commit 8b9d4f319ecc69dcb3c9ebbe77c35a06df7ebbbc)
The v5 place dataset hard-coded latitude/longitude to "0.0" and used a
constant locationKey "accu:123456", which prevented watches that were
never provisioned via the official Zepp app (Bip 6, Active 2, ...) from
accepting the response as authoritative — they treated the zero coords
as a missing-location signal and silently refused to display weather
(issue #5653).
- ZeppOsWeatherHandlerV5.createPlace: pull lat/lon from WeatherSpec
when set, else fall back to the user-configured location pref. Format
with Locale.ROOT and derive a stable per-location locationKey from a
hash of the coords so the watch can dedupe responses.
- ZeppOsWeatherService.onSendWeather: same fallback chain for the
CMD_SET_DEFAULT_LOCATION packet so the watch's default-location state
is bootstrapped with real coordinates instead of "1.234,-5.678".
Refs #5653.
source: https://github.com/PeterXMR/Gadgetbridge
(cherry picked from commit be87ac3364fbf5725f43e3dbac87ef2e103fdd89)
Peter KandThomas Kuehne