Comments 55
В дальнейшем планирую избавиться от камеры саоми (отдать матери для ухода за престарелой бабушкой). Сам буду пробовать камеры других производителей.
Пробовал я этот Z-Wave. В целом, конечно, работает, но очень дорого. Простое включение света по датчику движения выходит в кругленькую сумму в районе 10 тысяч рублей. При этом всё довольно сырое, вылезают как глюки прошивок, так и аппаратные проблемы, так же из-за беспроводности системы и отсутствия датчиков с питанием от сети появляется куча ограничений, из-за чего невозможно реализовать некоторые алгоритмы. Контроллер на Raspberry Pi — это такой колхоз, если уж говорить о хоть какой-то серьёзной системе… За год использования она раз 10 зависала. Да, и если приходят гости, то они не могут нормально пользоваться даже простым беспроводным выключателем, ибо задержка стандартная около 0,5 сек, а иногда доходит и до десятков секунд.
В результате, на съёмной квартире поигрался, в своей ставить не буду, для света при ремонте развёл кучу выключателей через импульсные реле, для защиты от протечек взял готовую систему, ибо в цене капитального ремонта незаметно (да и, наверное, дешевле решений на Z-Wave), а хоть какая-то гарантия, что сработает и не зависнет. По крайней мере, за 9 месяцев работы не зависла ни разу.
Т.е. вы считаете, что ежедневные перезагрузки по расписанию — это нормально?
ESP по WiFi не пробовал. Речь в статье и в моём комментарии о Z-Wave. Релюшка на один канал стоит 1500-2000 рублей, датчик движения больше 3000, Raspberry Pi — от 2000, плата расширения для работы с протоколом Z-Wave не помню сколько, но думаю не меньше 3000. Если брать готовый контроллер вместо Raspberry Pi, то не особо сэкономишь, т.к. он стоит тоже 4000-5000 рублей.
Это работает. Это не зависает. Это не особенно влияет на доступность и работоспособность системы. Следовательно это нормально.
поверю, когда с таким подходом будете эксплуатировать свой кардио-стимулятор.
а до тех пор — это КОЛХОЗ.
Странный аргумент.
Свет в сортире — одно. Кардиостимулятор — другое.
Зачем смешивать?
У периодической перезагрузки есть только одна проблема — надо как-то хранить персистентные настройки. (у меня, например, есть выключатель — стейт "каникулы". Покуда они не каждый день случаются, он рулится вручную. И после вынужденной перезагрузки его приходится щёлкать заново).
Z-wave не пробовал, у меня дугой протокол, но задержек нет. Все мгновенно
Речь в статье и моём комментарии о протоколе Z-Wave. У меня зависала малинка с этим Z-Wave'ом, не сказать что прям каждый день, но желание использовать такую связку отпало. Плюс довольно тормознутый интерфейс, плюс технические проблемы, типа того, что все настройки хранятся в одном файле в Json формате. В итоге пробовал максимально отвязаться от контроллера, но столкнулся с тем, что невозможно по расписанию изменять настройки у датчиков, т.к. они работают на батарейках и даже уменьшая время периодического опроса контроллера до 10 минут, они ни в какую не хотят брать эти настроки, надо физически на них нажать кнопку, причём кнопка эта внутри корпуса
А зачем вы связываете выключатель с лампочкой через raspberry?
Она же mesh, они отлично взаимодействуют напрямую!
Да, знаю, многие зачем-то пытаются делать софтовые ассоциации (чтоб с выключателя сигнал шёл в raspberry, а он уже давал команду реле), но это совершенно ненужное усложнение на ровном месте. Пойдёт только как сильно вынужденная мера в каких-то очень экзотических случаях (например, не хватает числа слотов ассоциаций. Или сценарий сильно мудрёный хочется сделать...). Если не мудрить, то всё вполне функционально и нормально работает!
Мне кажется, ситуация не особо экзотическая, но обойтись без постоянного участия контроллера я не смог. И все датчики, которые не имеют постоянного питания, не позволяют изменять настройки на лету, т.к. работая от батареек находятся в постоянном сне, по умолчанию самостоятельно просыпаются раз в сутки чтобы отправить свой статус, новые настройки они при этом не получают. А если учесть общую глючность решения. То у реле прошивка слетит, то в выключателе батарейка сядет, а он об этом даже не предупредит, то реле самопроизвольно включается и выключается, то зависнет контроллер, то ни с того ни с сего на несколько минут вообще вся сетка подвисает и даже напрямую связанные выключатель и реле не управляются, точнее управляются, но с задержкой секунд в 30, а то и в минуту. Так же реле у меня были с измерителями мощности, и я хотел реализовать напоминание того, что одна из лампочек в люстре перегорела. К сожалению, датчики при включении обновлялись как-то криво, и даже повторный опрос через некоторое время не всегда позволял получить реальные значения мощности. То один канал показывает, нулевую мощность, то другой…
В итоге, помучавшись, а затем переехав со съёмной квартиры в свою, я решил, что как минимум протокол Z-Wave это что-то очень сырое и больше подходит для каких-то игрушечных целей, нежели для серьёзного и стабильного использования. И всё это на фоне диких цен. Если посмотреть, сколько стоила только одна релюшка для управления светом в коридоре, то дешевле было купить три светодиодных лампочки и никогда их не выключать. Я уж молчу про добавку к этой релюшке выключателя, датчика движения и контроллера.
Ну там протокол то как раз сделан в расчёте на "кубики", которые тупые, как палка. Включил/выключил. Сработало/не сработало. А чего-то конфигурировать — только при распаковке и первом подключении (подозреваю, что сами устройства могут быть не очень готовы к постоянной переконфигурации из сценариев. Банально ресурс встроенной флэшки износится...)
Я бы тут попробовал сделать "ночной" сценарий напрямую (чтоб по датчику включалась лампочка), а параллельно хук на то же событие из контроллера, чтобы днём включалась ещё пара лампочек. Ну т.е. какой-то компромисс.
Были у меня и такие идеи, но напрямую завязать датчик движения всё равно не получается, т.к. он кроме события «включить» при начале движения, шлёт ещё и «выключить» при окончании таймаута после последнего зарегистрированного движения.
И если делать включение света, как вы говорите, в два этапа, то это от части противоречит самой идее протокола, т.к. изначально идёт речь о максимальном снижении количества передаваемой информации. В вашем же случае выключатель шлёт команду реле, чтобы то включило один канал, реле отсылает контроллеру оповещение, что оно включилось, контроллер шлёт в ответ, чтобы реле включило второй канал, реле в ответ снова шлёт сигнал, что оно включилось. Можно очень легко получить бесконечный цикл, на что я несколько раз напарывался. Значит, выключатель должен слать сигнал кроме релюшки ещё и контроллеру, что надо включить свет. Но с выключателем ещё сложнее, он не событие присылает, а изменяет статус. А если делать, чтобы он событие слал, то на это не умеет реагировать реле. В общем, там столько подводных камней вылезает, программирование с виду несложного алгоритма вываливается в простыню на пару экранов с дикой завязкой разных модулей и кучей виртуальных устройств. При этом по сети гоняется куча ненужной инфы (что увеличивает ещё и задержки), которая могла бы быть снижена в разы, если бы можно было переконфигурировать устройства на лету. И всё равно мы не можем в полной мере отказаться от постоянно включённого контроллера, т.к. в коридоре с одной лампочкой днём совсем некомфортно.
Это не ограничения протокола, это ограничения реализации конкретных устройств. Можно ж и плату для самостоятельной разработки взять, и намутить, чего хочется.
А готовые датчики движения разные, и настройки у них тоже. Обычно есть два таймаута — первый, когда выключить свет. Второй — сколько времени после срабатывания не воспринимать новые движения. И от протокола как такового это не зависит.
А вот само устройство "на той стороне" — уже да. Если брать готовый контроллер типа fibaro или прочих — работает классно, но дорог, + "чёрный ящик" сам по себе. Зато относительно стабилен. Отчасти как раз потому что закрыт и не пускает "очумелых ручек" придумать что-нибудь этакое. А разные решения-"модемы" (вроде razberry или usb-свистков, которые просто ловят/передают в uart то, что видят в эфире) уже целиком зависят от того, куда этот "свисток" вставлен. Можно же и cubie-truck завести, да ещё и батарейку к нему подцепить в качестве упса...
(к слову, до появления razberry и standalone-rasberry сервера у меня около года вполне успешно работал такой "свисток" воткнутый в роутер. Ну и плюс программка-коннектор, которая выпускала его в облако. И там сценарии были вполне отзывчивыми, несмотря на раунд-трип событий через интернет).
Кстати, реле далеко не всегда шлёт контроллеру своё состояние (включилось/не включилось). В США например, это отключено (запатентовал кто-то), поэтому придумывают разные периодические опросы или как-то по-другому выкручиваются. Т.е. это НЕ часть протокола, а просто хорошая плюшка. И так-то протоколу не противоречит — датчик шлёт сообщения своим подписчикам — свету и контроллеру. Контроллер в ответ шлёт ещё один пакет свету. Всё!
В родном софте razberry контроллер по умолчанию добавляется в ассоциации всех устройств (т.е. датчики, выключатели и т.д. шлют события по крайней мере ему).
А вот аппаратный протокол может и не идеален, но очень хорош. Хотя бы тем, что висит не в 2.4 и не в 430, где хватает помех, а в своём диапазоне. И требование скважности 1% тоже своего рода гарантия незагруженности канала.
Можно же и cubie-truck завести, да ещё и батарейку к нему подцепить в качестве упса…
Плюс наличие Sata
Получше тех. характеристики.
Для меня минус у cubietruck
1) Небольшая распостранённость и отсутствие готовых образов, форумов по решению проблем.
2) Вроде бы небольшой ряд ОС, устанавливаемых на это ПК. Почему то на работе так и не смог обновить Lubuntu 14 до 16.
3) Отсутствие утилиты настройки. Всё таки конфигурация тяжеловата для конечного пользователя (в моем случае, сын школьник).
4) Более высокая стоимость, Малинку можно и попроще купить (100 USD за кубик и от 40 за Raspberry Pi Model A+)
Если я вас правильно понял, то вы говорите о Z-Uno. Так вот там своих глюков столько, что я неделю мучался со счётчиком импульсов. В результате кое как запустил на ней, так она всё равно иногда пропускает импульсы, из-за чего так и не получилось сделать автоматическую отправку показаний счётчиков воды.
Как мне помогут эти два таймера? У меня задача днём первый таймер чтоб был на 300 секунд, а ночью на 30. Плюс, хочу иметь возможность ночью по желанию отменить действие ночи на, например, один час.
Вы говорите тормозов нет. Сколько проходит времени между нажатием на выключатель и включением света?
ну и таких проблем на моих модулях не наблюдалось. была как то ситуация похожая — свет ночью включался выключался сам, оказалось что в датчике движения батарейка садилась, а оповещение было выключено. после замены работает нормально. с релюшками был глюк «залипания» — часть перевел на трансформаторные нагрузки, часть на бесконтактные реле (все таки за такие деньги могли бы сразу ставить нормальные реле, а то приходится доделывать)
Просто, у меня реально задержка была не менее 0,5 секунды. Когда гости пришли, они даже не сразу поняли в чём дело, ведь сам выключатель тоже отличается от обычного механического. Он представляет из себя просто кнопку, а тут ещё и реакции то ли нет, то ли есть. В общем, прежде чем зайти в ванную комнату раз пять мигали светом, т.к. не понимали, как включить свет. Хотя выключатель там работал просто как выключатель, без каких-либо наворотов.
IMHO в первом посте хотелось бы увидеть что именно планируется достигнуть( или уже достигнуто). А то у меня сочетание безопасности, газа и воды вызывает беспокойство. В сочетании с беспроводными технологиями. А там может все продумано, но я этого пока не знаю… Вот с плана бы и начать
Есть актуаторы для вентилей (можно прикрепить к крану, и по команде механическая "рука" его перекроет). Есть датчики. Есть особые классы команд (alarm-ы), на которые можно настроить эти самые актуаторы (тупо — получил flood alarm — перекрыл вентиль воды).
И контроллер с малинкой (которая может внезапно зависнуть) нужен только для настройки связи датчиков и актуаторов. Для фактической работы он уже НЕ нужен (но если доступен, то может, например, sms-ку или письмо отправить — мол, сработало).
Если всё умрёт — ну, будет "обычный дом", где всё нужно делать руками. А в остальном всё только улучшается. (Хотя… можно насочинять: оказался запертым в доме, пролил кружку воды на датчик, он перекрыл воду, как открыть назад — не знаю, умер от обезвоживания)
Смотрел OpenHab2, Domoticz, MajorDoMo.
У всех очень плохо по нормальной документации/туториалам с добавлением своего протокола.
Роутер для моего протоколо стоит 300 рублей(с корпусом и сборкой), он маленький. Протокол не требует дополнительных шилдов, работая по сути с любым голым МК.
Так что на мой субъективный взгляд мой протокол лучше.
Реверс и метод тыка — крайний вариант. Есть надеждая, что я просто не увидел документации по добавлению протоколов. Поэтому и спрашиваю у более опытных товарищей.
Ну и протокол сам по себе простой. Сложности на уровне самого ПО и они к протоколу отношения не имеют.
По возможности русскоязычный интерфейс, документация, поддержка.?
В MajorDoMa понравился форум. На котором я мог найти некоторые ответы, на свои нужды.
У HASS из русского есть только интерфейс.
сайт переделали, установку и еще многие вещи упростили. И продолжаем упрощать.
Растет количество сторонних разработчиков, которые модули пишут. В целом активно развиваемся (тьфу-тьфу-тьфу) — можете посмотреть динамику версий (лента справа): connect.smartliving.ru/tasks.html
по PHP — у Цукерберга например Умный дом тоже на PHP написан — он тоже плохой поэтому?)) каждый использует инструменты которые ему привычны и понятны
OpenHab молодцы, смотрим время от времени на то что они делают. Им немного проще в плане развития, потому что получают финансирование от Deutsche telekom. Мы же систему в свободное время развиваем
мы развиваемся :)
сайт переделали, установку и еще многие вещи упростили. И продолжаем упрощать.
Спасибо вам!
Лично мне сильно импонировал ваш форум и сообщество.
Но… на самый первый взгляд и есть много вопросов.
Есть разные идеи и предложения, но это попозже, потом выложу постараюсь нормально сформировать и опубликовать их.
Ну а сейчас, надеюсь к выходным подготовлю вторую часть статейки.
habr.com/post/416369
Просто о сложном. Начало создания беспроводного «умного дома». На основе технологии Linux, Z-Wave и ПО MajorDoMo