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

[standov]

В 04.09.2023 в 12:05, anabioz сказал:

Що вибрати для мінімальної автоматизації в будинок? Які ідеї, плюси та мінуси?

В кожне місце/розетку/світильник, де потрібно:

  Показать контент

В щиток, для полегшення комутації:

  Показать контент

Або самі автомати:

  Показать контент

 

Ціна +/- така сама виходить, якщо б це був окремий автомат і щось з перших двох варіантів.

Автоматизації чого саме? Якщо світла то:

Якщо є гроші та/або великі вимоги то knx/dali

Якщо грошей нема та вимоги до того скромні то я обрав наш український ion8.

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

Стосовно ваших варіантів, я би третій варіант не розглядав, якщо мова про світло. Стосовно 1 чи 2 то вже по смаку і ситуації, головне пам'ятати що автоматизація має бути додатковою, тобто коли в вас вмер шлюз, мережа то світло має працювати на базовому рівні вкл/викл. Оскільки, як я бачу другий варіант не має входів а тільки виходи, тобто зв'язок вимикач/реле буде працювати через мережу то я би і такий варіант не розглядав. Залишається тільки перший.

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

[anabioz]

06.09.2023 в 11:00, standov сказав:

Стосовно ваших варіантів, я би третій варіант не розглядав, якщо мова про світло.

А в чому причина? Є і 10А.

[standov]

1 час назад, anabioz сказал:

А в чому причина? Є і 10А.

Ну як мінімум бо там знову таки переважно нема входу який *електрично* поєднаний із виходом, а по друге 1 місце 18мм на одну точку світла то якось як на а мене перебор. І в третіх то перебор по функціоналу, умовно кажучи використувовути дивайс якій вміє комутуввти 10а з контролем переходу через нуль щоб вмикати 5вт лампочку якось перебор, в четвертих в таких дивайсах ніхто не париться про затримку реакції в немає нічого більш бісячого ніж вимикач який вмикає світло через 500мс після натискання

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

[standov]

Трошки свіжої та актуальної автоматизаці. До зими докупив до свого інвертора другу літієву батарейку і все добре але є нюанси, основний нюанс в тому що, на час блекауту коли АКБ висаджується в ноль, я викатую невеличкий генератор на 3+квт, від якого йде зарядка та споживання будинку.

Від генератора я можу собі дозволити струм заряду максимум 30А (1500вт) щоб залишилося ще 1500 на будинок в цей час, саме цей струм в мене був виставлений на постійно, і то було досить зручно бо дозволяло коли з'являється мережа за 2-3 години повністю заряджатися.
АЛЕ як акб стало в 2 рази більше - заряджатися постійно струмом 30А стало зовсім не так радісно бо довго, при тому що і інвертор і батарея може значно швидше.

Я вирішив шо хочу мати 3 режими заряджання АКБ
1. дефолтний 30А як раніше, фактично це безпечний режим і для гріда і для інвертора і для генератора і батарейка не перегрівається
2. 70А коли є мережа а АКБ просів нижче 50%, тобто є задача зарядити максимально швидко хоча-б до 50% поки є мережа (пару годин)
3. 50А коли є мережа а заряд став більше 50%

Все начебто логічно, але тут є другий нюанс, 70А при напрузі 55В це вже під 4квт, а в мене інвертор всього 5квт, тобто скоріш за все я не зможу одночасно споживати будинок і заряджати струмом 70А в дефолтному режимі, АЛЕ інвертор можна перевести в режим байпасу, коли він через себе буде тільки заряджати а будинок буде напряму від гріда, при цьому якщо грід пропаде то включиться режим №1

Інвертор в мене підключений до SolarAssistant, який в свою чергу, дає mqtt інтерфейс для отримання данних та конфігурації.
В данному випадку отримую від SolarAssistant струм заряду+встановлення, поточний режим+вствновлення, soc батареї та потужність яка споживається/заливається в батарею.

