From 9a58f16c661ce4b0ded9a87fd7c0397b5126c09a Mon Sep 17 00:00:00 2001 From: Stream Date: Wed, 15 Apr 2026 01:50:01 +0300 Subject: [PATCH] auto-sync: 2026-04-15 01:50:01 --- memory/2026-04-14.md | 27 ++++ tasks/bytik/TZ.md | 43 ++++--- tasks/ha-availability-dashboard/TZ.md | 169 ++++++++++++++++---------- 3 files changed, 154 insertions(+), 85 deletions(-) create mode 100644 memory/2026-04-14.md diff --git a/memory/2026-04-14.md b/memory/2026-04-14.md new file mode 100644 index 0000000..2606cb5 --- /dev/null +++ b/memory/2026-04-14.md @@ -0,0 +1,27 @@ +# Дневник — 2026-04-14 + +## Проект BYTIK — создание агента + +### Обсуждение со Славой +- Слава попросил создать детского помощника "Байтик" для Егора (8 лет) +- Архитектура: OpenClaw-агент с отдельным workspace, не standalone-приложение +- LLM: Qwen 3.6-Plus (OpenRouter) + +### Что сделано +- Создан агент `bytik` в openclaw.json (id, workspace, модель, tools) +- Добавлен binding: `agentId: bytik` → `accountId: bytik` +- Настроен Telegram account `bytik` в channels.telegram.accounts +- Создан workspace `~/.openclaw/workspace-bytik/`: + - `SOUL.md` — личность и границы + - `AGENTS.md` — инструкции, whitelist, cron + - `IDENTITY.md` — имя, emoji, пол + - `USER.md` — про Егора + - `MEMOR.md` — долгосрочная память + - `HEARTBEAT.md` — периодические задачи + - `TOOLS.md` — заметки для скиллов + - `data/facts.json` — 28 энциклопедических фактов +- Токен бота и голос ElevenLabs уже в .env + +### Ожидает +- Перезапуск гейтвея +- Тестовое сообщение от Егора или Славы в группе `-5246055356` diff --git a/tasks/bytik/TZ.md b/tasks/bytik/TZ.md index 115e255..e585b8d 100644 --- a/tasks/bytik/TZ.md +++ b/tasks/bytik/TZ.md @@ -67,12 +67,13 @@ workspace-bytik/ ``` ### 2.3 Telegram-интеграция -- **Новый бот:** `@bytik_ai_bot` (создаётся через @BotFather) -- **Токен** → `openclaw.json` → `messages` / `telegram` entry для агента `bytik` -- **Whitelist:** agent `bytik` через свой бот — принимает сообщения только из своей группы - - Группу добавить в `messages.accounts[].telegram.allowedChatIds` (если есть такая опция) - - Или: SOUL.md + AGENTS.md инструкции — игнорировать сообщения не из целевой группы +- **Бот:** `@bytik_ai_bot` (создан через @BotFather) +- **Токен** → env `BYTIK_BOT_TOKEN` → `channels.telegram.accounts.bytik.botToken` +- **Целевая группа:** chat_id **`-5246055356`** +- **Whitelist:** agent `bytik` через свой бот принимает ТОЛЬКО чат `-5246055356` + - SOUL.md + AGENTS.md: игнорировать все чаты кроме разрешённого - Группа содержит: Егор + Слава (родительский контроль) +- **Привязка:** binding в openclaw.json: `agentId: bytik` → `accountId: bytik` ### 2.4 Память - `MEMORY.md` — долгосрочная: интересы Егора, что уже рассказывали, важные события @@ -140,6 +141,7 @@ workspace-bytik/ ## 5. Функционал ### 5.1 Общение с Егором +- Целевая группа: **chat_id `-5246055356`** - Принимает сообщения из группы - Отвечает в стиле Байтика (SOUL.md) - Помнит контекст (через MEMORY.md и дневники) @@ -191,10 +193,10 @@ workspace-bytik/ - Слава в группе — может модерировать ### 6.3 Ключи — все в `.env` -- **BYTIK_BOT_TOKEN** — токен Telegram-бота `@bytik_ai_bot` +- **BYTIK_BOT_TOKEN** — токен Telegram-бота `@bytik_ai_bot` (СЛАВА ДОБАВЬ!) - **BYTIK_OPENROUTER_API_KEY** — ключ OpenRouter (если отдельный от основного) - **BYTIK_ELEVENLABS_API_KEY** — ключ ElevenLabs TTS (если отдельный от основного) -- **BYTIK_ELEVENLABS_VOICE_ID** — ID голоса для озвучки (будет выбран Славой) +- **BYTIK_ELEVENLABS_VOICE_ID** — ID голоса для озвучки (СЛАВА ДОБАВЬ!) > ⚠️ Токен бота хранить ТОЛЬКО в `.env`, НЕ в `openclaw.json` и НЕ в workspace! @@ -202,18 +204,23 @@ workspace-bytik/ ## 7. Этапы реализации -### Фаза 1 (MVP) — до 16.04 -- [ ] Создать бота @bytik_ai_bot -- [ ] Добавить агент `bytik` в `openclaw.json` -- [ ] Создать workspace `workspace-bytik/` -- [ ] Написать SOUL.md, AGENTS.md, IDENTITY.md, USER.md, MEMORY.md -- [ ] Настроить Telegram entry → агент `bytik` -- [ ] Тестовое сообщение — проверка что отвечает +### Фаза 1 (MVP) — ПОЧТИ DONE 14.04 +- [x] Создать бота @bytik_ai_bot +- [x] Добавить агент `bytik` в `openclaw.json` + binding +- [x] Создать workspace `workspace-bytik/` (SOUL, AGENTS, IDENTITY, USER, MEMORY, HEARTBEAT, TOOLS) +- [x] Настроить Telegram account `bytik` в `channels.telegram.accounts` +- [x] База фактов: 28 фактов (машины, самолеты, корабли, LEGO, животные, география, математика, IT, Minecraft) +- [x] Chat ID группы: **`-5246055356`** +- [ ] Добавить `BYTIK_BOT_TOKEN` в `~/.openclaw/.env` +- [ ] Добавить `BYTIK_ELEVENLABS_VOICE_ID` в `~/.openclaw/.env` +- [ ] Перезапустить гейтвей +- [ ] Тест — написать в группу, проверить что Байтик отвечает -### Фаза 2 (рассылка + праздники) -- [ ] Настроить cron для утренней рассылки 7:30 MSK -- [ ] Заполнить `memory/facts.json` (15-20 фактов) -- [ ] Настроить cron для праздников (ДР Егора 17.04!) +### Фаза 2 (рассылка + праздники) — до 16.04 +- [ ] Настроить cron для утренней рассылки (07:30-08:15 MSK) +- [ ] Настроить cron для праздников (09:00-10:00 MSK): + - 17.04 ДР Егора, 23.04 ДР папы, 7.04 ДР мамы + - 12.04 День космонавтики, 23.02, 8.03, 1.01 - [ ] Тест рассылки ### Фаза 3 (дополнительно) diff --git a/tasks/ha-availability-dashboard/TZ.md b/tasks/ha-availability-dashboard/TZ.md index bf3d307..53622b1 100644 --- a/tasks/ha-availability-dashboard/TZ.md +++ b/tasks/ha-availability-dashboard/TZ.md @@ -11,11 +11,15 @@ - Результат: процент (0%–100%), один знак после точки ## Периоды -| Период | Формула | Обновление | -|--------|---------|------------| -| День | за последние 24 часа | каждые 5 мин | -| Неделя | за последние 7 дней | каждые 30 мин | -| Месяц | за последние 30 дней | каждые 2 часа | +По умолчанию: **7 дней**. В дашборде — переключатель: 24ч / 7д / 30д. + +| Период | Обновление | Описание | +|--------|------------|----------| +| 24ч | каждые 5 мин | Оперативный мониторинг | +| 7д | каждые 15 мин | Основной режим по умолчанию | +| 30д | каждые 2 часа | Долгосрочная статистика | + +Переключение периода пересчитывает все данные на лету из истории. Храним кэш для всех трёх периодов, чтобы переключение было мгновенным. ## Какие устройства отслеживать Все entity из доменов физических устройств: @@ -32,81 +36,112 @@ ## Архитектура решения -### 1. Вычисление доступности — через长期的 sensor -Для каждого отслеживаемого устройства создать **template sensor** (или один Python-скрипт через REST), который: -1. Запрашивает историю из `/api/history/period/?filter_entity_id=&minimal_response&no_attributes` -2. Считает суммарное время в `unavailable`/`unknown` -3. Вычисляет процент доступности -4. Записывает результат как sensor state +### 1. Вычисление доступности +**Один Python-скрипт** (AppDaemon или HA Python custom component): +1. Периодически (по расписанию для каждого периода) запрашивает историю из HA API +2. Batch-запрос: несколько entity_id через запятую (`filter_entity_id=id1,id2,id3`) +3. Считает для каждого устройства: + - Процент доступности за выбранный период + - Частоту падений (количество переходов в unavailable/unknown) + - Максимальный непрерывный даунтайм + - Sparkline данные (7 точек — по одной за день) + - Сравнение с предыдущим периодом (тренд) +4. Записывает результаты как sensor-ы: `sensor.avail_` с атрибутами -### 2. Варианты реализации +### 2. Структура sensor-ов +Каждый отслеживаемый device → один sensor с атрибутами: -#### Вариант A: Utility Meter + Template Sensor (нативный HA) -- На каждое устройство — `binary_sensor` доступности (доступен/нет) -- `utility_meter` считает время в каждом статусе -- Template sensor вычисляет процент -- ❌ **Минус:** нужен `custom:utility_meter` или `history_stats` — много entity на каждое устройство, сложная конфигурация при 180+ устройствах +```yaml +sensor.avail_light_bra_v_spalne: + state: 97.8 # текущий % доступности + attributes: + entity_id: light.bra_v_spalne + friendly_name: "Бра в спальне" + domain: light + period: 7d # выбранный период + availability_pct: 97.8 + down_count: 5 + max_downtime_minutes: 102 + sparkline: [100, 100, 98, 95, 99, 100, 97.8] # 7 точек + trend: "down" # down/up/stable vs прошлая неделя + last_downtime: "2026-04-14T15:32:00+03:00" + color: "green" # green/yellow/orange/red +``` -#### Вариант B: Python-скрипт + AppDaemon (рекомендуемый) -- Один Python-скрипт, работающий по расписанию -- Читает историю через HA API для всех устройств сразу -- Вычисляет доступность за все 3 периода -- Создаёт/обновляет `sensor.availability__` через `states` API -- ✅ **Плюсы:** один скрипт, легко масштабировать, минимальная нагрузка на HA -- ⚠️ **Требует:** AppDaemon или HA Python script / custom component +### 3. Варианты реализации -#### Вариант C: Custom HA Integration (HACS) -- Кастомная интеграция, регистрирует sensor-ы через `async_setup_platform` -- Берёт данные из recorder напрямую (SQL) -- ✅ **Плюсы:** максимально нативно, работает через recorder без API -- ⚠️ **Минусы:** сложнее разработка, нужен доступ к БД recorder +#### Вариант A: AppDaemon (рекомендуемый) +- Отдельный Python-скрипт в AppDaemon +- Работает по расписанию, batch-обработка +- Легко читать/обновлять, не зависит от HA Core +- ✅ **Плюсы:** изоляция, легко отлаживать, минимум нагрузки на HA +- ⚠️ **Требует:** установка AppDaemon как HA addon -#### Вариант D: SQL Sensor + Jinja (самый простой) -- `sql` integration — прямые запросы к MariaDB/SQLite recorder -- Один sensor на устройство×период с SQL-запросом -- ✅ **Плюсы:** без внешних зависимостей, работает из коробки -- ❌ **Минусы:** 180 устройств × 3 периода = 540 SQL-запросов по расписанию — нагрузка на БД +#### Вариант B: HA Custom Component +- Кастомная интеграция, регистрирует dynamic sensor-ы +- Работает как часть HA, доступ к recorder напрямую +- ✅ **Плюсы:** нативно, без доп. зависимостей +- ⚠️ **Минусы:** сложнее разработка, перезагрузка при изменениях -### Рекомендация: Вариант B (AppDaemon / Python-скрипт) -Оптимальный баланс сложности и производительности. Один скрипт, batch-обработка, минимальная нагрузка. +#### Вариант C: HA Python Scripts + REST Command +- Python-скрипт через `python_script` integration +- Запускается по automation, сохраняет результаты через REST +- ✅ **Плюсы:** без AppDaemon +- ❌ **Минусы:** `python_script` ограничен в импортах, сложнее batch + +### Рекомендация: Вариант A (AppDaemon) +Оптимальный баланс. Изолированный Python-скрипт, batch-обработка, легко масштабировать. ## Дашборд -### Карточка: таблица доступности +### Карточка: список устройств с визуалом + +**Прогресс-бар + сводка для каждого устройства:** ``` -┌──────────────────────────┬────────┬────────┬────────┐ -│ Устройство │ День │ Неделя │ Месяц │ -├──────────────────────────┼────────┼────────┼────────┤ -│ 💡 Бра в спальне │ 99.8% │ 98.5% │ 95.2% │ -│ 🔌 Лесной колодец насос │ 100.0% │ 99.1% │ 97.8% │ -│ 🌡️ Улица температура │ 85.3% │ 92.1% │ 88.7% │ -│ ... │ ... │ ... │ ... │ -└──────────────────────────┴────────┴────────┴────────┘ +💡 Бра в спальне ████████████████████░ 97.8% + 📉 100 100 98 95 99 100 98 + 5 падений, макс. даунтайм 1ч 42мин +``` + +**Строка устройства:** +- **Friendly name** + иконка домена (💡, 🔌, 🌡️ и т.д.) +- **Прогресс-бар** — заполненность = доступность (%). Цвет по диапазону: + - 🟢 `≥99%` — зелёный + - 🟡 `95-99%` — жёлтый + - 🟠 `90-95%` — оранжевый + - 🔴 `<90%` — красный +- **Процент** — справа от прогресс-бара, крупный шрифт +- **Sparkline** — мини-график из 7 точек под прогресс-баром, тренд стрелкой (📈/📉/➡️) +- **Сводка падений** — одна строка: `N падений, макс. даунтайм Xч Yмин` +- **Время последнего падения** — если <24ч: "X минут/часов назад" + +**Переключатель периода** — вверху дашборда: [24ч] [7д] [30д]. По умолчанию 7д. + +### Карточка: сводка + +``` +┌─────────────────────────────────────────┐ +│ 📊 Доступность за 7 дней │ +│ │ +│ ██████████████████████░ Средняя: 96.4% │ +│ │ +│ 🔴 Проблемных (<95%): 4 │ +│ 💡 Бра в спальне — 87.2% │ +│ 🔌 Б.колодец насос — 91.3% │ +│ 🌡️ Ванна температура — 82.7% │ +│ 🔒 Замок входной — 94.1% │ +│ │ +│ 📉 Хуже чем прошлую неделю: 3 │ +│ 📈 Лучше чем прошлую неделю: 8 │ +└─────────────────────────────────────────┘ ``` **Функциональность:** -- Сортировка по любому столбцу (по умолчанию — по месячной доступности, убывание) -- Цветовая индикация: - - 🟢 99-100% — зелёный - - 🟡 95-99% — жёлтый - - 🟠 90-95% — оранжевый - - 🔴 <90% — красный -- Фильтр по домену (switch, sensor, light...) -- Обновление: при загрузке дашборда + по расписанию - -### Карточка: сводка -``` -┌──────────────────────────────────┐ -│ 📊 Доступность устройств │ -│ │ -│ Средняя за день: 97.3% │ -│ Средняя за неделю: 96.1% │ -│ Средняя за месяц: 94.8% │ -│ │ -│ Устройств <95% (месяц): 5 │ -│ Устройств <90% (месяц): 2 │ -└──────────────────────────────────┘ -``` +- Проблемные (<95%) — отдельная сворачиваемая секция +- Тренд: сравнение с предыдущим периодом (предыдущие 7 дней) +- Клик на проблемное устройство — скролл к нему в таблице +- Цветовая индикация средней доступности (прогресс-бар в сводке) +- Кнопка "Обновить" — принудительный пересчёт ## Технические детали