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

[standov]

Решил завести отдельную тему про, как мне кажется, интересную открытую систему автоматизации, которую я активно и постоянно *на практике* использую в своем доме (в футере стройка), рассказать что использую, что получилось что нет, какие планы и тп. Надеюсь популяризации openhab-а среди застройщиков форума. 

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

Вводные, дом около 200м2 в конец 2021 в состоянии строительства (внутренняя отделка), инженерные системы изначально планировались под автоматизацию и сделаны в основном самостоятельно либо по четким заданиям. Что-то уже автоматизировано, что-то еще только в планах, что-то не будет автоматизироваться никогда (бо не считаю нужным). В доме проживает 2 взрослых, 2 детей, кот. Отопление - газ, вода, канализация автономные. Посты буду писать по мере нововведений так и по мере натхнення, рассказать и показать есть много чего но писать нужны силы. На старте сделаю пяток постов вводных "что где почему и как дожил"

Змінено 16 грудня 2021 користувачем standov

[standov]

В доме живем больше года (да, несмотря на идущую отделку) потому все опробовано, на грабли наступлено и мнение сформировалось именно по практическому использованию.
 

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

В автоматизации я отталкиваюсь от неских постулатов, которые сформулировал/посдмотрел и мне они кажутся основополагающими:

1. Автоматизация должна быть незаметной и безпроблемной, если ее надо чинить, следить, проверять то это гимно, если вашим постояльцам с автоматизацией живется сложнее чем без нее то это гимно.

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

3. Все что может сломаться то обязательно сломается, в этом *штатном* сценарии все должно продолжать работать как минимум в минимально-необходимой функциональности

4. Узко-специализированные системы *всегда* выполняют положенные на них функции лучше универсальных.

[standov]

Что такое openhab и почему я выбрал именно его?

Это бесплатное опенсорсное мультиплатформенное программное решение, написанное на богомерзкой Java (пожалуй единственный минус для меня) которое ведет свое начало от когда-то существовавшего специализированного фреймворка Eclipse SmartHome, который достаточно давно, на заре всего движа, ставил задачей объединить всех разработчиков Иот под некой общей стандартизированной программной платформой.
Фремворк ESH вроде даже еще живой но в 3й версии openhab активно выпиливали интеграцию с ним, как тормозящую развитие, но свое дело он сделал. Openhab версии 2 очень логичен, максимально лаконичен прост и очевиден, как минимум пограмисту. В текущей версии 3, как мне кажется, сделали много шагов навстречу функциональному "багацству" и лаконичность и простота пострадала. 
 

Сухая инфа про опенхаб в вики uk.wikipedia.org/wiki/OpenHAB

Сайт проекта www.openhab.org/

Какая роль опенхаба в автоматизации дома?

Не секрет что на рынке есть огромное количество технологий, решений, железок, протоколов так или иначе относящихся к умному дому, все эти решения либо выполняют какие-то прикладные задачи либо ограничены неким небольшим набором железок которые существуют на рынке. Openhab (а также несколько конкурирующих продуктов) делают попытку объединить их все в некий общий зоопарк и наладить взаимодействие между ними а также програмными системами которые вообще не заточены изначально под умный дом но фактически оказались очень полезными и удобными.

Какие есть конкуренты?

Самый мощный и пожалуй более популярный - HomeAssistant (HASS).
На момент моего выбора я пощупал оба, и как программист буквально через пару часов влюбился в строгую и лаконичную идеологию опенхаба, где зная базовые принципы логики работы вы можете представить и спланировать как будет работать сколько угодно сложная система, все-же базис ESH фремворка сыграл огромную роль.
Грубо говоря, весь опенхаб это набор элементарных кубиков из ограниченного набора стандартизированных размеров и цветов но с помощью которых можно сделать логику какой угодно сложности и вы всегда будете понимать почему она работает именно так как работает, но с некоторым ущербом в пользу визуальной красоты и причесанности.
В случае с HASS это все немножно не так, у него упор на юзерфрендли, большую достпность для не пограмистов но он изобилует ситуациями "сделайте именно так и не задавайте лишних вопросов".
Моя любимая аналогия openhab vs hass которую я прочитал в какой-то статье:
Вы можете сделать шар в hass и в openhab, в случае с hass он будет визуально сильно более шаром НО вы никогда не будете знать на сколько он геометрически точный и куда покатится когда потребуется, в случае с OH шар будет состоять из одинаковых кубиков, выглядеть несколько угловато но при приложении нужного выверенного усилия он покатится именно туда куда вы ожидаете.

Мне как пограмисту второй подход сильно более приятен и очевиден )

[standov]

Influxdb

OH в базе самодостаточен и из "коробки" может использоваться сам по себе, как минимум для ознакомления НО он предусматривает по своей природе что его нужно дополнить дополнительными программными пакетами.

Несмотря на то что ОН собирает данные из 100500 внешних систем, по хорошему, не требует их хранения, он просто их закидывает в биореатор сценариев в памяти, который на базе *текущих* значений строит некую логику взаимодействия которая вам нужна. 
Однако есть возможность OH дополнить так называемым Persistent Storage (www.openhab.org/docs/tutorial/persistence.html). Это внешнее хранилище куда OH будет складывать данные которые он получает из разных систем и которые считает сценариями, данные четко привязаны к сущностям и могут быть в будущем использованы в логике самого опенхаба. Например вы получаете доступ в сценариях к таким штукам как "среднее значение датчика за последние сутки" "значение 24 часа назад" "прошлое состояние" и тп багацтво, с которым логика играет другими красками.
Потому Persistent Storage это то что нужно подключить и настроить сразу, как настроить про это все есть в документации. Я просто хочу остановится на том почему это должен быть именно influxdb )
Influxdb это timeseries база данных, которая изначально заточена под хранение данных завязанных на время, она интегрируется максимально просто и естественно, НО дело даже не в этом а в том что данные, сохраненные опенхабом в influxdb, это автоматически и сразу отличный способ получить визуализированные данные в другом программном продукте - grafana. Вот прямо сразу и с разгону, с минимальными движениями и усилиями, вы получаете мощное средство для визуализации, анализа и изучения данных которых в случае с OH будет очень много.

 

