Не спорю. Если часы начинают жить вместо тебя это уже перебор, и мне самому такое не нужно.
У меня задача другая: не разбирать каждую цифру, а один раз спросить «как прошла неделя» и получить ответ по своим данным, без скринов и без ручного листания Garmin Connect. Дальше смотреть в часы или нет уже выбор человека, не обязанность.
Справедливо, с холтером ровно так и есть: кардиолог потом сверяет пики пульса с твоим же дневником "12:00 - лестница, 15:00 - начальник наорал", иначе половина графика необъяснима.
У Garmin с этим проще и хуже одновременно: сам контекст она не пишет, зато не надо вести дневник руками стресс, HRV и пульс уже привязаны к времени, и когда спрашиваю бота "почему сегодня стресс скакнул", ему хватает моих же тренировок и сна за последние недели, чтобы предположить что-то осмысленное. Но да, если бы часы ещё писали "покакал" с таймстампом на некоторые пульсовые скачки было бы приятно наконец получить объяснение.
Спасибо, не знал про Rouse Context,гляну. Действительно закрывает именно ту часть, о которой я писал: не нужно самому писать Android-приложение для чтения Health Connect, кто-то уже это сделал и раздаёт как MCP-сервер.
Но тут есть нюанс, который сам же и назвал: это решает задачу "достать данные", только если у пользователя вообще есть AI-клиент с поддержкой произвольных MCP-серверов. С ChatGPT Free/Plus, как понимаю, не заведётся вообще, с Claude Free ограниченно, нормально работает с openwebui/Cursor/Claude Pro. У меня в проекте задача была прямо противоположная: чтобы человек без всякого MCP и без платных тарифов просто поставил бота в Telegram и написал ему текстом. Rouse Context, получается, отличный вариант для тех, кто уже сидит в экосистеме MCP-клиентов, но не отменяет отдельную задачу для тех, кто в неё не встроен.
Для CMF/Nothing X всё равно придётся смотреть отдельно, сам факт, что данные лежат в Health Connect, не значит, что телефон должен быть постоянно доступен как сервер, плюс не проверял, что там по факту приходит от CMF конкретно. Но как отправная точка, спасибо, буду иметь в виду
Согласен, разумная позиция. У меня инструмент не про то, чтобы жить по графику или гнаться за цифрами. Он вообще не про мотивацию и не про план. Просто чтобы не листать самому экраны в Garmin Connect и не скидывать скрины в чат по одному, когда хочется спросить что-то про свои же данные.
Модель придумывает саму тренировку какие шаги, сколько интервалов, какие пульсовые зоны. Но записать это в Garmin напрямую она не может. Между её ответом и реальной записью стоит обычный код с жёсткими проверками: если суммарная длительность выходит за разумные границы или структура похожа на тот самый баг (когда одна тренировка на 30 минут превращается в повторяющийся блок на 4 часа) код просто отказывается отправлять план дальше, до Garmin он не доходит вообще.
И даже если проверки пройдены, бот не отправляет тренировку сразу. Он показывает мне готовый план текстом (сколько по времени, что за шаги, какие зоны) и ждёт, что я нажму подтвердить или отменить. То есть модель придумывает содержание, а решение "действительно отправлять или нет" всегда остаётся за проверкой кода и за мной, а не за LLM.
Сомнительно, у CMF/Nothing X закрыто, публичного API не нашёл. Данные с часов уходят в Apple Health на iOS и в Health Connect на Android через само приложение, но это не облачный API, который можно дёргать с сервера, а хранилище на самом телефоне. Чтобы забрать оттуда данные, нужен не скрипт, а отдельное мобильное приложение с разрешением на чтение Health Connect/HealthKit, это совсем другая по объёму задача, чем с Garmin или Polar, где есть облачный API.
Единственный официальный путь без костылей, письмо на privacy@nothing.tech с запросом выгрузки по EU Data Act, но это разовый архив, а не что-то, что можно синхронизировать регулярно.
Так что пока не обещаю, слишком другая архитектура интеграции.
Polar с официальным API это прямо тот случай про открытость к другим устройствам: если данные можно получить легально через API, а не выцарапывать руками, задача сильно проще, чем то, что было с Garmin.
Готов посмотреть на Polar AccessLink и попробовать собрать под него ту же логику: кэш, отчёты, бот. Но у меня самого нет Polar, вслепую писать интеграцию рискованно, легко сделать то, что выглядит правильно в коде, но ломается на реальных данных. Если вы готовы потестировать на своём аккаунте, получить токены, прогнать пару запросов, проверить, что реально приходит, можно собрать рабочий прототип. Пиши, договоримся, как организовать.
Геймификация это не вся польза, а один из сценариев, и не самый интересный. Можно спросить не «как растёт график», а «почему нагрузка растёт, а восстановление нет», и это уже не про красивые цифры, а про риск перетрена. Просто это другой вопрос, чем тот, который ты задавал.
Тут соглашусь наполовину. Часы не идеальны, это правда. У меня кроме часов ещё нагрудный датчик пульса, который включаю именно на тренировках, для пульса это точнее часов. А вот сон, HRV, стресс, Body Battery всё равно только с часов, там альтернативы нет. Так что часть данных надёжнее часов, часть завязана на них полностью, и это ограничение я не скрываю.
Не так. ИИ ничего не решает и не навязывает. Он делает то, что я попросил словами, показывает план и ждёт подтверждения, прежде чем что-то уйдёт в Garmin. Решение всегда моё.
И тренировка привязана к дате, не к конкретному часу. 19:00 или 19:30 бежать, решаю я сам, глядя на часы, а не бот.
Bevel реальный, по отзывам неплохой. Но у меня другая задача: важно было именно свои данные из Garmin донести до моего ChatGPT, у меня там переписка с 2023 года, ещё с версией GPT-3.5, и весь контекст моего образа жизни уже накоплен в ней. Заводить отдельного встроенного коуча в новом закрытом приложении смысла не было, хотелось кормить данными именно этот чат.
Плюс Bevel облачная подписка, закрытый код, только iOS, и по Garmin историю тянет всего месяц (ограничение самого Garmin API, в их же фидбеке люди жалуются и ссылаются на ту же библиотеку, что у меня, как на обходной путь). У меня открытый код, локальный кэш без такого ограничения, и агент, который не только показывает цифры, но может создать тренировку прямо в Garmin.
Через python-garminconnect (cyberjunky на GitHub) неофициальную библиотеку, которая имитирует запросы из веб-версии Garmin Connect: логинишься своей учёткой, дальше через неё дёргаешь эндпоинты, которые обычно ходят из браузера. Официального публичного API у Garmin для такого нет, поэтому это ровно reverse-engineered доступ, а не что-то задокументированное самим Garmin.
Согласен. Пока агент только читает HRV и собирает отчёт, цена ошибки - кривой markdown. Когда он пишет интервалы и зоны обратно в Garmin, цена уже другая: сломанная тренировка на часах.
Open source закрывает вопрос «куда уходят данные». Вопрос «насколько совету/действию можно доверять» он сам по себе не закрывает. Поэтому у изменяющих действий сейчас human-in-the-loop: бот не пишет в Garmin сам, показывает кнопки подтверждения. Это не валидация совета как у врача или тренера, а хотя бы явная точка, где человек смотрит и решает.
Дальше как раз и начинается продукт с ответственностью: проверять, что агент собрал, до нажатия «Подтвердить», а не чинить уже после.
Полностью открытым решение быть не может оно включает внутренние компоненты и интеграции, завязанные на корпоративную инфраструктуру, CI и окружение. Однако концепция остаётся универсальной, и её можно воспроизвести в облегчённом виде на любой машине:
запись действий + UI-метаданных,
сценарии в виде JSON,
раннер, который воспроизводит шаги и выполняет проверки.
Я рассматриваю возможность собрать небольшую демонстрационную версию без корпоративных зависимостей чтобы показать сам подход. Если будет запрос на это со стороны сообщества, можно сделать такой вариант.
Спасибо за вопросы - отвечу кратко и в рамках того, что можно описывать публично.
Аналог UI Automation в Linux Прямого аналога Windows UIA нет. Есть AT-SPI, но поддержка фрагментирована и зависит от тулкита (GTK/Qt). Поэтому в Linux работает только облегчённый режим: базовые операции доступны, но без полноценного дерева UI. Это скорее вспомогательная возможность, а не основная платформа.
Надёжность тестов На Windows тесты получаются устойчивые именно за счёт многослойного поиска элементов и использования нескольких источников метаданных. Мы не стремимся к 100% стабильности - она недостижима в принципе - но достигаем высокой повторяемости при реальных сценариях.
Продемонстрировать запись/воспроизведение Рабочие записи привязаны к корпоративным приложениям, поэтому показывать их нельзя. Думаю над подготовкой краткого публичного демо на нейтральном приложении.
Визуализация фиксируемых элементов Визуализация есть, но она утилитарная: отображает структуру метаданных элемента и путь в UI-дереве. Это внутренний технический инструмент, он не предназначен для широкого использования.
Вкладывание скриптов Да, есть механизм компоновки сценариев, чтобы переиспользовать повторяющиеся последовательности действий. Это позволяет сократить объём тестов и уменьшить рутинные правки при изменениях UI.
Если будет интерес, могу позже подготовить отдельный материал по архитектурным принципам, не углубляясь в закрытую часть реализации.
Да, вы совершенно правы — в идеальном мире API для САПР должно закрывать все потребности тестирования. Но у нас ситуация такая, что оно, к сожалению, не охватывает весь функционал, особенно если говорить про рендеринг, работу с 2D/3D-моделями и визуализацию.
Поэтому мы идем через эмуляцию действий пользователя: это помогает не просто проверить интерфейс, но и убедиться, что сама система — взаимодействие с моделью, отрисовка, поведение инструментов — работает как надо. По сути, мы воспроизводим реальный сценарий использования, чтобы ничего не упустить.
Если бы API давало полный контроль над этими штуками, мы бы, конечно, с радостью на него опирались. Но пока оно не тянет, особенно в части рендеринга и динамики инструментов.
Не спорю. Если часы начинают жить вместо тебя это уже перебор, и мне самому такое не нужно.
У меня задача другая: не разбирать каждую цифру, а один раз спросить «как прошла неделя» и получить ответ по своим данным, без скринов и без ручного листания Garmin Connect. Дальше смотреть в часы или нет уже выбор человека, не обязанность.
Справедливо, с холтером ровно так и есть: кардиолог потом сверяет пики пульса с твоим же дневником "12:00 - лестница, 15:00 - начальник наорал", иначе половина графика необъяснима.
У Garmin с этим проще и хуже одновременно: сам контекст она не пишет, зато не надо вести дневник руками стресс, HRV и пульс уже привязаны к времени, и когда спрашиваю бота "почему сегодня стресс скакнул", ему хватает моих же тренировок и сна за последние недели, чтобы предположить что-то осмысленное. Но да, если бы часы ещё писали "покакал" с таймстампом на некоторые пульсовые скачки было бы приятно наконец получить объяснение.
Спасибо, не знал про Rouse Context,гляну. Действительно закрывает именно ту часть, о которой я писал: не нужно самому писать Android-приложение для чтения Health Connect, кто-то уже это сделал и раздаёт как MCP-сервер.
Но тут есть нюанс, который сам же и назвал: это решает задачу "достать данные", только если у пользователя вообще есть AI-клиент с поддержкой произвольных MCP-серверов. С ChatGPT Free/Plus, как понимаю, не заведётся вообще, с Claude Free ограниченно, нормально работает с openwebui/Cursor/Claude Pro. У меня в проекте задача была прямо противоположная: чтобы человек без всякого MCP и без платных тарифов просто поставил бота в Telegram и написал ему текстом. Rouse Context, получается, отличный вариант для тех, кто уже сидит в экосистеме MCP-клиентов, но не отменяет отдельную задачу для тех, кто в неё не встроен.
Для CMF/Nothing X всё равно придётся смотреть отдельно, сам факт, что данные лежат в Health Connect, не значит, что телефон должен быть постоянно доступен как сервер, плюс не проверял, что там по факту приходит от CMF конкретно. Но как отправная точка, спасибо, буду иметь в виду
Благодарю!
Согласен, разумная позиция. У меня инструмент не про то, чтобы жить по графику или гнаться за цифрами. Он вообще не про мотивацию и не про план. Просто чтобы не листать самому экраны в Garmin Connect и не скидывать скрины в чат по одному, когда хочется спросить что-то про свои же данные.
Модель придумывает саму тренировку какие шаги, сколько интервалов, какие пульсовые зоны. Но записать это в Garmin напрямую она не может. Между её ответом и реальной записью стоит обычный код с жёсткими проверками: если суммарная длительность выходит за разумные границы или структура похожа на тот самый баг (когда одна тренировка на 30 минут превращается в повторяющийся блок на 4 часа) код просто отказывается отправлять план дальше, до Garmin он не доходит вообще.
И даже если проверки пройдены, бот не отправляет тренировку сразу. Он показывает мне готовый план текстом (сколько по времени, что за шаги, какие зоны) и ждёт, что я нажму подтвердить или отменить. То есть модель придумывает содержание, а решение "действительно отправлять или нет" всегда остаётся за проверкой кода и за мной, а не за LLM.
Сомнительно, у CMF/Nothing X закрыто, публичного API не нашёл. Данные с часов уходят в Apple Health на iOS и в Health Connect на Android через само приложение, но это не облачный API, который можно дёргать с сервера, а хранилище на самом телефоне. Чтобы забрать оттуда данные, нужен не скрипт, а отдельное мобильное приложение с разрешением на чтение Health Connect/HealthKit, это совсем другая по объёму задача, чем с Garmin или Polar, где есть облачный API.
Единственный официальный путь без костылей, письмо на privacy@nothing.tech с запросом выгрузки по EU Data Act, но это разовый архив, а не что-то, что можно синхронизировать регулярно.
Так что пока не обещаю, слишком другая архитектура интеграции.
Polar с официальным API это прямо тот случай про открытость к другим устройствам: если данные можно получить легально через API, а не выцарапывать руками, задача сильно проще, чем то, что было с Garmin.
Готов посмотреть на Polar AccessLink и попробовать собрать под него ту же логику: кэш, отчёты, бот. Но у меня самого нет Polar, вслепую писать интеграцию рискованно, легко сделать то, что выглядит правильно в коде, но ломается на реальных данных. Если вы готовы потестировать на своём аккаунте, получить токены, прогнать пару запросов, проверить, что реально приходит, можно собрать рабочий прототип. Пиши, договоримся, как организовать.
Геймификация это не вся польза, а один из сценариев, и не самый интересный. Можно спросить не «как растёт график», а «почему нагрузка растёт, а восстановление нет», и это уже не про красивые цифры, а про риск перетрена. Просто это другой вопрос, чем тот, который ты задавал.
Конкретно: это агент, который отвечает по твоим собственным данным Garmin в диалоге, а не общими фразами. Закрывает несколько задач:
Тренер: разбирает пульс, зоны, восстановление, историю тренировок, может сам создать и запланировать тренировку в Garmin по запросу.
Аналитик: отвечает на разовые вопросы типа «сколько я пробежал в мае» или «сравни эту неделю с прошлой по пульсу», без ручного копания в приложении.
Нутрициолог, но только если сам расскажешь ему, что ел, тогда сопоставит с тренировками и калориями. Само по себе питание не трекает.
Память: держит контекст за месяцы, а не только последний скрин, который принёс в чат.
Это не диагностика и не медицинский совет, просто разбор твоих же цифр вместо ручного анализа.
Тут соглашусь наполовину. Часы не идеальны, это правда. У меня кроме часов ещё нагрудный датчик пульса, который включаю именно на тренировках, для пульса это точнее часов. А вот сон, HRV, стресс, Body Battery всё равно только с часов, там альтернативы нет. Так что часть данных надёжнее часов, часть завязана на них полностью, и это ограничение я не скрываю.
Не так. ИИ ничего не решает и не навязывает. Он делает то, что я попросил словами, показывает план и ждёт подтверждения, прежде чем что-то уйдёт в Garmin. Решение всегда моё.
И тренировка привязана к дате, не к конкретному часу. 19:00 или 19:30 бежать, решаю я сам, глядя на часы, а не бот.
Bevel реальный, по отзывам неплохой. Но у меня другая задача: важно было именно свои данные из Garmin донести до моего ChatGPT, у меня там переписка с 2023 года, ещё с версией GPT-3.5, и весь контекст моего образа жизни уже накоплен в ней. Заводить отдельного встроенного коуча в новом закрытом приложении смысла не было, хотелось кормить данными именно этот чат.
Плюс Bevel облачная подписка, закрытый код, только iOS, и по Garmin историю тянет всего месяц (ограничение самого Garmin API, в их же фидбеке люди жалуются и ссылаются на ту же библиотеку, что у меня, как на обходной путь). У меня открытый код, локальный кэш без такого ограничения, и агент, который не только показывает цифры, но может создать тренировку прямо в Garmin.
Через
python-garminconnect(cyberjunky на GitHub) неофициальную библиотеку, которая имитирует запросы из веб-версии Garmin Connect: логинишься своей учёткой, дальше через неё дёргаешь эндпоинты, которые обычно ходят из браузера. Официального публичного API у Garmin для такого нет, поэтому это ровно reverse-engineered доступ, а не что-то задокументированное самим Garmin.Про архитектуру и детали, что конкретно тянется и как кэшируется, у меня отдельная статья, там технически: https://habr.com/ru/articles/1071224/.
не без этого, GPT приложил руку и к тексту, но код и результат вполне реальны, ссылка на репозиторий в статье
карта = силуэт в приложении; через API её нет, считаем сами по категориям упражнений.
Согласен. Пока агент только читает HRV и собирает отчёт, цена ошибки - кривой markdown. Когда он пишет интервалы и зоны обратно в Garmin, цена уже другая: сломанная тренировка на часах.
Open source закрывает вопрос «куда уходят данные». Вопрос «насколько совету/действию можно доверять» он сам по себе не закрывает. Поэтому у изменяющих действий сейчас human-in-the-loop: бот не пишет в Garmin сам, показывает кнопки подтверждения. Это не валидация совета как у врача или тренера, а хотя бы явная точка, где человек смотрит и решает.
Дальше как раз и начинается продукт с ответственностью: проверять, что агент собрал, до нажатия «Подтвердить», а не чинить уже после.
Благодарю за отзыв!
Полностью открытым решение быть не может оно включает внутренние компоненты и интеграции, завязанные на корпоративную инфраструктуру, CI и окружение. Однако концепция остаётся универсальной, и её можно воспроизвести в облегчённом виде на любой машине:
запись действий + UI-метаданных,
сценарии в виде JSON,
раннер, который воспроизводит шаги и выполняет проверки.
Я рассматриваю возможность собрать небольшую демонстрационную версию без корпоративных зависимостей чтобы показать сам подход. Если будет запрос на это со стороны сообщества, можно сделать такой вариант.
Спасибо за вопросы - отвечу кратко и в рамках того, что можно описывать публично.
Аналог UI Automation в Linux
Прямого аналога Windows UIA нет.
Есть AT-SPI, но поддержка фрагментирована и зависит от тулкита (GTK/Qt). Поэтому в Linux работает только облегчённый режим: базовые операции доступны, но без полноценного дерева UI. Это скорее вспомогательная возможность, а не основная платформа.
Надёжность тестов
На Windows тесты получаются устойчивые именно за счёт многослойного поиска элементов и использования нескольких источников метаданных.
Мы не стремимся к 100% стабильности - она недостижима в принципе - но достигаем высокой повторяемости при реальных сценариях.
Продемонстрировать запись/воспроизведение
Рабочие записи привязаны к корпоративным приложениям, поэтому показывать их нельзя.
Думаю над подготовкой краткого публичного демо на нейтральном приложении.
Визуализация фиксируемых элементов
Визуализация есть, но она утилитарная: отображает структуру метаданных элемента и путь в UI-дереве.
Это внутренний технический инструмент, он не предназначен для широкого использования.
Вкладывание скриптов
Да, есть механизм компоновки сценариев, чтобы переиспользовать повторяющиеся последовательности действий. Это позволяет сократить объём тестов и уменьшить рутинные правки при изменениях UI.
Если будет интерес, могу позже подготовить отдельный материал по архитектурным принципам, не углубляясь в закрытую часть реализации.
Ответ:
Да, вы совершенно правы — в идеальном мире API для САПР должно закрывать все потребности тестирования. Но у нас ситуация такая, что оно, к сожалению, не охватывает весь функционал, особенно если говорить про рендеринг, работу с 2D/3D-моделями и визуализацию.
Поэтому мы идем через эмуляцию действий пользователя: это помогает не просто проверить интерфейс, но и убедиться, что сама система — взаимодействие с моделью, отрисовка, поведение инструментов — работает как надо. По сути, мы воспроизводим реальный сценарий использования, чтобы ничего не упустить.
Если бы API давало полный контроль над этими штуками, мы бы, конечно, с радостью на него опирались. Но пока оно не тянет, особенно в части рендеринга и динамики инструментов.