auto-sync: 2026-04-15 01:50:01

2026-04-15 01:50:01 +03:00
parent 8ba32969be
commit 9a58f16c66
3 changed files with 154 additions and 85 deletions
--- a/memory/2026-04-14.md
+++ 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`
--- 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 (дополнительно)
--- 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/<start>?filter_entity_id=<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_<sanitized_id>` с атрибутами

-### 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_<entity_id>_<period>` через `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 дней)
+- Клик на проблемное устройство — скролл к нему в таблице
+- Цветовая индикация средней доступности (прогресс-бар в сводке)
+- Кнопка "Обновить" — принудительный пересчёт

 ## Технические детали