Перевести значки погоды и будильника в шрифт #9
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Перевести значки погоды и будильника в шрифт
Перевести значки текущей погоды и будильника в шрифт на Main и AOD. Форму, толщину, размеры и расположение сохранить.
Шрифтовые значки уже подготовлены. Осталось найти способ получать от часов текущий тип погоды и состояние будильника. Сейчас прошивка сама выбирает картинку погоды и показывает картинку будильника.
Не подменять текущую погоду прогнозом. Не считать видимость виджета доказательством включённого будильника.
Задача выполнена, когда:
Погода и будильник отображаются шрифтом на Main и AOD.
Значок погоды соответствует текущей погоде.
Значок будильника появляется и исчезает при его включении и выключении.
Сохранён согласованный внешний вид.
Работа проверена на Amazfit Bip Max, включая переход Main → AOD → Main и возврат из приложений.
Связано с #8 и подготовкой 0.91.0-beta. Ветер отложен отдельно и в эту задачу не входит.
Для будильника есть конкретный обходной путь без чтения alarmEnabled. Для текущей погоды подтверждённого способа получить штатный код состояния я не нашёл — но нашёл готовую интеграцию с альтернативным источником и отдельный путь проверки нативного виджета.
Посмотрел саму задачу и реализацию: сейчас погода действительно оставлена на IMG_LEVEL + WEATHER_CURRENT, а будильник — на IMG_STATUS + CLOCK. Файл font-native-weather-alarm.js только разрешает эти исключения из шрифтовой миграции, а не получает их состояния.
Предлагаю использовать TEXT_FONT с hmUI.data_type.ALARM_CLOCK и специальной раскладкой глифов. Это моя инженерная гипотеза, не найденный готовый патч для Bip Max.
Основание достаточно предметное: Zepp документирует ALARM_CLOCK как время будильника в формате HH:MM, а в требованиях к циферблатам указывает время следующего будильника и пустое состояние --. Привязку TEXT_FONT к data_type также описывал представитель Zepp.
Как это должно работать
В отдельном шрифте, производном от уже подготовленного значка:
Символ Что рисует Ширина продвижения
-, пробел Ничего 0
Получается следующая цепочка:
Штатное значение "07:30" → пусто + пусто + ЗНАЧОК + пусто + пусто
Штатное значение "--" → пусто
Значок рисуется шрифтом, а выбор состояния остаётся за прошивкой. Не нужны ни getProperty(TEXT), ни чтение VISIBLE, ни постоянный JavaScript-опрос. Сам алгоритм не изменяет настройки будильника.
Для Main и AOD нужно использовать соответствующие утверждённые начертания и размеры, поставить char_space: 0 и сохранить размещение через существующий механизм управления нативными виджетами.
Что проверить перед внедрением
Сначала следует показать TEXT_FONT / ALARM_CLOCK обычным читаемым шрифтом рядом со штатным значком будильника. Проверить отсутствие будильников, все выключенные, один включённый, будильник только на следующий день или определённый день недели и отключение после однократного срабатывания.
Главная проверка — какую строку фактически выводит Bip Max в выключенном состоянии. Если это --, предложенное преобразование подходит. Если --:--, двоеточие останется и получится ложный включённый значок — такую реализацию принимать нельзя. Также нужно проверить формат 12/24 часа и Main → AOD → Main.
То есть первый полезный эксперимент — не очередной поиск скрытого alarmEnabled, а проверка TEXT_FONT + ALARM_CLOCK. При успешном результате будильник можно перевести в шрифт, вообще не вытаскивая его состояние в JavaScript.
Отдельно: @zos/alarm.getAllAlarms() здесь не поможет. Это список таймеров текущего мини-приложения, а не пользовательских будильников системного приложения.
Здесь нельзя применить тот же приём напрямую: документированный WEATHER_CURRENT для числового отображения — текущая температура, не код «ясно / облачно / дождь». А weather.getForecastWeather().forecastData.data[0].index относится к прогнозу на день и не выполняет условие твоей задачи.
Причём расхождение погодного сенсора со встроенным приложением уже обсуждалось разработчиками: в обращении к Zepp отдельно отмечены несовпадения температуры и index. Ответ про TEXT_FONT помогает сохранить нативную привязку чисел, но не предоставляет отдельный getter текущего типа погоды.
Один нативный путь, который имеет смысл проверить
Проверять нужно текущий выбранный уровень самого IMG_LEVEL, а не текст температуры:
// Диагностика, а НЕ подтверждённый getter погоды.
const properties = weatherWidget.getProperty(hmUI.prop.MORE, {});
И отдельно hmUI.prop.LEVEL — только если эта константа действительно экспортируется на часах.
Почему именно это направление: IMG_LEVEL выбирает изображение по level, а getProperty(MORE, {}) документирован как получение свойств виджета. Но Zepp прямо предупреждает, что получение свойств поддерживается не всеми виджетами. Поэтому из документации не следует, что для привязанной погоды вернётся именно актуальный выбранный кадр.
Критерий успеха здесь строгий: возвращаемое значение должно совпадать с реально выбранным погодным изображением и меняться вместе с ним. Постоянный 0, начальное значение конфигурации, undefined или просто список image_array — не результат.
И ещё ограничение: даже успешное чтение уровня само по себе не докажет возможность полностью удалить погодные PNG. Потребуется отдельно проверить, сохраняется ли нативная привязка без полного набора изображений. Иначе получится шрифтовая отрисовка, которая всё ещё зависит от скрытого растрового виджета.
Чтение TEXT повторять не стоит: в твоём диагностическом README уже записан аппаратный результат undefined для привязанного TEXT_FONT.
Это уже не моя гипотеза: автор RuWeather публикует интеграцию с циферблатами через файл текущей погоды weather.json, отдельно от forecast.json. В нём есть weatherIconString, weatherDescription и время обновления weatherTime. Опубликован и пример чтения через hmFS с указанием appid приложения.
Для шрифтового циферблата предлагаю такую обработку:
weather.json
→ проверка данных и времени обновления
→ weatherIconString
→ таблица соответствия твоим погодным глифам
→ TEXT со шрифтом Main / AOD
Здесь важно брать поле текущего состояния, а не hourlyForecast[0], и не считать числовой weatherIcon индексом твоего штатного массива: у приложения собственная система обозначений. Строковые теги вроде skc_d, skc_n, ovc позволяют сделать явную таблицу соответствий. Автор также приводит пример интегрированного циферблата для GTR 4, Balance и T-Rex 3; подтверждения именно для Bip Max на этой странице нет.
Но это альтернативная архитектура, а не незаметная замена реализации #9. Появляются дополнительное приложение, его обновления и другой источник погоды. Совпадение со штатным погодным значком Zepp гарантировать нельзя. Без согласования такой переход я бы в задачу не включал.
Что делать именно в твоём репозитории
Я бы начал с двух изолированных диагностик, не меняя рабочий релиз:
Будильник: читаемый TEXT_FONT / ALARM_CLOCK рядом с нативным IMG_STATUS / CLOCK; после подтверждения формата — шрифт, превращающий двоеточие в значок.
Погода: чтение свойств существующего IMG_LEVEL, с проверкой реального изменения выбранного уровня. Не подставлять прогноз при неудаче.
Наиболее перспективный результат сейчас — закрыть шрифтовой будильник через нативное время, не дожидаясь решения погоды. Для погоды найден готовый внешний источник RuWeather, но способ извлечения именно штатного текущего состояния остаётся неподтверждённым. Я не проверял эти гипотезы на физических часах, поэтому выдавать их за полностью решённую #9 было бы неправильно.