HOME ASSISTANT — ЧАСТ 9

☠️ Колко тъп става умният ти дом, когато Home Assistant умре?

В Част 8 най-накрая събрахме всичко на едно място.

Направихме си нашия:

🖥️ SHTF DASHBOARD

Вече имаме:

⚡ POWER
💧 WATER
🌫️ AIR
🧊 FOOD
🌐 COMMS
⛈️ WEATHER
🌍 EVENTS
🔋 SENSORS

И вместо да гледаме 84 entities, 19 gauges и 14 графики, искаме системата просто да ни казва:

🟢 Всичко е наред.

🟡 Погледни това.

🟠 Имаме проблем.

🔴 Действай.

⚪ Не знам какво става.

Прекрасно.

Само че докато пишехме предишната част, се появи един доста неприятен въпрос:

А КАКВО СТАВА, АКО САМИЯТ HOME ASSISTANT УМРЕ?

😏

---

☠️ НЕ ГОВОРЯ САМО ЗА „СПРЯ ТОКЪТ“

Това вече го разгледахме.

Имаме UPS.

Имаме BLACKOUT MODE.

Имаме критични товари.

Имаме някаква стратегия.

Тук говорим за нещо друго.

Home Assistant може да спре, защото:

💾 SSD/SD/storage устройството е умряло;

🖥️ компютърът е повреден;

🔌 захранването му е дефектирало;

🐝 Zigbee coordinator-ът е умрял;

🌐 network infrastructure има проблем;

⚙️ update е счупил нещо;

🧩 някоя integration е направила беля;

🗄️ configuration/database има проблем;

🤦 или защото ние сме решили:

„Само това ще пипна набързо…“

в 23:47 вечерта.

😂

И половин час по-късно:

HOME ASSISTANT IS NOT AVAILABLE.

---

😁 ДОБРЕ. И?

Това е въпросът.

Какво точно спира да работи?

Само:

„Лампата вече не се включва сама.“

или:

🚫 не можете да включите лампата;

🚫 отоплението не може да се управлява;

🚫 крана за вода е останал в някакво състояние;

🚫 нямате monitoring;

🚫 няма alerts;

🚫 Zigbee устройствата вече не могат да бъдат управлявани;

🚫 никой вкъщи не знае какво да прави.

Защото има огромна разлика между:

SMART HOME DOWN

и:

HOME DOWN.

---

🧠 И ТУК ИДВА ЕДИН ОТ НАЙ-ВАЖНИТЕ ПРИНЦИПИ В ЦЯЛАТА СЕРИЯ

Вече го споменахме.

Сега ще го напишем с големи букви:

SMART НЕ ТРЯБВА ДА ПРЕМАХВА NORMAL.

Ако Home Assistant умре…

искам къщата ми да стане:

по-малко умна.

Не:

НЕИЗПОЛЗВАЕМА. 😂

---

💡 НАЙ-ЛЕСНИЯТ ПРИМЕР — ОСВЕТЛЕНИЕТО

Имаме smart bulb.

Имаме Home Assistant.

Имаме motion sensor.

Имаме automation.

Влизаме в коридора:

👣 motion detected
↓
🤖 automation
↓
💡 light ON

Прекрасно.

Докато Home Assistant работи.

Но ако HA умре…

как включвам лампата?

Ако отговорът е:

„Ами… трябва Home Assistant.“

имаме архитектурен проблем.

---

🖐️ ФИЗИЧЕСКИЯТ КЛЮЧ НЕ Е ОТЖИВЕЛИЦА

Напротив.

За мен физическият ключ е:

FALLBACK.

Натискам.

Лампата светва.

Не ме интересува дали:

🌐 Internet е достъпен;

🏠 Home Assistant работи;

🐝 Zigbee coordinator е жив;

📱 телефонът ми е зареден;

☁️ някакъв cloud service съществува.

ЦЪК.

💡

😂

И това е прекрасно.

---

🏠 „АМА НАЛИ Е SMART HOME?“

Да.

И точно затова трябва да бъде проектиран умно.

Smart не означава:

„Премахни всички нормални начини за управление.“

Smart означава:

„Добави възможности.“

Това е огромна разлика.

---

🚰 СЪЩОТО ВАЖИ ЗА ВОДАТА

В Част 6 имахме:

💧 leak detected
↓
🧠 evaluate
↓
🚰 close valve
↓
🔄 verify

Чудесно.