Змінено 16 грудня 2021 користувачем standov

[standov]

Mqtt

Другая штука которая вам с вероятностью 99% понадобится при автоматизации дома это MQTT.
Википедия сообщает следующее MQTT (англ. Message Queue Telemetry Transport) — спрощений мережевий протокол, що працює на TCP/IP. Використовується для обміну повідомленнями між пристроями за принципом видавець-підписник.

Другими словами это стандартизированный простой протокол который разработан для задач автоматизации и получения данных от железок и программных систем. С MQTT работает огромное количество продуктов - все возможные ESP прошивки, в тч под sonoff, все железки shelly. А главное все возможные самодельные железки на базе ESP чипов, я также написал пару программ для внутреннего использования которые в конечном счете данные отправляют в mqtt броккер или подписываются на него для получения данных.

Поддержка MQTT в опенхабе реализована в максимальной мере, и предусмотрена на каждом шагу, если у вас есть возможность отправить данные по MQTT вы всегда их просто и удобно сможете обработать в опенхабе.

Есть только одно НО, если одно время (2я версия) опенхаб поставлялся с встроенным броккером то в акутальных версиях эту возможность убрали и броккер требуется поднимать отдельно, но с другой стороны он может быть любым по вкусу.

Я как и подавляющее большинство юзеров опенхаба использую броккер Eclipse Mosquitto mosquitto.org/ (да-да, те самые ребята которые пилили фрймворк под иот). Брокер легковестный, простой, в достаточной степени беспроблемный.

Есть только один нюанс на который я наступил - в дефолтном конфиге москито через какое-то время переставал принимать данные от медленных железок, лечится настройкой - stackoverflow.com/questions/49130641/mosquitto-outgoing-messages-are-being-dropped

[standov]

Итого, для комфортного взлета вам нужно 4 пакета - openhab, influx, grafana, mosquitto. 
Все указанные пакеты на столько "родные" для опенхаба что опенхабовцы разработали специальную утилиту для пакетной установки в режиме мастера всех сразу - www.openhab.org/docs/installation/openhabian.html

Все 4 пакета работают в тч на малине и очень много людей так и использует опенхаб, поставили все на малину и погнали, НО производительности малины не достаточно например для большого потока данных в influx или при просмотре потом данных в графане, да и в целом малина решение ограниченное и решил не идти по этому пути.

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

Я на ебее за очень недорого (порядка 80 баксов по памяти) приобрел микро ПК HP EliteDesk 800 G1 Desktop Mini, в конфигурации intel i3-4030U/8G. Это коробочка очень миниатюрных размеров с внешним БП, которая при этом является брендовым (а значит в теории более надежным) полноценным ПК. Они бывают в разных конфигурациях но вот я нашел именно такой из соображений "до 100 баксов но живой и на приличном процессоре". На него ставится любая ось, начиная от винды 10 и заканчивая любым линуксом.
.

Некоторое время (наверное с год) на нем крутилась убунта с заинсталлеными пакетами опенхаба и всего нужного, в том числе того до чего ееще не дошел разговор, это работало и каши не просило, но по факту оказалось что такое решение не очень удобное.

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

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

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

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

Потратив пару вечеров на чтение документации пришел к тому что по хорошему для proxmox требуется 3 физические машины в кластере, что-бы заработало бекапирование автоматические и авторазворачивание сервисов при падении физической машины. Но у меня 3х пока нет, зато был второй ПК HP Microserver GEn8 который я давно использовал как файлопомойку и бекап.
Итого я поднял на двух железках proxmox, объединил их в кластер и наподнимал на них тонких контейнеров LXC под все сервисы отдельно.
Сейчас это выглядит так

Что мне это дало сразу:
1. Все сервисы в отдельных контейнерах, все контейнеры бекапятся по расписанию
2. Я могу сервисы обновлять не переживая, если обновление не взлетело - я просто откатываю контейнер до предыдушего состояния
3. Я могу поднять совсем новый контейнер рядом с новой версией софта (делал так когда вышел третий опенхаб), поиграться и если вижу что норм то - старый гашу, новый оставляю
4. Контейнеры бекапятся перекрестно - первый "сервер" на второй, второй на первый. Если упадет железка или диск то восстановить будет сильно-сильно проще.

В планах - докупить еще один микродесктоп, сделать 3м в кластер и настроить автоматический фейловер

Важные нюансы:

1. Самый главный нюанс, если контейнер предполагает использование USB (zwave zigbee modbus и тп) то контейнер надо поднимать сразу как "unprivileged" иначе вас ждет куча секса с правами на порт в линуксе. Переделать существующий контейнер в unprivileged в теории можно но на практике у меня получалось с вероятностью 50%.

2. Контейнеры по возможности следует поднимать с alpine linux, разница по диску и памяти с убунтой колоссальная. Но увы не все (например openhab) на alpine поднять или проблематично или невозможно, тогда по вкусу убунту/дебиан/генту...
 

Змінено 16 грудня 2021 користувачем standov

[standov]

Proxy Pattern

openhab предусматривает написание развитых и сложных сценариев автоматизации, на столько сложных что сообщество наработало некоторое количество стандартных архитектурных шаблонов. Следование этим шаблонам дело сугубо добробовальное но, как показывает практика, целесообразное.

На мой взгляд, есть один главный шаблон использование которого строго обязатально если система чуть больше чем маленькая.
Называется Proxy Item community.openhab.org/t/design-pattern-proxy-item/15991.

Попробую пояснить почему он необходим и как я его использую.

У вас есть конкретный дом, есть абсолютно конкретные потребности (контроль освещения, доступа, утечек, потребления, задвижек и тп), вы для реализации этих потребностей заводите в опенхабе *виртуальные железки*, вот реальный пример из моего дома:
 