Bridge mqtt:broker:solar "Solar" @ "MQTT" [ host="192.168.10.60", secure=false, username="***", password="****", retainMessages=false, qos=2, enableDiscovery=false,clientID="openhab34" ]
{
    Thing topic SolarAssistant_Inverter_1 "SolarAssistant Inverter 1"  @ "SolarAssistant"  {
    Channels:
        Type number : charge-current-max "Max grid charge current" [ 
            stateTopic="solar_assistant/inverter_1/max_grid_charge_current/state",
            commandTopic="solar_assistant/inverter_1/max_grid_charge_current/set",
            min=10, max=100, step=10,
            unit="A"         
        ]
        Type string : operation-logic "Operation logic" [ 
            stateTopic="solar_assistant/inverter_1/operation_logic/state",
            commandTopic="solar_assistant/inverter_1/operation_logic/set"
        ]
    }

    Thing topic SolarAssistant_Total "SolarAssistant Total"  @ "SolarAssistant"  {
    Channels:
        Type number : battery-soc "Battery SOC" [ 
            stateTopic="solar_assistant/total/battery_state_of_charge/state",
            unit="%"          
        ]

        Type number : battery-power "Battery Power" [ 
            stateTopic="solar_assistant/total/battery_power/state",
            unit="W"          
        ]
    }
}

Ці дані фактично замаплені у відповідні айтеми через проксі:
 

Number:Dimensionless SA_TOTAL_BATTERYSOC "Battery [%.0f %]" {unit="%", channel="mqtt:topic:solar:SolarAssistant_Total:battery-soc", expire="1m"}
Number:Power SA_TOTAL_BATTERYPOWER "Battery Power [%.0f W]" {channel="mqtt:topic:solar:SolarAssistant_Total:battery-power", expire="1m"}

Number:ElectricCurrent SA_INVERTER1_GRIDMAXCHARGE "Charge Max current [%.0f A]" {channel="mqtt:topic:solar:SolarAssistant_Inverter_1:charge-current-max"}
String SA_INVERTER1_OPERATIONLOGIC "Operation logic [%s]" {channel="mqtt:topic:solar:SolarAssistant_Inverter_1:operation-logic"}

Group ElectricityInput_Inverter "Інвертер" <solar_energy> (ElectricityInput) ["Inverter"]
        Switch ElectricityInput_InverterBypassMode "Режим байпасу інвертора [MAP(uk.map):%s]" (ElectricityInput_Inverter) ["Control"]

        Group ElectricityInput_InverterBattery "Батарея" <battery> (ElectricityInput_Inverter) ["Battery"]
            Number:Power InverterBattery_Power "Споживання від батареї [%.0f %unit%]"   <measurement> (ElectricityInput_InverterBattery, gElectricityPower) ["Measurement", "Power"]
            Number:Dimensionless InverterBattery_SOC "Стан батареї [%.0f %]"   <measurement> (ElectricityInput_InverterBattery) ["Measurement", "Level"] {unit="%", widgetOrder="0"}
            Number:Time InverterBattery_SocTime "Залишилося часу [%1$tH:%1$tM:%1$tS]"  <measurement> (ElectricityInput_InverterBattery) ["Measurement", "Time"]
            Number:ElectricCurrent InverterBattery_MaxChargeCurrent "Максимальний струм заряду батареї [%.1f %unit%]"   <measurement> (ElectricityInput_InverterBattery) ["Control", "Currency"] {listWidget="oh-stepper-item"[ step=10, min=10, max=100]}


let proxy = require('openhab-proxy-pattern');
proxy.bind('InverterBattery_SOC', 'SA_TOTAL_BATTERYSOC').update(undefined, 15);
proxy.bind('InverterBattery_Power', 'SA_TOTAL_BATTERYPOWER').update(bw, 15);
proxy.bind('InverterBattery_MaxChargeCurrent', 'SA_INVERTER1_GRIDMAXCHARGE').update().forward();

proxy.bind('ElectricityInput_InverterBypassMode', 'SA_INVERTER1_OPERATIONLOGIC').update(function(value) {
    return (value == 'ECO mode') ? 'ON' : 'OFF';
}).forward(function(value) {
    return (value == 'ON') ? 'ECO mode' : 'Online mode';
});
            

Ну і фактично основна "бізнес-логіка" автоматизації дуже лаконічна
 