Но моторизираният кран трябва да има обмислен начин за управление, ако:

Home Assistant не работи;

комуникацията е паднала;

моторът има проблем;

няма захранване;

automation-ът не се изпълни.

При критични системи manual override не е екстра.

Той е част от дизайна.

---

🔥 ОТОПЛЕНИЕТО?

Същото.

Ако Home Assistant изчезне за три дни…

трябва ли семейството да стои на 11°C, защото:

„Automation-ът не тръгва.“

😂

Критичните функции трябва, доколкото конкретната система позволява, да могат да продължат в някакъв безопасен базов режим независимо от Home Assistant.

HA може да:

оптимизира;

автоматизира;

наблюдава;

координира.

Но трябва много да внимаваме, преди да го превърнем в единствения възможен начин нещо важно да работи.

---

☠️ SINGLE POINT OF FAILURE

Това е терминът, който ни интересува.

Ако повредата на едно нещо сваля прекалено много други функции…

имаме:

SINGLE POINT OF FAILURE.

И колкото повече строим около Home Assistant…

толкова по-лесно е самият Home Assistant да стане точно това.

---

🧩 НО „HOME ASSISTANT“ ВСЪЩНОСТ Е ЦЯЛА ВЕРИГА

Това също често се пропуска.

Казваме:

„Home Assistant ми работи.“

Добре.

Но за една Zigbee automation може да ни трябват:

⚡ електричество;

🔋 UPS;

🖥️ HA host;

💾 storage;

🐝 Zigbee coordinator;

📡 Zigbee mesh;

🔘 sensor;

💡 actuator;

⚙️ automation.

За notification към телефона добавяме:

🌐 router;

📡 Wi-Fi;

🌍 Internet;

☁️ външни услуги;

📱 телефон.

Изведнъж:

„една automation“

е доста дълга верига.

И всяко звено може да се счупи.

---

🔗 ЗАТОВА ПИТАМЕ:

КАКВО ЗАВИСИ ОТ КАКВО?

Това е много полезно упражнение.

Изберете една важна функция.

Например:

💧 LEAK PROTECTION.

И тръгнете назад:

За да получа notification…

какво трябва да работи?

За да се затвори вентилът…

какво трябва да работи?

За да бъде засечен течът…

какво трябва да работи?

И после започнете да махате неща.

Internet OFF?

Какво остава?

Home Assistant OFF?

Какво остава?

Zigbee coordinator OFF?

Какво остава?

Router OFF?

Какво остава?

Това е много по-полезно от:

„Всичко ми е smart.“ 😁

---

🧪 CHAOS TESTING — В ДОМАШЕН ВАРИАНТ

Не е нужно да разбиваме системата нарочно.

Но можем контролирано да изключим отделни зависимости.

Например:

🌐 спираме WAN;

🖥️ спираме Home Assistant;

🐝 изключваме coordinator-а;

📡 спираме Wi-Fi access point;

🔌 симулираме отпадане на захранването.

И проверяваме:

Какво продължава да работи?

Това е истинският тест.

Не:

„На теория би трябвало…“

А:

„ПРОБВАХ ГО.“

---

💾 И ТУК СТИГАМЕ ДО BACKUP

Естествено.

Първата реакция на:

„Ами ако Home Assistant умре?“

обикновено е:

„Имам backup.“

Супер.

Само че:

BACKUP ≠ RECOVERY.

Backup е файл.

Recovery е:

„Системата ми отново работи.“

И между двете може да имате доста интересен ден. 😂

---

💾 HOME ASSISTANT ВЕЧЕ ИМА ДОСТА ДОБРА BACKUP СИСТЕМА

Към септември 2026 г. Home Assistant има вградени автоматични backups през UI и Backup integration за създаване и възстановяване на backups при всички актуални installation types. Може да следим и кога е бил последният успешен автоматичен backup и дали автоматичен backup е пропаднал.

Тоест вече няма особена причина стратегията ни да бъде:

„От време на време, като се сетя, натискам Backup.“

😂

Можем да го автоматизираме.

---

🗄️ НО КЪДЕ Е BACKUP-ЪТ?

Ето това е по-интересният въпрос.

Представете си:

Home Assistant е на SSD.

Backup-ите са…

на същия SSD.

SSD-то умира.

😐

Имаме страхотна колекция от backups.

Само дето са върху мъртвия диск.

