Я полагаю, что если голосовое управление хоть как-то уместно в домашней тишине, то на улице или за рулём очень много сторонних шумов и без наушников вообще есть проблема реакции устройства на посторонние сигналы, схожие с мнемоникой команд. Что ещё больше "утяжеляет" решение для ESP32
А чем обычный MQTT хуже Kafka и Кролика? И почему сравнивали не с первоисточником протокола, тщательно прописанного в документации по MQTT а с его производными? Что они улучшили? Интересно послушать, наверняка вы это прорабатывали
Поддерживаю - результатами бесконечных обсуждений в чатах должны быть Протоколы как сухой остаток. Причём Протокол должен автоматически архивировать предыдущее общение с тем, чтобы последующее уже опиралось не на предыдущую переписку, а на Протокол. Тогда механизм становится полезным. Иначе и таск-чаты и чат-таски лишь обычные болталки
Хорошая, статья, я тоже предпочитаю Клода другим ИИ при создании кода, мне нравится его стиль с учётом особенностей, которые хорошо описаны в статье, особенно тема "залипания" и само творчества. Я пришёл к схожим заключениям
А мне подход к ментальной модели понравился, вполне точно изложена работа профессионала, который прежде чем хвататься за исправление явных ошибок на скорую руку тратит определённое время на понимание общей структуры и логики продукта прежде чем приступить к каким-либо правкам.
Единственное, что удивляет в этой истории, почему РКН так щепетильно ограничился только юрлицами, ИП и самозанятыми? А как же физики? У каждого из нас записная книжка в телефоне - кладезь персональных данных и до сих пор не под контролем. Считаю это огромным упущением, над которым РКН следует тщательно поработать, причем обязывать регистрироваться при рождении, а после смерти сдавать накопленные персональные данные в архив под угрозой запрета захоронения.
Нормальная статья для исследующего возможности Питона и делящегося своими наработками. Если кто метаклассно крут в Питоне, то какой смысл комментировать? А если есть вопросы по логике решений - имеет смысл обсуждать. Я давно пишу на Питоне, но не перестаю пользоваться справочниками или подобными статьями, так как есть решения, которыми не часто пользуешься. Автор - молодец
Благодаря Вашей статье у меня начался болезненный переход к иному восприятию программирования - от линейного и даже асинхронного к машинному обучению. Парадигма программирования чего либо радикально меняется. Я только размышлял, как мне примени ь ПИД- регулятор для контроля параметров температуры и влажности при инкубации а это уже, как оказалось, глубокое прошлое. Конечно, читая статью хотелось "покапризничать", так как проработка обсуждения, доведенная до битов старт-стопа утяжелила изложение, тем не менее прекрасная работа, буду с интересом следить за Вашим творчеством. Еще раз благодарю за то, что зародили во мне новый Интерес - погрузиться в машинное обучение
А что такое "крейт" На обычном русском? Или это сленг для дистанцирования "посвященных"? И жаль, что ссылка на список архитектур не работает. А так информация хорошая, особенно про рассуждения про прерывания
Интересный подход, только в чем фишка использования английских слов на русском? Сложно писать вместо "ендпойнт" - конечная точка, "валидации" - проверка целостности и тп? Текст от этого только читабельнее был бы. Научные от этого он точно не становится. А так - молодец)
Для моих целей управления режимами инкубатора, брудера, курятника, горелки на отработке скорость не является критичной и я не заморачивался подобными исследованиями. Процессы, которыми управляю, измеряются секундами в худшем случае.
Чисто теоретически надо смотреть алгоритмы, используемые в решениях и сравнивать их по производительности, по объему используемой памяти, если есть на это время, желание и потребность
Резюме
Если вы используете ESP-NOW, потребление тока составляет около 3 мА для передачи с интервалом до 100 мс. Потребление тока увеличится примерно на 3 мА с интервалами в 10 мс
github.com/HarringayMakerSpace/ESP-Now — репозиторий одного из экспериментаторов ESP-NOW, возможно, подтолкнет к каким-либо решениям в Вашем случае. Вообще, нет ограничений на организацию иерархии, к примеру, я группирую информацию по территориальному признаку — котельная и находящийся рядом курятник или пасеку, собираю в более плотный пакет и переправляю тому, кто по смыслу может разумно распорядиться полученной информацией. В этом отношении интересны алгоритмы реализации mesh-сетей, которые должны позволить донести информацию от сенсоров и обратно к управляющим элементам по оптимальным маршрутам — если какой-либо узел перестал работать. Причем мне хочется это исполнить на MicroPython а не на C. Одна из вдохновляющих идей — здесь github.com/AnyMesh/anyMesh-Python
Что ж, мне доводилось работать в 80-е и в более тесных условия на компьютерах фирмы DEC, а также писать на разных ассемблерах, в частности для MicroVAX, Intel8080 для автоматизации экспериментов в ФИАНе, разрабатывать реляционные базы данных на С++ на основе трехтомника Кнута, и программы ведения бухучета, поэтому мне нравится сделать себе удобно и красиво в моем понимании используя MicroPytnon вместо не самого навороченного ассемблера Intel и С++ в Arduino или Platformio, так что мне золотая рыбка для воплощения моих намерений не нужна, хотя сказка красивая
Я полагаю, что если голосовое управление хоть как-то уместно в домашней тишине, то на улице или за рулём очень много сторонних шумов и без наушников вообще есть проблема реакции устройства на посторонние сигналы, схожие с мнемоникой команд. Что ещё больше "утяжеляет" решение для ESP32
А как быть с while (1)? Стек забъется и что потом?
А чем обычный MQTT хуже Kafka и Кролика? И почему сравнивали не с первоисточником протокола, тщательно прописанного в документации по MQTT а с его производными? Что они улучшили? Интересно послушать, наверняка вы это прорабатывали
Поддерживаю - результатами бесконечных обсуждений в чатах должны быть Протоколы как сухой остаток. Причём Протокол должен автоматически архивировать предыдущее общение с тем, чтобы последующее уже опиралось не на предыдущую переписку, а на Протокол. Тогда механизм становится полезным. Иначе и таск-чаты и чат-таски лишь обычные болталки
Хорошая, статья, я тоже предпочитаю Клода другим ИИ при создании кода, мне нравится его стиль с учётом особенностей, которые хорошо описаны в статье, особенно тема "залипания" и само творчества. Я пришёл к схожим заключениям
А мне подход к ментальной модели понравился, вполне точно изложена работа профессионала, который прежде чем хвататься за исправление явных ошибок на скорую руку тратит определённое время на понимание общей структуры и логики продукта прежде чем приступить к каким-либо правкам.
Единственное, что удивляет в этой истории, почему РКН так щепетильно ограничился только юрлицами, ИП и самозанятыми? А как же физики? У каждого из нас записная книжка в телефоне - кладезь персональных данных и до сих пор не под контролем. Считаю это огромным упущением, над которым РКН следует тщательно поработать, причем обязывать регистрироваться при рождении, а после смерти сдавать накопленные персональные данные в архив под угрозой запрета захоронения.
Нормальная статья для исследующего возможности Питона и делящегося своими наработками. Если кто метаклассно крут в Питоне, то какой смысл комментировать? А если есть вопросы по логике решений - имеет смысл обсуждать. Я давно пишу на Питоне, но не перестаю пользоваться справочниками или подобными статьями, так как есть решения, которыми не часто пользуешься. Автор - молодец
Для теплого пола это вполне комфортная температура
Благодаря Вашей статье у меня начался болезненный переход к иному восприятию программирования - от линейного и даже асинхронного к машинному обучению. Парадигма программирования чего либо радикально меняется. Я только размышлял, как мне примени ь ПИД- регулятор для контроля параметров температуры и влажности при инкубации а это уже, как оказалось, глубокое прошлое. Конечно, читая статью хотелось "покапризничать", так как проработка обсуждения, доведенная до битов старт-стопа утяжелила изложение, тем не менее прекрасная работа, буду с интересом следить за Вашим творчеством. Еще раз благодарю за то, что зародили во мне новый Интерес - погрузиться в машинное обучение
Мммм. А либа - это что по-русски?
А что такое "крейт" На обычном русском? Или это сленг для дистанцирования "посвященных"? И жаль, что ссылка на список архитектур не работает. А так информация хорошая, особенно про рассуждения про прерывания
Интересный подход, только в чем фишка использования английских слов на русском? Сложно писать вместо "ендпойнт" - конечная точка, "валидации" - проверка целостности и тп? Текст от этого только читабельнее был бы. Научные от этого он точно не становится. А так - молодец)
Хороший подход, понравилась Парадигма избегать раньше времени погружения в поиск Цикла. Отвлекает от Сути. Браво!
Хорошая работа, интересно продолжение. Если встаёт Linux, то и Python приложения влезут, поди
Для моих целей управления режимами инкубатора, брудера, курятника, горелки на отработке скорость не является критичной и я не заморачивался подобными исследованиями. Процессы, которыми управляю, измеряются секундами в худшем случае.
Чисто теоретически надо смотреть алгоритмы, используемые в решениях и сравнивать их по производительности, по объему используемой памяти, если есть на это время, желание и потребность
Резюме
Если вы используете ESP-NOW, потребление тока составляет около 3 мА для передачи с интервалом до 100 мс. Потребление тока увеличится примерно на 3 мА с интервалами в 10 мс