Добрый день! Спасибо за конструктивные комментарии.
По поводу модуля часов реального времени — у нас давно был вопрос, стоит ли добавлять его в базовую комплектацию. Однако ни одного реального запроса на эту функцию мы не получили, поэтому решили не усложнять плату и не добавлять дополнительные элементы, которые в 99% проектов оставались бы невостребованными.
У нас есть разработанный модуль, который включает несколько вариантов часов реального времени, EEPROM и сторожевой таймер. Но мы не запускали его в производство из-за отсутствия спроса. Если такой запрос есть, можем вернуться к этому проекту — на складе даже есть определенное количество таких модулей. Реализация часов реального времени и EEPROM в текущих платах не представляет сложности.
Кроме того, сторожевой таймер тоже был запланирован и на самих платах Lavriboard, но фактически в реализуемых нами проектах он не требовался. Этот модуль можно установить практически в любой из нескольких доступных сокетов на наших платах.
Но, опять же, важна реальная потребность. Если есть интерес, можем не только поднять проект, но и опубликовать схему, чтобы обсудить, какие часы или сторожевые таймеры предпочтительнее и какой функционал действительно необходим. Пока мы не развивали это направление именно из-за отсутствия реальных запросов.
Схемы плат не публикуются, входы и выходы расположены на модулях расширения. В данном проекте это Modbus диммеры и реле Wiren Board, в других проектах — модули расширения Lavritech. Схем в публичном доступе у нас нет.
Наша зона ответственности в данном проекте заканчивается на виртуальной машине. Заказчик нам предоставляет работающий компьютер с Windows и AnyDesk. Может быть, это много слоев абстракции, но включить компьютер на Windows проще. Статистически намного больше людей умеют это делать, и если компьютер сломается, проще дать другой аналогичный компьютер. Если машина вышла из строя, у нас есть образ, а вот найти человека, кто может предоставить такой же хост на чем-то еще, куда сложнее. На HA решение переходное, в дальнейшем планируем перейти на контроллер Lavritech для такого простого сценарного освещения. У нас есть облачный доступ к веб-интерфейсу контроллера, и мы удаленно там все настраиваем, плюс бэкапы конфигурации в один клик делаются на сервер.
Да, вы все правильно сказали. Уже есть настроенный образ VirtualBox с HA, заранее настроенный для тиражирования. Установка VirtualBox понятна любому пользователю без квалификации: достаточно импортировать машину, и сервер работает. Контроллер Lavritech знает все устройства, используемые в сборке, из коробки и пробрасывает их в MQTT в несколько кликов. При этом дальше планируем отказаться от HA и сделать простые сценарные кнопки внутри Lavritech.
Мы идем к тому, чтобы настройку и обслуживание системы могли делать и электрик, и студент, и среднестатистический системный администратор. Поэтому стараемся использовать более простые технологии, с точки зрения IT-специалистов это не сильно рационально. Но в реальности это будет барьером по квалификации, особенно в глубинке.
Спасибо за вопрос, эти пины доступны на SOCKET WB 1.1, он становится SPI разъемом, так что ничего не пропадает. Это позволяют делать перемычки R68, R69, R71, R73, R72, R66.
Добавим немного фиктивности: каждый контроллер получает информацию с лора-датчика на улице, и эту метрику можно вставлять в термостат вместе с показателем температуры в помещении. Предвижу комментарии, что завеса не является обогревательным прибором, но так уж сложилось, что люди на входе, охранники и другие, включают её, чтобы погреться, и забывают выключить, когда становится жарко. Такое часто происходит на КПП павильонного типа, где нет тамбура. Сам павильон на входе и выходе имеет завесы, поэтому запрет на ручное управление нужен, и можно выключать завесу, когда в помещении жарко. Второй критерий - это подсчет количества импульсов в единицу времени с датчика движения. Предполагается, что если количество импульсов меньше определённого порога, то это можно считать отсутствием движения. Это оборудование уже есть в текущих сборках, но как будет на деле, мы узнаем, когда появится статистика ближе к весне. Ключевое в этом процессе - локальный контроллер, который будет доступен всем и не потребует построения сложных систем на объектах для экономии.
Вы абсолютно правы, что интерфейс для ручного управления в данном случае не является приоритетом, и мы тоже не хотим превращать систему в очередную диспетчеризацию, которой никто не пользуется. Основная ставка сделана на статистику, которая позволяет создавать автономные ячейки на основе комплекта: завеса + контроллер Lavritech + датчики движения и температуры. Именно эти ячейки будут самостоятельно принимать решения о необходимости работы завесы, что существенно снижает потребность в ручном вмешательстве.
Сейчас мы как раз планируем добавить датчики движения для подсчета трафика через существующие реле с импульсными входами. Кроме того, обсуждается настройка температурного порога для наружной температуры, при котором завеса может быть отключена. Это позволит гибко управлять работой завес в зависимости от реальной ситуации.
Графическая визуализация (графики, метрики) действительно остается вспомогательным инструментом. Она поможет подтвердить, что система работает корректно и настройки применяются правильно, но основную работу будет выполнять контроллер Lavritech.
Цель — создать полностью автономный комплект, который способен учитывать множество факторов (трафик, температуры внутри и снаружи) для принятия решений о работе завесы. Пока для завес это лучший подход, который мы видим. Но в будущем, по мере развития технологий и искусственного интеллекта, возможно, удастся перейти на более сложные и точные алгоритмы управления. Инфраструктура для этого уже создается сейчас за счет централизации оборудования.
Проект прошел два основных этапа. На первом этапе мы свели данные о работе тепловых завес в единую систему. Это включало фиксацию информации о текущих режимах работы, расходах, температурах, а также состоянии каждой завесы (работает или нет). Таким образом, мы получили базовую картину работы системы, необходимую для дальнейшего анализа.
На втором этапе была разработана метрика, позволяющая оценивать энергопотребление по всему объекту. Метрика формируется ежедневно и ежемесячно, с возможностью сравнения текущих данных с аналогичными показателями за прошлый год. Это позволило выявить общие тенденции и ключевые точки, где расход энергии может быть оптимизирован.
Сейчас мы находимся на третьем этапе, который заключается в выявлении и разработке алгоритмов управления для каждой конкретной завесы. Эти алгоритмы будут привязаны собранных данных и учитывают параметры, такие как трафик, температурные условия и особенности каждой зоны, к сожалению завеса это не конвектор, которую можно привязать к температуре в помещение. С алгоритмом управления прийдется повозится, на данный момент 3 этап еще не реализован.
Похоже прийдется писать еще одну статью, делать анализ загрузки шины логическим анализатором и сравнивать оба подхода с цифрами. В данной статье была задача рассказать именно о прикладной пользе быстрого Modbus и о том, что не так сложно его интегрировать в уже существующие решения если нахватает быстродействия шины.
ESP32 занят опросом шины постоянно, если опрашивать 50 устройств на шине и требуется реакция 1 секунда, нужно за эту секунду прочитать все 50 устройств и обработать данные с них, если взять таки сложные устройства как MAP12E, то это более сотни регистров на одно устройство. Но быстрая реакция требуется не для всех устройств, поэтому включив быстрый Modbus, мы не делаем короткий интервал опроса для всех, быстро опрашиваются только устройства требующие быстрого отклика. Возможно выше была не точность. Точнее было бы сказать, что ESP32 занят избыточными опросами других устройств и мы освобождаем это время на устройства, которым действительно нужен быстрый отклик.
Критерий подходит устройство для ПЛК или нет , определяется принципом построения его ПО, в контроллерах Lavritech концепция сильно отличается от классических ПЛК. У нас есть что то похожее на каталог приложений, которые можно загружать в контроллер по воздуху, в зависимости от задачи и требуемых функций. Сам же встроенный обработчик сценариев достаточно медленные по меркам ПЛК, зато человек может быстро скачать из каталога нужно приложение, немного его настроить и решить свою задачу. При работе же ПЛК есть среда разработки, которая позволяет в визуальном редакторе строить сложные алгоритмы, задавать задержки и тд. ПЛК очень быстро обрабатывает в реальном времени процессы, там крайне важны тайминги. Наше же ПО заточено под быстрое решение задач мониторинга и домашней автоматизации, сбора данных, обработки простых алгоритмов, Термостаты, планировщики задач, работа по расписанию, но все это алгоритмы достаточно медленные. А так многие современные ПЛК построенные на микроконтроллерах куда медленнее ESP32, все дело в принципе построения их ПО и подхода к разработке самих программ.
Могут быть разнесены в пределах одного щита на разные DIN-рейки, а бывает что контроллер стоит в одной щитовой, а счетчик в соседней щитовой в 50 метрах. Во всех проектах по разному.
Распределением ресурсов процессора ESP32 занимается RTOS, что происходит на низком уровне скрыто в SDK, мы не ставили себе задачи проанализировать нагрузку, RTOS не дает такой информации в явном виде, а писать код для этого, возможно с некоторыми "костыльными" решениями до пока не требовалось. Еще раз повторюсь в контроллере много процессов, MQTT клиент только один из них, есть еще планировщик заданий, опции обработки кода сценариев, подсистема Lora Wan шлюза, так же есть процессы работы с нашим облачным сервером, веб сервер интереса пользователя, может быть включен телеграмм клиент, процесс работы с устройствами на шине I2C, и это далеко не весь список. У нас на шине Modbus обычно не более 10 устройств, хотя теоретически их можно сбыть существенно больше. Ключевое, что при использовании быстрого Modbus вам не важно сколько устройств на шине, хоть 2 хоть 50, они отпрашиваются за один запрос, а в классическом протоколе на опрос 50 устройств требуется в 50 раз больше запросов чем если бы было одно устройство. Информацию конечно обрабатывает облако, пишется статистика метрик в базы данных на сервере и выводится в виде графиков оператору. Опрос делается через SDK, и да скорее всего на низком уровне там это реализовано через DMA, SPI точно работает через SMA, UART не факт. Конкретных цифр к сожалению нет, не решали задачу таких измерений.
Добрый день! Спасибо за конструктивные комментарии.
По поводу модуля часов реального времени — у нас давно был вопрос, стоит ли добавлять его в базовую комплектацию. Однако ни одного реального запроса на эту функцию мы не получили, поэтому решили не усложнять плату и не добавлять дополнительные элементы, которые в 99% проектов оставались бы невостребованными.
У нас есть разработанный модуль, который включает несколько вариантов часов реального времени, EEPROM и сторожевой таймер. Но мы не запускали его в производство из-за отсутствия спроса. Если такой запрос есть, можем вернуться к этому проекту — на складе даже есть определенное количество таких модулей. Реализация часов реального времени и EEPROM в текущих платах не представляет сложности.
Кроме того, сторожевой таймер тоже был запланирован и на самих платах Lavriboard, но фактически в реализуемых нами проектах он не требовался. Этот модуль можно установить практически в любой из нескольких доступных сокетов на наших платах.
Но, опять же, важна реальная потребность. Если есть интерес, можем не только поднять проект, но и опубликовать схему, чтобы обсудить, какие часы или сторожевые таймеры предпочтительнее и какой функционал действительно необходим. Пока мы не развивали это направление именно из-за отсутствия реальных запросов.
Схемы плат не публикуются, входы и выходы расположены на модулях расширения. В данном проекте это Modbus диммеры и реле Wiren Board, в других проектах — модули расширения Lavritech. Схем в публичном доступе у нас нет.
Наша зона ответственности в данном проекте заканчивается на виртуальной машине. Заказчик нам предоставляет работающий компьютер с Windows и AnyDesk. Может быть, это много слоев абстракции, но включить компьютер на Windows проще. Статистически намного больше людей умеют это делать, и если компьютер сломается, проще дать другой аналогичный компьютер. Если машина вышла из строя, у нас есть образ, а вот найти человека, кто может предоставить такой же хост на чем-то еще, куда сложнее. На HA решение переходное, в дальнейшем планируем перейти на контроллер Lavritech для такого простого сценарного освещения. У нас есть облачный доступ к веб-интерфейсу контроллера, и мы удаленно там все настраиваем, плюс бэкапы конфигурации в один клик делаются на сервер.
Да, вы все правильно сказали. Уже есть настроенный образ VirtualBox с HA, заранее настроенный для тиражирования. Установка VirtualBox понятна любому пользователю без квалификации: достаточно импортировать машину, и сервер работает. Контроллер Lavritech знает все устройства, используемые в сборке, из коробки и пробрасывает их в MQTT в несколько кликов. При этом дальше планируем отказаться от HA и сделать простые сценарные кнопки внутри Lavritech.
Спасибо, поправили
Мы идем к тому, чтобы настройку и обслуживание системы могли делать и электрик, и студент, и среднестатистический системный администратор. Поэтому стараемся использовать более простые технологии, с точки зрения IT-специалистов это не сильно рационально. Но в реальности это будет барьером по квалификации, особенно в глубинке.
Контроллер Lavritech работает на ESP32, поэтому запустить на нём Home Assistant не получится.
Спасибо за вопрос, эти пины доступны на SOCKET WB 1.1, он становится SPI разъемом, так что ничего не пропадает. Это позволяют делать перемычки R68, R69, R71, R73, R72, R66.
Добавим немного фиктивности: каждый контроллер получает информацию с лора-датчика на улице, и эту метрику можно вставлять в термостат вместе с показателем температуры в помещении. Предвижу комментарии, что завеса не является обогревательным прибором, но так уж сложилось, что люди на входе, охранники и другие, включают её, чтобы погреться, и забывают выключить, когда становится жарко. Такое часто происходит на КПП павильонного типа, где нет тамбура. Сам павильон на входе и выходе имеет завесы, поэтому запрет на ручное управление нужен, и можно выключать завесу, когда в помещении жарко. Второй критерий - это подсчет количества импульсов в единицу времени с датчика движения. Предполагается, что если количество импульсов меньше определённого порога, то это можно считать отсутствием движения. Это оборудование уже есть в текущих сборках, но как будет на деле, мы узнаем, когда появится статистика ближе к весне. Ключевое в этом процессе - локальный контроллер, который будет доступен всем и не потребует построения сложных систем на объектах для экономии.
Спасибо за ваш комментарий!
Вы абсолютно правы, что интерфейс для ручного управления в данном случае не является приоритетом, и мы тоже не хотим превращать систему в очередную диспетчеризацию, которой никто не пользуется. Основная ставка сделана на статистику, которая позволяет создавать автономные ячейки на основе комплекта: завеса + контроллер Lavritech + датчики движения и температуры. Именно эти ячейки будут самостоятельно принимать решения о необходимости работы завесы, что существенно снижает потребность в ручном вмешательстве.
Сейчас мы как раз планируем добавить датчики движения для подсчета трафика через существующие реле с импульсными входами. Кроме того, обсуждается настройка температурного порога для наружной температуры, при котором завеса может быть отключена. Это позволит гибко управлять работой завес в зависимости от реальной ситуации.
Графическая визуализация (графики, метрики) действительно остается вспомогательным инструментом. Она поможет подтвердить, что система работает корректно и настройки применяются правильно, но основную работу будет выполнять контроллер Lavritech.
Цель — создать полностью автономный комплект, который способен учитывать множество факторов (трафик, температуры внутри и снаружи) для принятия решений о работе завесы. Пока для завес это лучший подход, который мы видим. Но в будущем, по мере развития технологий и искусственного интеллекта, возможно, удастся перейти на более сложные и точные алгоритмы управления. Инфраструктура для этого уже создается сейчас за счет централизации оборудования.
Спасибо за ваш комментарий!
Проект прошел два основных этапа. На первом этапе мы свели данные о работе тепловых завес в единую систему. Это включало фиксацию информации о текущих режимах работы, расходах, температурах, а также состоянии каждой завесы (работает или нет). Таким образом, мы получили базовую картину работы системы, необходимую для дальнейшего анализа.
На втором этапе была разработана метрика, позволяющая оценивать энергопотребление по всему объекту. Метрика формируется ежедневно и ежемесячно, с возможностью сравнения текущих данных с аналогичными показателями за прошлый год. Это позволило выявить общие тенденции и ключевые точки, где расход энергии может быть оптимизирован.
Сейчас мы находимся на третьем этапе, который заключается в выявлении и разработке алгоритмов управления для каждой конкретной завесы. Эти алгоритмы будут привязаны собранных данных и учитывают параметры, такие как трафик, температурные условия и особенности каждой зоны, к сожалению завеса это не конвектор, которую можно привязать к температуре в помещение. С алгоритмом управления прийдется повозится, на данный момент 3 этап еще не реализован.
Не секрет, применяем УФ-печать и лазерную печать с ламинированием наклеек.
Сфера мониторинга для предприятий, ритейлер, склады и тд., где нет АСУ ТП.
Похоже прийдется писать еще одну статью, делать анализ загрузки шины логическим анализатором и сравнивать оба подхода с цифрами. В данной статье была задача рассказать именно о прикладной пользе быстрого Modbus и о том, что не так сложно его интегрировать в уже существующие решения если нахватает быстродействия шины.
Планируем что бы можно было более 4шт MAP12E опрашивать одним контроллером, почему нет?
ESP32 занят опросом шины постоянно, если опрашивать 50 устройств на шине и требуется реакция 1 секунда, нужно за эту секунду прочитать все 50 устройств и обработать данные с них, если взять таки сложные устройства как MAP12E, то это более сотни регистров на одно устройство. Но быстрая реакция требуется не для всех устройств, поэтому включив быстрый Modbus, мы не делаем короткий интервал опроса для всех, быстро опрашиваются только устройства требующие быстрого отклика. Возможно выше была не точность. Точнее было бы сказать, что ESP32 занят избыточными опросами других устройств и мы освобождаем это время на устройства, которым действительно нужен быстрый отклик.
Критерий подходит устройство для ПЛК или нет , определяется принципом построения его ПО, в контроллерах Lavritech концепция сильно отличается от классических ПЛК. У нас есть что то похожее на каталог приложений, которые можно загружать в контроллер по воздуху, в зависимости от задачи и требуемых функций. Сам же встроенный обработчик сценариев достаточно медленные по меркам ПЛК, зато человек может быстро скачать из каталога нужно приложение, немного его настроить и решить свою задачу. При работе же ПЛК есть среда разработки, которая позволяет в визуальном редакторе строить сложные алгоритмы, задавать задержки и тд. ПЛК очень быстро обрабатывает в реальном времени процессы, там крайне важны тайминги. Наше же ПО заточено под быстрое решение задач мониторинга и домашней автоматизации, сбора данных, обработки простых алгоритмов, Термостаты, планировщики задач, работа по расписанию, но все это алгоритмы достаточно медленные. А так многие современные ПЛК построенные на микроконтроллерах куда медленнее ESP32, все дело в принципе построения их ПО и подхода к разработке самих программ.
Могут быть разнесены в пределах одного щита на разные DIN-рейки, а бывает что контроллер стоит в одной щитовой, а счетчик в соседней щитовой в 50 метрах. Во всех проектах по разному.
В этом и суть, что на одной шине живут устройства с быстрым Modbus и другие, медленные Modbus устройства.
Распределением ресурсов процессора ESP32 занимается RTOS, что происходит на низком уровне скрыто в SDK, мы не ставили себе задачи проанализировать нагрузку, RTOS не дает такой информации в явном виде, а писать код для этого, возможно с некоторыми "костыльными" решениями до пока не требовалось. Еще раз повторюсь в контроллере много процессов, MQTT клиент только один из них, есть еще планировщик заданий, опции обработки кода сценариев, подсистема Lora Wan шлюза, так же есть процессы работы с нашим облачным сервером, веб сервер интереса пользователя, может быть включен телеграмм клиент, процесс работы с устройствами на шине I2C, и это далеко не весь список. У нас на шине Modbus обычно не более 10 устройств, хотя теоретически их можно сбыть существенно больше. Ключевое, что при использовании быстрого Modbus вам не важно сколько устройств на шине, хоть 2 хоть 50, они отпрашиваются за один запрос, а в классическом протоколе на опрос 50 устройств требуется в 50 раз больше запросов чем если бы было одно устройство. Информацию конечно обрабатывает облако, пишется статистика метрик в базы данных на сервере и выводится в виде графиков оператору. Опрос делается через SDK, и да скорее всего на низком уровне там это реализовано через DMA, SPI точно работает через SMA, UART не факт. Конкретных цифр к сожалению нет, не решали задачу таких измерений.