///////////////////////
// Кабінет
Group          GF_Office                 "Кабінет"               <office>           (Home_GroundFloor)                       ["Office"]
Group          GF_Office_HVAC            "Клімат кабінету"      <heating>          (GF_Office, gHVAC) ["HVAC"] {ga="Thermostat" [ modes="heat,eco=ECO,auto" ]}

    Number:Temperature          GF_Office_Temperature        "Температура у кабінеті [%.1f %unit%]"           <hvac_temperature>        (GF_Office_HVAC, gTemperature)        ["Measurement", "Temperature"] {ga="thermostatTemperatureAmbient"}
    Number:Temperature          GF_Office_SetpointTemperature        "Бажана температура у кабінеті [%.1f %unit%]"           <hvac_setpoint>        (GF_Office_HVAC, gSetpointTemperature)        ["Setpoint", "Temperature"] {ga="thermostatTemperatureSetpoint"}
    Number:Dimensionless        GF_Office_Humidity           "Вологість у кабінеті [%d %%]"             <hvac_humidity>           (GF_Office_HVAC)           ["Measurement", "Humidity"] {ga="thermostatHumidityAmbient"}
    Number:Dimensionless        GF_Office_Co2              "Co2 у кабінеті [%d ppm]"             <hvac_co2>           (GF_Office_HVAC)         ["Measurement", "CO2"] { ga="Sensor" [ sensorName="CarbonDioxideLevel", valueUnit="PARTS_PER_MILLION" ] }

Тут нет абсолютно никакой привязки к реальному железу, более того в кабинете (для которого эти виртульные элементы) на данный момент не существует железки "термостат" для установки "Бажаної температури", она заведена "на вырост". Это просто виртуальное оборудование и датчики которые соответствуют текущим и будущим задачам.

Далее вы заводите уже "железные железки", аналогично пример из моего дома

Number Netatmo_Indoor_Humidex             "Humidex [%.0f]"              <temperature_hot>  { channel = "netatmo:NAMain:home:inside:Humidex", expire="60m" }
Number:Temperature Netatmo_Indoor_HeatIndex           "HeatIndex [%.1f %unit%]"            <temperature_hot>  { channel = "netatmo:NAMain:home:inside:HeatIndex", expire="60m" }
Number:Temperature Netatmo_Indoor_Dewpoint            "Dewpoint [%.1f %unit%]"             <temperature_cold> { channel = "netatmo:NAMain:home:inside:Dewpoint", expire="60m" }
Number:Temperature Netatmo_Indoor_DewpointDepression  "DewpointDepression [%.1f %unit%]"   <temperature_cold> { channel = "netatmo:NAMain:home:inside:DewpointDepression", expire="60m" }

Number:Dimensionless Netatmo_Indoor_Co2                 "Co2 [%d %unit%]"                 <carbondioxide>    { channel = "netatmo:NAMain:home:inside:Co2", expire="60m" }

Фактически это именно железки которые именно то и делают что меряют "климат" кабинета

Далее описываются простые правила которые связывают элементы первого списка со вторым, одно из правил:

rule "GF_Office_Temperature update"
when
    Item Netatmo_Indoor_Temperature received update
    or
    System started
then
    if (Netatmo_Indoor_Temperature.state != UNDEF) {
        if (Netatmo_Indoor_Temperature.state != NULL) {
        GF_Office_Temperature.postUpdate(Netatmo_Indoor_Temperature.state as QuantityType<Temperature>)
        } else {
            GF_Office_Temperature.postUpdate(UNDEF);
        }
    } else {
        GF_Office_Temperature.postUpdate(UNDEF);
    }
end

Суть правила, если состояние "железной железки" изменилось то меняем состояние виртуальной, также для железок которые предусматривают упралвение делаем второе правило "если нажали на виртуальную то эмулируем нажатие на железную".

Чем прекрасен этот подход:

1. Вы пишите основную бизнес логику по виртуальнолму железу, "Если влажность в кабинете упала до ... включаем увлажнитель в кабинете". Логика полностью абстрагирована от железа

2. Железо имеет свойство ломаться, обновляться - у вас поломался увлажнитель, вы купили другой - перебросили за 5 минут прокси логику на новую железку, основная логика (которой всегда много и она сложная) осталась неизменной а значит продолжает работать

3. Персистентный слой хранения настроен только для виртуальных устройств, вы поменяли железку а статистика в графане у вас продолжается как будто ничего не случилось

4. Вы можете планировать архитектуру наперед, при этом оставив реализацию до того момента когда у вас появится настоящая железка.

5. Семантическая модель опенхаба гараздо логичнее и прозрачнее натягивается на прокси чем на настоящее железо, где разработчики бондинга могли что-то сделать на свое усмотрение

6. У вас во всем доме "оборудование" получается однотипным, например все диммеры света 0..100 несмотря на то что у одних железок это 0-100, у других 0-128 а у третих 1-5. Пересчет а адаптация выполняется в прокси-слое логики.

7. При добавлении "железных железок" вы можете прямо копировать из мануала, вам нет необходимости "адаптировать" имена или группы под ваш конкретный дом.

Единственный минус этого подхода - чуть больше работы в самый первый раз.

Повторюсь, если вы серьезно хотите играть в автоматизацию с опенхабом изучите и осознайте этот паттерн, также есть смысл посмотреть другие паттерны (community.openhab.org/tag/designpattern), там много полезного, пусть и не на столько.

 

Змінено 17 грудня 2021 користувачем standov

[standov]

Соглашение по именованию и структура дома

Openhab предусматривает добавление элементов двумя разными способами - чисто визуальный в интерфейсе и через файлы конфигурации.

Я ярый сторонник второго способа, причины следующие:
1. Вы всегда имеете перед глазами все "дерево"
2. Файлы конфигурации очень легко дополнительно "бекапить", я просто весь проект держу в гитхабе, и сразу имею историю изменений
3. При использовании файловых конфигураций их можно редактировать в почти нормальной IDE Visual Studio Code

Файлы конфигурации хранятся на сервере openhab и для их редактирования к ним нужно иметь удобный доступ. Слава богу ребята - разработчики о нас позаботились. Если openhab устанавливался через утилиту openhabian (а это предпочтительный способ) то для доступа ко всем файлам, которые предусматривают изменение, поднимается samba сервер и они становятся расшаренными в windows-сети.

Для редактирования файлов, естественно, можно использовать любой любимый текстовый редактор, но для Microsoft Visual Studio Code в его маркете существует openhab плагин, который считается основным для опенхаба и вы с его помощью получаете подсветку синтаксиса и пару плюшек.

