Практическая автоматизация дома на базе openhab

[standov]

12 минут назад, yur43 сказал:

перевірте свої кімнатні, буде неприємне відкриття

а шо саме з ними не так? привирають? сильно? в мене по кімнатним дельта зараз від 450 десь до 1200 коли вимикають світло і ПВУ вимикається, виглядає досить правдоподібно

[TaurosRMK]

Десь одним оком бачив, що ви при увімкненні кухонної витяжки вимикаєте витяжку в ПВУ. Як то реалізовано? Також є такий пункт в списку задач, але поки він відтермінувався. Але я думав не вимикати витяжку, а збільшувати приток, щоб рекуперація все ж таки відбувалася. Витяжка в мене звичайна побутова, 3 швидкості, і тут напевно якось потрібно для кожної швидкості збільшувати приток на відповідну величину, тому що продуктивність витяжки значно відрізняється на 1й і 3й швидкості.

[yur43]

7 хвилин тому, standov сказав:

а шо саме з ними не так? привирають? сильно? в мене по кімнатним дельта зараз від 450 десь до 1200 коли вимикають світло і ПВУ вимикається, виглядає досить правдоподібно

якщо датчик з автокалібруванням не виносити з приміщення, а рівень там не буде періодично знижуватись до рівня калібрування (400), то з часом він бреше в нижчу сторону, бо калібрується по існуючим мінімумам даних. Тим більше датчики з періодом калібрування тиждень.

Шторки з приводами нормально працюють при постійних імпульсних режимах і частковому відкриванні. Я так байпасними шторками все літо регулював нічне охолодження.

Змінено 26 грудня 2024 користувачем yur43

[standov]

Ось два графіки, перший новий (куплений десь в кінці літа ), другий старий якому під 10 років

В цілому я не бачу великої проблеми якщо вони мають якусь в моменті похибку, воніа все одно на інтервалі часу буде нівельована статистично, для під-регулювання більше важливо напрямок тренду а скільки там 500 або 600 насправді то взагалі не бачу причину паритися, крім того все одно це вимірювання в якісь точці а не середне/максимальне по кімнаті. тож хай само собі там калібрує, результат мене влаштовує абсолютно. Особливо коли світло є )

[standov]

4 минуты назад, TaurosRMK сказал:

увімкненні кухонної витяжки вимикаєте витяжку в ПВУ. Як то реалізовано?

зараз ніяк, але якийсь час то було реалізовано на реле шеллі з вимірюванням потужності, на витяжці висіло це реле і якщо на ньому потужність більше 50вт то ПВУ перемикало режим на пріоритет подачі. Але потім реле це згоріло (як і більшість шеллі) то я поки тим не запарююсь просто на ПВУ майже завжди стоїть пріоритет подачі. Але треба буде якось відновити, ще треба додати такий функціонал на камін, бо зараз як запалюю камін то вимикаю витяжний ПВУ з телефона, це замахує.

[standov]

6 минут назад, yur43 сказал:

бо калібрується по існуючим мінімумам даних

теоретично можна додати в алгоритм щоб він по черзі ставив пріоритет по окремим зонам, нагоняти мінімум штучно, але знову таки поки не бачу в тому великого сенсу, поточний алгоритм працює адекватно і дає очікувані результати )

[standov]

Трошки новорічної магії під залишки олівье.

Купив я під новий рік по дисконту розумний дверний дзвоник Ubiquiti G4 doorbell pro. Чого саме його - бо в мене весь відеонагляд від них і логічно мати все в одній апі та екосистемі.

Дзвоник гарний, але мова не про це - є в нього одна фіча не дуже документована, це підтримка відбитків пальців (+ карток NFC, але я не тестував). Фіча ця не дуже афішується бо вона сама по собі сенсу особливо не має і має працювати в комплекті з їх аксес-хабом, який вже буде відкривати замки і тп.

Я вирішив що ставити на 1 хвіртку хаб/замок по перше дуже складно а по друге занадто дорого, вирішив задачу інакше.

 

Спойлер

 Починаючи з якоїсь версіі протекта (софт для NVR) з'явилася можливість робити HTTP запити на зовнішні системи у випадку настання якихось евентів, зокрема doorbell має евент "розпізнаний відбиток пальця". Тож задача звелася до організації додаткового пристрою який би міг отримати HTTP запит та відкрити замок хвіртки.

