🏠 HomeCore
Локальный хаб умного дома без облака — учебный проект по инженерии информационных систем
HomeCore — учебный проект по дисциплине «Инженерия информационных систем».
Цель репозитория — предоставить единый браузерный вход к результатам всех итераций: от выбора темы и анализа предметной области до требований, концептуальной архитектуры, модели данных, сценариев использования и демонстрационного прототипа.
HomeCore — программная платформа для управления устройствами умного дома, работающая полностью автономно в локальной сети. Все данные, автоматизации и сценарии хранятся и исполняются на устройстве пользователя; интернет-подключение не требуется ни для управления устройствами, ни для выполнения правил.
Преподавателю или проверяющему не требуется скачивать презентации, чтобы понять результат проекта. Ниже сразу приведены визуальные материалы: видео-обзор прототипа, состав экранных форм и ссылка на маршрут проверки.
Анимированный обзор автоматически воспроизводится выше. Полную версию можно посмотреть в файле demo.mp4.
Web-панель (SPA) собрана в одном окне браузера и состоит из трёх рабочих зон:
| Зона интерфейса | Что показывает |
|---|---|
| Карточки устройств | Чайник Redmond (BLE) и умная лампа (MQTT): состояние, температура, команды управления |
| Список правил | Правила автоматизации «если событие → то команда» с индикатором «⚡ сработало» |
| Журнал событий | Лента событий с отметкой времени, источника и инициатора (команды, срабатывания правил, ошибки) |
- Посмотреть видео-обзор прототипа.
- Перейти к README прототипа с пошаговой демонстрацией сценариев.
- Просмотреть итерационную карту работ.
- Проверить связь прототипа с требованиями в сквозной трассировке.
Для локального запуска прототипа:
cd prototype
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
uvicorn backend.main:app --host 0.0.0.0 --port 8000После запуска приложение доступно по адресу http://localhost:8000, а Swagger API — по адресу http://localhost:8000/docs.
- Быстрый просмотр демо
- Назначение репозитория
- Краткое описание проекта
- Учебный фокус проекта
- Итерационная карта работ
- Ключевые артефакты для проверки
- Бизнес-требования и цели
- Заинтересованные лица и потребности
- Пользовательские и системные требования
- Концептуальная архитектура
- Структура данных
- Базовые сценарии использования
- Демонстрация прототипа
- Структура репозитория
- Запуск прототипа
- Проверка работоспособности
- Ограничения текущего результата
- Итоговый статус
Репозиторий предназначен для проверки результатов учебного проекта по инженерии информационных систем. Основной акцент сделан не на промышленной реализации, а на демонстрации понимания методологии разработки ИТ-продукта:
- формирование проектной идеи;
- анализ предметной области и конкурентов;
- определение границ системы;
- выявление заинтересованных лиц и их потребностей;
- формирование бизнес-, пользовательских и системных требований;
- описание состава MVP;
- построение концептуальной архитектуры (C4);
- описание модели данных;
- трассировка требований к сценариям и прототипу;
- демонстрация результата через браузер.
README выступает как основная навигационная страница проекта. Все вложенные документы доступны по ссылкам из соответствующих разделов.
HomeCore — локальный хаб умного дома, работающий полностью офлайн.
Система позволяет пользователю:
- подключать и удалять устройства умного дома (BLE-чайник, MQTT-лампа, ESP32);
- управлять устройствами и опрашивать их состояние из браузера;
- создавать правила автоматизации вида «если событие → то команда»;
- наблюдать журнал всех событий с отметкой времени и источника;
- работать с системой через открытый REST/MQTT API;
- сохранять все данные локально, без передачи в облако.
Проблема пользователя в том, что существующие системы умного дома (Home Assistant, Яндекс, Tuya) требуют постоянного облачного подключения: это нарушает приватность, создаёт единую точку отказа за пределами контроля пользователя и затрудняет интеграцию самодельных устройств. HomeCore решает эти проблемы, исполняя все сценарии локально.
Проект рассматривается как учебный кейс по инженерии информационных систем. Поэтому документация организована вокруг вопросов, важных для курса:
- зачем создаётся система;
- какие проблемы пользователя она решает;
- кто является заинтересованными лицами;
- какие потребности необходимо учесть;
- какие требования вытекают из потребностей;
- какие сценарии подтверждают требования;
- какие данные нужны системе;
- как прототип демонстрирует концепцию решения.
Реализация прототипа добавлена как подтверждение жизнеспособности концепции, но не подменяет собой аналитическую и проектную документацию.
| Итерация | Основной фокус | Результат | Документ |
|---|---|---|---|
| 0 | Изучение устройства (ПЗ 1–3) | Паспорт чайника, контекстная диаграмма (чёрный ящик), внутреннее устройство (белый ящик): физблоки и типы интерфейсов | Устройство |
| 1 | Организация проекта и идея | Выбрана тема (локальный хаб умного дома), создан репозиторий, сформулирована концепция | Канон проекта |
| 2 | Анализ предметной области | Выполнен конкурентный анализ, построены контекстная диаграмма и event storming, определены границы системы и заинтересованные лица | Конкуренты |
| 3 | Формирование требований | Описаны бизнес-, пользовательские и функциональные требования, атрибуты качества, состав MVP и спецификация REST API | Функциональные требования |
| 4 | Концепция решения | Описана логическая архитектура, C4-контейнеры (CNT-1..5), компоненты, интерфейсы и потоки данных | Архитектура |
| 5 | Модель данных и сценарии | Описаны семь сущностей (ENT-1..7), ER-диаграмма и ключевые сценарии использования (SC-1..4) | Модель данных |
| 6 | Итоговая связность и прототип | Построена сквозная трассировка требований, реализован рабочий прототип, записан демо-ролик | Сквозная трассировка |
Презентации по каждой итерации доступны в форматах HTML (открывается в браузере) и PDF (просмотр прямо в GitHub):
| Итерация | Тема | HTML | |
|---|---|---|---|
| 1 | Организация проекта и идея | iter-1.html | iter-1.pdf |
| 2 | Анализ предметной области | iter-2.html | iter-2.pdf |
| 3 | Формирование требований | iter-3.html | iter-3.pdf |
| 4 | Концепция решения | iter-4.html | iter-4.pdf |
| 5 | Модель данных и сценарии | iter-5.html | iter-5.pdf |
| 6 | Итоговая связность и прототип | iter-6-final.html | iter-6-final.pdf |
| Раздел проверки | Где смотреть | Что показывает |
|---|---|---|
| Канон проекта | docs/00-canon.md | Единый источник истины: все ID, требования и сущности |
| Изучение устройства (ПЗ 1–3) | docs/01-device.md | Паспорт чайника, чёрный ящик (контекст, входы/выходы), белый ящик (физблоки C-1…C-11, интерфейсы I-1…I-10) |
| Бизнес-анализ | Стейкхолдеры, Контекст, Конкуренты, Event Storming | Заинтересованные лица, контекст системы, конкуренты, домен умного дома |
| Требования | Бизнес, Функциональные, MVP, API | Бизнес- и функциональные требования, состав MVP, спецификация REST API |
| Концептуальная архитектура | docs/04-architecture.md | Контекст, контейнеры C4, компоненты, интерфейсы, архитектурные решения |
| Модель данных и сценарии | Модель данных, Сценарии | Семь сущностей, ER-диаграмма, ключевые и ошибочные сценарии |
| Сквозная трассировка | docs/06-traceability.md | Связь целей, требований, сущностей, сценариев, компонентов и прототипа |
| Демонстрация прототипа | prototype/README.md | Запуск, пошаговая демонстрация сценариев SC-1..4, демо-ролик |
Бизнес-цель проекта — показать, как локальная платформа умного дома может управлять устройствами без облака, сохраняя приватность пользователя и работоспособность при отключённом интернете.
Ключевые бизнес-цели (из канона):
| ID | Цель |
|---|---|
| BG-1 | Выпустить MVP локального хаба, управляющего ≥ 2 типами устройств, за семестр |
| BG-2 | Время отклика команды «нажал → устройство сработало» ≤ 500 мс в локальной сети |
| BG-3 | Установка хаба пользователем-непрофессионалом ≤ 15 минут |
| BG-4 | Автоматизации продолжают работать при полном отсутствии интернета (100 % сценариев MVP) |
Подробная формализация бизнес-требований приведена в документе бизнес-требований.
Основные заинтересованные лица:
| Заинтересованное лицо | Интерес | Потребность |
|---|---|---|
| ST-1 — Житель квартиры | Управлять домом просто и приватно | Подключать устройства, управлять ими из браузера и видеть журнал событий |
| ST-2 — Гик-энтузиаст | Интегрировать самодельные устройства | Иметь открытый REST/MQTT API без регистрации в облаке |
| ST-3 — Владелец жилья / арендодатель | Безопасность и отсутствие утечек | Гарантия, что поведенческие данные не покидают локальную сеть |
| ST-4 — Производитель устройств | Простой протокол интеграции | Подключать новый тип устройства через адаптер-плагин без изменения ядра |
Полное описание заинтересованных лиц, персонажей и CJM находится в документе стейкхолдеров.
В проекте требования разделены на несколько уровней:
- бизнес-требования — зачем нужен продукт и какую ценность он создаёт;
- потребности заинтересованных лиц — что ожидают разные участники проекта;
- пользовательские требования — какие возможности нужны пользователю;
- функциональные требования — какие действия должна выполнять система;
- атрибуты качества (NFR) — каким должно быть поведение системы с точки зрения отклика, приватности, надёжности и расширяемости.
Основные группы функциональных требований:
- управление устройствами: добавление, удаление, опрос состояния (FR-1, FR-2, FR-3);
- правила автоматизации: создание и исполнение (FR-4, FR-5);
- веб-панель управления: список устройств, управление, журнал (FR-6);
- журнал событий с отметкой времени, источника и инициатора (FR-7);
- открытый документированный REST API (FR-8).
Ключевые атрибуты качества: отклик ≤ 500 мс (NFR-1), офлайн-независимость (NFR-2), расширяемость через адаптеры (NFR-3), privacy-first (NFR-4), лёгкий стек (NFR-5).
Требования описаны в документе функциональных требований. Связь требований с компонентами и сценариями раскрыта в сквозной трассировке.
Для учебного MVP выбрана модульная структура из пяти контейнеров (C4). Она показывает разделение ответственности без избыточной сложности распределённой архитектуры. Хаб устанавливается на Raspberry Pi или аналогичный мини-ПК и работает без облачного взаимодействия.
┌─────────────────────────────────────────────────┐
│ HomeCore Hub │
│ │
│ ┌──────────┐ ┌────────────────┐ │
│ │ CNT-1 │ │ CNT-2 │ │
│ │ Web-панель│◄───►│ API-ядро │ │
│ │ (SPA) │ │ (FastAPI) │ │
│ └──────────┘ └───────┬────────┘ │
│ │ │
│ ┌─────────────┼─────────────┐ │
│ ▼ ▼ ▼ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ CNT-3 │ │ CNT-4 │ │ CNT-5 │ │
│ │ Движок │ │Адаптеры │ │ SQLite │ │
│ │ правил │ │BLE/MQTT │ │ │ │
│ └─────────┘ └─────────┘ └─────────┘ │
└─────────────────────────────────────────────────┘
Логические части решения:
- CNT-1 — Web-панель (SPA): пользовательский интерфейс в браузере;
- CNT-2 — API-ядро (FastAPI): маршрутизация команд, реестр устройств, REST API;
- CNT-3 — Движок правил: подписка на события и исполнение автоматизаций;
- CNT-4 — Адаптеры устройств: плагины BLE (ES-1) и MQTT (ES-2), симуляторы;
- CNT-5 — Хранилище: SQLite для прототипа, in-memory для тестов.
Полное описание архитектуры, C4-представлений и архитектурных решений приведено в документе архитектуры.
Логическая модель данных строится вокруг семи сущностей (ENT-1..ENT-7):
- ENT-1 — Device (устройство);
- ENT-2 — Capability (возможность устройства);
- ENT-3 — Rule (правило автоматизации);
- ENT-4 — Trigger (триггер правила);
- ENT-5 — Action (действие правила);
- ENT-6 — EventLog (журнал событий);
- ENT-7 — User (пользователь).
Ключевая связь MVP: устройство → событие → правило (триггер + действие) → команда → запись в журнале.
Подробная модель данных и ER-диаграмма описаны в документе модели данных.
Ключевые сценарии продукта:
- SC-1 — пользователь включает чайник через web-панель и наблюдает рост температуры до 100 °C.
- SC-2 — правило «чайник вскипел → лампа мигает» срабатывает автоматически.
- SC-3 — устройство недоступно: система обрабатывает ошибку и фиксирует её в журнале.
- SC-4 — подключение нового типа устройства через адаптер-плагин без изменения ядра.
Полное описание сценариев, включая диаграммы последовательности и ошибочные ситуации, приведено в документе сценариев.
Для просмотра результата подготовлены:
- README прототипа с пошаговой демонстрацией сценариев;
- демо-ролик прототипа (GIF);
- демо-ролик прототипа (MP4);
- исходный код прототипа: backend (FastAPI-ядро) и frontend (SPA web-панель).
Прототип демонстрирует не промышленную систему, а учебное подтверждение ключевых требований: подключение устройства, управление, исполнение правила, обработку ошибки и расширяемость через адаптеры. Прототип работает in-memory, в одном процессе, без внешних зависимостей.
homecore/
├── docs/ # аналитическая и проектная документация
│ ├── 00-canon.md # канон: единый источник истины (ID, требования, сущности)
│ ├── 01-device.md # устройство (чайник): паспорт, чёрный/белый ящик (ПЗ 1-3)
│ ├── 02-stakeholders.md # стейкхолдеры: персонажи, потребности, CJM
│ ├── 02-context.md # контекстная диаграмма системы
│ ├── 02-competitors.md # конкурентный анализ
│ ├── 02-event-storming.md # event storming домена умного дома
│ ├── 03-business-requirements.md # бизнес-требования и цели
│ ├── 03-functional-requirements.md # функциональные требования и атрибуты качества
│ ├── 03-mvp.md # состав MVP
│ ├── 03-api.md # спецификация REST API
│ ├── 04-architecture.md # логическая архитектура, C4
│ ├── 05-data-model.md # модель данных, ER-диаграмма
│ ├── 05-scenarios.md # ключевые сценарии использования
│ └── 06-traceability.md # сквозная трассировка требований
├── presentations/ # презентации по итерациям (HTML + PDF)
├── prototype/ # демонстрационный прототип
│ ├── backend/ # FastAPI-ядро: реестр, адаптеры, правила, события
│ ├── frontend/ # SPA web-панель (index.html)
│ ├── demo/ # демо-ролик (GIF + MP4) и скрипт записи
│ ├── requirements.txt # зависимости прототипа
│ └── README.md # запуск и демонстрация сценариев
├── README.md # основной вход в проект
└── .gitignore # правила исключения служебных файлов
Перейти в каталог прототипа и создать виртуальное окружение:
cd prototype
python3 -m venv .venv
source .venv/bin/activateУстановить зависимости:
pip install -r requirements.txtЗапустить приложение:
uvicorn backend.main:app --host 0.0.0.0 --port 8000После запуска доступны:
http://localhost:8000 # web-панель (SPA)
http://localhost:8000/docs # Swagger API
Основные эндпоинты REST API:
GET /api/v1/devices— список устройств;POST /api/v1/devices/{id}/commands— отправка команды устройству;GET /api/v1/rules— список правил автоматизации;GET /api/v1/events?limit=20— журнал последних событий.
Прототип проверяется через сценарии SC-1..SC-4 — вручную в web-панели или через REST API. Пошаговые команды приведены в README прототипа.
Базовая проверка показывает:
- включение чайника и рост температуры до состояния
boiled(SC-1); - автоматическое срабатывание правила «чайник вскипел → лампа мигает» (SC-2);
- обработку недоступности устройства с ответом
409 device_unreachableи записью ошибки в журнал (SC-3); - подключение нового адаптера без перезапуска ядра (SC-4).
Пример проверки SC-1 через API:
curl -s http://localhost:8000/api/v1/devices | python3 -m json.tool
curl -s -X POST http://localhost:8000/api/v1/devices/KETTLE_ID/commands \
-H "Content-Type: application/json" \
-d '{"command": "turn_on"}' | python3 -m json.toolТекущий результат является учебным MVP и имеет ограничения:
- хранилище прототипа реализовано in-memory; SQLite (CNT-5) описан архитектурно, но в прототипе упрощён;
- реальные BLE- и MQTT-устройства заменены симуляторами (KettleSimulator, LampSimulator);
- облачная синхронизация, мобильное приложение и голосовое управление намеренно вынесены за пределы MVP;
- промышленное развёртывание и детальное проектирование безопасности относятся к дальнейшему развитию;
- веб-панель реализована в базовом виде, достаточном для демонстрации ключевых сценариев.
Проект приведён к формату, удобному для браузерного ознакомления:
- README содержит маршрут проверки проекта;
- документация по итерациям оформлена как последовательная учебная документация;
- цели, требования, сущности, сценарии и компоненты связаны сквозной трассировкой;
- подготовлены демо-ролик и описание экранных форм прототипа;
- прототип можно запустить локально и проверить основные пользовательские сценарии.
Главный результат проекта — не только наличие работающего прототипа, но и демонстрация понимания полного учебного цикла: предметная область → потребности → требования → концепция решения → данные → сценарии → прототип.
HomeCore — учебный проект. Все права на используемые торговые марки принадлежат их владельцам.