rules.JSRule({
    name: 'Inverter charger mode',
    description: "",
    triggers: [
        triggers.ItemStateChangeTrigger('InverterBattery_SOC')
    ],
    execute: e => {
        let now = time.ZonedDateTime.now();
        const soc = parseInt(items.getItem('InverterBattery_SOC').state);
        // мінімальна напруга по фазі С останні 5 хвилин
        const vc = items.getItem('ElectricityInput_VC').history.minimumSince(now.minusMinutes(5));

        if (vc) {
            if (vc.numericState > 200) {
                // є грід останні 5 хвилин і він живий (мінімальна напруга > 200В)
                if (soc < 50) {
                    // 70А + байпас
                    items.getItem('ElectricityInput_InverterBypassMode').sendCommand('ON');
                    items.getItem('InverterBattery_MaxChargeCurrent').sendCommand('70 A');
                    return;
                } else {
                    items.getItem('ElectricityInput_InverterBypassMode').sendCommand('OFF');
                    items.getItem('InverterBattery_MaxChargeCurrent').sendCommand('50 A');
                    return;
                }
            }
        }

        // дефолтний режим, в тч для заряду від генератора
        items.getItem('ElectricityInput_InverterBypassMode').sendCommand('OFF');
        items.getItem('InverterBattery_MaxChargeCurrent').sendCommand('30 A');
    }
});

Як бонус, виявилося що дружина не дуже розуміє заряд батарейки в процентах (це скільки в часі?) і я для неї (ну і для себе) додатково зробив розрахунок часу до повного заряду та розряду АКБ. Тут трохи магії бо процент віддається в цілих і не можна просто проценти ділити на час бо буде постійно "пила" на графіку часу, фактично треба було зловити точки часу коли заряд (SOC) переходить в наступний процент:

 

proxy.bind('InverterBattery_SocTime', 'SA_TOTAL_BATTERYSOC').update(function(value) {
    if (typeof value == 'string') {
        if (value == '100') return undefined;

        let now = time.ZonedDateTime.now();
        let before = time.ZonedDateTime.now().minusMinutes(20);

        let prev_soc = items.getItem("InverterBattery_SOC").history.previousState(true);
        let soc = items.getItem("InverterBattery_SOC").history.previousState(false);
        let before_soc = items.getItem("InverterBattery_SOC").history.historicState(before);

        if (before_soc && prev_soc.timestamp.isAfter(before_soc.timestamp)) prev_soc = before_soc;
        
        let soc_time = soc.timestamp;
        let prev = prev_soc.timestamp;

        if (soc.numericState == 100) return undefined;
        
        var t =  soc_time;
        
        do {
            t = t.minusSeconds(5);

            if (items.getItem("InverterBattery_SOC").history.historicState(t).numericState == soc.numericState) {
                soc_time = t;
            } else {
                break;
            }
        } while (t.isAfter(prev));

        t =  prev; 
        var prev_before = time.ZonedDateTime.now();
        prev_before = prev_before.minusSeconds((time.ZonedDateTime.now().toEpochSecond() - prev.toEpochSecond()) * 20);

        do {
            t = t.minusSeconds(5);

            if (items.getItem("InverterBattery_SOC").history.historicState(t).numericState == prev_soc.numericState) {
                prev = t;
            } else {
                break;
            }
        } while (t.isAfter(prev_before));


        if (prev_soc.numericState < soc.numericState) {
            // charge
            t = (soc_time.toEpochSecond() - prev.toEpochSecond()) * (100 - soc.numericState) / (soc.numericState - prev_soc.numericState);

            return `${t} s`;
        } else if (prev_soc.numericState > soc.numericState) {
            // discharge
            t = (soc_time.toEpochSecond() - prev.toEpochSecond()) * (soc.numericState - 10)  /  (prev_soc.numericState - soc.numericState);

            return `${t} s`;
        }

        return undefined;
    }
    return undefined;
}, 10);

 

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

[volomoto]

22.09.2023 в 22:35, standov сказав:

Як бонус, виявилося що дружина не дуже розуміє заряд батарейки в процентах (це скільки в часі?) і я для неї (ну і для себе) додатково зробив розрахунок часу до повного заряду та розряду АКБ. Тут трохи магії бо процент віддається в цілих і не можна просто проценти ділити на час бо буде постійно "пила" на графіку часу, фактично треба було зловити точки часу коли заряд (SOC) переходить в наступний процент:

Цікавий метод розрахунку залишкового часу. Я б рахував moving average із споживаної потужності і ділив би залишкову ємність на це значення. Вікно взяв би кілька хвилин, щоб естімейт сильно не стрибав при зміні навантаження.

[standov]

45 минут назад, volomoto сказал:

Цікавий метод розрахунку залишкового часу. Я б рахував moving average із споживаної потужності і ділив би залишкову ємність на це значення. Вікно взяв би кілька хвилин, щоб естімейт сильно не стрибав при зміні навантаження.

