Добавлю про интерфейсы: простое правило, интерфейс нужен не для «нескольких возможных реализаций», а для абстракции без которой невозможно организовать зависимости между слоями.
Репы в слой домена, фабрика в слой апп (например если у нас сущности зависят от инфраструктуры, и описываются также интерфейсами).
Также я не вижу проблемы если сущность анемична, делайте бизнес логику в handler/command прямо в домене, какая в этом проблема?
А в чем проблема если в го у меня много файлов? Вы предлагаете решить ее запихав агрегаты, vo и сущности в один файл? Что будет там через год? Даже у вас в статье уже начинает пахнуть мясом.
Основная суть всего ддд это легко читаемый код, а особенно бизнес логика.
В массе tuya розетки/реле - говно, согласен, но, найти для мелких задач более-менее качество можно (опять же, дело в стоимости). Sonoff очень хороши за свою стоимость (я брал в районе $15).
Меттер класс, но, пока очень мало устройств + цены еще кусаются, не вижу смысла прямо сейчас переходить.
Реле стоит только у одного выключателя, остальные просто посылают импульс. Я не выносил все в щит для сохранения обратной совместимости, в любой момент можно все откатить на обычные выключатели.
Ну я и не спорю про вводной кран, конечно, его в первую очередь нужно закрывать. Я привожу пример по опыту (со стиральной машиной), где прибор может спокойно завершить фазу без подачи воды, разливая воду с бака. Объем не большой - но это вред, который так-же можно избегать отключая в момент тревоги розетку.
Это очень сильно увеличивает смету. Посчитайте - просто один двойной выключатель в комнате, с одного провода 3x1.5 от щита до комнаты, превращается в три или даже четыре таких провода. Тут тогда шину нужно тянуть. Но я планировал все для обратного отката до не умного дома.
Ну тут смотря что называть умным домом, сейчас очень многая бытовая техника уже с wifi, с помощью ha это все можно собрать в одну экосистему. Управлять этим автоматически или просто руками с дашборда - уже решать пользователю.
Вводные краны да, но есть еще ряд устройств связанных с водой которые могут доставить проблем. Например:
Стиральная машина, бывает течь в работе, из люка для порошка (избыток пены), в таком случае хорошо бы отключить саму машинку, т.к. перекрытие крана не спасает.
Аналогично с посудомоечной машиной, если течет бак, перекрыть вводной кран - пол дела, нужно остановить и сам прибор.
Течь накопительного водонагревателя, тут только уведомление, перекрывать краны нет смысла, если бак на 100 литров.
Я пытался выстроить разными способами связь (у меня похожая ситуация, только не гараж, а паркинг и кладовая). Самое надежное и безопасное решение - VPS + VPN, использую WG.
Настроить WireGuard не сложно, в интернете полно примеров, чуть сложнее будет выстроить маршруты сети между устройствами, именно в рамках безопасности.
Да, но протечка бывает (тьфу тьфу тьфу) не только у стояка, а вот решения максимально простые где я могу разместить датчики по всей квартире, это уже не совсем "простые решения".
Плюс - по опыту, датчики zigbee достаточно надежны и их легко маштабировать, я больше доверяю себе и той платформе которую я выстраиваю руками, чем простому но закрытому оборудованию.
Согласен, одного универсального решения нет. Но, мы можем среагировать и на просто уведомление - связаться с УК, они могут перекрыть полностью стояк, или в новых домах часто краны в подъезде.
Но по опыту разработки и архитектуры, я еще у берега для себя решил и создал правила как, где и что я буду называть. Какие префиксы для entity id, названия самих устройств и т.д.
Так-же все автоматизации пишу только в yaml, используя:
Нет проблемы править хендлеры/сервисы/фасады, проблема гонка данных в сущностях.
Добавлю про интерфейсы: простое правило, интерфейс нужен не для «нескольких возможных реализаций», а для абстракции без которой невозможно организовать зависимости между слоями.
Репы в слой домена, фабрика в слой апп (например если у нас сущности зависят от инфраструктуры, и описываются также интерфейсами).
Также я не вижу проблемы если сущность анемична, делайте бизнес логику в handler/command прямо в домене, какая в этом проблема?
А в чем проблема если в го у меня много файлов? Вы предлагаете решить ее запихав агрегаты, vo и сущности в один файл? Что будет там через год? Даже у вас в статье уже начинает пахнуть мясом.
Основная суть всего ддд это легко читаемый код, а особенно бизнес логика.
Да, так и сделал. Паранойю чуть убавил добавив базовый логин/пароль на уровне http + пару хитрых правил на уровне nginx
Я плачу 3 евро в месяц за VM, настроил один раз - больше не трогаю там ничего.
В массе tuya розетки/реле - говно, согласен, но, найти для мелких задач более-менее качество можно (опять же, дело в стоимости). Sonoff очень хороши за свою стоимость (я брал в районе $15).
Меттер класс, но, пока очень мало устройств + цены еще кусаются, не вижу смысла прямо сейчас переходить.
Реле стоит только у одного выключателя, остальные просто посылают импульс. Я не выносил все в щит для сохранения обратной совместимости, в любой момент можно все откатить на обычные выключатели.
Лучшее решение - это VPN, часто нужен не только http трафик, например камеры (webrtc).
Ну я и не спорю про вводной кран, конечно, его в первую очередь нужно закрывать. Я привожу пример по опыту (со стиральной машиной), где прибор может спокойно завершить фазу без подачи воды, разливая воду с бака. Объем не большой - но это вред, который так-же можно избегать отключая в момент тревоги розетку.
Это очень сильно увеличивает смету. Посчитайте - просто один двойной выключатель в комнате, с одного провода 3x1.5 от щита до комнаты, превращается в три или даже четыре таких провода. Тут тогда шину нужно тянуть. Но я планировал все для обратного отката до не умного дома.
Да, я остановился на таком варианте. Реле будет обычные zigbee с поддержкой импульсного управления. Сейчас несколько в тесте - пока проблем нет.
С выключателями звонкового типа чуть сложнее, их меньше и они сильно дороже.
Выбрали хорошие по дизайну, вставили обратные пружины с AliExpress - все работает как с завода.
Да, но сам проект электрики не раскроет особо ничего. Главные моменты которые нужно учесть в электрике:
Все подрозетники глубокие (под реле)
Все выключатели с постоянным нулем
Отдельный слаботочный щит с разводкой на каждого потребителя
Желательно отдельный щит под оборудование: роутер, mini-pc, бесперебойник
Ну тут смотря что называть умным домом, сейчас очень многая бытовая техника уже с wifi, с помощью ha это все можно собрать в одну экосистему. Управлять этим автоматически или просто руками с дашборда - уже решать пользователю.
Я могу составить список и чуть подробней расписать.
Кратко:
Стик: Sonoff ZBDongle-E, отлично работает с z2m
Реле и сокет-розетки zigbee, Sonoff или girier (дешевле)
Датчики дверей/окон zigbee moes, по опыту хорошие цена/качество, лучше Sonoff
Датчики температуры zigbee Sonoff - очень хорошие
Датчики присутствия очень мало хороших, как попадёт. У меня несколько zigbee moes, разной сборки, из 5 толко 3 оставил, работают стабильно
Но нудно подбирать под свои задачи, я пока много экспериментирую.
Тестировал реле shelby, хорошие - но размер больше чем то же Sonoff.
Вводные краны да, но есть еще ряд устройств связанных с водой которые могут доставить проблем. Например:
Стиральная машина, бывает течь в работе, из люка для порошка (избыток пены), в таком случае хорошо бы отключить саму машинку, т.к. перекрытие крана не спасает.
Аналогично с посудомоечной машиной, если течет бак, перекрыть вводной кран - пол дела, нужно остановить и сам прибор.
Течь накопительного водонагревателя, тут только уведомление, перекрывать краны нет смысла, если бак на 100 литров.
Я пытался выстроить разными способами связь (у меня похожая ситуация, только не гараж, а паркинг и кладовая). Самое надежное и безопасное решение - VPS + VPN, использую WG.
Настроить WireGuard не сложно, в интернете полно примеров, чуть сложнее будет выстроить маршруты сети между устройствами, именно в рамках безопасности.
Да, но протечка бывает (тьфу тьфу тьфу) не только у стояка, а вот решения максимально простые где я могу разместить датчики по всей квартире, это уже не совсем "простые решения".
Плюс - по опыту, датчики zigbee достаточно надежны и их легко маштабировать, я больше доверяю себе и той платформе которую я выстраиваю руками, чем простому но закрытому оборудованию.
Согласен, одного универсального решения нет. Но, мы можем среагировать и на просто уведомление - связаться с УК, они могут перекрыть полностью стояк, или в новых домах часто краны в подъезде.
Может быть.
Но по опыту разработки и архитектуры, я еще у берега для себя решил и создал правила как, где и что я буду называть. Какие префиксы для entity id, названия самих устройств и т.д.
Так-же все автоматизации пишу только в yaml, используя:
```