Комментарии 62
Какое-то костыльно-велосипедное строительство. На днях настроил на OrangePi PC Home assistant — интеграция с Алисой (через HACS) и Гугл — из коробки. Esp8266 прошиты Tasmota — тоже из коробки есть в HA. Камеры от регистратора HiWatch — даже выбор был — через onvif или тупо rtsp. Выбрал последнее. Даже смарт события от регистратора — из коробки. Даже ИБП подтянул через NUT. Попробуйте HA — вам понравится.
Я, как раз, с нод-ред мигрировал на ha. И, как раз, стабильности node-red не хватает. Для него тоже висел в кроне таск на запуск сервиса. Причём виновата была интеграция с Алисой — она эпизодически поняла всю году. А уж отсутвие необходимости изобретать свои велосипеды под всё что есть у меня — прям вообще обрадовало. Но, в целом, если нужна гибкость — то да, года позволяет вообще всё.
У HA есть модуль node-red.
Кстати да, пробовал Domoticz, OpenHab в итоге остановился на Home Assistant
- Наколхозить какую-нибудь примочку их готовых "кубиков", совершенно не задумываясь о безопасности (ни отдельных "кубиков", ни примочки в целом), и порадоваться, как по команде моргают лампочки в доме.
- Сильно удивиться, когда примочка окажется взломанной "рюцкими хацкерами", и лампочки начнут моргать уже по их команде.
- ???
- PROFIT!!!
Недаром говорят — "in IoT, S stands for Security".
Sonoff Mini у меня в тасмоту прошитые уже с год работают без проблем. И пара собственных сборок на esp8266. Вот ещё никак на esp32 не соберу — тоже ждут своей участи.
А в чём плюс прошивки? У моих sonoff basic с 3 прошивкой появился lan доступ, с ним может работать HA. Пока думаю, а нужно-ли прошивать.
Ну, не считая того, что меня вообще не волнует доступность и работа Китайского облака ( в т.ч. при добавлении нового устройства в сеть) — я шил до появления lan на официальной. И у меня не только sonoff, есть и пара собственных ковыряний на esp. С Tasmota — всё единообразно, подключать-обслуживать проще — всё через одну интеграцию. Но, да, через HACS в HA можно добавить поддержку официальной прошивки Sonoff с lan-доступом и облаком и не напрягаться.
Всегда возникает вопрос: если отключилось электричество, потом снова появляется, то что будет с системой, включится ли она повторно без вмешательства человека?
Зависит, конечно, от конкретного решения. Вот моё старое решение на node-red, запущенной на роутере, после некоторого допиливания напильником вполне себе само запускалось и всё приводило в рабочий вид само. Новое решение на HA — даже без допиливания пока само стартует нормально.
Если для умной розетки и лампочки это допустимо, то всевозможные датчики, пульты- выключатели с проводным питанием как то не комильфо.
Или BLE
Это как раз то, что я хочу сделать сейчас :) А какие варианты лучше? Zigbee выключатеь и zigbee реле?
Zigbee тоже нравится, но пока свои устройства только проектирую, а работаю с готовыми от Xiaomi
Сервер у меня на MajorDoMo. HA пробовал, но не смог решить проблему, что он ронял Mysensors Gatway по непонятным причинам
Ну, к слову, у esp есть режим сна, и, при желании, в виде датчика с батарейкой, люди вполне добивались от esp автономии больше года. Но, на мой взгляд, wi-fi, всё же, плохо подходит для датчиков в системах умного дома. Для этих целей лучше z-wave, zigbee, bluetooth ble наконец. И вот все датчики пусть там и сидят, а к wi-fi уже их всех скопом подключает один шлюз. Причём, при желании, для zigbee и ble для этой задачи достаточно esp32 с модулем для zigbee и прошитую tasmota. Ну, или, если уж совсем лень, те же свистки с BT, zigbee и z-wave, обычно, вполне можно подключить к тому устройству, на котором работает ваш сервер "автоматизации".
Zigbee, BLE и Co хороши, но гонять управление через шлюз — тоже так себе решение. И медленно и ненадежно. В Zigbee сети ESP явно лишний )))
По BLE кстати, хорошего готового решения не нашел. Да и в ESP32 как шлюзе разочаровался. Там один радиотракт на WiFi и BLE, поэтому как шлюз BLE/MQTT он нормально не сможет работать. Хотя модуль очень мощный и не такой глючный как ESP8266.
Домотиксз работает гораздо медленнее homeassistant, менее удобный в настройке, поддерживает гораздо меньше различных систем и в принципе умирает.
Говорю про своему опыту т.к. пришлось переезжать с него на ha
В процессе эксплуатации я заметил, что Domoticz иногда падает с ошибкой. Чтобы поднимать его автоматически, напишу watchdog с помощью cron.
Но зачем такие костыли? Если прочитать, да хотя-бы ровно один ман (man systemd.service), то выяснится, что минимум одной строчкой в юните можно обеспечить автоматический перезапуск сервиса. Кстати, как я понимаю, domoticz свои штатным инсталлятором не создаёт *.service файл, хотя распбиан или как он там сейчас зовётся — вполне systemd-like система. Короче вот. Юнит из AUR (manjaro / arch). Если нужно, пути / User / Group / порты поправьте под свою конфигурацию.
[Unit]
Description=Domoticz Daemon
After=network.target
[Service]
User=http
Group=http
PermissionsStartOnly=true
ExecStartPre=/usr/bin/install -d -m 0700 -o http -g http /var/run/domoticz
ExecStart=/opt/domoticz/domoticz -www 8080 -pidfile /var/run/domoticz/domoticz.pid
PIDFile=/var/run/domoticz/domoticz.pid
WorkingDirectory=/opt/domoticz
RestartSec=5
Restart=on-failure
[Install]
WantedBy=multi-user.target
Останавливаете domoticz и свой демон-наблюдатель. Кладёте сожержимое в /etc/systemd/system/domoticz.service, убираете штатный скрипт из rc.d, Запускаете
sudo systemctl enable --now domoticz
Если падает — это ненормально. Интересно, проверял ли кто-то исходники pvs studio хотя бы.
Её лучше удалить, и отредачить ExecStartPre=:
ExecStartPre=+/usr/bin/install -d -m 0700 -o http -g http /var/run/domoticz
install не требуется. Всё ещё проще:
[Service]
…
RuntimeDirectory=domoticz
RuntimeDirectoryMode=0700
…И, согласно FHS 3.0, следует использовать /run вместо /var/run. Обычно /var/run это симлинк.
А если эта тулза может не записывать PID в файл, то всё ещё можно упростить, типа так:
[Service]
User=http
Group=http
ExecStart=/opt/domoticz/domoticz -www 8080
WorkingDirectory=/opt/domoticz
RestartSec=5
Restart=on-failure
Какие вы отважные. Строите системы жизнеобеспечения на базе алис, каких то непончтных прошивок, работающих через сторонние приложения или облачные сервисы.
ну, справедливости ради, все облачные сервисы и сторонние приложения — лишь дополнение к системе, которая будет оставаться управляемой до тех пор, пока работает локальная сеть
Достаточно долго занимался разработкой системы инженерного оборудования зданий. Там все свое было — все контроллеры сами делали (на STM32). Прошивки под них сами. Микроядро системы (через которое связь между контроллерами верхнего уровня и интерфейсными клиентами была) — тоже сами (этим я занимался). Протоколы обмена все свои, фактически там был один протокол, который одинаково хорошо работал что по RS485 (контроллер нижнего уровня — контроллер верхнего уровня), что по UDP (контроллер верхнего уровня — микроядро), что по TCP (микроядро — интерфейсный клиент).
Интерфейсные клиенты тоже свои. И никаких облаков.
Но там был принцип основной — все, что можно сделать на нижнем уровне, делается на нижнем уровне. Наверх только данные о событиях, сверху изменение параметров и какие-то разовые запросы или команды. Т.е. даже без связи низа с верхом все продолжает работать, пока связь не восстановят.
Ну, например, энергоэффективное управление отоплением и вентиляцией загородного дома по датчикам температуры, влажности, СО2? В возможностью удаленного мониторинга и корректировки параметров.
Там же как минимум контроль потребления электричества, сигнализация о его пропадении, управлением переключения на резервный генератор?
Т.е. нормальная автоматизация, а не просто свет по хлопку включать.
Такое лучше на плк, чтобы работало стабильнее, а для перехода на генератор при пропадании энергии есть специальные железки.
Вот как раз в процессе реализации именно такой задачи. Есть котёл на OpenTherm, есть esp8266 с прошивкой и физикой для работы с OpenTherm, теперь есть пара датчиков температуры и влажности. Осталось докупить управляемые электрозаслонки на радиаторы и можно автоматизировать. А с контролем потребления электричества и резервированием уже давно сделано...
Но еще интересна вентиляция. Если начать считать теплопотери дома, то зимой значительная часть приходится на вентиляцию (нагрев поступающего по притоку воздуха). А если считать вентиляцию по СНиП, то даже минимальная оценка (замещение всего воздуха за два часа) дает весьма существенные затраты на нагрев.
Снизить их можно только путем оптимизации по датчикам влажности и СО2. Т.е. вентилировать не по нормативу, а по реальной потребности. Но это потребует отдельной системы мониторинга состояния воздуха в помещениях и управления вентилятором (вытяжкой) как минимум, а возможно, еще и притоком (например, КИВами). Над этим не думали?
1. Реальную эффективность оценивают где-то процентов в 20.
2. Стоимость более-менее приличной модели тысяч 50.
3. Затраты на установку — тут уже не обойдешься простой схемой «приток через комнаты — вытяжка через санузел» — нужна полноценная разводка
4. В морозы от -20 и ниже многие отмечали обмерзание теплообменника и необходимость его дополнительного подогрева (еще минус в эффективность)
5. Конденсат, который надо отводить, там в любом случае будет.
6. Теплобоменник приходится периодически чистить и дезинфицировать.
В общем, решение спорное.
Есть более простые — подземный воздуховод достаточной (10-20 метров?) ниже глубины промерзания. Тоже требует разводки по притоку, но приток-вытяжка раздельные что несколько проще. Единственное — воздухозабор нужно выносить вверх, выше 1.5м от земли. Дальше воздух идет под землей где подогревается и потом уже поступает в дом с температурой выше наружной. Менее затратно, но 5-10 процентов эффективности даст.
Электрозаслонки это имеется ввиду головки?
Закупил Moes (zigbee), идут в комплекте с адаптерами под разную резьбу клапанов, из коробки есть интеграция в НА.
А почему не использовать majordomo? Он удобнее и проще в настройках, все делается через web интерфейс.
Если нужна только Алиса то можно просто ESP (можно NodeMCU) с прошивкой EasyEDA + любой MQTT + навык домовёнок Кузя.
Безумный дом