В такого варіанту є недолік - рано чи пізно ємність батереї буде упливати з деградацією, контролер батареї це враховує і самокалібрується(в теорії), і відповідно, в теорії, розрахунок по soc від контролера не потребує корегування в алогортмі "повної ємності", яку ще і незрозуміло як визначити. А головне, оскільки контролер все одно не віддає (як мінімум через solar-assistant) миттєвий залишок то все одно все зав'язано на soc

[volomoto]

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

В такого варіанту є недолік - рано чи пізно ємність батереї буде упливати з деградацією, контролер батареї це враховує і самокалібрується(в теорії), і відповідно, в теорії, розрахунок по soc від контролера не потребує корегування в алогортмі "повної ємності", яку ще і незрозуміло як визначити. А головне, оскільки контролер все одно не віддає (як мінімум через solar-assistant) миттєвий залишок то все одно все зав'язано на soc

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

Якщо батарею підключити напряму до Solar Assistant, тоді стає доступним ще й SoH, який показує фактичну ємність повну ємність батареї відносно початкової. Тоді виходить що:

Почтакова ємність (Q) — константа.

SoC — змінна, яка приходить по PYLON протоколі.

SoH — змінна, яка приходить по PYLON протоколі.

Відповідно фактична залишкова ємність буде Qnow = Q•SoC•SoH;

Я недавно робив адаптер для БМС, яка не підтримує PYLON протокол, то заодно в прошивці адаптера (esp32) додав передавання всієї телеметрії по MQTT прямо в HASS. І було трохи сумно, що CAN PYLON дуже бідний і описується на двох аркушах паперу. В той час PYLON RS485 має повно всього, але я не можу його використовувати, бо в нових 3 фазних Deye хтось придумав зробити один RS485 як для БМС, так і для даталогера. Відповідно в мене той порт занятий солар ассістатнтом, а батарея може бути підключена тільки по CAN.

[standov]

Я шось не впевнений що soh це саме лінійні проценти від залишкової ємності а не якийсь алгоритмічний показник, бо в мене на сотні циклів він все ще 100%, хоча може звичайно і так. 

 По soc да, є невеличке відставання але там навіть нема півгодини, хвилин 5-10, взагалі не принципово 

[volomoto]

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

Я шось не впевнений що soh це саме лінійні проценти від залишкової ємності а не якийсь алгоритмічний показник, бо в мене на сотні циклів він все ще 100%, хоча може звичайно і так.

Це алгоритнічний показник, бо без повного циклу від відсічки до відсічки неможливо точно визначити залишкову ємність акумулятора. Оскільки ніхто так не ганяє акум, то в контроллер зашивають LUT, в якій є залежність SoH від віку та циклів. Цю таблицю отримують на основі лабораторних тестів і навіть можуть оновлювати, якщо БМС підтримує оновлення прошивки.

[standov]

Написав розлогий текст про автоматизацію вентиляції (ПВУ, догрівання, ГТО) засобами openhab - Розлога автоматизація припливної вентиляції в openhab

[volomoto]

20.10.2023 в 19:12, standov сказав:

Написав розлогий текст про автоматизацію вентиляції (ПВУ, догрівання, ГТО) засобами openhab - Розлога автоматизація припливної вентиляції в openhab

Дуже гране чтиво і багато інформації. Я хотів зробити схожу автоматизацію своєї вентиляції, або лінь перемогла, бо в мені того іоті на роботі хватає ))

Трохи коментарів:

1. Якщо в будинку кондиціоноване повітря, то в літній вставці чи байпасі нема сенсу, точніше вони роблять більше шкоди, ніж користі.

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

3. Надлишковий тиск в будинку може мати один дуже неприємний побічний ефект: конденсат та обмерзання там, де тепле повітря через нещільності виходить назовні. У вас таке таке може бути у вхідних дверях або де в інших місцях, це повітря, яке має багато вологи, охолоджується. Для експерименту можна накачати великий тиск всередині і пройтись з тепловізором ззовні, щоб побачити де втікає повітря. Тоді можна моніторити ті місця в штатному режимі роботи вентиляції і відповідно реагувати, якщо буде кондесат чи обмерзання.

4. У вас ентальпійний теплообмінник, тому правильніше було б рахувати ККД рекуперації по ентальпії, а для цього треба знати масовий потік і ми повертаємось до пункту #2. В мене, правда, точно такий самий розрахунок ККД по температурі і воно показує плюс-мінус трамвайну зупинку, бо те, що в мене в зимовий час працює 3 зволожувачі повітря, які випаровують 10-15 л/доба, ніде в розрахунку ККД не враховується.