Для среднестатистического дома в порядке вещей иметь несколько сотен элементов в опенхабе, в сообществе натыкался на тему где ребята меряются размерами, и там были и тысячи.
При использовании паттерна Proxy item (ранее рассказал почему вы *должны хотеть* его использовать) количество элементов будет еще больше.
Очень много смысла до старта "умного дома", на берегу,  определиться со структурой чтобы потом было с этим удобнее жить.

У опенхаба есть специальный тип элемента "группа", это некий контейнер который позволяет элементы дома выстроить в древовидную структуру по иерархии (Дом - Этаж - Комната - Зона - Устройство и тд)
Второе удобное применение групп - функциональное(горизонтальное, не иерархическое) объединение элементов из разных иерархических групп (Свет, Температура Помещений, Климат и тп)

В документации на опенхаб фигурирует такой пример, который очень похож на то что я пытаюсь рассказать:

Как такового соглашения по наименоваю openhab не навязывает, но есть некий общеустоявшийся с моими личными доработками:

1. Группы первого типа а также все-все элементы в них я решил именовать с использованим комбинации snake_case+CamelCase, часть snake_case указывает на иерархию, CamelCase на элемент внутри. Например GF_Office_SetpointTemperature = термостат(SetpointTemperature) в кабинете(Office) на первом этаже(GF=GroundFloor)
2. Имя элемента и группы включает в себя имя элемента с верхнего элемента ирерархии (пример выше)
3. Горизонтальные, не иерархические группы я именую в CamelCase нотации с прификсом g (gHVAC - климат, gLight - свет, gSetpointTemperature - термостаты)

Структура самого дерева и его элементов несколько раз переосмысливалась, и в последней итерации (по факту оказавшейся очень удобной) выглядит следующим образом:

main.items

Group  Main "Ворзель" <home> ["Location"]
  Group Home "Будівля" <home> (Main) ["House"]
    Group Home_GroundFloor "Перший поверх" <groundfloor> (Home) ["GroundFloor"]
       //... кімнати 1го поверху
    Group Home_FirstFloor "Другий поверх" <firstfloor> (Home) ["FirstFloor"]
       //... кімнати 2го поверху
    Group Home_Attic "Горище" <attic> (Home) ["Attic"]
    Group Home_Corridor "Коридор" <corridor> (Home) ["Corridor"]
    Group Home_BoilerRoom  "Бойлерна" <gas> (Home) ["Room"]
  Group Outdoor "Ззовні" <home> (Main) ["Outdoor"]
    Group OU_Parking "Паркування" <home_parking> (Outdoor) ["Carport"]
      Group OU_Parking_Camera "Камера паркінгу" <cctv> (OU_Parking) ["Camera"]
        ...

При этом элементы мелких групп уже организованы по одноименным файлам, например GF_Office_HVAC.items

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

Поскольку я использую шаблон Proxy item то есть также необходимость организации айтемов "железных железок". Я для себя выработал такую схему

1. элементы железок хранятся в отдельных файлах (отдельно sonoff, отдельно shelly, отдельно netatmo и тп)
2. имена файлов "железок" начинаются с "_" ("_netatmo.items"). Это позволило визуально в дереве файлов в IDE их все выделить в группу
3. айтемы железок именуются в snake_case, только по железке и никак не привязаны к иерархии дома (Netatmo_Indoor_Humidex - "влажность внутреннего датчика Netatmo")
4. прокси-правила для связи виртуальных и реальных железок в отдельных файлах в формате "_[группа].rules" ("_GF_Office_HVAC.rules")
5. основная бизнес-логика в файлах rules уже по смыслу ("alarm.rules", "status.rules", "ventilation.rules")

Persistence

Как писал выше, слой исторического хранения данных в случае с паттерном Proxy item, позволяет организовать хранение только для виртуального оборудования.
Как выглядит конфигурация хранения в моем доме

Strategies {
    everyMinute   : "0 * * * * ?"
    every5Minutes : "0 */5 * * * ?"
    everyHour     : "0 0 * * * ?"
    everyDay      : "0 0 0 * * ?"

    default = everyMinute
}

Items {
    Main* : strategy = everyChange, everyMinute, restoreOnStartup
    gLog*: strategy = everyChange
}

Тут написано следующее:

1. Все элементы группы Main, в моем доме это самая-самая верхняя группа в иерархии виртуальных элементов, хранят в influx ежеминутное значение и значение при изменении, также восстанавливают свое последнее значение при перезапуска опенхаба
2. Элементы горизонтальной группы gLog просто хранят каждое изменение. Это очень удобный лайфхак который позволяет нужной вам настоящей железке присвоить горизонтальную группу и посмотреть потом в графане что с ней просиходит без необходимости заводить виртуальный полноценный элемент.
3. Все остальные (фактически железные железки) не хранят изменение

Полезное