Официалната документация на Home Assistant изрично препоръчва копие на друга система извън самия Home Assistant и в идеалния случай — още едно off-site копие.

Ето това вече е стратегия.

---

3️⃣ 2️⃣ 1️⃣

Класическата система:

3 копия на данните

2 различни места/носителя

1 извън основната локация

Home Assistant разви backup системата си именно с възможности за automatic encrypted backups, retention и различни backup locations.

Не е нужно домашната автоматизация да се превръща в банков data center.

Но:

BACKUP НА СЪЩОТО УСТРОЙСТВО НЕ Е ДОСТАТЪЧНА СТРАТЕГИЯ.

---

☁️ А CLOUD?

Може.

Home Assistant Cloud например може да пази encrypted backup; текущата документация посочва до 5 GB и едно последно запазено cloud backup за абонати. За възстановяване на encrypted backup е нужен encryption key от backup emergency kit.

Може да използвате и друга поддържана backup location.

Или собствено хранилище.

NAS.

Друг компютър.

Важното е:

да не е само върху машината, която се опитваме да защитим.

---

🔑 И НЕ ЗАБРАВЯЙТЕ КЛЮЧА

Encrypted backup е прекрасно нещо.

Докато в деня на бедствието не се окаже:

„Абе… къде беше ключът?“

😂

Emergency kit / encryption key трябва да бъде пазен така, че да можете реално да го намерите, когато Home Assistant вече не работи.

Не само:

вътре в Home Assistant.

Очевидно. 😁

---

🧪 НЕТЕСТВАНИЯТ BACKUP…

Вече знаете какво ще кажа.

…Е ПРЕДПОЛОЖЕНИЕ.

Може backup job да е минал.

Може файлът да съществува.

Може да пише:

SUCCESS.

Но истинският въпрос е:

МОГА ЛИ ДА ГО RESTORE-НА?

Home Assistant поддържа restore от backup, включително при преминаване към друга инсталация/хардуер; проектът посочва, че backup може да бъде възстановен и между различни поддържани installation methods и архитектури.

Това е изключително полезно.

Но аз пак бих искал да съм го пробвал преди да ми потрябва.

---

🖥️ РЕЗЕРВЕН ХАРДУЕР

Тук не казвам:

„Всички трябва да имате втори Home Assistant сървър в hot standby.“

Спокойно. 😂

За повечето домове това би било излишно.

Но ако системата вече е важна за вас, може да е разумно да знаете:

На какво ще я възстановя?

Стар mini PC?

Резервен Raspberry Pi?

VM?

Друг x86 компютър?

Home Assistant OS в момента остава препоръчваният installation type за повечето потребители и може да работи както на поддържан физически хардуер, така и във VM.

Не е задължително резервната машина да работи постоянно.

Може просто да знаете:

PLAN B Е ТОВА.

---

⏱️ И ТУК СЕ ПОЯВЯВА ДРУГ ИНТЕРЕСЕН ВЪПРОС

Не само:

„Имам ли backup?“

А:

КОЛКО ВРЕМЕ МИ ТРЯБВА ДА СЕ ВЪРНА ONLINE?

15 минути?

Един час?

Половин ден?

Три дни, защото трябва да поръчам SSD?

😂

Това е реалната стойност на recovery plan-а.

---

🐝 А ZIGBEE?

Ето тук много хора могат да получат леко сърцебиене.

Представете си:

70 Zigbee устройства.

Coordinator-ът умира.

И първата мисъл е:

„СЕГА ТРЯБВА ЛИ ДА PAIR-ВАМ ВСИЧКО ОТНАЧАЛО?!“

😐

Ако използвате ZHA, има добра новина.

ZHA прави автоматични backups на Zigbee network-а и поддържа restore/recovery и миграция към друг Zigbee coordinator. Home Assistant документацията описва и migration между поддържани адаптери, като целта е да запазите съществуващата мрежа и устройствата.

Това е точно причината:

backup стратегията да не спира само до Home Assistant Core.

Трябва да мислим и за инфраструктурата около него.

---

📦 А РЕЗЕРВЕН COORDINATOR?

Ако имате пет Zigbee устройства?

Вероятно не бих се паникьосвал.

Ако имате:

87 устройства

и половината къща зависи от тях…

един съвместим резервен coordinator в чекмеджето вече не звучи чак толкова параноично. 😁

Не защото трябва да работи постоянно.

А защото:

доставка след три дни

и:

имам го тук