[standov]

23 минуты назад, volomoto сказал:

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

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

29 минут назад, volomoto сказал:

Без сенсорів потоку повітря важко зрозуміти, що відбувається в теплообміннику ПВУ, бо температура сама по собі не є показником енергії.

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

32 минуты назад, volomoto сказал:

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

в мене лише одне таке місце через вхідні двері, я з тим змирився, вони пластикові тож особливо нічого крім естетичної історії за собою то в теорії не тягне

33 минуты назад, volomoto сказал:

У вас ентальпійний теплообмінник, тому правильніше було б рахувати ККД рекуперації по ентальпії, а для цього треба знати масовий потік і ми повертаємось до пункту #2

абсолютно згодний але як показала практика для вирахування точки вмикання байпасу вистачає цього розрахунку по температурам БО мені треба саме порахувати четверту температуру. Тобто фактично, якщо цю мою розраховану цифру банально обізвати якось інакше я не ефективність то все стане на свої місця )
 

37 минут назад, volomoto сказал:

того іоті на роботі хватає ))

саме так тому все то трошки довго рухається і інколи щось зробити виходить лише тоді коли щось стається

[volomoto]

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

в мене майже що не роби в будинку під самою стелею в жару повітря 34

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

[standov]

3 минуты назад, volomoto сказал:

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

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

[volomoto]

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

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

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

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

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

[standov]

ну це трохи холіварна історія, за умови плоскої стелі під якою висить кондей та перемішує щоб не допускати вторинного нагріву я може і згодний але коли є великий за висотою А-образний вертикальний простір, в якому є якась кількість гарячого повітря (більш-гарячого ніж інше) яке під дією фізики та під дією притоку холодного повітря з ГТО витісняється в невеликий об'єм звідки видаляється, нагрітих поверхонь там нема як таких в достатній кількості, тобто градієнт там дуже нерівномірний по довжині і з точки зору комфорту ота наявність повітря нагорі вона визначається лише вимірюванням

[standov]

Деякий час тому зробив нову автоматизацію - просунуте нагадування в телеграм-бота про відкриті ворота парковки

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

Для реалізації дуже зручно використати мініатюрний модуль shelly uni, він як раз під таке створювався і наприклад живиться від 12ac які є в китайських приводах та має два не потенціальні транзисторні виходи, 2 входи та ще додаткові можливості які тут не використані

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

Group Parking "Паркування" <parking> (Outdoor) ["Carport"]
    Group ParkingCamera "Камера паркінгу" <cctv> (Parking) ["Camera"]
        Contact ParkingCamera_Presense "Рух камери паркінгу [MAP(uk.map):%s]" <motion> (ParkingCamera) ["Presense"]
        Image ParkingCamera_Image "Останне зображення камери на парковці" <shot> (ParkingCamera) ["Status"]

    Group ParkingGate "Ворота" (Parking) ["Gate"]
        Contact ParkingGate_Closed "Ворота закриті [MAP(uk.map):%s]" <gate> (ParkingGate) ["OpenState", "Opening"]
        Switch ParkingGate_Control "Управління воротами" <gate> (ParkingGate) ["Control"] {expire="1s,state=OFF"}
        Switch ParkingGate_PartControl "Часткове управління воротами" <gate> (ParkingGate) ["Control"] {expire="1s,state=OFF"}

тут окрім управління воротами є ще зображення з камери, яке кожні 15 секунд береться з камери парковки і знадобиться для автоматизації.

Сам алгоритм досить вийшов лаконічний через те що використовує аж 3 з 4х моїх бібліотек

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

var gate_open_timer; 
var gate_check_timer;

var ask_bot = function(t, message) {
    // поточна картика з камери в бота
    t.image(items.getItem('ParkingCamera_Image'));

    if (items.getItem('ParkingGate_Closed').state == 'CLOSED') { // ворота відкриті
        const answer = t.ask((message == undefined) ? 'Схоже ворота відкриті' : message, {
            'Закрити ворота': function(b) {
                alerts.contact('Alert_ParkingGateOpen').restore('Ворота зачиняються');
                items.getItem('ParkingGate_Control').sendCommand('ON');

                // через хвилину від команди закриття треба перевірити що це фактично сталося
                gate_check_timer = actions.ScriptExecution.createTimer('Gate check timer', time.ZonedDateTime.now().plusSeconds(60), function() {
                    if (items.getItem('ParkingGate_Closed').state == 'CLOSED') {
                        alerts.contact('Alert_ParkingGateOpen').fire('Ворота не зачинилися');
                    }
                });
                return true;
            },
        });
    } else { // ворота закриті
        const answer = t.ask('Схоже ворота закриті', {
            'Відкрити ворота': function(b) {
                items.getItem('ParkingGate_Control').sendCommand('ON');
                return true;
            },
        });
    }
}

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