Обратите пристальное внимание на такую новую функциональность в опенхабе как семантическая модель (www.openhab.org/docs/tutorial/model.html#semantic-model) - это очень легкий способ, с помощью специальных меток-тегов подсказать движку опенхаба что делаюь те или иные элементы, после чего сам опенхаб сделает универсальный развернутый интерфейс, где будет пусть и не самым удобным способом но возможность посомтреть все-все про ваш дом:

Змінено 17 грудня 2021 користувачем standov

[standov]

Вроде с теоретической подготовкой я все что хотел - написал. Получилось возможно нудновато но это было нужно, как минимум для того что-бы каждый раз не рассказывать почему что-то делается/офрмлено именно так. Дальше больше практики и конкретики

[standov]

Связь с внешним миром, уведомления.

Интерфейс опенхаба должен быть доступен мне как дома так и где-то вне моей домашней сети. Опенхаб предлагает 2 решения - либо классический проброс портов если у вас есть статистический IP (или DDNS) либо подключить ваш личный опенхаб к публичному бесплатному облаку (www.myopenhab.org/). Теоретически есть еще третий вариант - исходный код облака myopenHAB открытый и есть возможность его поднять на каком-то внешнем хосте (амазон, диджиталоушен и тп).

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

Я пробовал все три варианта (и пожил с каждым пару месяцев) и есть что сказать:
1. проброс портов. Сам опенхаб работает без авторизации, авторизация только на администрирование и то только с 3й версии, что автоматом означает что кроме проброса портов нужно еще городить какое-то nginx проксирование с HTTP-авторизацией, приложение HTTP авторизацию умеет но это лишняя работа. НО самый главный минус такого решения - у вас в приложении не будут работать пуш-уведомления а также интерграция с внешними сервисами (IFTTT, Amazon Alexa, Google Assistant)

2. Облако myopenHAB - у вас появляется автоматом пуш-уведомления, авторизация и интерграция с IFTTT, Amazon Alexa, Google Assistant. НО облако это облако, оно не у вас, народу там много - стабильность под вопросом.

3. Поднять личное облако myopenHAB на хостинге. У меня получилось, это даже работало, также завелись пуши НО не Google Assistant. Также это стоит пусть и копейку но денег. А самое главное там инструкция на пару вечеров, местами абсолютно загадочная и второй раз я это повторять не решусь.

В конечном итоге я остановился на втором варианте, облако оказалось не таким уж падучим + я решил подстраховаться, а именно поднял на домашней сети впн (так вроде ниразу и не использовал) и настроил в опенхабе уведомления в телеграм.

Как настраивать myopenHAB и телеграм-уведомления все разжевано в документации, я просто расскажу как я с ними работаю из сценариев.

Group           Main                         "Ворзель"               <home> ["Location"]
    String Main_NotifyMessage  "Останне повідомлення" (Main) ["Status", "Level"]
    DateTime Main_NotifyTime  "Час останнього повідомлення" (Main) ["Measurement", "Timestamp"]

и правило:

rule "Dispatch Notification"
when
    Item Main_NotifyMessage received command
then
    logInfo("alert", receivedCommand.toString)
    Main_NotifyTime.postUpdate(new DateTimeType()) // defaults to now

    val mailActions = getActions("mail","mail:smtp:main")
    val telegramAction = getActions("telegram","telegram:telegramBot:#####")

    telegramAction.sendTelegram("Будинок: " + receivedCommand.toString)
    mailActions.sendMail("####@####.###", "Будинок", receivedCommand.toString)
    
    sendBroadcastNotification(receivedCommand.toString, "error", "alert")
    
end

Далее в любом правиле основной бизнес-логики мне достаточно виртуальному устройству Main_NotifyMessage отправить команду и она улетит в приложение/телеграм и почту

Main_NotifyMessage.sendCommand("Схоже що в будику вже декілька хвилин нікого, але сигналізація не увімкнута")

Что тут можно доработать:
 1. разделить уведомления на критические(разослать везде) и информационные(только в апу)
 2. интеграция с телеграмом позволяет сделать диалоги, что-то спросить у меня и по ответу отработать логику. Но пока до этого не дошли руки

 

 

 

Змінено 17 грудня 2021 користувачем standov

[standov]

Сигнализация

Дабы исключить заведомо подгорания сразу уточню:

1. Я не делал и не буду делать сигнализацию на коленке

2. Я не буду и никому не советую делать какие-то механизмы авто постановки/снятия и тп самопал

У меня сигнализация AJAX, достаточно давно (пожалуй примерно с начала ее существования) и все у нее неплохо, кроме одного момента - у нее нет никаких возможностей интеграции. Этот странный факт я долго обсуждал лично и суппортом и с паном Конотопским, обсуждали варианты сотрудничества в контексте "описать что нужнои зачем", вроде даже пришли к общему мнению что этот функционал ничему не угрожает, были заявления вида "я обмозгую" но в конечном итоге результата нет, и скорее всего не будет. А что же мне нужно и зачем?)

А нужно мне очень банальная вещь - поиметь событие постановки/снятия на сигнализацию.

Нужно мне это для следующего
1. Если дом поставлен на сигнализацию то это значит что в доме никого точно нет и с-но можно предпринять например действия по снижению энергопотребления, вентиляции. Включить дополнительные средства (не завязанные на сигнализацию) защиты и тп
2. Если дом снят с сигнализации то можно попробовать подсветить вечером улицу или включить "продув" вентиляции, догрев и тп событийная логика
3. Если в доме нет людей согласно каким-то другим признакам - напомнить поставить на сигнализацию. Есть такой грешок у нас - я думаю что жена поставила на пульт, жена думает что я.

Но штатно это сделать нельзя, но можно не штатно ) Я к сожалению уже схему не найду но расскажу как это можно сделать сейчас, работает уже пару лет без единого косяка. 

1. Понадобится Ajax Relay, которое добавляем в систему и прописываем сценарий аджакс, постановка на пульт - замкнули реле, сняли с пульта - разомкнули реле
2. Понадобится детектор сухого контакта который имеет какой-либо интерйфейс наружу. Я взял esp, накатил на нее прошивку ESPEasy, и заставил по событию на пине отправлять в mqtt пакет "замкнуто/разомкнуто"

По факту у меня схема несколько сложнее, потому как тогда слаботочного варианта Ajax Relay еще не существовало, а было только управляемое 220 реле, где не сухой контакт а 220 на выходе, пришлось городить схему детектора нуля на оптронах. Но сейчас в этом уэе нет смысла, проще взять Ajax Relay

"железные" айтемы

Тут дополнительно ESPEasy отправляет мне свою температуру, поскольку они вместе с Ajax Relay в общем герметичном боксе, это выглядит логично.

Contact  Ajax_Relay_1_STATE  {channel="mqtt:topic:main:Ajax_Relay_1:contact", expire="5m"}
Number:Temperature  Ajax_Relay_1_TEMP "Температура [%.1f %unit%]" {channel="mqtt:topic:main:Ajax_Relay_1:temp", expire="5m"}

"виртуальные"

Contact Equipment_Secure_AlarmState "Сигналізація [MAP(uk.map):%s]"   <myalarm> (Main, gEquipmentSecure) ["Status"]
Contact Home_ModeAway  "Поза домом [MAP(uk.map):%s]"                  <ecohouse> (Main, gStatus) ["Status"]

Логика проксирования

