Комментарии 61
Micropython для ESP8266 не рассматривали наряду с uLisp? Или там будет такая же проблема нехватки флеша как и с Lua? Если рассматривали, интересны были бы подробности
На момент отказа от lua, уже было понимание, что при активном обмене сообщениями между устройствами, важна простота программной генерации кода (может породить skynet), тут lisp вне конкуренции… Поэтому micropython глубоко не рыл…
Добрый день. А скажите пожалуйста, на каком железе, и какой операционке организован клиент сервер для работы устройств. На чем работает питон? Вы выложите исходники для железа, которое вы сделали, что можно было собрать себе такоеже.?
Клиент на python, работает на всём… я всем этим на макбуке занимаюсь. Весь софт/ прошивки/интаеграция в HA/утилиты тут github.com/bskaplou/iot_home_esp8266_POC. С железом всё предельно просто — пихаем i2c к ногам i2с и spi к ногам spi… Особо нечего тут документировать
В то же время xiaomi реализовали правильный децентрализованный протокол, но зачем-то сузили возможности устройств ограничив их стрёмным, но развесистым json-based dsl (личное впечатление составлять тут).Ха! Это Вы ещё не подключали к умному дому тёплое ламповое интернет радио, вот где россыпь
Интересно следить за развитием Вашего проекта. И славно, что руки Вам сидеть явно не мешают.
Насчёт сомнений по поводу момента, когда все железки наконец подружатся и станут непринуждённо болтать сами по себе — берегите МГД-генератор в тепле и сухости.
Что-то я плохо понимаю ваши претензии к HA. HA — это, прежде всего, фронт, красивенький интерфейс.
Если не хотите завязывать все управление устройствами на него — не завязывайте, никто не заставляет. У меня например mqtt брокер вообще на другом устройстве работает.
Я, если честно, несильно знаком с УД от Xiaomi, но скажите мне: будет ли он работать, если отключится интернет? Что-то мне подсказвает, что без обращений к серверам Xiaomi тут не обходится…
Если не хотите завязывать все управление устройствами на него — не завязывайте, никто не заставляет. У меня например mqtt брокер вообще на другом устройстве работает.
Я, если честно, несильно знаком с УД от Xiaomi, но скажите мне: будет ли он работать, если отключится интернет? Что-то мне подсказвает, что без обращений к серверам Xiaomi тут не обходится…
Подробно исследовано вот тут habr.com/ru/post/503570. У xiaomi если в строю устройства задействованные в сценарии работают — сценарий будет выполнен. Сервера xiaomi в сценариях не задействуются. Для HA сверх того нужен рабочий HA.
Что-то я не совсем понимаю вашей терминологии. По ссылке не нашел:
— Где хранится этот самый сценарий Xiaomi?
— Кто проверяет его условия?
— Кто дает команды устройствам?
— Где хранится этот самый сценарий Xiaomi?
— Кто проверяет его условия?
— Кто дает команды устройствам?
Скрипт засылается на устройство тригерящее событие
При появлении события на устройстве оно проверяется на соответствие входным условиям всех скриптов.
Затем выполняются команды сматчившихся скриптов.
Команды могут относиться как к устройству стриггерившему событие так и к другим устройствам. Во втором случае будет послан пакет xiaomi-miio в сторону удаленного устройства
github.com/rytilahti/python-miio/blob/fd563968baab5f4a1cca16566a2e79f169e9d08a/miio/gateway_scripts.py#L58-L90
По ссылке код генерящий такие скрипты в формате xiaomi… Они втыкаются не с первого раза — в этом минус протокола… Я счлёл что сценарии на lisp получатся и понятнее и мощнее чем скрипты в xiaomi-miio
При появлении события на устройстве оно проверяется на соответствие входным условиям всех скриптов.
Затем выполняются команды сматчившихся скриптов.
Команды могут относиться как к устройству стриггерившему событие так и к другим устройствам. Во втором случае будет послан пакет xiaomi-miio в сторону удаленного устройства
github.com/rytilahti/python-miio/blob/fd563968baab5f4a1cca16566a2e79f169e9d08a/miio/gateway_scripts.py#L58-L90
По ссылке код генерящий такие скрипты в формате xiaomi… Они втыкаются не с первого раза — в этом минус протокола… Я счлёл что сценарии на lisp получатся и понятнее и мощнее чем скрипты в xiaomi-miio
Да, в закрытой эко-системе такое возможно…
Но у такого решения тоже есть минусы:
— Ну тут понятно, не наши устройства с нашими особо не свяжешь (дибо нужно опять же отдельное устройство, что сводит на нет преимущества децентрализации);
— Ограничена гибкость сценариев, если нужно какое-то замысловатое условие, которое не предусмотрели в Xiaomi — труба. Ибо сценарий — это не скрипт. Слово «скрипт» подразумевает какой-то тьюринг-полный язык с соответствующей гибкостью;
— Получается, каждое устройство должно иметь полноценный процессор сценариев и достаточный объем памяти для хранения множества таковых. Не будет ли переполнения?
Но у такого решения тоже есть минусы:
— Ну тут понятно, не наши устройства с нашими особо не свяжешь (дибо нужно опять же отдельное устройство, что сводит на нет преимущества децентрализации);
— Ограничена гибкость сценариев, если нужно какое-то замысловатое условие, которое не предусмотрели в Xiaomi — труба. Ибо сценарий — это не скрипт. Слово «скрипт» подразумевает какой-то тьюринг-полный язык с соответствующей гибкостью;
— Получается, каждое устройство должно иметь полноценный процессор сценариев и достаточный объем памяти для хранения множества таковых. Не будет ли переполнения?
Так статья жжж блин о том что:
1. Централизованная система типа HA не лучший вариант
2. Xiaomi децентрализованный и поэтому хорош, но скрипты урезают возможности
3. Собрал устройства
4. Сделал прошивку которая позволяет вместо сценариев xiaomi исполнять тюринг полные программы на lisp
Я могу связать свои устройства с устройствами xiaomi реализовав функцию xioaomi-request, с протоколом я уж неплохо знаком :)
Другие сложнее но 4-5 под протоколов сложности xiaomi-miio памяти хватит
Я создал устройства и прошивки в которых есть полноценный процессор сценариев, а на примерах показал что мощностей современного MCU достаточно для этого.
1. Централизованная система типа HA не лучший вариант
2. Xiaomi децентрализованный и поэтому хорош, но скрипты урезают возможности
3. Собрал устройства
4. Сделал прошивку которая позволяет вместо сценариев xiaomi исполнять тюринг полные программы на lisp
Я могу связать свои устройства с устройствами xiaomi реализовав функцию xioaomi-request, с протоколом я уж неплохо знаком :)
Другие сложнее но 4-5 под протоколов сложности xiaomi-miio памяти хватит
Я создал устройства и прошивки в которых есть полноценный процессор сценариев, а на примерах показал что мощностей современного MCU достаточно для этого.
например esphome, который и сам по себе и ХА хорошо интегрирован.
Не панацея, но большинство задач решает.
Не панацея, но большинство задач решает.
Цитата
Угу ESPHome тоже почему-то считают что SPoF в виде HA и MQTT это плохо, нас — еретиков кажется много :)
ESPHome вещь, но изменение конфигурации требует перепрошивки…
You could write an automation to do this task in Home Assistant’s automation engine, but ideally the IoT should work without an internet connection and should not break with the MQTT server being offline.
Угу ESPHome тоже почему-то считают что SPoF в виде HA и MQTT это плохо, нас — еретиков кажется много :)
ESPHome вещь, но изменение конфигурации требует перепрошивки…
Может я тупой, но вопрос где сам скрипт хранится остался мне непонятен. Кто что и как вызывает это было и раньше ясно, но вот где хранится сам скрипт?
Практика использования ir remote показала что без серверов xiaomi он вообще не работает даже скрипты не завязанные ни на одно устройство не выполняются. А теряет их (сервера) он стабильно, так как сервера работают просто погано.
Практика использования ir remote показала что без серверов xiaomi он вообще не работает даже скрипты не завязанные ни на одно устройство не выполняются. А теряет их (сервера) он стабильно, так как сервера работают просто погано.
...
Скрипт хранится в памяти устройства...
Общий подход такой:
1) Устройство просыпается и смотрит есть ли init файл
2) Если нет - становиттся точкой доступа и принимает код lisp, если есть исполняет его
3) Для загрузки init надо вызвать init-save, аргмент функции записывается в память устройство
Надо сказать, что воды утекло много, я уж дом этим оборудовал. Ленты/Вентмашина/Бак с водой/LED ленты/Свет всё на потомке описанной системы. Правда вместо esp8266 использую esp32 и esp32s2
Все так. По факту если брать какую-нибудь тасмоту в качестве базовой прошивки для девайсов, то на HA накладываются только несколько ролей
* Няшный интерфейс с хранением истории данных
* Интеграция более тупых сервисов в экосистему (условный смарт тв который не умеет в mqtt)
* Интеграция внешних систем в экосистему (например, подключение к google home\alexa\алисе или подключение других брендов IoT у которых нет нормальных локальных протоколов)
Все остальное успешно работает мимо HA, через mqtt и системы автоматизации типа node-red.
* Няшный интерфейс с хранением истории данных
* Интеграция более тупых сервисов в экосистему (условный смарт тв который не умеет в mqtt)
* Интеграция внешних систем в экосистему (например, подключение к google home\alexa\алисе или подключение других брендов IoT у которых нет нормальных локальных протоколов)
Все остальное успешно работает мимо HA, через mqtt и системы автоматизации типа node-red.
Так MQTT тоже SPoF и требует довольно отдельного девайса… Из MQTT никогда не родится SkyNet ;(
У вас нет SPoF только до тех пор пока вы все девайсы настраивайте и спаривайте вручную. Когда девайсов станет несколько десятков, то SPoF станете вы сами.
У меня полтора десятка и я бы уже задолбался каждый настраивать вручную
Но в целом та же тасмота умеет в device groups (udp multicast)
tasmota.github.io/docs/Device-Groups без mqtt если очень хочется.
У меня полтора десятка и я бы уже задолбался каждый настраивать вручную
Но в целом та же тасмота умеет в device groups (udp multicast)
tasmota.github.io/docs/Device-Groups без mqtt если очень хочется.
>>У вас нет SPoF только до тех пор пока вы все девайсы настраивайте и спаривайте вручную.
Уточните связь между SPoF и способом настройки…
Уточните связь между SPoF и способом настройки…
Сейчас вы выступаете в качестве «ручного» окрестратора устройств при их конфигурации. При наличии большого количества устройств если спаривать их все вручную друг с другом займет кучу времени. Вы по сути предлагаете каждому устройству рассказать про каждое физическое устройство. Если нужно будет внести изменения, то это тоже куча работы — например отправлять данные не на одно устройство, а на 10. имея MQTT вам вообще не придется ничего модифицировать — вы просто подписываете 10 девайсов на один и тот же топик (т.е. по факту имеете 10 одинаковых девайсов с идентичной прошивкой).
Во вторых MQTT это не только точка отказа, но и точка резервации данных для устройств. Если какой-то девайс ребутался и пропустил последний пакет со стейтом то он легко может вычитать его из топика сразу при загрузке. В вашем случае он будет ожидать следующего пакета.
То что требует отдельного девайса — на той же esp можно поднять брокер
Я конечно выражаю точку зрения бытового потребителя этого всего добра. Для частного случая и единичного применения наверное это прикольно, но заставлять массового потребителя вручную прошивать и сопрягать каждое устройство с каждым ради децентрализации — выглядит оверхедом. Я заливаю на все свои устройства одинаковую прошивку с одинаковым конфигом — они знают только про вайфай сеть и mqtt брокера.
Нигде вручную не зашиваются полтора десятка айпишников (у меня устройства вообще по dhcp получают адреса)
Более того благодаря проектам типа zigbee2mqtt в эту же экосистему легко интегрируются девайсы котороые вообще не умеют в tcp\ip. Как это можно сделать с вашим подходом?
Во вторых MQTT это не только точка отказа, но и точка резервации данных для устройств. Если какой-то девайс ребутался и пропустил последний пакет со стейтом то он легко может вычитать его из топика сразу при загрузке. В вашем случае он будет ожидать следующего пакета.
То что требует отдельного девайса — на той же esp можно поднять брокер
Я конечно выражаю точку зрения бытового потребителя этого всего добра. Для частного случая и единичного применения наверное это прикольно, но заставлять массового потребителя вручную прошивать и сопрягать каждое устройство с каждым ради децентрализации — выглядит оверхедом. Я заливаю на все свои устройства одинаковую прошивку с одинаковым конфигом — они знают только про вайфай сеть и mqtt брокера.
Нигде вручную не зашиваются полтора десятка айпишников (у меня устройства вообще по dhcp получают адреса)
Более того благодаря проектам типа zigbee2mqtt в эту же экосистему легко интегрируются девайсы котороые вообще не умеют в tcp\ip. Как это можно сделать с вашим подходом?
>>При наличии большого количества устройств если спаривать их все вручную друг с другом займет кучу времени.
1. Спариваются только устройства задействованные в сценарии — в ходе инсталляции сценария в память устройств.
2. Сценарий заливается не в центр, а в выполняющие устройства. Динамическая среда позволяет это делать без перепрошивки.
3. Вместе с заливкой скриптов нужно раскидать ключи доступа доступные на устройстве с которого инсталлируется сценарий
Шага «спарить всех со всеми» нет.
>>В вашем случае он будет ожидать следующего пакета.
В статье я тему резервирования не затрагивал. Кстати у xiaomi никакого резервирования нет, есть перепосылка…
Тема интересная, но не такая и простая и довольно теоретическая… Обедающие профессора, византийские генералы — вот это всё…
Если ответить кратко, то в сети агентов резервирование делается максимально близко к резервируемому устройству, если на устройстве есть постоянная память — то прям сам свои данные и резервирует, если нет — то на ближайшем с доступной энергонезависимой памятью. Если данные mission critical, то еще и избыточность накидывается DHT и прочее…
>>сопрягать каждое устройство с каждым ради децентрализации — выглядит оверхедом.
>>Для частного случая и единичного применения наверное это прикольно, но заставлять массового потребителя вручную прошивать и сопрягать каждое устройство с каждым ради децентрализации — выглядит оверхедом.
Это ложные тезисы…
Споряжение всех со всеми не нужно.
Ручная прошивка и сопряжение не нужны, я такой дичи нигде не предлагал…
Прошивка делается один раз на фабрике.
Прошивка включает протокол подключения к новой сети позволяющий полную автоматизацию процесса (даже в моём прототипе такой протокол реализован).
>>Я конечно выражаю точку зрения бытового потребителя этого всего добра.
А я тут про теорию распределенных систем распинаюсь :)
Чуть разжую тезис статьи:
— На рынке есть две модели: клиент-сервер и одноранговая сеть
— IoT явно тяготеет к разростанию кол-ва устройств, будем считать кол-вом устройств N
— Кол-во устройств вовлеченных в один сценарий будем называть M
— M <= N всегда, но при росте N, M растет намного медленнее, растет кол-во сценариев, но кол-во устройств задействованных в одном сценарии не растет — сценарии задействующие десятки устройств — редкость. Обычное кол-во устройств задействованных в сценарии < 5 независимо от общего кол-ва устройств в сети
— За отказ считаем невыполнение сценария при наступлении события по которому срабатывает сценарий
— Для отказа сценария в системе клиент-сервер нужно убить одну из M + 1 устройств
— Для отказа сценария в системе одноранговой сети агентов нужно убить одну из M устройств — надежность выше
— В клиент-серверной архитектуре та самая единица добавляемая к M — это убернода, выруб которой убивает всю систему — это еще снижает надежность. x Такой SkyNet сможет завалить любой Нео нашедший сервер HA/MQTT.
— Так-же есть фактор стоимости — нода под HA нередко окажется самой дорогой во всей сети
>>Я заливаю на все свои устройства одинаковую прошивку с одинаковым конфигом — они знают только про вайфай сеть и mqtt брокера.
Вы кажется используете крайне примитивную прошивку, даже в моём прототипе есть протокол первоначального подключения к сети, по которому можно подключить устройство в новую сеть без перепрошивки — это стандарт для commodity устройств…
>>Я заливаю на все свои устройства одинаковую прошивку с одинаковым конфигом — они знают только про вайфай сеть и mqtt брокера.
Это чуть за рамками статьи. Но в моём PoC устройства появившись в сети имеют возможнось быть настроенными автоматически — без вмешательства человека совсем…
>>Более того благодаря проектам типа zigbee2mqtt в эту же экосистему легко интегрируются девайсы котороые вообще не умеют в tcp\ip. Как это можно сделать с вашим подходом?
И таких устройств успел наделать (хотя за рамками статьи), в моём случае таким протоколом является BLE и у меня есть сенсоры на NRF51, для таких устройств используются gateway (в моём случае на ESP32). При этом подходе если в сценарии используются устройства находящиеся в сетях на разных протоколах то gateway становится частью сценария. Сейчас мои nrf51 работают выполняя всё те-же программы lisp, просто получаются они не по TCP а по BLE. Для передачи данных устройству на NRF51 используется устройство на ESP32.
Тут всё довольно стандартно, возможно позже опишу как убрать SPoF с gateway.
1. Спариваются только устройства задействованные в сценарии — в ходе инсталляции сценария в память устройств.
2. Сценарий заливается не в центр, а в выполняющие устройства. Динамическая среда позволяет это делать без перепрошивки.
3. Вместе с заливкой скриптов нужно раскидать ключи доступа доступные на устройстве с которого инсталлируется сценарий
Шага «спарить всех со всеми» нет.
>>В вашем случае он будет ожидать следующего пакета.
В статье я тему резервирования не затрагивал. Кстати у xiaomi никакого резервирования нет, есть перепосылка…
Тема интересная, но не такая и простая и довольно теоретическая… Обедающие профессора, византийские генералы — вот это всё…
Если ответить кратко, то в сети агентов резервирование делается максимально близко к резервируемому устройству, если на устройстве есть постоянная память — то прям сам свои данные и резервирует, если нет — то на ближайшем с доступной энергонезависимой памятью. Если данные mission critical, то еще и избыточность накидывается DHT и прочее…
>>сопрягать каждое устройство с каждым ради децентрализации — выглядит оверхедом.
>>Для частного случая и единичного применения наверное это прикольно, но заставлять массового потребителя вручную прошивать и сопрягать каждое устройство с каждым ради децентрализации — выглядит оверхедом.
Это ложные тезисы…
Споряжение всех со всеми не нужно.
Ручная прошивка и сопряжение не нужны, я такой дичи нигде не предлагал…
Прошивка делается один раз на фабрике.
Прошивка включает протокол подключения к новой сети позволяющий полную автоматизацию процесса (даже в моём прототипе такой протокол реализован).
>>Я конечно выражаю точку зрения бытового потребителя этого всего добра.
А я тут про теорию распределенных систем распинаюсь :)
Чуть разжую тезис статьи:
— На рынке есть две модели: клиент-сервер и одноранговая сеть
— IoT явно тяготеет к разростанию кол-ва устройств, будем считать кол-вом устройств N
— Кол-во устройств вовлеченных в один сценарий будем называть M
— M <= N всегда, но при росте N, M растет намного медленнее, растет кол-во сценариев, но кол-во устройств задействованных в одном сценарии не растет — сценарии задействующие десятки устройств — редкость. Обычное кол-во устройств задействованных в сценарии < 5 независимо от общего кол-ва устройств в сети
— За отказ считаем невыполнение сценария при наступлении события по которому срабатывает сценарий
— Для отказа сценария в системе клиент-сервер нужно убить одну из M + 1 устройств
— Для отказа сценария в системе одноранговой сети агентов нужно убить одну из M устройств — надежность выше
— В клиент-серверной архитектуре та самая единица добавляемая к M — это убернода, выруб которой убивает всю систему — это еще снижает надежность. x Такой SkyNet сможет завалить любой Нео нашедший сервер HA/MQTT.
— Так-же есть фактор стоимости — нода под HA нередко окажется самой дорогой во всей сети
>>Я заливаю на все свои устройства одинаковую прошивку с одинаковым конфигом — они знают только про вайфай сеть и mqtt брокера.
Вы кажется используете крайне примитивную прошивку, даже в моём прототипе есть протокол первоначального подключения к сети, по которому можно подключить устройство в новую сеть без перепрошивки — это стандарт для commodity устройств…
>>Я заливаю на все свои устройства одинаковую прошивку с одинаковым конфигом — они знают только про вайфай сеть и mqtt брокера.
Это чуть за рамками статьи. Но в моём PoC устройства появившись в сети имеют возможнось быть настроенными автоматически — без вмешательства человека совсем…
>>Более того благодаря проектам типа zigbee2mqtt в эту же экосистему легко интегрируются девайсы котороые вообще не умеют в tcp\ip. Как это можно сделать с вашим подходом?
И таких устройств успел наделать (хотя за рамками статьи), в моём случае таким протоколом является BLE и у меня есть сенсоры на NRF51, для таких устройств используются gateway (в моём случае на ESP32). При этом подходе если в сценарии используются устройства находящиеся в сетях на разных протоколах то gateway становится частью сценария. Сейчас мои nrf51 работают выполняя всё те-же программы lisp, просто получаются они не по TCP а по BLE. Для передачи данных устройству на NRF51 используется устройство на ESP32.
Тут всё довольно стандартно, возможно позже опишу как убрать SPoF с gateway.
Хорошо, а что делать с устройствами безопасности? Например датчик окна, его же надо мониторить, т.е. всё равно нужно устройство которое будет гонять скрипты, а если оно есть то зачем ещё что-то городить.
Да и единая точка отказа у вас всё равно есть — вайфай.
Не сочтите за критику, Ваше решение мне очень понравилось.
Ручная прошивка и сопряжение не нужны, я такой дичи нигде не предлагал…
Неправильно выразился, да. под «каждый с каждым» я имел ввиду именно ручное распределение сценариев по устройствам
Вы кажется используете крайне примитивную прошивку, даже в моём прототипе есть протокол первоначального подключения к сети, по которому можно подключить устройство в новую сеть без перепрошивки — это стандарт для commodity устройств…
Я использую голые esp — на них ничего нет изначально, так что прошивать все равно приходится. Но вообще да, на них можно залить прошивку вообще без конфига и донастроить опосля, но если девайс воткнут у меня в сериал порт — мне проще сразу и конфиг залить
но кол-во устройств задействованных в одном сценарии не растет — сценарии задействующие десятки устройств — редкость.
Классический сценарий «погасить весь свет в доме по нажатию на кнопку» будет требовать манипуляций с перенастройкой при добавлении каждого устройства (или замены обычного светильника на умный).
— В клиент-серверной архитектуре та самая единица добавляемая к M — это убернода, выруб которой убивает всю систему — это еще снижает надежность. x Такой SkyNet сможет завалить любой Нео нашедший сервер HA/MQTT.
— Так-же есть фактор стоимости — нода под HA нередко окажется самой дорогой во всей сети
Как я уже сказал HA — вообще необязательный компонент сети, а MQTT можно развернуть на таких же esp. Выруб — да, валит всю систему. Но как уже не раз сказали вероятность такая же как вырубить роутер\центральный свитч или что у вас там за сеть отвечает, имхо
Я же в целом эту проблему решаю чуть проще (и в плане исполнения и в плане удобства). Все критические девайсы в случае отвала SPoF (mqtt\роутер) можно тыкать физически прямо через девайс. т.е. можно подойти и переключить умную розетку вручную (на них есть кнопка), подойти и выключить умный свет выключателем и т.д. Т.е я заранее строю UX так, чтобы все деградировало до обычного «неумного» дома в случае проблем с девайсами
Но я процитирую соседний ответ
Не сочтите за критику, Ваше решение мне очень понравилось.
Мне кажется вам надо попробовать применить эту концепцию в сторону зигби девайсов. Они умеют строить меш сети где аргумент про отвал роутера больше не будет валидным ) Если присыпать это дело UI, который будет уметь заливать скрипты в девайсы — и кажется будет крутой продукт
Как раз попалось на глаза видео про zigbee direct binding
youtu.be/xgtZazMZNto?t=202
Выглядит очень удобно — координатор жив — получаем полноценное взаимодействие, mqtt и прочее. Выключили координатор — связанные устройства все еще общаются напрямую, не нужен даже роутер.
При этом сопряжение идет через удобный UI. Кажется если научиться заливать в такие штуки сценарии подобные вашим, то будет совсем круто
youtu.be/xgtZazMZNto?t=202
Выглядит очень удобно — координатор жив — получаем полноценное взаимодействие, mqtt и прочее. Выключили координатор — связанные устройства все еще общаются напрямую, не нужен даже роутер.
При этом сопряжение идет через удобный UI. Кажется если научиться заливать в такие штуки сценарии подобные вашим, то будет совсем круто
НЛО прилетело и опубликовало эту надпись здесь
Блииин, но их танковый размер убивает всю эстетику :(
То есть автор www.jaredwolff.com/finding-the-best-tvoc-sensor-ccs811-vs-bme680-vs-sgp30 работает на врагов и всё врет глубоко заблждаясь?
То есть автор www.jaredwolff.com/finding-the-best-tvoc-sensor-ccs811-vs-bme680-vs-sgp30 работает на врагов и всё врет глубоко заблждаясь?
Вот ещё неплохие датчики, у меня такой трудится дома:
aliexpress.com/item/32844884313.html
Они кстати установлены в нижней части корпуса в этих бризерах от Xiaomi:
www.aliexpress.com/item/4000500378504.html
aliexpress.com/item/32844884313.html
Они кстати установлены в нижней части корпуса в этих бризерах от Xiaomi:
www.aliexpress.com/item/4000500378504.html
НЛО прилетело и опубликовало эту надпись здесь
>>Запускайте HA на имеющемся в доме устройстве бесплатно.
Такой подход ограничивает проникновение технологий в дома людей у которых нет docker сервера в шкафу.
>>И, если на то пошло, у вас в любом случае есть single point of failure — ваш роутер.
Так оно и есть, суть улучшения отказоустойчивости в сокращении кол-ва точек отказа.
>>Да и умный дом у вас не Xiaomi, а на железе Xiaomi с паяльником.
А те устройства о которых речь в статье вообще к xiaomi отношения не имеют :)
Такой подход ограничивает проникновение технологий в дома людей у которых нет docker сервера в шкафу.
>>И, если на то пошло, у вас в любом случае есть single point of failure — ваш роутер.
Так оно и есть, суть улучшения отказоустойчивости в сокращении кол-ва точек отказа.
>>Да и умный дом у вас не Xiaomi, а на железе Xiaomi с паяльником.
А те устройства о которых речь в статье вообще к xiaomi отношения не имеют :)
Почему бы просто не использовать православный рест? В ха он отлично развит и работает, на есп как сервер и клиент тоже работает молниеносно. Зачем эти грабли с репли по удп? По мне так схема скопировать неудачный велосипед.
Здесь та-же претензия что к mqtt. TCP требует установления и поддержания соединения — это затратно с точки зрения ресурсов тезис не мой, он широко известен — вот тут например изложен www.oreilly.com/library/view/analytics-for-the/9781787120730/e86ff73d-7e8c-4eda-9890-0ceebbadcf78.xhtml
Зачем кипалайв? Просто закрыть после поста. А тсп убивает зайца о состоянии доставки запроса кратким ответом в виде заголовков. Да, сам запрос и тело больше занимают, но в рамках лана пользы больше чем вреда, даже в сравнении с мктт.
Сам по себе rest прекрасен…
Но чтобы получить шифрованный https канал для rest общения нужно потрать пригоршню тактов и десятки миллисекунд времени, по сути до передачи данных нужны два хендшейка:
1) TCP handshake (тратим время)
2) SSL handshake (тратим время и греем ядро)
keepalive используется, чтобы сократить кол-во таких хендшейков ибо они случаются только при установлении соединения.
В итоге если например переключатель будет посылать сигнал врубить свет устанавливая https соединение, то пользователь будет видеть, что система тормозит… На рынке есть такие устройства, пытаюсь этого избегать…
Время выполнение сценария по хорошему должно вписываться в 50ms в худшем случае…
Примерно по этим-же причинам HTTP/3 реализовывают на UDP, но в глобальной сети требования к времени реакции по идее всегда будут мягче…
Но чтобы получить шифрованный https канал для rest общения нужно потрать пригоршню тактов и десятки миллисекунд времени, по сути до передачи данных нужны два хендшейка:
1) TCP handshake (тратим время)
2) SSL handshake (тратим время и греем ядро)
keepalive используется, чтобы сократить кол-во таких хендшейков ибо они случаются только при установлении соединения.
В итоге если например переключатель будет посылать сигнал врубить свет устанавливая https соединение, то пользователь будет видеть, что система тормозит… На рынке есть такие устройства, пытаюсь этого избегать…
Время выполнение сценария по хорошему должно вписываться в 50ms в худшем случае…
Примерно по этим-же причинам HTTP/3 реализовывают на UDP, но в глобальной сети требования к времени реакции по идее всегда будут мягче…
Не с целью критики, а только для удовлетворения любопытства: Вы не смотрели в сторону PICOBIT (http://www.ccis.northeastern.edu/~stamourv/papers/picobit.pdf)?
Не знаю Вашу конечную цель, но как рекомендацию могу обратить внимание в сторону ZigBee.
Во-первых Вы расширяете список доступных устройств, т.к. можно не только Xiaomi, но и другие вендоры, а так же самоделки. Относительно не давно пробегали счётчик Гейгера и датчик углекислого газа.
Во-вторых часть устройств умеет общаться на прямую меж собой, например у меня кнопка на прямую управляет реле и оба они отдают свои статусы в mqtt и HA (я выбрал путь через zibee2mqtt).
В-третьих, исходя из второго у Вас есть некая отвязка от HA, т.к. есть mqtt и частично прямое взаимодействие. Частично, т.к. датчик температуры не может управлять кондиционером и т.п. сценарии.
Тем не менее есть опенсорсный шлюз на основе esp32 и cc25** (в реализации возможны разные модели), что по сути есть железное воплощение мозга, что управляет на основе Ваших сценариев. С учётом его стоимости и относительно простоты изготовления или приобретения имеет смысл иметь дублирующее с теми же настройками в шкафу на всякий случай. А HA становится лишь интерфейсом, или так же берет на себя часть автоматизаций, или же отсутствует в принципе.
В-четвёртых батарейное питание!
Так же возможно будет интересно посмотреть в сторону ESPhome, мне особо нравится простая интеграция с HA, в частности у меня из ESP32 в HA прокидывается уровень сигнала BLE от Xiaomi/Amazefit браслета и часов (нужно в HA для скрипта по определению меня дома) и данные с датчика BME680, а из HA в сторону ESP32 и в конечном счёте на экран — температуры с датчиков ZigBee.
Во-первых Вы расширяете список доступных устройств, т.к. можно не только Xiaomi, но и другие вендоры, а так же самоделки. Относительно не давно пробегали счётчик Гейгера и датчик углекислого газа.
Во-вторых часть устройств умеет общаться на прямую меж собой, например у меня кнопка на прямую управляет реле и оба они отдают свои статусы в mqtt и HA (я выбрал путь через zibee2mqtt).
В-третьих, исходя из второго у Вас есть некая отвязка от HA, т.к. есть mqtt и частично прямое взаимодействие. Частично, т.к. датчик температуры не может управлять кондиционером и т.п. сценарии.
Тем не менее есть опенсорсный шлюз на основе esp32 и cc25** (в реализации возможны разные модели), что по сути есть железное воплощение мозга, что управляет на основе Ваших сценариев. С учётом его стоимости и относительно простоты изготовления или приобретения имеет смысл иметь дублирующее с теми же настройками в шкафу на всякий случай. А HA становится лишь интерфейсом, или так же берет на себя часть автоматизаций, или же отсутствует в принципе.
В-четвёртых батарейное питание!
Так же возможно будет интересно посмотреть в сторону ESPhome, мне особо нравится простая интеграция с HA, в частности у меня из ESP32 в HA прокидывается уровень сигнала BLE от Xiaomi/Amazefit браслета и часов (нужно в HA для скрипта по определению меня дома) и данные с датчика BME680, а из HA в сторону ESP32 и в конечном счёте на экран — температуры с датчиков ZigBee.
А как вы прошиваете e18 (или как там оно называется?)?
Я не нашёл простой доступной инструкции без траты $$$$$$ на коммерческую ide и конский программатор
Но очень хочу. В идеале через PIO в VSCode и китайский st-link с али за 200₽ у меня валяется парочка
если есть jlink до 1к₽ то тоже можно смириться
Вообще хочется в гости сходить/позвать обменятся опытом :) я в Москве на Марьиной роще
Я уже не Москвич, к сожалению не получится ))
Нет необходимости шить ZigBee модуль самостоятельно. Если очень хочется что-то прошить, то можно начать с ptvo. Но обычно сообщество уже всё придумало в плане необходимых конечных устройств. Заходите, почитайте sprut.ai и/или modkam.ru.
Если прям хочется самому, да ещё и через VSCode, то присоединяйтесь к нам ждунам. Есть обещания относительно ESP32-H2, которая должна уметь в ZigBee. Если так и будет и ещё немного повезёт, то завезут поддержку в VSCode.
Ничего не мешает поднять ha на том же роутере. Все равно ведь для уд с большим числом вафельных устройств абы что не подойдёт. А средняки уже вполне тянут ha
О нет. HA на роутере — невозможно… он же на python и памяти надо больше чем в роутере есть и проца, минимум raspberry pi, желательно 4gb, и это оно еще на выборках данных под графиков тормозить будет…
Если есть ссылка на описание удачного эксперимента по установке на роутер — поделитесь
Если есть ссылка на описание удачного эксперимента по установке на роутер — поделитесь
Эм, на этой страничке нет ничего про установку HA на роутер. Это инструкция как подключить роутер в качестве девайс-трекера
Не ту ссылку дал.
forum.keenetic.net/topic/9423-home-assistant
forum.keenetic.net/topic/9423-home-assistant
А ничего что малинка слабее половины средних роутеров? я уж не говорю про топовые комбайны.
У Xiaomi есть партнёрский датчик CO2/tVOC/температуры. Могу поискать название, если интересно.
Xiaomi ClearGrass Air detector
спасибо, но чот 12k многовато…
gigant-store.ru/goods/analizator-vozduha-xiaomi-mijia-cleargrass-air-detector-belyj
gigant-store.ru/goods/analizator-vozduha-xiaomi-mijia-cleargrass-air-detector-belyj
7500 на Али можно найти
Я давно закупился датчиками, но все было лень собирать.
Потом вышла эта штука и я ее чуть не купил, но вспомнил что датчики уже валяются.
Собрал из esp8266 + mhz19b + Sharp GP2Y1010AU0F + Gy-302 + 40x40x10 noctua (для воздушного потока).
Датчик температуры там будет лишним, так как даже в продуваемом корпусе теплей чем на самом деле.
Покупал все это в Москве и обошлось тыщ в 5.
Сначала наколхозил свою паршивку, а потом забил и прошился ESP Easy (данные отправляю в HA по mqtt)
wifi + датчики + вентилятор — экономить пакеты/электричество смысла ноль.
Потом вышла эта штука и я ее чуть не купил, но вспомнил что датчики уже валяются.
Собрал из esp8266 + mhz19b + Sharp GP2Y1010AU0F + Gy-302 + 40x40x10 noctua (для воздушного потока).
Датчик температуры там будет лишним, так как даже в продуваемом корпусе теплей чем на самом деле.
Покупал все это в Москве и обошлось тыщ в 5.
Сначала наколхозил свою паршивку, а потом забил и прошился ESP Easy (данные отправляю в HA по mqtt)
wifi + датчики + вентилятор — экономить пакеты/электричество смысла ноль.
ESPHome позволяет и с HA дружить и самостоятельно скрипты выполнять
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Умный дом xiaomi правильнее, чем home assistant, но можно еще правильнее