Варіанта було 2
1. Заюзати у якості HTTP апі openhab, який би вже далі кудись шось давав команду

2. Мати окремий пристрій з окремим АПІ, ходити на нього напряму а це пристрій би вже *додатково* стучався в опенхаб по результатам.

Взяв другий варіант, бо меньше посередників і процес не залежить від опенхаба, а опенхаб лише лає додатковий функціонал.

В якості пристрою обрав wifi реле sonoff SV, воно дешеве, правильно зроблене, може бути доопрацьване до ізольованого режиму та живиться від 12В.

 Додатково купив Ajax Relay + "тривожну кнопку" Ajax.

Реле прошив в мою улюблену Tasmota, на 4 пін повісив вихід реле аджаксу, налаштував в апі аджакса 0.5с імпульс на реле при натисканні кнопки.

На самому реле, по інструкції на сайті sonoff ізолював вихід реле від входу.

Додаткові модифікації в Tasmota:

1. Статичний IP

2. 4 пін зробив Switch (на ньому висить реле аджакса)

3. Дуже важливо, включити авторизацію по паролю в веб-морду Tasmota, бо с-сесуріті

4. Правило автоматичного вимикання реле через 1 секунду після вмикання (щоб не спалити замок), нажаль затримка меньше секунди в тасмоті робить дуже муторно то-ж вирішив поки 1с
 

Rule1 ON Power1#State=1 DO RuleTimer1 1 ENDON ON Rules#Timer=1 DO Power1 0 ENDON