alerts.contact('Alert_ParkingGateOpen').on(function (alerts, e) {
    ask_bot(bot, e.message);
}, function(alerts, e) {
    bot.message(e.message);
});

rules.JSRule({
    name: 'Gate monitor',
    description: "",
    triggers: [
        triggers.ItemStateChangeTrigger('ParkingGate_Closed')
    ],
    execute: e => {
        if (gate_open_timer) {
            gate_open_timer.cancel();
        }
        if (e.newState == 'CLOSED') { // open!
            // ворота відкрилися, виставляємо таймер на 10 хвилин щоб нагадати закрити
            gate_open_timer = actions.ScriptExecution.createTimer('Gate open timer', time.ZonedDateTime.now().plusMinutes(10), function() {
                alerts.contact('Alert_ParkingGateOpen').fire('Ворота відчинені довше 10 хвилин');
            });

        } else {
            // ворота фактично закрилися
            if (gate_check_timer) {
                gate_check_timer.cancel();
            }
            alerts.contact('Alert_ParkingGateOpen').restore('Ворота зачинені');
        }
    }
});

 

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

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

Крім того окремою командою /parking можна отримати стан воріт, фото та закрити/відкрити їх в залежності від поточного статуса

Змінено 4 листопада 2023 користувачем standov

[uafisher]

В 04.11.2023 в 15:51, standov сказал:

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

Циклічно за умови бездіяльності юзера? Нажав перший раз кнопку закрити на фото-спроба невдала, далі юзер повторно вже не натискає баттон "закрити" - кожні 10 хв нові фотки?

[standov]

6 часов назад, uafisher сказал:

Циклічно за умови бездіяльності юзера? Нажав перший раз кнопку закрити на фото-спроба невдала, далі юзер повторно вже не натискає баттон "закрити" - кожні 10 хв нові фотки?

Ні, трошки некоректно написав, не в плані кожні 10 хвилин а цикл логіки до наступної спроби закриття. Тобто:

- закрити не вийшло, написали про це з фото

- чекаємо реакції, хоч тиждень

- є реакція, пробуємо закрити, переходимо на перший пункт.

10 хвилин тут лише перший раз 

[k-master]

18.07.2023 в 18:59, standov сказав:

так, там є спеціальний тип сторінки де на підложку ставиш картинку, в тч svg а на нєї можна насипати датчиків з прив'язкою до координат

Щось вийшло, в принципі саме складне то було чим малювати схему. Правда щось не виходить форматувати потужність в кіловатах замість ватт.

 

 

 

[standov]

36 минут назад, k-master сказал:

кіловатах замість ватт

Як в вас айтем виглядає? 

37 минут назад, k-master сказал:

саме складне то було чим малювати схему

109% чим ви таке гарне намалювали?)

[k-master]

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

Як в вас айтем виглядає? 

OH в курсі про правильне значення, бо передаю я йому взагалі у кіловатах:

case HEATING_POWER -> new QuantityType<>(String.format("%.1f kW", device.getSensorData().getPower()));

Він нормально парсить 18.5 kW та малює це як 18500.

Ну й канал виглядає так:

	<channel-type id="heating_power">
		<item-type>Number:Power</item-type>
		<label>Heating power</label>
		<state pattern="%s %unit%" readOnly="true"></state>
	</channel-type>

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

109% чим ви таке гарне намалювали?)

Та ось це знайшов: www.hydrosketch.com/

 

Змінено 20 листопада 2023 користувачем k-master

[standov]

Замкніть %unit% на kW бо ви зараз виводите просто в базових юнітах айтема, без перерахунку 

[standov]

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

Та ось це знайшов

99 баксов після тріалу, охх

[k-master]

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

99 баксов після тріалу, охх

Ну не так часто схема опалення міняється, намалював та забув. А потім якщо що то можна зробити ще один тріал. Може не красиво, але й не в комерційних цілях. Я поки малював зрозумів що я б її не придбав. Веб версію точно бо не подобається вона мені. Поки шукав я ще знайiов компоненти для MS Visio, але його в мене нема.