Comments 26
Рецензия от ChatGPT
Коротко о главных противоречиях в тексте
Команда ↔ одиночка. Автор говорит, что «развиваю RuFA Hub вместе с небольшой командой» — и почти сразу заявляет: «я — единственный разработчик проекта».
Зрелый продукт ↔ сырой альфа. Сначала RuFA Hub описан как уже «универсальный центр взаимодействия», но спустя несколько абзацев называется «стадией альфы, которую автор регулярно переписывает».
От «говорящей банки» к всеядной шине. Проект стартовал как простая колонка, подающая питание на пины, а мгновенно стал маршрутизатором «между чем угодно», без чёткого объяснения перехода.
А так вообще не понял что это и даже GPT не сильно помог. Скорее всего плохая копипаста с DeepSeek
Спасибо за обратную связь. Да у нас действительно есть небольшая команда где у каждого своя роль, так вышло что роль программиста есть только у автора статьи. Насчёт последнего пункта вы правы. Переход в статье не оптсан, это связано с тем что колонка осталась пока на бумаге, для её создания мне (схемотехника в команде) не хватает опыта и средств, а то что описано в статье можно реализовать на готовых и бюджетных решениях, по этому это направление было выбрано как основное, а колонка отправилась в ящик будущих идей. Я рад что Demorien горит идеей и находится в постоянной работе над ошибками и улучшениями, и я очень рад что наш проект не безразличен энтузиастам. На данный момент ведётся работа над созданием видео с популярным объяснением нашего проекта, в связи с этим так же разрабатывается демонстрационный стенд. Ещё раз спасибо за почву для размышлений
а почему не показал «умную лампу»?
и ссылки нет на опенсурс.
Спасибо за замечание. Ссылка на открытый репозиторий: GitHub репозиторий
Буду признателен за обратную связь.
На данный момент эта ветка проекта ушла на второй план из за сложности реализации, стоимости, и отсутвии программной базы. Мы решили сначало разработать всю систему, а уже потом внедрить в неё "Умную лампу".
это уже не просто проект для диплома, а универсальный центр взаимодействия между чем угодно: микроконтроллерами, внешними программами, скриптами, оборудованием, софтом.
1) Судя по описанной реализации данный роутер работает медленно, так как использует скриптовые языки. Я прав?
2) В любой сети есть адреса источника и приемника. Можете объяснить, чем Ваше решение лучше концентратора беспроводной mesh или роутера проводной сети на основе протокола TCP/IP ?
Спасибо за интерес к проекту! Постараюсь по порядку:
Вообще, я использовал Python, потому что это единственный язык, которым я действительно свободно владею и на котором могу быстро писать. Хотелось сделать работающий проект, а не застрять на изучении нового языка. Конечно, если бы выбирал с точки зрения производительности, то C++ подошёл бы лучше, но Python позволил быстро собрать всё воедино и запустить.
Да, роутер и mesh — нормальное сравнение, но тут немного другая история. Это не сетевое оборудование, а скорее серверное ПО, которое получает данные от микроконтроллеров и направляет их в нужные модули на сервере. А дальше уже каждый модуль делает своё: логирование, уведомления, анализ, отправка в сторонние сервисы — что угодно.
То есть, грубо говоря, это не про маршрутизацию сетевых пакетов, а про логическую маршрутизацию данных и событий внутри системы. Устройства скидывают данные, сервер разбирает, что куда, и рассылает по нужным обработчикам. Всё это можно кастомизировать под конкретные задачи, и архитектура легко расширяется.
Архитектура довольно лёгкая: весь RuFA Hub весит около 89 МБ
89 МБ для IOT это много. На каких микроконтроллерах Вы это предлагаете реализовать?
Спасибо за вопрос!
Да, 89 МБ — это действительно много для микроконтроллеров, и я не планирую запускать сам RuFA Hub прямо на них. Это серверное ПО, которое работает на полноценном сервере или ПК, а не на микроконтроллерах.
Микроконтроллеры — это просто устройства, которые отправляют данные в этот сервер. Сам RuFA Hub принимает эти данные, обрабатывает и распределяет по модулям уже на стороне сервера. Поэтому ограничения по памяти микроконтроллеров тут не влияют на работу Hub’а.
Если нужна лёгкая версия прямо для микроконтроллера — это уже отдельная история, где придётся делать сильно урезанный функционал или писать совсем на низком уровне.
детский сад. на диплом, конечно потянет, но "Что-то вроде роутера, но не для интернета, а для логики и взаимодействия между устройствами." "роутер для логики" ёпрст. для взаимодействия есть куча уже готовых протоколов любой сложности. самый широко известный, легкий, надежный, промышленный - mqtt. Возможно надо для начала (как это и положено в дипломных работах) провести анализ и выбрать уже существующие технологии и оборудование? велосипедостроением можно и нужно заниматься, но в основном для собственного развития и дальнейшего осмысления почему в промышленности сделано так, а не иначе.
Что же с лампой то? И почему на esp32, а не 8266 или другом mcu. какой функционал лампы и в чем ее "умность"? сразу виден "подход инженера" - из говна и палок, вместо того, чтобы взять готовое устройство и модифицировать его под свои нужны. Почему инженер сам не писал прошивку? он вообще как разрабатывал свое устройство?
"сервер на Python" - сервер чего? какой протокол взаимодействия?
"логику, маршрутизацию и действия, чтобы они не мешали друг другу. " да уж.. главное, мне кажется, чтобы логика вам в проекте не мешала, ее надо отдельно маршрутизировать в dev/null
жесть, конечно. если такое будет работать в газпроме, то всё... кранты.
Спасибо за ваш комментарий. На данный момент мы уже поняли что объяснить что такое наш проект в полном спектре тяжело, с этой целью были написаны статьи в Дзен и Хабр, благодаря вашему клиенту мы поняли на что ещё нужно обращать внимание, на данный момент ведётся работа по созданию видео с популярным объяснением и демонстрацией работы проекта на тестовом стенде.
история RuFA Hub
систему маршрутизации пакетов между микроконтроллерами? Что-то вроде роутера, но не для интернета, а для логики и взаимодействия между устройствами.
Основная идея: разделить логику, маршрутизацию и действия, чтобы они не мешали друг другу.
1) Так что же Вы сделали, hub, роутер или маршрутизатор?
2) Каким образом Вы устранили коллизию пакетов? Почему пакеты перестали мешать друг другу?
Это скорее hub, но не в классическом сетевом смысле. Это серверное ПО, которое принимает данные с разных микроконтроллеров и направляет их в разные модули на сервере. Каждый модуль выполняет свои задачи — логирует, анализирует, отправляет уведомления и так далее. Главное — разделить логику, маршрутизацию и действия, чтобы они не мешали друг другу.
Коллизии пакетов здесь решаются на уровне протокола и логики приложения. Пакеты собираются в буфер в течение определённого времени (например, 2 секунды), проверяются на наличие специальных токенов или меток и только после этого передаются в обработку. Так данные не пересекаются и не мешают друг другу, потому что их обработка происходит по очереди и по заданным правилам.
Пакеты собираются в буфер в течение определённого времени (например, 2 секунды), проверяются на наличие специальных токенов или меток и только после этого передаются в обработку.
То есть лампочка включится через 2 секунды после нажатия на выключатель? У - удобство!
Не совсем понял про это "разделение" и что там может чему мешать.
Маршрутизация - вообще какое-то неподходящее слово. Маршрутизация может быть в сети, когда сеть сложная и надо понимать, на какой физический порт надо отдать пакет, чтобы он ушел дальше по своему логическому адресу. Ну и если физических маршрутов может быть несколько, то надо выбрать наиболее оптимальный. А здесь больше на диспетчеризацию похоже. Только вот не очень понятно, зачем оно вообще надо, что мешает пакет-команду от контроллера, к примеру, послать сразу исполняющему устройству на какой-то URL/порт?
Зачем копить пакеты в буфере, тратить на это память и вносить дополнительные коммуникационные задержки? Какой профит от этого? По-хорошему это вообще все многопоточкой должно обрабатываться, даже на одноядерной системе задержки на прием/передачу/логирование позволят работать с несколькими пакетами одновременно, пусть и с переключением ядра между ними. Пока процессор ожидает ответа от сетевой карты и HDD/SSD можно чем-то другим полезным заняться. Ну, а если скорости не хватает обрабатывать все приходящие пакеты, то просто очередь организуется, памяти будет выделяться столько, сколько надо, безо всяких специальных накоплений и лишних задержек. Если придет один пакет (ну или несколько, если ядер много) будут обрабатываться мгновенно, если пакетов много, то подождут в очереди, тут ничего не попишешь, но и они будут обрабатываться сразу по мере возможности.
Не вчитывайтесь в каждое слово душнил с хабра и продолжайте развивать свой проект)
Для 17 лет это большое дело, если вы нашли для себя то, что вас вдохновляет и помогает двигаться дальше)
Уверен, дальше вы столкнетесь с ещё большим рядом проблем, которые заставят вас пересматривать многое в вашем проекте, но именно так вы будете расти)
Удачи вам и не теряйте искру)
я искал этот комментарий
Спасибо, очень приятно такое слышать!
Для меня это действительно важно — не только сам проект, но и то, как я расту и учусь в процессе. Да, проблем будет много, и, наверное, ещё больше, но это часть пути. Буду стараться не сдаваться и двигаться дальше.
Спасибо, я тоже состою в команде этого проекта (у нас поделены роли, автор статьи пишет ПО, а остальные занимаются задачами) и мне приятно слышать что идея Demorien хорошая, сейчас ему не хватает поддержки
Красавчик мужик, для 17 лет довольно неплохо, удачи тебе в будущем
Так и не понял, что это такое и зачем надо.
универсальный центр взаимодействия между чем угодно
Не "между чем угодно", а тем, что поддерживает определенный протокол. Т.е. это "что угодно" либо написано вами, либо поддерживает плагины, которые еще тоже надо написать, либо требуется какой-то прокси-преобразователь из протокола этого агента в протокол RuFA Hub. На выходе чуть попроще, там уже плагины предусмотрены, которые в принципе что угодно сделают. Просится нечто подобное и на входе, которое может не только JSON принимать, но и XML, protobuf, plain text, любые кастомные данные и т.д. А еще не только в пассивном режиме работать, но и в режиме опроса "чего угодно". Вот тогда будет универсально. А потом придет понимание, что неплохо бы написать несколько универсальных модулей, которые покрывают 90% кейсов взаимодействия и описывать data flow декларативно, через конфигурацию этих модулей, а не писать новый плагин на каждый чих.
Вот тогда это превратится в реально универсальную шину для "чего угодно".
Но это охрененно сложная задача даже для людей с опытом, а не только первокура.
Не особо понял что это, не особо понял для чего это. Ну, не может простой маршрутизатор пакетов весить 89 мегабайт на питоне, значит это что-то другое.
Совсем не понял почему хвост виляет собакой конечное устройство само решает кому ему маршрутизировать пакет. Если мой выключатель шлёт пакеты лампочке в туалете, а потом я решу выключать им свет в ванной, то придётся перепрограммировать либо выключатель либо две лампочки вместо того, чтобы перестроить маршрут в маршрутизаторе - я правильно понял? Какое это даёт преимущество?
Как я хотел сделать говорящую банку, а получилось нечто гораздо большее: история RuFA Hub