Вся ця історія заживлена від 12в БЖ Hіkvision, вихід реле працює на "БУЗ" (revel.com.ua/info/articles/podklyuchenie-elektromekhanicheskogo-zamka/. Фактично це накопичувальний конденсатор, який дозволяє в катушку замка віддавати імпульс струму до 24в/2а при слабенькому живленні.

На цьому етапі я отримав можливість відкрити хвіртку з кнопки аджаксу.

Далі в AlarmManager до Unifi Protect треба прописати правило, у випадку Activity "Fingerprint Scan", з Fingerprint "Registered Fingerprint" робити Webook на урл
 

<ip>/cm?user=<user>&password=<password>&cmnd=Power%20Toggle

Далі треба зайти в апу Protect та в налаштуваннях дзвінка додати свій відбиток пальця (+ в акаунті членів сім'ї зробити те саме з їх пальцями).

На цьому етапі замок вже відкривається по відбитку будь кого хто додав його в свій аккаунт Protect.

 

 

Додам магію опенхабу. Я хочу щоб по перше мені в телеграм-бот приходило повідомлення коли хтось дзвонить, коли хтось відкриває хвіртку через реле, та щоб я міг з бота мати можливість відкрити її віддалено + це все з фото, бо це-ж камера!

Реле tasmota заведено в опенхаб через mqtt, я маю стан входу та керую виходом.

В опенхабу в маркетплейсы є бондінг під Protect, дозволяє отримувати зображення з камер, але є велика проблема - він опрошує камери наприклад раз в хвилину і картинка з камери завжди є трошечки "старою". Але в нього є механізм зробити знімок по запиту. Також з цього бондінга я отримую евент коли хтось дзвонить в сам дзвінок.

Я додав трошки магії - створив ручне правило в яке я передаю ім'я камери та калбек, в яке передається контекст коли фото готове. Виглядає трошки страшно але працює.

сonst cameras = {
    ParkingCamera: 'PARKING',
    TerraceCamera: 'BACKYARD',
    EntryGateDoorbell: 'DOORBELL',
    EntryCamera: 'FRONTYARD'
};

const motion_triggers = [];
const update_triggers = [];
const modules = {};

const images = {};

for (const [k, v] of Object.entries(cameras)) {
    update_triggers.push(triggers.ItemStateChangeTrigger('UNIFI_PROTECT_' + v + '_SNAPSHOTIMAGE', undefined, undefined, k + "_update"));

    modules[k + "_update"] = k;
    images[k] = [];
};

rules.JSRule({
    name: "Update camera snaps pics",
    triggers: update_triggers,
    execute: event => {
        let module = modules[event.module];

        console.log('Update', typeof images[module]);

        images[module].forEach(function (c, index) {
            c(module, items.getItem(event.itemName));
        });

        images[module] = [];
    }
});

rules.JSRule({
    id: "UPDATE_CAMERA",
    execute: event => {
        const name = event.raw.name;
        console.log('Ask update image', name);
        
        images[name].push(event.raw.callback);
        items.getItem('UNIFI_PROTECT_' + cameras[name] + '_SNAPSHOTSWITCH').sendCommand('ON');
    }
});

Тепер якщо я викличу в коді правило UPDATE_CAMERA я з невеличною затримкою (0.1-1с) отримаю прям поточне фото з камери. Можна оживити хвіртку

const bot = require('openhab-telegram').bot("telegram:telegramBot:......");

const control_item = items.EntryGate_Control;
const contact_ring = items.EntryGateDoorbell_Ring;

var ask_bot = function(t, message) {

    rules.runRule('UPDATE_CAMERA', {
        name: 'EntryGateDoorbell',
        callback: (name, image) => {
            t.image(image);

            

            if (contact_ring.state == 'OPEN') {
                t.ask((message == undefined) ? 'Дзвінок у хвіртку' : message, {
                    'Відкрити хвіртку': (b) => {
                        control_item.sendCommand('ON');

                        return true;
                    },
                });
            } else {
                if (message == undefined) {

                    message = 'Поточне зображення з дзвінка';
                }
                t.ask(message, {
                    'Відкрити хвіртку': (b) => {
                        control_item.sendCommand('ON');
                        return true;
                    },
                });
            }
        }
    });
    
    
}

bot.onCommand('entry', function(t) {
    ask_bot(t);
});

rules.JSRule({
    name: "Enter ring",
    triggers: [triggers.ItemStateChangeTrigger(contact_ring, 'CLOSED', 'OPEN')],
    execute: (event) => {
      ask_bot(bot, 'Дзвінок у хвіртку');
    }
});

rules.JSRule({
    name: "Enter opened",
    triggers: [triggers.ItemStateUpdateTrigger(control_item, 'ON')],
    execute: (event) => {

        rules.runRule('UPDATE_CAMERA', {
            name: 'EntryGateDoorbell',
            callback: (name, image, event) => {
                bot.image(image, 'Хвіртку відчинено по запиту');
            }
        });
    }
});

1. Якщо хтось дзвонить я бачу в телегу поточний скріншот та кнопку з якою можу відкрити хвіртку
2. якщо хтось сам відкрив хвіртку за допомогою аджакса або відбитка або своєї апи/бота то я отримаю фото та повідомлення про це
3. в боті маю команду /entry за якою можу подивитися що там відбувається та відкрити примусово

В боті це виглядає так
 

 

 

Не забувайте донатити на ЗСУ.

 

 

Змінено 6 січня користувачем standov

[k-master]

А хто як в ОН світлом керує? Ну тобто є вимикач у вигляді контакта та свіч. І мені щось набридло писати по 2 правила на керування кожною лампочкою. Без правил це якось можна зробити? 

[standov]

2 часа назад, k-master сказал:

А хто як в ОН світлом керує? Ну тобто є вимикач у вигляді контакта та свіч. І мені щось набридло писати по 2 правила на керування кожною лампочкою. Без правил це якось можна зробити? 

Чесно кажучи не дуже розумію про два правила, можете пояснити думку?

Я особисто все світло ( да і не лише світло) заводжу через мою проксі-бібліотекуюґ, але і там є лише свіч, через проксі.

Що ви робите з контактом і нащо? Достатньо свіча.

Змінено 1 лютого користувачем standov

[k-master]

10 годин тому, standov сказав:

Чесно кажучи не дуже розумію про два правила, можете пояснити думку?

Я особисто все світло ( да і не лише світло) заводжу через мою проксі-бібліотекуюґ, але і там є лише свіч, через проксі.

Що ви робите з контактом і нащо? Достатньо свіча.

Вимикач настінний - посилає 1/0 в mqtt замаплен в контакт та відображається як айтем з станом OPEN/CLOSED

Лампа - свіч, керується 1\0 в mqtt, замаплена в свіч.

Правила:
1. Коли контакт змінив стан на OPEN послати команду ON в свіч
2. Коли контакт змінив стан на CLOSED послати команду OFF в свіч.

Тобто на кожну лампу треба 2 правила, але мені здається що це не правильно. Якось воно повинно працювати взагалі без правил як я думаю.
 

[standov]

Вимикач настянній тут мається на увазі хардварний? Тобто він має два бондінга на вхід вихід? Я категорично проти таких схем коли хардварний вимикач та хардварна лампа зв'язуються через ох, бо це по перше не найдііно а по друге вносить затримку.

Якщо лампу та вимикач поєднати між собою поза опенхабом (зігбі прив'язка, електрично, реле якесь) то контакт не потрібен і достатньо аросто свіч лампи зкий читає/міняє стан, і в усих прикладах схема саме така, напрямую мапимо лампу.

Використовувати контакт (contact) для чогось що може змінити юзер напряму не коректно, якщо вже робити таку єтажерку правил то саме лампа мсє бути Contact, а свіч настінний Switch.

Якби мені було потрібно всеж так зробити як ви хочете, я би мабуть.

1. Зробив 1 mqtt thing який має stateTopic(ввшого настянного перемикача)

2. Зробив switch для лампи на цей thing

3. Зробив правило на цей switch при update слати в mqtt  команду.для лампи

Тобто айтем на перемикач імхо зайва сутність і я шось не зузстрічав в інших щоб вони її використовували.

Це трошки на пальцях, і може я шось не так зрозумів

Змінено 2 лютого користувачем standov

[k-master]

2 хвилини тому, standov сказав:

Вимикач настянній тут мається на увазі хардварний? Тобто він має два бондінга на вхід вихід? Я категорично проти таких схем коли хардварний вимикач та хардварна лампа зв'язуються через ох, бо це по перше не найдііно а по друге вносить затримку.

Якщо лампу та вимикач поєднати між собою поза опенхабом (зігбі прив'язка, електрично, реле якесь) то контакт не потрібен і достатньо аросто свіч лампи зкий читає/міняє стан, і в усих прикладах схема саме така, напрямую мапимо лампу.

Використовувати контакт (contact) для чогось що може змінити юзер напряму не коректно, якщо вже робити таку єтажерку правил то саме лампа мсє бути Contact, а свіч настінний Switch.

Якби мені було потрібно всеж так зробити як ви хочете, я би мабуть.

1. Зробив 1 mqtt thing який має stateTopic autoupdate=false

2. Зробив switch для лампи на цей thing

3. Зробив правило на цей switch при update слати в mqtt команду.

Тобто айтем на перемикач імхо зайва сутність і я шось не зузстрічав в інших щоб вони її використовували.

Це трошки на пальцях, і може я шось не так зрозумів

Затримки немає, там менше 20 мс виходить, не помітно. Через підрозетники з вимикачами проходять дроти на лампу з загального щіта транзитом на випадок якщо щось буде не так, але ніяких проблем немає тому там просто дріт цілий, неушкоджений йде далі, а вимикач хардварний підключений до крученої пари котра теж туди приходить. 
Ну в UI я не знайшов як транслювати OPEN/CLOSED в ON/OFF. Може погано шукав. А так як не знайшов окреме правило то на кожну лампу по 2 правили типа таких:
 

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: SNG_STM_DEV01_CH17
      state: OPEN
    type: core.ItemStateChangeTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      command: OFF
      itemName: SNG_MQTT_CH_FL1_KITCHEN_WORKPLACE_LIGHT
    type: core.ItemCommandAction

Доведеться таки замість слати команду виконувати скрипт, тоді достатньо буде одного правила.

А контакт насправді нормальна штука, бо вимикач це й є контакт. Та й наприклад є лампи котрі керуються 2-ма вимикачами і тоді 2 свіча робити,а у UI що буде на одну лампу? А так у UI є лампа - свіч та є контакти котрими керувати неможливо, бо вони тільки зчитують інформацію з хардварних пристроїв. 

[standov]

Якщо ви почитаєте доку про контакт,  то там написано що він для readonly кейсів Іншими словами він не має перемикатися ні в інтерфейсі ні правилами. Найкращий приклад залізки для contact це геркон, ви його статус читаєте але не можете міняти в ох, тільки хардварео, на це наприклад орієтовані дефолтні інтерфейси. Тобто це можна натягнути на лампочку (яка вбо горить або ні) але аж ніяк не на перемикач, який ви в інтеріейсі можете переключити

По мапінгу, почитайте доку на mqtt бондінг,  вм точно є, я просто thing завжди роблю через files і не пам'ятаю що там в інтерфейсі, але зазвичай там є галочка Advanced яка відкриває доступ до додаткового функціоналу

Змінено 2 лютого користувачем standov

[standov]

Оце ви шукаєте? Це в налаштуваннях каналу thing 

[k-master]

2 години тому, standov сказав:

Якщо ви почитаєте доку про контакт,  то там написано що він для readonly кейсів Іншими словами він не має перемикатися ні в інтерфейсі ні правилами. Найкращий приклад залізки для contact це геркон, ви його статус читаєте але не можете міняти в ох, тільки хардварео, на це наприклад орієтовані дефолтні інтерфейси.

Правильно, я кажу те саме - є на стіні перемикач, а контакт в ОН просто відображає його стан. А от в залежності від стану контакта ми можемо робити правила і керувати наприклад свічем котрий керує лампочкою.

 

[standov]

1 час назад, k-master сказал:

Правильно, я кажу те саме - є на стіні перемикач, а контакт в ОН просто відображає його стан. А от в залежності від стану контакта ми можемо робити правила і керувати наприклад свічем котрий керує лампочкою.

 

Зррзумів,  тобто у вас бістабільний вимикач, не імпульсний, який заведений прямо в ох, ну тоді я би мабуть робив як вище писав, з thing stateTopic та правило з посилання в mqtt команди напряму черкз actions або через commandTopiс+autoupdate=false. Якщо у вас задача лише зв'язати лампу з вимикачем не бачу глибокого сенсу  мати повноцінний  Contact 

[standov]

Приклад з дркументації, там правда з додатковою трансформацією але не принципово

Thing mqtt:topic:bedroom1-switch (mqtt:broker:myInsecureBroker) [ availabilityTopic="tele/bedroom1-switch/LWT", payloadAvailable="Online", payloadNotAvailable="Offline" ] {

Channels: Type switch : power [ stateTopic="stat/bedroom1-switch/RESULT", transformationPattern="REGEX((.*POWER.*))∩JSONPATH($.POWER)", commandTopic="cmnd/bedroom1-switch/POWER" ]

}

Це черкз files, але можна використати як шпаргалку для інтерфейса, плюс погратися з autoupdate.

Якщо хочеться саме мати окремий контакт та лампу то я би може пошукав в комьюніт маркетплейсі якийсь ruleTemplate про це, я не натикався але мені здається може бути

[k-master]

02.02.2025 в 15:34, standov сказав:

Приклад з дркументації, там правда з додатковою трансформацією але не принципово

Thing mqtt:topic:bedroom1-switch (mqtt:broker:myInsecureBroker) [ availabilityTopic="tele/bedroom1-switch/LWT", payloadAvailable="Online", payloadNotAvailable="Offline" ] {

Channels: Type switch : power [ stateTopic="stat/bedroom1-switch/RESULT", transformationPattern="REGEX((.*POWER.*))∩JSONPATH($.POWER)", commandTopic="cmnd/bedroom1-switch/POWER" ]

}

Це черкз files, але можна використати як шпаргалку для інтерфейса, плюс погратися з autoupdate.

Якщо хочеться саме мати окремий контакт та лампу то я би може пошукав в комьюніт маркетплейсі якийсь ruleTemplate про це, я не натикався але мені здається може бути

Здається що все ж таки правильно так як в мене - вимикач це контакт, лампа - свіч. А щоб їх зв'язати без правил то треба прилінкувати контакт в свіч з трансформацією OPEN=>ON/CLOSED=>OFF. Але через баг в UI це прилінкувати неможливо. Пофіксили буквально 2 місяця тому правда для 5.0, на 4.3 ще не портували, на 5.0 протестувати не можу бо біндинг не ставиться Може на днях фікс для 4.3.1 спробую зробити якщо там просто копи-паст без суттевих змін у версіях.

[standov]

@k-masterне можу нічого сказати, не заводжу через ui ні items ні things, тому не стикався мабуть з таким багом

[k-master]

3 хвилини тому, standov сказав:

@k-masterне можу нічого сказати, не заводжу через ui ні items ні things, тому не стикався мабуть з таким багом

От з таким конфігом 

Switch  TST_Lamp_202       "Lamp 202"   <lightbulb> {channel="mqtt:topic:87e124e83c:stm32-rtl-iot-device1:SNG_MQTT_STM_RTL1_O04", channel="mqtt:topic:87e124e83c:stm32-rtl-iot-device1:SNG_MQTT_STM_RTL1_I11" [profile="transform:MAP", function="|OPEN=ON;CLOSED=OFF" ]}
Contact TST_WallSwitch     "Wall 202"   <switch> {channel="mqtt:topic:87e124e83c:stm32-rtl-iot-device1:SNG_MQTT_STM_RTL1_I11" }

 

я сьогодні дійшов до того що коли починаю клацати вимикачем іконка для перемикання зникає, але з'являється рядок де міняється стан ON/OFF. Здається замість послати команду воно сетить стан. Як надіслати команду не знайшов.

[standov]

Items, якщо це спеціально не вимкнути (autoupdate), завжди сетять свій стан незалежно від того чи вдалося в канал зробити "корисну роботу". Відповідно у вас профіль відпрацював з транформацією. Не має великого сенсу робити профіль як ви зробили, бо ви фактично намагаєтеся свічу встановити значення яке він не знає як відобразити (тому іконку міняє на текст).

Якщо в вас не з'являється в mqtt топіка то з ймовірністю 99% щось не так в things яким відповідає channel

Ви кудись не туди пішли, ви спробували то що я вище писав про stateTopic commandTopic + transformationPattern? Не спрацювало?

Змінено 9 лютого користувачем standov

[standov]

Покажіть конфігурацію для отих двох каналів які в свічі і чого їх два? 

[standov]

"думайте як залізка"

Варіант 1, точно рабочий але багато рухів

Зробіть по каналу на кожну залізку, прямо в налаштуваннях каналу добийтеся щоб канал чітко відповідав формату даних або свіча або контакта, це 100% можно бо це базові можливості mqtt бондінга, далі зробіть по айтему на кожен канал відповідного типу і поєднайте правилом якщо це потрібно

Варіант 2. Більш лаконічний.

Створити 1 канал який буде читати з одного топіка (лампа) а писати в другий (перемикач) та трансформовувати то все до формату свіча

Свіч на цей канал, вимкнути автоапдейт і забити на контакт бо імхо він не потрібний на рівні опенхабу

 

[k-master]

09.02.2025 в 22:50, standov сказав:

"думайте як залізка"

Варіант 1, точно рабочий але багато рухів

Зробіть по каналу на кожну залізку, прямо в налаштуваннях каналу добийтеся щоб канал чітко відповідав формату даних або свіча або контакта, це 100% можно бо це базові можливості mqtt бондінга, далі зробіть по айтему на кожен канал відповідного типу і поєднайте правилом якщо це потрібно

Варіант 2. Більш лаконічний.

Створити 1 канал який буде читати з одного топіка (лампа) а писати в другий (перемикач) та трансформовувати то все до формату свіча

Свіч на цей канал, вимкнути автоапдейт і забити на контакт бо імхо він не потрібний на рівні опенхабу

 

Вирішив проблему таким чином:
Від вимикача зробив 2 канала на той самий топик. Один як контакт, один як перемикач. Той що контакт прилінкував до перемикача, той що перемикач налаштував з postCommand: true та прилінкував до лампи з дефотлним профілем і все працює без правил.

[FOX.kissfm]

В 16.12.2021 в 22:48, standov сказал:

Пакеты и софт имеют свойство обновляться, выходят новые версии, новый функционал который хочется попробовать, пару раз обновления не проходили без проблемм, было пару ситуаций когда обновление рас***ашивало все, и я мог потратить весь вечер на банальное восстановление работоспособности. А потом у меня умер дешевый SSD и е-но утянул за собой все )

Это был эпик фейл который мне показал что я делаю что-то не так (см. самый первый пост темы)

Я решил что мне нужна контейнерная виртуализация, так что-бы я мог бекапить контейнеры, поднимать их по щелчку пальцев, переключаться между версиями и вообще спать спокойно.

Я поизучил разные бесплатные решения и остановился на proxmox ve (www.proxmox.com/en/), который мне показался не сильно красноглазым и с удобным веб-интерфейсом для тех кто любит "открывать окна мышкой".

Задумав ось розгорнути розумний будинок на Home Assistant.

І тут базово відразу постало питання архітектури, сиджу ламаю голову яким шляхом піти... здається, що піднімати віртуалку, і розкласти їх на три залізяки в кластері - було б відносно не ресурсоємко.

А що б ви порадили через час використання своєї архітектури?