са две различни recovery стратегии.

---

🌐 ROUTER-ЪТ СЪЩО Е ЧАСТ ОТ SMART HOME

Това е нещо, което много лесно забравяме.

Може Home Assistant да е перфектно backup-нат.

SSD — здрав.

UPS — 100%.

Zigbee — работи.

Само че router-ът е умрял.

И половината IP устройства вече:

„Чао.“ 👋

Затова network infrastructure също е част от dependency map-а.

Router.

Switch.

Access points.

DNS.

DHCP.

VLAN configuration, ако използвате такава.

---

📝 ИМА СМИСЪЛ ДА ИМАМЕ И МАЛКО ДОКУМЕНТАЦИЯ

Знам.

Ужасна дума.

😂

Но представете си, че след две години нещо умира.

Помните ли:

кой USB stick беше Zigbee coordinator?

какъв IP има router-ът?

къде е backup encryption key?

как се влиза в NAS-а?

кои устройства са критични?

кое трябва да стартира първо?

вероятно не.

Затова един малък:

📝 RECOVERY SHEET

може да бъде безценен.

Не роман.

Една страница.

---

📋 МОЯТ БИ ИЗГЛЕЖДАЛ НЕЩО ТАКОВА

HOME ASSISTANT

Hardware: Mini PC
Install: HA OS
Backup: Automatic
Last off-site backup: ______

NETWORK

Router: ______
Switch: ______
AP: ______

ZIGBEE

Coordinator: ______
Spare: ______
Network backup: YES / NO

POWER

UPS: ______
Estimated critical runtime: ______

RECOVERY

Backup location: ______
Encryption key location: ______
Spare hardware: ______

И може би най-важното:

START ORDER:

1. Network
2. Home Assistant
3. Coordinator / gateways
4. Integrations
5. Critical automations
6. Notifications
7. Everything else

Просто.

---

👨‍👩‍👧 ИМА ОБАЧЕ ОЩЕ ЕДИН SINGLE POINT OF FAILURE

И той не е устройство.

ВИЕ. 😂

Ако само един човек в къщата знае:

как се включва отоплението ръчно;

как се отваря водният вентил;

как се изключва automation;

къде е router-ът;

как се рестартира Home Assistant;

как се включват лампите без приложението…

имаме:

HUMAN SINGLE POINT OF FAILURE.

И това също не е особено добра архитектура.

---

😁 „АМА ЖЕНА МИ НЕ ИСКА ДА УЧИ HOME ASSISTANT“

И не трябва.

Това е важно.

Семейството не трябва да завършва:

HOME ASSISTANT ADMINISTRATOR — LEVEL 3

за да живее вкъщи. 😂

Трябва да може:

💡 да включи лампата;

🔥 да управлява отоплението;

🚰 да пусне/спре водата при нужда;

🔌 да изключи нещо;

📞 да разбере какво не работи.

Колкото по-малко обяснения са нужни…

толкова по-добре сме проектирали системата.

---

🏷️ ПОНЯКОГА ЕДИН ЕТИКЕТ Е ДОСТАТЪЧЕН

Например до моторизирания вентил:

MANUAL OVERRIDE → HERE

До network cabinet:

ROUTER

SWITCH

HOME ASSISTANT

UPS

Не изглежда толкова cyberpunk.

Но при проблем е много по-полезно. 😁

---

🧠 А КАКВО СТАВА С AUTOMATIONS, КОГАТО HOME ASSISTANT СЕ ВЪРНЕ?

Ето още един интересен въпрос.

Представете си:

HA е бил offline два часа.

После стартира.

Какво е състоянието на къщата?

Водата?

Осветлението?

Климатизацията?

UPS-ът?

Вратите?

Sensors?

Не искам системата просто да каже:

„Здрасти, пак съм тук!“

😂

Искам:

🔄 REASSESS.

---

👁️ КОГАТО СЕ ВЪРНЕ — ПЪРВО ДА ПОГЛЕДНЕ

Например след restart:

провери critical sensors;

провери unavailable devices;

провери water valve;

провери UPS;

провери Internet;

провери fridge/freezer;

провери дали има active alerts.

И чак тогава:

NORMAL.

Не:

„Boot completed → всичко е зелено.“

---

⚪ UNKNOWN ОТНОВО Е НАШ ПРИЯТЕЛ

Home Assistant току-що е стартирал.

20 Zigbee sensors още не са дали update.