rule "Ajax_Relay_1_STATE update"
when
    Item Ajax_Relay_1_STATE received update
    or System started
then
    if (Ajax_Relay_1_STATE.state === OPEN) {
        Equipment_Secure_AlarmState.postUpdate(CLOSED)
    } else if (Ajax_Relay_1_STATE.state === CLOSED) {
        Equipment_Secure_AlarmState.postUpdate(OPEN)
    } else {
        Equipment_Secure_AlarmState.postUpdate(UNDEF)
    }
end

"Бизнес логика"

rule "Home_ModeAway update"
when
    System started
    or Item Equipment_Secure_AlarmState received update
    or Time cron "* 0/1 * * * ?"
then
    Home_ModeAway.postUpdate(Equipment_Secure_AlarmState.state)
end

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

Важный нюанс

На практике оказалось что может возникнуть ситуация когда вы ставите дом на охрану но у вас нет света, аджакс эту ситуацию отработает поскольку у него есть АКБ встроенный но вы про это не узнаете когда появится свет, потому детектор сухого контакта, который отправляет состояние должен его регулярно повторять, благо в ESPEasy можно просто настроить регулярную отправку состояния пина а не только при изменении.

Итого, по результатам этой интеграции у меня в доме есть виртуальный контакт который хранит состояние "AWAY", что я буду использовать дальше. При єтом сигнализация работает в штатном режиме, ничего нигде не нарушено и все так-же надежно.

 

Змінено 17 грудня 2021 користувачем standov

[standov]

Интернет и безопасность

Есть такое расхожее мнение что «Буква S в аббревиатуре IoT обозначает Security»(с). Было понимание что нужно что-то сделать с этим в меру сил, как минимум отделить безопасную сеть от потенциально не безопасной, куда будут ходить всякие непонятные китайские и не только железки, с хз какими китайскими бекдорами на борту. Интернет организован на оборудовании американцев Ubiquiti, конкретно на их распределенной инфраструктуре Unifi.

Что сделано:

1. Выделена подсеть-песочница на базе VLAN конкретно под IOT
2. Заведена специальная wifi-сеть конкретно под IOT с отдельным SSID, естественно под VLAN выше.
3. IOT Сеть приклеена к одной только вайфай-точке, на этой точке выключена 5ггц и включены разные legacy-опции для работы медленных клиентов.
4. В этой сети ограничена скорость, ну просто на всякий случай
5. Все контейнеры служебные в proxmox (mqtt, influx) перемещены эту сеть
6. В контейнере openhab настроено два сетевых интерфейса, один смотрит в сеть IOT второй в основную
7. Сделана третья сеть "гостевая", там вообще только доступ в интернет, от нее даю пароли гостям )

В основной сети остались рабочие ПК, личные ноутбуки, наши с женой телефоны, телевизоры.

Под Ubiquiti Unifi у опенхаба есть интеграция, там много всяких забавных возможностей, но я пока использую одну. Он позволяет получать статус подключения к вайфаю клиентов по маку. Зачем это нужно мне:

Switch  Unifi_Controller_Honor10_Online   <presence>     ["Online"]   {channel="unifi:wirelessClient:home:honor_10:online", expire="3m"}
DateTime Unifi_Controller_Honor10_OnlineTime {channel="unifi:wirelessClient:home:honor_10:lastSeen"}

Switch  Unifi_Controller_HSmart_Online    <presence>     ["Online"]   {channel="unifi:wirelessClient:home:huawei_smart:online", expire="3m"}
DateTime Unifi_Controller_HSmart_OnlineTime  {channel="unifi:wirelessClient:home:huawei_smart:lastSeen"}

Это мой телефон и телефон жены, я делаю допущение что если телефон не подключен к вайфаю то есть предположение что он не дома.

Group:Contact:OR(OPEN, CLOSED) Home_ModePresence  "Мешканці вдома [MAP(uk.map):%s]" <presence> (Main, gStatus) ["Status"]
  Group People_Stas "Стас" <people> (Main) ["Equipment"]
    Contact People_StasPresence  "Стас вдома [MAP(uk.map):%s]" <presence> (People_Stas, Home_ModePresence) ["Status", "Presence"]
    //Location        People_StasLocation             "Розташування Стаса"                   <movecontrol> (People_Stas) ["Status"]

  Group People_Ira "Іра" <people> (Main) ["Equipment"]
    Contact People_IraPresence "Іра вдома [MAP(uk.map):%s]" <presence> (People_Ira, Home_ModePresence) ["Status", "Presence"]

Тут щепотка магии опенхаб, специальная группа Home_ModePresence оформлена виртуальным контактом который "замкнут" если замкнут хоть один из его наследников (в данном случае "контакты" пристутствия меня или жены)

Прокси правила

rule "People_StasPresence update"
when
    Item Unifi_Controller_Honor10_Online received update
    or
    System started
then 
    if (Unifi_Controller_Honor10_Online.state == ON) {
        People_StasPresence.postUpdate(OPEN)
    } else if (Unifi_Controller_Honor10_Online.state == OFF) {
        People_StasPresence.postUpdate(CLOSED)
    } else {
        People_StasPresence.postUpdate(UNDEF)
    }
end


rule "People_IraPresence update"
when
    Item Unifi_Controller_HSmart_Online received update
    or
    System started
then 
    if (Unifi_Controller_HSmart_Online.state == ON) {
        People_IraPresence.postUpdate(OPEN)
    } else if (Unifi_Controller_HSmart_Online.state == OFF) {
        People_IraPresence.postUpdate(CLOSED)
    } else {
        People_IraPresence.postUpdate(UNDEF)
    }
end

А теперь "магия"

var Timer offlineNotificationTimer = null

rule "People offline"
when
    Item Home_ModePresence changed to CLOSED // оба жителя стали "оффлайн"
    or Item Home_ModeAway changed // или изменился статус охраны дома
    or System started
