| +51 |
20966
23
|
| +83 |
71546
59
|
kvvhost.ru/2020/10/07/sonoff-zigbee-bridge-zha/
Пока склоняюсь ко второму — меньше жрет и не нужно доп питания.
В этом шлюзе применен более навороченный контроллер EFR32MG21 (к сожалению суффикс с объемами flash и ram автор не указал).
Чип сделал на Cortex m33 (у сс2531 используется ядро 8051) и способен 'вытянуть' сеть в 2-3 раза большего размера, в том числе Zigbee v3. Да еще одновременно держать стек Bluetooth.
Из-за большей скорости уменьшаются задержки выполнения команд.
Дополнительно имеет усилитель на выходе +10дБ (либо +20дБ, зависит от суффикса в названии чипа).
Удручает что нет исходного кода прошивки.
У шлюза гораздо лучше дальнобойность.
И взаимодействовать с ним после установки Tasmota сильно проще, чем со свистком.
Прошивка Tasmota действительно позволяет использовать MQTT. Только в сообщениях придётся парсить JSON. И есть некоторое неудобство: управляющие команды надо слать в один топик в одном формате, а вычитывать изменения состояний устройств из другого в совершенно другом формате.
Поддержка Zigbee в Tasmota не выглядит родной. Как будто наспех её сбоку в виде дополнительных команд прикрутили. Часть настроек вообще не имеет имён, просто нумерованные опции. Но, если разобраться, то всё работает без каких-либо проблем.
github.com/kmeaw/mqttlights/blob/master/index.html
На стене висит телефон, на котором открыт браузер во весь экран. Браузер смотрит на страничку, внутри которой есть mqtt/websocket клиент. На сервере стоит mosquitto с двумя слушателями — tcp и websocket. Javascript на этой страничке заставляет браузер подписываться на изменения состояний переключателей и посылать управляющие команды.
Не знаю, где можно почитать, я просто запустил mosquitto_sub -v -t '#' и посмотрел, какие сообщения передаются, когда я щёлкаю выключателем, и когда я командой ZbSend через консоль Tasmota отправляю устройству запрос на включение/выключение.
Получилось, что состояние приходит в JSON-структуре, в поле ZbReceived.0xB70B.Power в топике tele/bedroom/SENSOR, а изменить его можно, отправив сообщение «{«Device»:«bedroom», «send»:{«Power»:XXX}}» (где XXX=0 — выключить, XXX=1 — включить) в топик cmnd/tasmota_D7F296/ZbSend. А чтобы не ждать минуту, пока устройство отрапортует своё состояние, можно написать в тот же топик сообщение «{«device»: «bedroom», «endpoint»: 1, «cluster»: 6, «read»: 0}».
Ещё у меня есть шелл-скрипт, который в цикле читает некоторый топик и занимается более умной автоматизацией — управляет группами, например: . На готовые системы смотрел, они выглядят сильно более навороченно, и хотят больше ресурсов.
Вот тут список поддерживаемых устройств, включая координаторы:
zigbee.blakadder.com/zigbee2tasmota.html
А вот тут инфа с их гитхаб:
tasmota.github.io/docs/Zigbee/
В среднем никому не интересен дом конкретного Васи, Пети и Серёжи.
Но если все эти дома (тысячи домов, сотни тысяч домов) можно будет использовать в качестве ботнета, то стоимость такого актива (ботнет из дырявых устройство тех самых Васи, Пети и Серёжи) начинает обретать уже ощутимую стоимость.
Но это уже, скорее, касается не «сам наваял что-то дырявое», а «выставил в интернет дешёвую китайскую камеру за $15 с выходом в облако».
Лично мне в любом случае больше нравится вариант с ZigBee, нежели с WiFi.
WiFi уже совсем засран, там реально может найтись шутник, который смеха ради бросит рядом с многоквартирным домом копеечный деаутентификатор, который положит нафиг все ближайшие WiFi сети.
1) WiFi — позволяет сделать централизованную систему управления (Роутер — сервер, устройства — клиенты), соответственно, если у Вас сеть развернута в 2-3 комнатах, то проблем нет, вопросы начинаются — когда у Вас большая площадь и WiFi — не везде может достать.
Zigbee — создают свою Mesh-сеть, получается децентрализованная система передачи сигнала, достаточно одного маленького шлюза и множества устройств разбросанных по территории.
2) WiFi — нонстопом жарит на частоте 2.4 гигагерца (на этой частоте микроволновка разогревает еду), устройства — постоянно держат связь с роутером гоняя пакеты, чем больше устройств — тем больше трафик. WiFi — устройства обычно реализуют собственные методы управления, чаще всего это Rest API, реже Mqtt, конечное встраивание их в систему много дома вызывает трудности. Многие пользуются EspEasy или тасмотой, там уже реализован функционал отправки данных на сервер Mqtt, но здесь образуется брешь в безопасности, чаще всего защита отсутствует, т.к. считается — что устройства в сети WiFi — все доверенные, а у злоумышленника нет доступа в эту сеть. Глубоко ошибаются, т.к. взлом пароля вай-фай — вопрос времени.
3) Протокол WiFi (на обычных роутерах) имеет несколько брешей в безопасности, позволяет проводить различного рода атаки — деаутентификация например, для того чтобы перехватить хеш пароля wifi, хеш это не закодированная строка и раскодировать его невозможно, раскодировать нет, а подобрать аналогичную хеш-сумму вполне себе, т.к. метод хеширования известен, дистрибутив AirSlax позволяет провести подобную атаку без особых знаний и умений.
4) Деаутентификатор в считанные минуты выведет вашу сеть WiFi из строя. С Zigbee это сделать будет сложнее. В первую очередь потому, что не все понимают как она работает, а инструментария по взлому не так много и он специализированный.
5) По правилам безопасности для IoT устройств обычно делают отдельную сеть, так какая разница по какому протоколу ее реализовывать? Просто обычные самоделкины не чаще всего не заморачиваются и пихают все в одну сеть…
— это вообще не аргумент. Не дядя Вася же с соседнего подъезда будет вас «взламывать». Те, кому нужно взломать именно Вас — взломают именно Вас.
Сами подумайте над плюсами и минусами этих двух технологий. Они обе имеют как и плюсы, так и минусы.Быть адептом чего-то одного это уже обманывать себя)
А то, что сейчас Zigbee-сеть не ломает каждый второй школьник, так это тоже может быть временным явлением.
Получит Zigbee широкое распространение — могут начать и его ломать (сразу скажу — в этом вопросе я не профи, так, предположения только).