Weather integration още не се е обновила.

UPS integration още зарежда.

Тогава:

⚪ INITIALIZING / UNKNOWN

е много по-честен статус от:

🟢 ALL SYSTEMS NORMAL.

Пак стигаме до:

UNKNOWN ≠ SAFE.

---

🔄 И ЕТО КЪДЕ СЕ ЗАТВАРЯ ЦЕЛИЯТ КРЪГ

Спомнете си нашия алгоритъм:

👁️ ВЪЗПРИЕМИ

↓

🧠 ОЦЕНИ

↓

🎯 ПРИОРИТИЗИРАЙ

↓

⚙️ ДЕЙСТВАЙ

↓

🔄 ПРЕОЦЕНИ

↓

🧩 АДАПТИРАЙ СЕ

Същото важи и когато системата се повреди.

Home Assistant умря?

Добре.

👁️ Какво загубих?

🧠 Какво продължава да работи?

🎯 Кое е важно?

⚙️ Как минавам на manual?

🔄 Как възстановявам?

🧩 Какво трябва да променя, за да не стане същото пак?

Това е preparedness.

Не:

„НИКОГА НИЩО ДА НЕ СЕ СЧУПИ.“

Защото ще се счупи.

А:

„КАТО СЕ СЧУПИ — ДА ИМАМ ДРУГ ВАРИАНТ.“

---

🧰 REDUNDANCY НЕ ОЗНАЧАВА ДА ИМАМЕ ПО ДВЕ ОТ ВСИЧКО

Това също е важно.

Не ви казвам да купите:

два router-а;

два UPS-а;

два mini PC;

два Zigbee coordinator-а;

три Internet доставчика;

четири генератора;

и малък ядрен реактор в мазето.

😂

Redundancy може да бъде и:

друг начин да постигнем същия резултат.

Smart light не работи?

Физически ключ.

Automation за водата не работи?

Manual valve.

Internet няма?

Local control.

HA host умря?

Backup + друг компютър.

Notification не пристига?

Локална сирена.

Това е:

FUNCTIONAL REDUNDANCY.

И много често е по-ценна от:

„Имам две еднакви джаджи.“

---

🧠 И ТУК СТИГАМЕ ДО ЕДНА МНОГО SHTF ИДЕЯ

В survival средите често говорим за:

TWO IS ONE, ONE IS NONE. (Предполагам знаете кой го е казал това? )

Полезна идея.

Но понякога я разбираме прекалено буквално.

Не винаги ни трябват:

два еднакви предмета.

Понякога ни трябват:

ДВА НАЧИНА ДА РЕШИМ ЕДИН ПРОБЛЕМ.

Това е много по-интересно.

---

🏠 МОЯТ ТЕСТ ЗА „УСТОЙЧИВ SMART HOME“

Бих направил нещо много просто.

Изключвам Home Assistant.

Напълно.

И питам:

Може ли семейството ми да живее нормално в къщата?

Не:

„Ще работи ли всичко както преди?“

Разбира се, че не.

Затова имаме Home Assistant.

А:

Може ли да използва основните функции на дома?

💡 Светлина?

🚰 Вода?

🔥 Отопление?

🚪 Врати?

🔌 Основни уреди?

Ако отговорът е:

ДА.

Прекрасно.

Smart layer-ът е паднал.

House layer-ът е останал.

Точно това искам.

---

🔥 А АКО ОТГОВОРЪТ Е „НЕ“?

Тогава вече знаем какво да правим.

Не купуваме веднага още gear.

Не инсталираме още integrations.

Не добавяме още automations.

Първо питаме:

КЪДЕ СЪМ СЪЗДАЛ ЗАВИСИМОСТ БЕЗ FALLBACK?

И я оправяме.

---

🧪 МОЖЕ БИ ТОВА Е НАЙ-ПОЛЕЗНИЯТ ТЕСТ ОТ ЦЯЛАТА СЕРИЯ

Не красив dashboard.

Не 150 sensors.

Не lightning map.

А:

ИЗКЛЮЧИ HOME ASSISTANT.

И виж какво ще стане.

😂

Ако след пет минути всички вкъщи викат:

„ТАТИИИИ! НИЩО НЕ РАБОТИ!“

имаме работа.

Ако просто:

motion lights не работят;

някои удобства липсват;

dashboard-ът го няма;

notifications ги няма;

но къщата продължава да функционира…

значи сме на правилния път.

---