Керування освітленням AI: де ламається ручна логіка
Класична автоматика тримається на розкладі та реле: щит вмикає групу до початку зміни й гасить за часом, а датчик руху лише продовжує таймер.
Керування освітленням AI вирішує інше завдання — не «увімкнути за годинником», а утримувати світло там, де воно потрібне людям прямо зараз, і не витрачати його на порожні зони.
Датчик присутності — погане джерело правди. Хибні спрацювання датчиків дають потік повітря від припливної вентиляції, нагрів від обладнання, рух за скляною перегородкою — і група залишається увімкненою на весь витриманий таймер, хоча в приміщенні нікого немає.
Зворотна помилка трапляється не рідше: людина сидить нерухомо за монітором, сенсор її не бачить і гасить світло в зайнятому кабінеті.
Розклад проти зайнятості — головний конфлікт. У пікові години сусідні зони завантажені нерівномірно: десь повна посадка при приглушеному світлі, а поруч горить уся група в порожній переговорній.
Ручні сценарії це не лікують — їх доводиться переписувати після кожного переставляння меблів, а AI-логіка освітлення спирається на поточну картину зайнятості, а не на зафіксований список груп і годин.
Сигналу для цього достатньо: керування освітленням за датчиками освітленості, присутності та обліку зайнятості робочих місць зводиться в одну модель, яка навчається на фактичному використанні зон і поступово прибирає і пересвіт, і провали. Нижче розбираємо, як це закривається.
Що змінює адаптивна логіка освітлення на об'єкті
Рахувати ефект адаптивної логіки зручно за чотирма величинами: частка освітлення в загальному споживанні об'єкта, кількість хибних увімкнень за добу, час реакції на зміну зайнятості та частка спрацювань класу «світло не там і не тоді». Саме ці показники знімаємо до і після впровадження.
Зони, які реагують на людей, а не на час
Освітлення ділиться не за поверхами та щитами, а за сценаріями використання: коридор, переговорна, складська секція, група робочих місць.
Кожна зона отримує свій датчик присутності та поріг за природним світлом — світло вмикається там, де людина є, а не там, де проходить межа шлейфу.
Ключова перевірка — хибні увімкнення. Поки один прохід піднімав освітлення цілого крила, рахунок ішов на десятки за добу; після зонування реагують 2–4 світильники з утриманням 5–10 хвилин і гістерезисом за порогом.
Реакція на зайнятість вкладається в секунди замість півгодинного таймера, а відмови «світло не там і не тоді» стають поодинокими.
Плавне ведення яскравості замість різких перемикань
Різкий вихід на повну яскравість із темряви — це і дискомфорт для очей, і перевитрата. Крива регулювання виводить рівень до робочого за 1–2 секунди, а коли людина йде, спочатку знижує його до чергових 10–20% і лише потім гасить.
Біля вікон яскравість приглушується за датчиком природного світла, тому вдень зона біля скла працює на мінімумі.
Економія на освітленні без втрати комфорту виходить не вимкненням, а відмовою освітлювати порожні зони: споживання падає на третину й більше за тієї самої освітленості на робочих місцях.
Режими роботи: локальна логіка, хмара, гібрид
Вибір тут не про «розумність» алгоритму, а про те, де ухвалюється рішення і що відбувається з об'єктом при втраті каналу.
Локальна логіка освітлення живе на контролері в щиті, хмарна аналітика освітлення рахує моделі за агрегованою телеметрією, а гібридна схема керування ділить контури відповідальності між ними. Нижче — коли кожен варіант доречний і чим за нього платять.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Локальна логіка | Один об'єкт зі стабільним набором сценаріїв: паркінг, склад, цех, сходові клітки | Модель не бачить контекст між майданчиками; зміна сценаріїв — виїзд або розсилання конфігурації на кожен контролер |
| Зовнішній аналітичний контур | Багато однотипних об'єктів, потрібні порівняння майданчиків, пошук аномалій, звітність з експлуатації | Відгук залежить від каналу; при обриві зв'язку сценарії завмирають в останньому стані |
| Змішана схема | Розподілена мережа, де частина точок критична, а частина оптимізується | Складніша конфігурація: потрібно явно розділити, які правила залишаються на місці, а які надходять ззовні |
Коли об'єкт зобов'язаний працювати без зовнішнього зв'язку
Автономна робота при втраті зв'язку — обов'язкова вимога для підземних паркінгів, евакуаційних шляхів, холодильних і виробничих майданчиків.
Контролер зберігає сценарії та пороги у власній пам'яті, продовжує опитувати датчики присутності та освітленості й перемикає групи світла без участі зовнішнього контуру.
Телеметрія при цьому пишеться в локальну чергу й довантажується після відновлення каналу, тому розрив у даних не перетворюється на прогалину у звітності.
Що йде в зовнішній контур, а що залишається на місці
Рішення «увімкнути світло» залишається на об'єкті — воно потребує передбачуваного відгуку й не може залежати від мережі. У зовнішній контур ідуть агрегати за майданчиками, пошук аномалій, порівняння профілів споживання та перерахунок рекомендованих сценаріїв.
Таке розділення дає керованість мережі без ризику, що зовнішній сервіс або канал «покладуть» світло: критичний контур ізольований, а оптимізація надходить на об'єкт як оновлення конфігурації й застосовується лише після перевірки.
Як відбувається впровадження: від аудиту точок до передачі
Впровадження розбито на етапи з перевірюваним результатом після кожного кроку. Порядок не переставляється: налаштування порогів має сенс лише після того, як зафіксовано зони та групи.
Аудит наявної інфраструктури
Спочатку обмірюємо те, що вже стоїть: датчики руху та освітленості, щити, лінії живлення, фактичні навантаження за групами. Аудит системи освітлення показує, де точки дають хибні спрацювання і де не вистачає даних для моделі.
- Обмір і аудит точок — які датчики працюють, як розведені групи, які щити доступні для керування.
- Схема зон і груп — прив'язка кожної групи до сценарію: коридор, сходи, паркування, склад, і логіка переходів між ними.
- Налаштування порогів датчиків — рівні спрацювання, затримки вимкнення, чутливість під фактичний фон освітленості.
Перевірка на реальному потоці людей
Пороги, виведені з документації, майже завжди потребують правки: на живому потоці видно хибні увімкнення та «темні вікна», коли світло гасне раніше, ніж людина вийшла із зони.
- Пусконалагодження освітлення — прогін сценаріїв у години пік і в міжсезоння, підстроювання затримок за реальними маршрутами.
- Перевірка на живому потоці — добовий прогін по всіх групах, звірка журналів спрацювань з обходами персоналу.
- Навчання персоналу — регламент на ручний режим і відкат до штатного керування.
- Передача — документація, доступи, межі відповідальності, період супроводу.
На виході замовник отримує систему, де алгоритм вимикається однією командою без втрати освітлення.
Що залишається в замовника після впровадження
Систему передаємо не архівом файлів, а робочим комплектом, за яким служба експлуатації закриває більшість завдань власними силами.
Усі документи прив'язані до конкретного об'єкта й оновлюються при зміні конфігурації — інакше за півроку ніхто не згадає, чому в коридорі третього поверху сценарій спрацьовує саме так.
- Карта груп і адрес — який світильник до якого щита, лінії та адреси прив'язаний і яка зона датчиків ним керує. Без неї заміна одного приладу перетворюється на перебір варіантів на об'єкті.
- Матриця сценаріїв — сценарій, умова запуску (рух, рівень природного світла, розклад), цільова яскравість і таймаути. Правку значень експлуатація вносить сама, без виклику налаштувальника.
- Виконавча документація освітлення — схеми зон, щитів, трас і маркування, приведені до фактичного монтажу, а не до початкового проєкту.
- Регламент експлуатації — дії при відмові датчика або лінії, переведення зони в ручний режим, повернення автоматики, порядок ескалації.
- Інструкція для служби експлуатації — покроково й коротко: де подивитися стан, як перемкнути режим, як оформити заявку.
- Протокол перевірок — які зони, сценарії та класи відмов прогнано при здачі, з результатами й датами повторних прогонів.
Регламент прав доступу й ролей експлуатації
Ролі фіксуємо явно: диспетчер бачить стан і перемикає сценарії, інженер експлуатації править порогові значення датчиків і межі зон, повний доступ до конфігурації залишається в одного-двох людей.
Кожна зміна потрапляє в журнал з автором і часом, а еталонна конфігурація зберігається окремою копією — відкат до неї займає хвилини, а не нічний розбір інциденту.
Кейс: офісний поверх і склад на одній логіці
Об'єкт — адміністративний поверх і склад сухого зберігання під одним дахом. Світлом там уже керували, але двома незалежними контурами: в офісі — вимикачі за зонами, на складі — щиток із ручними групами, які черговий перемикав перед змінами.
Ми звели все в одну адресну шину DALI: у кожного світильника й датчика є адреса та своя зона, а сценарії описуються один раз і успадковуються обома контурами.
До впровадження картина була передбачувано поганою. Світло в переговорних і в дальніх рядах стелажів горіло майже 14 годин на добу — незалежно від того, є там хтось чи ні.
Нестачу освітленості в проходах підтверджували регулярні звернення, а черговий персонал вручну перемикав групи до і після кожної зміни.
Що показав замір до і після
| Показник | До | Після |
|---|---|---|
| Години горіння в порожніх зонах | 62% доби | 8% доби |
| Звернення через нестачу світла | 9 на місяць | 1 на місяць |
| Ручні втручання чергового | більше 40 на місяць | лише аварійний режим |
Ключовим виявилося не наявність датчиків, а правило переходу: зона без руху переходить на низький рівень потужності, а не вимикається — люди перестали скаржитися, що «погасло під рукою».
Датчики освітленості вдень зрізають верхній рівень біля віконних ліній, тому зникло й «сліпить». Нові стелажні ряди додаються в ту саму логіку, без переписування сценаріїв.
Чим відрізняється розклад від сценарію за датчиками?
Розклад — детермінований контур: перемикання груп прив'язане до календаря й астрономічного часу, результат відтворюваний і не залежить від стану датчиків. Плата за це — сліпота до факту: світло горить у порожній залі й не вмикається, коли зміна вийшла за графік.
Сценарії за присутністю працюють від подій: датчики руху та освітленості формують зону зайнятості, а витримка утримання не дає світлу гаснути, поки людина сидить без руху.
Поріг спрацювання й час утримання задаються окремо для коридору, переговорної та складу — інакше отримуємо або мерехтіння, або освітлений порожній прохід.
На практиці контури не конкурують, а вкладаються: розклад задає базовий режим і служить безпечним станом при втраті зв'язку з датчиками, а датчики уточнюють картину всередині дозволених вікон.
Стандарт адресації світильників DALI дозволяє обмежити ручне перехоплення однією групою, а не всім поверхом.
Пріоритет ручного керування проєктується явно: команда оператора або настінного вимикача перебиває автоматику на заданий інтервал, після чого керування повертається сценарію. Так аварійний вихід залишається освітленим незалежно від того, що вирішила автоматика.
Технічні питання, які ставлять до старту
Служба експлуатації ставить питання раніше проєктувальників: не про алгоритми, а про поведінку системи в реальній будівлі. Нижче — чотири сумніви, які спливають на об'єктних зустрічах до старту.
Що буде з освітленням, якщо зникне зовнішній зв'язок?
Логіка керування живе на локальному контролері: розклад, реакція на датчики й чергові сцени продовжують працювати без каналу.
Зовнішній зв'язок потрібен для аналітики та оновлення моделей — після його відновлення накопичені події синхронізуються, розбіжностей у журналі не залишається.
Існуючі датчики руху доведеться міняти?
Не обов'язково. Спочатку інвентаризація: що змонтовано, який сигнал на виході, чи потрапляють зони покриття в потрібні контури. Дискретний вихід заводиться через модуль спряження, обмін по шині — напряму, якщо обладнання підтримує DALI. Заміна потрібна лише там, де датчик не дає потрібного розділення за зонами.
Як відсікаєте хибні увімкнення?
Рішення ухвалюється за сукупністю ознак: рух, рівень природного світла, час утримання, прив'язка до зони. Затримка на вимкнення й гістерезис за порогом знімають спрацювання від потоків повітря, відблисків і відображень. Частка хибних увімкнень фіксується на прийманні як вимірюваний показник.
Хто відповідає за налаштування після здачі?
Пороги та сцени залишаються в конфігурації об'єкта, а не в нашій системі — служба експлуатації може змінювати їх сама.
Передаємо схеми, регламент змін і навчаємо персонал; супровід після здачі працює окремим режимом з обумовленим вікном реакції, коли логіку потрібно правити за фактом експлуатації.
Обговоримо вашу задачу й повернемося з планом
Щоб обговорити задачу предметно, а оцінка проєкту освітлення не перетворилася на «середню по ринку», потрібен мінімум ввідних. Зберемо їх за одну розмову — без довгого листування й уточнювальних кіл на тиждень.
- Схема приміщень або зон: де стоять світильники, як розведені лінії, чи є вже групи керування.
- Тип датчиків — присутність, освітленість, рух — і за яким інтерфейсом вони віддають показання.
- Поточний контур керування: щити, реле, шлюзи, що вже доступно віддалено, а що доведеться додавати.
- Сценарії, які потрібні на практиці: робочі години, черговий режим, зони з підвищеними вимогами до рівня світла.
- Обмеження за монтажем і допусками: нічні вікна робіт, заборонені зони, хто відкриває доступ на об'єкт.
- Що вважаємо результатом: частка автоматичних спрацювань, відсутність хибних увімкнень, звіт за витратою за зміну.
У відповідь віддаємо схему інтеграції з точками підключення, план впровадження за етапами з перевірюваним результатом на кожному й склад робіт з межею відповідальності.
Окремо проговорюємо, що залишається на стороні монтажної організації, а що закриваємо ми — щоб логіка керування не повисла між підрядниками.
Опишіть задачу у двох-трьох абзацах — повернемося з оцінкою та планом.
