РЕКЛАМА НА ФОРУМХАУС В качестве гейта модуль с LAN очень удобен, да и в щиток такие модули удобно становятся. Ну будем делать на RS485 OpenHAB прекрасно подключается по MQTT. Но при наличии своего конфигуратора для модулей, переключатся на другие программы надоедало. Так был написан PLC. За ним и WebUI подтянулся.
отчего же, могу дать исходники, попозже, когда будет готов CAN bootloader, чтобы модули прогружать по CAN. Только они все под RTOS Chibios. Пока же еще ручками шьем. Шлюзами у меня трудятся Raspberry Pi, дешево и гибко...
Год назад я тоже начинал УД на шине CAN. Разработал несложный протокол поверх CAN, разработал два устройства: сенсорный выключатель на 6 кнопок и релейный модуль на 12 реле на DIN-рейку. Прототипы работали. Однако при зрелом размышлении я решил CAN забросить, как неоптимальный и потому бесперспективный. Сейчас я делаю все заново. Основные принципы такие: В качестве основного (рекомендуемого) кабеля должен использоваться кабель Cat5/Cat6. Из четырех витых пар кабеля: - одна витая пара используется для обмена данными - одна витая пара является общим проводом - одна витая пара передает питание (ток до одного ампера), типовое значение +12В или +24В, в зависимости от обстоятельств. +12В предпочтительно если типичные расстояния между крайними узлами в сети до 100м, однако +24В тоже может использоваться если расстояния большие. - одна витая пара - запасная, может использоваться, например, для передачи видео от камер наблюдения. На физическом уровне приемопередатчики - CAN, однако обмен ведется при помощи обычных UART на скорости 19.2 kbps. При такой скорости топология может быть произвольной. В минимальном случае для обмена пригодны самые маленькие и дешевые Arduino, у которых к UART-у надо будет довесить шинный формирователь CAN Протокол CSMA/CD, при передаче узел обязан слушать свое "эхо" и сравнивать с переданными данными. Если на шине тихо, то любой узел имеет право начать передачу в любой момент времени. Коллизии, возникающие при одновременной передаче двух или более узлов, обнаруживаются, после чего узлы, участвовавшие в коллизии, выдерживают рандомизированные паузы и пробуют повторить передачу. Протокол обмена - максимально приближенный к MQTT-SN. Однако все сообщения, проходящие по физическому интерфейсу, парсятся и воспринимаются всеми узлами. Поэтому в локальной сети подписка к брокеру не требуется. Вместо подписки в локальной сети реализуется принцип "производитель-потребитель", в результате чего интерфейс становится пригодным для управления светом. Помимо MQTT-SN, который в локальной сети действует как "точка-многоточка", для конфигурирования узлов используется несложный протокол "точка-точка". Настройки сохраняются в энергонезависимой памяти узлов.
Спасибо за подробный ответ. То же думали в свое время использовать что-то типа CSMA/CD. Имеет смысл если планируете использовать микроконтроллеры не имеющие аппаратного CAN. У нас в проекте микроконтроллер один - stm32f103, благо цена на него 1 USD, никаких Ардуино. CAN точно также слушает эхо, и имеет свой протокол повторов датаграмм при коллизиях, только все это делается аппаратно, аппаратны и буферы/майлбоксы датаграмм, что очень удобно. Bootloader может прошивать по CAN микропроцессор. Пока никаких минусов не нашли. Проблемы с шинной топологией решаются простым каскадируемым CAN-HUB. Протокол ZMQ у нас появляется слоем выше. Все питается от 14В (аккумулятор в буфере). Самое сложное было найти микросхему DC/DC конвертора, которая работает с хорошим КПД на малых токах и не стоит при этом 5 долларов. Каждый узел потребляет от 14В не более 4 -10 мА, позволяя на одну витую пару по питанию повесить их несколько десятков.
Я более-менее в курсе того, как сделан CAN. Короткие сообщения, вследствие чего приходится делать много дополнительных и по сути ненужных телодвижений. Как результат - по-хорошему пригодны только МК со встроенным CAN-ом, что сильно сужает выбор и создает дополнительный геморрой. Сами CAN контроллеры простыми не назовешь, это даже "не вещь в себе", а "зоопарк в себе". Это если по миллиону штук покупать? Поштучно в Digi-key он стоит USD $5.15
Собственно говоря, можно взять за основу какой-нибудь J1939, под него и куча исходников написана, и передача длинных сообщений там есть, и запрос нужных данных (PGN). С некоторой натяжкой его под УД вполне можно использовать. В CAN удобна именно мультимастерность. При этом сильно меняется подход к построению системы. Дело не в том, что выключатель будет сам управлять реле и т. п., а в том, что можно полностью уйти от опроса датчиков. То есть каждый датчик сам по себе с заданным периодом выдаёт свои показания в шину, а использовать эти данные может кто угодно. Допустим, данные датчика температуры на улице может использовать и автоматика котла, и управление жалюзи (к примеру), и просто экранчик для информации хозяевам дома.
Такой принцип обмена называется "производитель-потребитель". Производитель публикует информацию, а потребители ее используют, кому нужно. Так сделан не только CAN, на этом же принципе работают интерфейсы автоматизации зданий KNX и C-Bus. Но это не то же самое, что мультимастерность. Мультимастерные шины вообще говоря такого не умеют. Например, LonWorks - мультимастерный интерфейс, но по принципу "производитель-потребитель" он работать не может. Из-за этого на шине больше обмена впустую, мастер повторяет узлам одно и то же много раз, чтобы до каждого дошло. А так, чтобы один раз послать, а все сразу получили - этого в LonWorks нет.
Начну с того, что все контроллеры УД в нашем проекте только на STM32F103. Пришлось "покурить" документацию чтобы разобраться c его CAN, согласен. Сейчас либы под ОС Chibios уже написаны, все отлажено, из любого треда ОС можно отправлять сообщения. Протокол простой, длины датаграмм 3-4 байта. На скорости 12 кб/с при 20% загрузке шины получим 50 сообщений в секунду. Это большая величина. Вот где надо покупать STM32F103, чтобы не тратить много. https://ru.aliexpress.com/item/Free-shippingSTM8S105K4T6C-STM32F103C8T6-STM8AF6266TA-STM8S005K6T6C/32394199372.html При желании и более крупной партии можно найти и еще более низкие цены. С учетом того, что печатка контроллера тоже делается в правильном месте она стоит около 1 USD. Весь модуль УМ обойдется в 5-6 USD. https://sites.google.com/site/cansmarthouse/standartnyj-kontroller/osnovnoj-kontroller-um
Протокол - это вообще самая сложная часть во всем деле. Простота - она хуже воровства, как я убедился на собственном опыте, прилепив простой интерфейс поверх CAN. "Простой протокол" почти наверняка означает тупик в развитии, причем заложен этот тупик на ранней стадии разработки. Нормальный протокол поверх CAN - это что-то вроде CANopen. Но хватит ли ресурсов STM32F103 на CANopen, я не уверен. Для интерфейсов "производитель-потребитель" скорость не является ограничивающим фактором. KNX прекрасно работает на бодовой 9600, а C-Bus - вообще на скорости 5 kbps. При этом они управляют светом в больших зданиях и на стадионах, реактивность отличная. Правда, неизвестно, что вы на самом деле там покупаете, то ли отбракованные чипы, то ли ворованные, то ли китайские клоны, похожие на настоящие, но с неизвестным букетом аномалий. Когда пойдут косяки, претензии предъявлять будет некому. Но, как говорится, "кто не рискует - тот не пьет шампанское".
Известно, уже покупали, оригинальные, обычные распродажи остатков больших партий. 72 МГц ARM? Хватит и еще 90% останется. Сложное - это много простых уровней - модель OSI. Никак иначе, ибо потом не разобраться. Вот это будет настоящий тупик.
Я просто не вижу необходимости тянуть в контроллер стек CANopen (хотя поначалу один из участников проекта высказывал данную мысль), имело бы смысл для взаимодействия с другими устройствами, понимающими CANopen, но это реально редко нужно, да и можно организовать быстрее и проще на модулях-серверах, что на Raspberry Pi.
Может ли ваш протокол обеспечить такую функциональность: - Один выключатель (при входе) гасит весь свет в доме - Двухкнопочный выключатель управляет люстрой на 5 плафонов. - - Одна кнопка включает-выключает всю люстру - - Вторая кнопка управляет 2-мя плафонами в люстре, короткие нажатия включают-выключают их, длинные нажатия - уменьшают или увеличивают яркость.
Может, дело в том что УМ перепрограммируется по CAN целиком, порты - суть объекты, например, тип "button" генерит события при одиночном нажатии, двойном, длительном ... Вы просто пишите на С любой сценарий и закачиваете. Что-то посложнее - сценарий уже пишите на OpenHAB, который работает на кластере из двух Raspberry Pi.
То есть, кто не умеет программировать на С, пользоваться не сможет? А сам он воспринимает события, относящиеся к тому же объекту, но сгенерированные другими кнопками? Или "чукча не читатель, чукча писатель"? И как обеспечивается управление всей люстрой и ее частью? Надо адресовать 3 плафона и 2 плафона, так что для управления всей люстрой надо выдать 2 команды? Или всю люстру придется через Распбери включать?