1) Устройство просыпается и смотрит есть ли init файл
2) Если нет - становиттся точкой доступа и принимает код lisp, если есть исполняет его
3) Для загрузки init надо вызвать init-save, аргмент функции записывается в память устройство
Надо сказать, что воды утекло много, я уж дом этим оборудовал. Ленты/Вентмашина/Бак с водой/LED ленты/Свет всё на потомке описанной системы. Правда вместо esp8266 использую esp32 и esp32s2
Клиент на python, работает на всём… я всем этим на макбуке занимаюсь. Весь софт/ прошивки/интаеграция в HA/утилиты тут github.com/bskaplou/iot_home_esp8266_POC. С железом всё предельно просто — пихаем i2c к ногам i2с и spi к ногам spi… Особо нечего тут документировать
Таки да, но:
1) это не очень спортивно…
2) скрипты предлагаемые и home assistant и esphome — занятные, но очень ограничены относительно полноценных ЯП и по возможностям и по выразительности… lisp ощутимо удобнее/богаче…
О нет. HA на роутере — невозможно… он же на python и памяти надо больше чем в роутере есть и проца, минимум raspberry pi, желательно 4gb, и это оно еще на выборках данных под графиков тормозить будет…
Если есть ссылка на описание удачного эксперимента по установке на роутер — поделитесь
Но чтобы получить шифрованный https канал для rest общения нужно потрать пригоршню тактов и десятки миллисекунд времени, по сути до передачи данных нужны два хендшейка:
1) TCP handshake (тратим время)
2) SSL handshake (тратим время и греем ядро)
keepalive используется, чтобы сократить кол-во таких хендшейков ибо они случаются только при установлении соединения.
В итоге если например переключатель будет посылать сигнал врубить свет устанавливая https соединение, то пользователь будет видеть, что система тормозит… На рынке есть такие устройства, пытаюсь этого избегать…
Время выполнение сценария по хорошему должно вписываться в 50ms в худшем случае…
Примерно по этим-же причинам HTTP/3 реализовывают на UDP, но в глобальной сети требования к времени реакции по идее всегда будут мягче…
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 вещь, но изменение конфигурации требует перепрошивки…
>>При наличии большого количества устройств если спаривать их все вручную друг с другом займет кучу времени.
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.
>>Запускайте HA на имеющемся в доме устройстве бесплатно.
Такой подход ограничивает проникновение технологий в дома людей у которых нет docker сервера в шкафу.
>>И, если на то пошло, у вас в любом случае есть single point of failure — ваш роутер.
Так оно и есть, суть улучшения отказоустойчивости в сокращении кол-ва точек отказа.
>>Да и умный дом у вас не Xiaomi, а на железе Xiaomi с паяльником.
А те устройства о которых речь в статье вообще к xiaomi отношения не имеют :)
Так статья жжж блин о том что:
1. Централизованная система типа HA не лучший вариант
2. Xiaomi децентрализованный и поэтому хорош, но скрипты урезают возможности
3. Собрал устройства
4. Сделал прошивку которая позволяет вместо сценариев xiaomi исполнять тюринг полные программы на lisp
Я могу связать свои устройства с устройствами xiaomi реализовав функцию xioaomi-request, с протоколом я уж неплохо знаком :)
Другие сложнее но 4-5 под протоколов сложности xiaomi-miio памяти хватит
Я создал устройства и прошивки в которых есть полноценный процессор сценариев, а на примерах показал что мощностей современного MCU достаточно для этого.
Скрипт засылается на устройство тригерящее событие
При появлении события на устройстве оно проверяется на соответствие входным условиям всех скриптов.
Затем выполняются команды сматчившихся скриптов.
Команды могут относиться как к устройству стриггерившему событие так и к другим устройствам. Во втором случае будет послан пакет xiaomi-miio в сторону удаленного устройства
Подробно исследовано вот тут habr.com/ru/post/503570. У xiaomi если в строю устройства задействованные в сценарии работают — сценарий будет выполнен. Сервера xiaomi в сценариях не задействуются. Для HA сверх того нужен рабочий HA.
На момент отказа от lua, уже было понимание, что при активном обмене сообщениями между устройствами, важна простота программной генерации кода (может породить skynet), тут lisp вне конкуренции… Поэтому micropython глубоко не рыл…
Тестировать уже можно питоновский API и CLI интерфейс взяв код отсюда github.com/rytilahti/python-miio/pull/709
Чтобы появилось в home assistant надо дождаться принятия пула — там чуть протормоз так как я ждал рефакторинга другого комитера.
Как случится релиз python-miio сделаю пул в home assitant и после его релиза будет у всех…
P.S. Я то быстрый, но приходится ждать комьюнити ;(
Скрипт хранится в памяти устройства...
Общий подход такой:
1) Устройство просыпается и смотрит есть ли init файл
2) Если нет - становиттся точкой доступа и принимает код lisp, если есть исполняет его
3) Для загрузки init надо вызвать init-save, аргмент функции записывается в память устройство
Надо сказать, что воды утекло много, я уж дом этим оборудовал. Ленты/Вентмашина/Бак с водой/LED ленты/Свет всё на потомке описанной системы. Правда вместо esp8266 использую esp32 и esp32s2
1) это не очень спортивно…
2) скрипты предлагаемые и home assistant и esphome — занятные, но очень ограничены относительно полноценных ЯП и по возможностям и по выразительности… lisp ощутимо удобнее/богаче…
gigant-store.ru/goods/analizator-vozduha-xiaomi-mijia-cleargrass-air-detector-belyj
Если есть ссылка на описание удачного эксперимента по установке на роутер — поделитесь
Но руки у меня всего 2, версии для Xtensa нет… кажется он заброшен 9 лет назад ;(
Но чтобы получить шифрованный https канал для rest общения нужно потрать пригоршню тактов и десятки миллисекунд времени, по сути до передачи данных нужны два хендшейка:
1) TCP handshake (тратим время)
2) SSL handshake (тратим время и греем ядро)
keepalive используется, чтобы сократить кол-во таких хендшейков ибо они случаются только при установлении соединения.
В итоге если например переключатель будет посылать сигнал врубить свет устанавливая https соединение, то пользователь будет видеть, что система тормозит… На рынке есть такие устройства, пытаюсь этого избегать…
Время выполнение сценария по хорошему должно вписываться в 50ms в худшем случае…
Примерно по этим-же причинам HTTP/3 реализовывают на UDP, но в глобальной сети требования к времени реакции по идее всегда будут мягче…
Угу ESPHome тоже почему-то считают что SPoF в виде HA и MQTT это плохо, нас — еретиков кажется много :)
ESPHome вещь, но изменение конфигурации требует перепрошивки…
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.
В пору создавать список «датчики которым нельзя верить»
Уточните связь между SPoF и способом настройки…
Такой подход ограничивает проникновение технологий в дома людей у которых нет docker сервера в шкафу.
>>И, если на то пошло, у вас в любом случае есть single point of failure — ваш роутер.
Так оно и есть, суть улучшения отказоустойчивости в сокращении кол-ва точек отказа.
>>Да и умный дом у вас не Xiaomi, а на железе Xiaomi с паяльником.
А те устройства о которых речь в статье вообще к xiaomi отношения не имеют :)
1. Централизованная система типа HA не лучший вариант
2. Xiaomi децентрализованный и поэтому хорош, но скрипты урезают возможности
3. Собрал устройства
4. Сделал прошивку которая позволяет вместо сценариев xiaomi исполнять тюринг полные программы на lisp
Я могу связать свои устройства с устройствами xiaomi реализовав функцию xioaomi-request, с протоколом я уж неплохо знаком :)
Другие сложнее но 4-5 под протоколов сложности xiaomi-miio памяти хватит
Я создал устройства и прошивки в которых есть полноценный процессор сценариев, а на примерах показал что мощностей современного MCU достаточно для этого.
То есть автор www.jaredwolff.com/finding-the-best-tvoc-sensor-ccs811-vs-bme680-vs-sgp30 работает на врагов и всё врет глубоко заблждаясь?
При появлении события на устройстве оно проверяется на соответствие входным условиям всех скриптов.
Затем выполняются команды сматчившихся скриптов.
Команды могут относиться как к устройству стриггерившему событие так и к другим устройствам. Во втором случае будет послан пакет xiaomi-miio в сторону удаленного устройства
github.com/rytilahti/python-miio/blob/fd563968baab5f4a1cca16566a2e79f169e9d08a/miio/gateway_scripts.py#L58-L90
По ссылке код генерящий такие скрипты в формате xiaomi… Они втыкаются не с первого раза — в этом минус протокола… Я счлёл что сценарии на lisp получатся и понятнее и мощнее чем скрипты в xiaomi-miio
github.com/rytilahti/python-miio/pull/709
Чтобы появилось в home assistant надо дождаться принятия пула — там чуть протормоз так как я ждал рефакторинга другого комитера.
Как случится релиз python-miio сделаю пул в home assitant и после его релиза будет у всех…
P.S. Я то быстрый, но приходится ждать комьюнити ;(