then
    
    if (Home_ModeAway.state == OPEN || Home_ModePresence.state == OPEN) {
        // если кто-то вдруг "вернулся" то сбрасываем таймер
        offlineNotificationTimer = null
        return;
    }

    if (offlineNotificationTimer === null || offlineNotificationTimer.hasTerminated()) {
        // делаем таймер "через 5 минут отправить уедомление что дом не под охраной"
        offlineNotificationTimer = createTimer(now.plusMinutes(5), [ |
            if (Home_ModeAway.state == CLOSED && Home_ModePresence.state == CLOSED) {
                Main_NotifyMessage.sendCommand("Схоже що в будику вже декілька хвилин нікого, але сигналізація не увімкнута")
            }
            offlineNotificationTimer = null
        ])
    } else {
        // если что-то поменялось то пролонгируем таймер на еще 5 минут
        offlineNotificationTimer.reschedule(now.plusMinutes(5))
    }
end

rule "People offline recover"
when
    Time cron "0 0/5 * * * ?"
then
    // раз в пять минут перепроверяем не вернулся ли кто домой и сбрасываем таймер уведомления
    if (Home_ModeAway.state == OPEN || Home_ModePresence.state == OPEN) {
        offlineNotificationTimer = null
        return;
    }
end

Почему так сложно и зачем понадобился таймер и 5 минут задержка - вайфай вокруг дома работает не очень (я добавлю со временем аутдор точк unifi но пока ее нет) и регулярно возникали ситуации когда мы находимся возле дома и телефоны то соединяются с вайфаем то отваливаются, это вызывало ложные срабатывания уведомления. Опытным путем установлено что задержка 5 минут, на протяжении которой ничего не должно поменяться, это как раз то что нужно. Это позволяет надежно уйти от вайфая но не достаточно далеко что0бы дом не стоял без охраны слишком долго.

 

Змінено 17 грудня 2021 користувачем standov

[k-master]

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

Итого, для комфортного взлета вам нужно 4 пакета - openhab, influx, grafana, mosquitto. 
Все указанные пакеты на столько "родные" для опенхаба что опенхабовцы разработали специальную утилиту для пакетной установки в режиме мастера всех сразу - www.openhab.org/docs/installation/openhabian.html

Все 4 пакета работают в тч на малине и очень много людей так и использует опенхаб, поставили все на малину и погнали, НО производительности малины не достаточно например для большого потока данных в influx или при просмотре потом данных в графане, да и в целом малина решение ограниченное и решил не идти по этому пути.

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

Я на ебее за очень недорого (порядка 80 баксов по памяти) приобрел микро ПК HP EliteDesk 800 G1 Desktop Mini, в конфигурации intel i3-4030U/8G. Это коробочка очень миниатюрных размеров с внешним БП, которая при этом является брендовым (а значит в теории более надежным) полноценным ПК. Они бывают в разных конфигурациях но вот я нашел именно такой из соображений "до 100 баксов но живой и на приличном процессоре". На него ставится любая ось, начиная от винды 10 и заканчивая любым линуксом.
 

Ставимо у цей комп 2 вінта, на нього Truenas та маємо локальний сторадж та систему де у «віртуалках» можна все підняти. Truenas все буде бекапити. 

17.12.2021 в 16:56, standov сказав:

Связь с внешним миром, уведомления.

Интерфейс опенхаба должен быть доступен мне как дома так и где-то вне моей домашней сети. Опенхаб предлагает 2 решения - либо классический проброс портов если у вас есть статистический IP (или DDNS) либо подключить ваш личный опенхаб к публичному бесплатному облаку (www.myopenhab.org/). Теоретически есть еще третий вариант - исходный код облака myopenHAB открытый и есть возможность его поднять на каком-то внешнем хосте (амазон, диджиталоушен и тп).

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

Я пробовал все три варианта (и пожил с каждым пару месяцев) и есть что сказать:
1. проброс портов. Сам опенхаб работает без авторизации, авторизация только на администрирование и то только с 3й версии, что автоматом означает что кроме проброса портов нужно еще городить какое-то nginx проксирование с HTTP-авторизацией, приложение HTTP авторизацию умеет но это лишняя работа. НО самый главный минус такого решения - у вас в приложении не будут работать пуш-уведомления а также интерграция с внешними сервисами (IFTTT, Amazon Alexa, Google Assistant)

2. Облако myopenHAB - у вас появляется автоматом пуш-уведомления, авторизация и интерграция с IFTTT, Amazon Alexa, Google Assistant. НО облако это облако, оно не у вас, народу там много - стабильность под вопросом.

3. Поднять личное облако myopenHAB на хостинге. У меня получилось, это даже работало, также завелись пуши НО не Google Assistant. Также это стоит пусть и копейку но денег. А самое главное там инструкция на пару вечеров, местами абсолютно загадочная и второй раз я это повторять не решусь.

Варіант номер 4, якщо є білий айпі, навіть динамічний - підіймаємо впн, та с телефона працюємо як влома без хмар.

[standov]

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

Ставимо у цей комп 2 вінта, на нього Truenas та маємо локальний сторадж та систему де у «віртуалках» можна все підняти. Truenas все буде бекапити

1. виртуалки это не контейнеры, вернее контейнеры это не виртуалки

2. есть 100500 способов сделать по другому, тут тема про мой личный. Виртуалки в трунасе я прошел лет 10 назад, на 5-10 ресурсы заканчиваются, оверхед все-же избыточен, поднимать на lxc на фре..ну я не на столько смелый и умелый

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

підіймаємо впн, та с телефона працюємо як влома без хмар

1. про впн есть в тексте

2. гугл ассистента не будет

3. пушей не будет

4. поднимать впн клиента на телефоне только для опенхаба, ну я слишком ленивый )

Змінено 18 грудня 2021 користувачем standov

[standov]

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

Ставимо у цей комп 2 вінта

на двух винтах это в смысле зеркало? софтовый? я очень сомневаюсь что это хорошая идея. А без зеркала вылет диска ровно так-же утягивает ваш сервер в Вальгаллу 

[k-master]

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

на двух винтах это в смысле зеркало? софтовый? я очень сомневаюсь что это хорошая идея. А без зеркала вылет диска ровно так-же утягивает ваш сервер в Вальгаллу 

