Сообщений в теме: 490

[lexx8691]

Не думаю, что облако будет обязательным. Пока такую формулировку оставлю. 

 

Хочется сделать шину на уровне локальной сети тоже. В частности по широковещательному UDP. 

 

1. Думаю как раз облако обязательно. Как параллельный инструмент управления и способ обмена настройками между пользователями.

Вы посмотрите сколько тем  "поделитесь пресетами", кому то жалко, ну ладно, кому то неохото скидывать, кто то тему не увидел, а поделиться не против.

С облаком эти вопросы отпадают.

Да и иногда необходимо получить удаленный доступ к управлению устройствами и тем более мониторингу.

2. Это большой плюс для обмена между устройствами, обходим интернет стороной

[balabollng]

1. Видится мне концепция такой: хочешь брать, нужно отдавать.

 

Т.е. если пользователь захочет пользоваться базой спектров например, то он автоматом будет соглашаться на публикацию своих спектров. 

 

Но право согласия останется за ним. Т.е. сама прошивка не будет публиковать что-либо в облако без разрешения пользователя.

 

Таким образом, предполагается, создать некую социалку, где у всех появится возможность анализировать опыт. Естественно обезличенный.

 

2. Да. Тут вопросов будет гораздо меньше. Кто захочет будет создавать совершенно локальные связи устройств. 

[lexx8691]

Ну и плюс к этому облако должен кто то содержать, хостинг ведь не бесплатный.

[balabollng]

Ну и плюс к этому облако должен кто то содержать, хостинг ведь не бесплатный.

 

Облако будет выполнено так, что стоимость его содержания будет очень условна. А проект облака также открыт. Но это отдельная история. Совсем отдельная. 

[serpantins]

Какая база спектров, какие пресеты? Если это только контроллер, то диоды будет каждый свои ставить.....

[lexx8691]

Естественно, но уже сложились схемы которые повторяют. 

Потом надеюсь светом не ограничится проект. Ту же схему работы помп зачем изобретать каждый раз?

[balabollng]

Какая база спектров, какие пресеты? Если это только контроллер, то диоды будет каждый свои ставить.....

 

Все те же. Люди используют решения в том числе - готовые. Ровно потому, что хотят иметь качественный свет. Да, будет часть людей кто поставить китайскую рассыпуху. Но их не более 50%. Остальные же, зачастую, используют готовые решения по сборкам диодов. И вполне смогут делиться спектрами. 

 

У Алексея например вообще ID сборки в саму сборку вшивается. И вполне можно сделать автоматическую идентификацию. 

[lexx8691]

Точно у меня многие покупают сборки, а управляют ими ардуинами и другими контроллерами.

Потом есть сборки и матрицы с али они то же одинаковые. Да и единицы экспериментируют со своим набором диодов в основном да же на звездах цвета и соотношения повторяются. В итоге светильники очень похожи по спектру, отличаются эффективностью.

[serpantins]

Остальные же, зачастую, используют готовые решения по сборкам диодов. 

 

Может быть да, а может и свои сборки используют....Это нужно учитывать так же....

[avfv]

Получается, что скрипты будут двух классов - одни работают внутри устройств и имеют доступ к оборудованию, а вторые висят на общей шине и видят только ее. По мне так первый класс избыточен - их функционал проще в коде прошивки устройства сделать.

 

Почему именно UDP? У него собственно одно достоинство - на ESP32 так сделать проще всего. От общей шины хочется возможности интегрировать несколько универсальных плат в одно устройство - например у нас есть плата измерителя pH, плата ШД дозатора и плата розеток - втыкаем их в общую шину, назначаем им роли, загружаем скрипт - и получаем контроллер кальциевого реактора.

 

Предлагаю шину не изобретать заново, а взять CAN. Еще лучше, взять CAN FD, там можно будет в сообщениях короткие JSONы гонять, не наворачивая сложных протоколов.

[serpantins]

 Да и единицы экспериментируют со своим набором диодов в основном да же на звездах цвета и соотношения повторяются. В итоге светильники очень похожи по спектру, отличаются эффективностью.

И да и нет, но , оставить возможность для творчества стоит. 

[lexx8691]

Получается, что скрипты будут двух классов - одни работают внутри устройств и имеют доступ к оборудованию, а вторые висят на общей шине и видят только ее. По мне так первый класс избыточен - их функционал проще в коде прошивки устройства сделать.

 

Почему именно UDP? У него собственно одно достоинство - на ESP32 так сделать проще всего. От общей шины хочется возможности интегрировать несколько универсальных плат в одно устройство - например у нас есть плата измерителя pH, плата ШД дозатора и плата розеток - втыкаем их в общую шину, назначаем им роли, загружаем скрипт - и получаем контроллер кальциевого реактора.

 

