РЕКЛАМА НА ФОРУМХАУС А можно как-то посмотреть на проект? У нас так-же используется MQTT-SN, но реализованы пока только радиоканал и Ethernet
Я проект пока не доделал, поэтому еще не выкладывал. Прототип простого узла сделан, нижний уровень работает. Прототип шлюза заказан, ПП придет в январе, однако РС-шный софт хоть в каком-то виде раньше марта-апреля вряд ли появится.
Кто не знает С, хотя бы минимально тот пишет на OpenHAB Или тратит несколько часов на изучение азов С, больше там не потребуется... А вообще проект хоббийный, неумеющих писать простенькие сценарии на С у нас нет Шлете с OpenHAB три команды - включили три плафона. Пять - пять...
У нас PC софту уже больше двух лет, а вот простого проводного решения руки так и не добрались пока. Как это реализовано? Ведь у MQTT-SN в publish есть только TopicId, значит ноды должны слушать и register сообщения. Откуда нода знает что делать с принятыми данными? Имеется уже прописанная логика или поведение можно задавать снаружи?
Понятно. Нечто вроде Ардуино, вид сбоку. Нет, мне это не интересно. Я хочу получить функциональность на уровне KNX/С-Bus, где проект могут сконфигурировать интеграторы со школьным образованием, а выключение всего света в доме возможно средствами самого интерфейса, одной командой, без участия PC (или эквивалента).
Не встрявая в дискуссию. Я для промышленного изделия реализовал CANopen на STM32F103 и F105 Ресурсов и памяти там хватает за глаза. В качестве стека был взят опеноурсный CANfestival. Если погуглите по этим словам, то найдете мои исходники - там всего лишь надо было переделать пару низкоуровневых функций для STMовского CAN контроллера и обработчик прерываний от таймера.
Конфигурирование ноды производится снаружи, от PC, при помощи протокола "точка-точка". Тогда и задается, какие топики нода выдает/слушает и как на них реагирует. В интерфейс вшиты два протокола, "точка-точка" для конфигурирования нод, и "точка-многоточка" (т.е. "производитель-потребитель") для нормальной работы. При этом "точка-многоточка" более-менее следует MQTT-SN, чтобы не было заморочек с преобразованием и дальнейшей отсылкой в сеть, облако, и т. п.
Это же все есть в CANopen, включая и указанные вами требования по настройке обмена без программирования на Си. А вы то зачем протокол изобретаете?
А я хочу положить все это на копеешный Ардуино-мини и другие МК без CAN контроллера. И еще обеспечить совместимость с MQTT, для упрощения интеграции с IoT.
Ну зачем вы так... Тут очень не соглашусь, всегда можно написать генератор кода, причем это не сложно, если вдруг сильно понадобится... Он будут генерировать С-код в соответствие с тем что и где кликнул "интегратор" мышкой в интерфейсе... Если "интегратор" не может освоить азы С на несколько дней, то доверять ему построение инфраструктуры УД нельзя, только соединять провода, не более того.
Анахронизм... Покуда вы это будете писать AVR контроллеры станут дороже ARM, такая тенденция идет давно.
На ARM-ы это тоже встанет без проблем. Мне вот, например, XMC1100 приглянулся, он как раз на такие задачи заточен. Только начинаю я не с ARM-ов, и даже не с AVR. Свои прототипы я пока делаю на PIC24, потому что это вообще не играет никакой роли.