Так, 2 вінта у дзеркало. Гарна чи не гарна, але хардварний рейд це такий самий рейд з процесором та софтом. Якщо рейд хардварний, то там батарейка обов'язково повинна бути. Багато таких контролерів для дому? TrueNAS з софтовим рейдом достатньо для дому. Якщо з компом щось станеться, то можна на цей випадок тримати поруч запасний, але ймовірність цього дуже мала. 
Якщо є бажання зробити так, щоб домашня автоматизація не зламалась, то треба зробити так, щоб основні функції працювали без опенхаба. Ну наприклад вимикач світла повинен давати команду на лампочку при зміні стану незалежно від опенхаба, тоді якщо щось станеться то світлом керувати можна буде, що дасть можливість продовжити користуватись будинком.

[standov]

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

Так, 2 вінта у дзеркало. Гарна чи не гарна, але хардварний рейд це такий самий рейд з процесором та софтом. Якщо рейд хардварний, то там батарейка обов'язково повинна бути. Багато таких контролерів для дому? TrueNAS з софтовим рейдом достатньо для дому. Якщо з компом щось станеться, то можна на цей випадок тримати поруч запасний, але ймовірність цього дуже мала. 
Якщо є бажання зробити так, щоб домашня автоматизація не зламалась, то треба зробити так, щоб основні функції працювали без опенхаба. Ну наприклад вимикач світла повинен давати команду на лампочку при зміні стану незалежно від опенхаба, тоді якщо щось станеться то світлом керувати можна буде, що дасть можливість продовжити користуватись будинком.

Вы видимо эту тему читали не сначала да?)

Софтовый рейд по моему личному "рабочему" опыту больше источник проблем чем решений, домой я это тащить точно не хочу, считаю решение с проксмокс кластером надёжнее, гибче, очевиднее и в общем-то не особо дороже, особенно если файлопомойка уже есть. 

[k-master]

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

Вы видимо эту тему читали не сначала да?)

Софтовый рейд по моему личному "рабочему" опыту больше источник проблем чем решений, домой я это тащить точно не хочу, считаю решение с проксмокс кластером надёжнее, гибче, очевиднее и в общем-то не особо дороже, особенно если файлопомойка уже есть. 

просто в мене опенхаб на трунас з софтовим рейдом працює вже другий рік і щось ніяких проблем немає. І разом з опенхабом там influxdb, mysql, transmission та ще кілька тестових контейнерів. Прийде людина подивитись що таке опенхаб, побачить що для нього треба кластер та забуде про нього. 

[standov]

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

і щось ніяких проблем немає

типичная ошибка выжившего, нет проблем и отично, но если вдруг то сразу станет и не так, у меня таже работало пару лет а потом перестало и сразу стало не так. Тут как в бекапами где "есть те кто еще не делает бэкапы, те, кто уже делает бэкапы".

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

Прийде людина подивитись що таке опенхаб, побачить що для нього треба кластер та забуде про нього. 

а надеюсь что все-же человек прочитает не так как вы, по диагонали, я же максимально подробно пояснил что где почему и зачем, и то что так как у меня это совершенно не обязательно делать всем

[uafisher]

В 17.12.2021 в 21:15, standov сказал:

отделить безопасную сеть от потенциально не безопасной, куда будут ходить всякие непонятные китайские и не только железки, с хз какими китайскими бекдорами на борту

 

В 17.12.2021 в 21:15, standov сказал:

"unifi:wirelessClient:home:honor_10:lastSeen"}

Switch  Unifi_Controller_HSmart_Online    <presence>     ["Online"]   {channel="unifi:wirelessClient:home:huawei_smart:online", expire="3m"}
DateTime Unifi_Controller_HSmart_OnlineTime  {channel="unifi:wirelessClient:home:huawei_smart:lastSeen"}

А Хонор и Хуавей не непонятные китайские железки, с китайскими бэкдорами?)
Или под угрозой считаются только нонейм устройства?
Ибо по поводу бэкдоров у Хуаевей (читай + Хонор) история тянется достаточно давно..

[uafisher]

В 17.12.2021 в 20:12, standov сказал:

А нужно мне очень банальная вещь - поиметь событие постановки/снятия на сигнализацию.

Нужно мне это для следующего
1. Если дом поставлен на сигнализацию то это значит что в доме никого точно нет и с-но можно предпринять например действия по снижению энергопотребления, вентиляции. Включить дополнительные средства (не завязанные на сигнализацию) защиты и тп
2. Если дом снят с сигнализации то можно попробовать подсветить вечером улицу или включить "продув" вентиляции, догрев и тп событийная логика
3. Если в доме нет людей согласно каким-то другим признакам - напомнить поставить на сигнализацию. Есть такой грешок у нас - я думаю что жена поставила на пульт, жена думает что я.

Тема очень интересная. 
Но что интересно -покупка Айфона и Яблотрона решает эти три вопроса (последний относительно) и всё это в красивой упаковке. И без бэкдоров.
Правда "зуд рук" и пытливый ум эт конечно не остановит я в хорошем смысле)

[standov]

7 минут назад, uafisher сказал:

А Хонор и Хуавей не непонятные китайские железки, с китайскими бэкдорами?)
Или под угрозой считаются только нонейм устройства?

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

Змінено 19 грудня 2021 користувачем standov

[standov]

1 минуту назад, uafisher сказал:

Тема очень интересная. 
Но что интересно -покупка Айфона и Яблотрона решает эти три вопроса (последний относительно) и всё это в красивой упаковке. И без бэкдоров.
Правда "зуд рук" и пытливый ум эт конечно не остановит я в хорошем смысле)

яблотрон да, но аджакс у меня появился сильно раньше задачи, работал с тем что есть, про айфон понял не очень

[uafisher]

Только что, standov сказал:

 Другими словами я не сильно переживаю про бекдоры китайского правительства но очень переживаю про кривые штуки которые может заюзать кто угодно

Ок, я предполагал такой ответ). Частично полностью поддерживаю, но предположу, что широко известные в узких кругах траблы Хуавей - думаю легко могут эксплуатироваться и не китайским и не правительством)

[standov]

1 минуту назад, uafisher сказал:

Ок, я предполагал такой ответ). Частично полностью поддерживаю, но предположу, что широко известные в узких кругах траблы Хуавей - думаю легко могут эксплуатироваться и не китайским и не правительством)

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