Предлагаю шину не изобретать заново, а взять CAN. Еще лучше, взять CAN FD, там можно будет в сообщениях короткие JSONы гонять, не наворачивая сложных протоколов.

???

Это в другую тему, тут ESP32 и только.

 

 

И да и нет, но , оставить возможность для творчества стоит. 

Неправильно меня понял, я это все написал по поводу обмена спектрами, а наборы каналов конечно должны создаваться пользователем без всяких ограничений по порядку и названиям, в т.ч. и назначить какой то из каналов релейным для МГ или ЛЛ.

[BorisKramer]

Почему именно UDP? У него собственно одно достоинство - на ESP32 так сделать проще всего. От общей шины хочется возможности интегрировать несколько универсальных плат в одно устройство - например у нас есть плата измерителя pH, плата ШД дозатора и плата розеток - втыкаем их в общую шину, назначаем им роли, загружаем скрипт - и получаем контроллер кальциевого реактора.

Предлагаю шину не изобретать заново, а взять CAN. Еще лучше, взять CAN FD, там можно будет в сообщениях короткие JSONы гонять, не наворачивая сложных протоколов.

Так это вы уже мой “идеальный аквакомпьютер” описываете

[avfv]

ESP32 имеет в том числе и поддержку CAN А "идеальный компьютер" все же закрытое решение.

[bbasil]

 

 

Почему именно UDP? У него собственно одно достоинство - на ESP32 так сделать проще всего. 

не только, основное его преимущество в том, что UDP не требует подтверждения доставки пакета, в отличии от TCP.

[balabollng]

Получается, что скрипты будут двух классов - одни работают внутри устройств и имеют доступ к оборудованию, а вторые висят на общей шине и видят только ее. По мне так первый класс избыточен - их функционал проще в коде прошивки устройства сделать.

 

Почему именно UDP? У него собственно одно достоинство - на ESP32 так сделать проще всего. От общей шины хочется возможности интегрировать несколько универсальных плат в одно устройство - например у нас есть плата измерителя pH, плата ШД дозатора и плата розеток - втыкаем их в общую шину, назначаем им роли, загружаем скрипт - и получаем контроллер кальциевого реактора.

 

Предлагаю шину не изобретать заново, а взять CAN. Еще лучше, взять CAN FD, там можно будет в сообщениях короткие JSONы гонять, не наворачивая сложных протоколов.

 

Не так. Первые имеют доступ к API которые дает контроллер. Никакого доступа они к железу самостоятельно не имеют. Они же получают события которые приходят из шины или генерируются самим контроллером. И они же могут генерировать события в шину. 

 

Шина это не физическая реализация, а логическая. Она не заменяет физические шины. Это шина данных. Я особо это подчеркнул ранее. То, что должно быть подключено по проводам, так и будет подключено. Но скрипты об этом знать не будут. Они просто отсылают некое сообщение которое доставляется другим устройствам на шине. Как им знать не положено. За это отвечает системный уровень.

 

Да, по UDP потому, что пока это сделать проще всего. Потом можно и CAN добавить и 1W. Т.е. расширять физические каналы передачи. Но не все сразу. 

[balabollng]

ESP32 имеет в том числе и поддержку CAN А "идеальный компьютер" все же закрытое решение.

 

Расширять средства доставки можно будет без проблем. Пишешь шлюз и и вперед. 

[balabollng]

Так, сегодня достиг прогресса, связал два проекта WEB и С. 

 

Теперь можно почеловечески разрабатывать на PHPStorm, компилировать страницу webpack и тут же ее вкомпиливать в прошивку на С

 

Сам проект WEBстраницы контроллера будет с локальным сервером эмулирующим API самого контроллера. Что позволит легко разрабатывать вебчасть без постоянной перепрошивки. 

 

Да собственно web-часть я сразу и опубликую - https://github.com/rpiontik/athom_web

 

С С там есть еще нюансы по развертыванию и его публиковать сейчас рано, т. к. без мануала это сделать не выйдет. 

[BorisKramer]

ESP32 имеет в том числе и поддержку CAN А "идеальный компьютер" все же закрытое решение.

Идеальный компьютер - это идеология.

А реализацию может сделать кто угодно, как железа так и софта.

Он там совершенно примитивный и не требует и 10% умных терминов, которые написаны в этой теме

[BorisKramer]

не только, основное его преимущество в том, что UDP не требует подтверждения доставки пакета, в отличии от TCP.

скорее недостаток