Очередной "Умный дом", на этот раз модульная система...

MaksVV
Offline
Зарегистрирован: 06.08.2015

в heartbeat-e количество ошибок узла, количество ошибок кан контроллера, согласен. Буду это добавлять .  

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

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

А если уж мастер перестал свой heartbeat с временем слать, тогда уж в аварийном режиме начинают ноды  сами пульс гнать в шину. 

Я говорю как сделан  heartbeat в протоколе CANOpen. Твой вариант называется там NodeGuard.

Heartbeat. При мониторинге сети по принципу heartbeat узел автоматически передает свое коммуникационное состояние с регулярными интервалами как доказательство своей коммуникационной работоспособности. 

Node guarding. При работе по принципу node guarding определенный узел сети (это главный узел сети, так называемый NMT-master) опрашивает остальные узлы сети (подчиненные узлы, соответственно называемые NMT-slave) фреймом CAN remote (что такое remote frame, см. [12]). Опрос узлов идет последовательно, друг за другом, с заранее определенным интервалом времени ("guard time", защитный интервал времени). В ответ подчиненные узлы должны передать телеграмму данных, описывающую их текущее коммуникационное состояние (stopped, operational, pre-operational) вместе с так называемым битом toggle. Если узел по какой-то причине не ответил на запрос NMT-master в течение заданного времени ("node life time", время жизни узла), то это регистрируется как ошибка соответствующего узла, и показывается контроллеру хоста NMT-master как "node-guarding event" (событие защиты узла). Другими словами, подчиненные устройства NMT-slave также мониторят сеть на предмет обнаружения запроса от NMT-master в течение своего "времени жизни". Если такой запрос отсутствовал дольше, чем так называемый интервал "времени жизни" узла, то узел NMT-slave также предполагает, что мастер сети NMT-master поломался, и показывает это своему хост-контроллеру через "Life guarding event" (событие защиты жизни сети).

Его целые конторы разрабатывали, так что я пошел на поводу. )

Рекомендую почитать здесь про протокол. Очень много идей можно дернуть.

http://microsin.net/programming/arm/canopen-overview.html

Кстати MULTIFRAME придется переделывать, там все очень не просто. 3х команд не хватит.

MaksVV
Offline
Зарегистрирован: 06.08.2015

ок, интересно, поизучаю. Я два года назад начинал читать про этот CANopen нифига не понял. 

riv
Offline
Зарегистрирован: 20.07.2017

Все просто как табуретка

Есть система мониторинга NMT - Network Management в ней Heartbeat и Node guarding

Есть SDO - это мультифрейм

Есть PDO - это передача в одном фрейме

Все остальное нам думаю не нужно в маленькой сети.

riv
Offline
Зарегистрирован: 20.07.2017

И кстати обрати внимание что даже в CANOpen идет не один широковещательный запрос, а опрос всех по очереди. Я пробовал твой вариант, сеть ложиться ошибки нарастают. Контроллеры при превышении ошибок блокируются.

Помнишь я долго бился об ошибки в сети. Так вот 99% проблема в алгоритмах. И при 125кбит 20 одновременных запросов положит сеть. Так что ребут я на этот случай предусмотрел. Т.к. программно не нашел решения вывести контроллер из состояния блокировки передатчика по переполнению буфера ошибок.

MaksVV
Offline
Зарегистрирован: 06.08.2015

по диагонали пробежался. Так же мыслят люди. Словарь объектов  - это наши массивы parameter и device. и т.д. По сложнее всё только там немного. 

Node Guarding больше понравился. 

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

по диагонали пробежался. Так же мыслят люди. Словарь объектов  - это наши массивы parameter и device. и т.д. По сложнее всё только там немного. 

Node Guarding больше понравился. 

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

Так же я где то вычитал что HB лучше.

Сделай проще реализуй оба варианта. Потом проверишь на живой сети.

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:
Помнишь я долго бился об ошибки в сети. Так вот 99% проблема в алгоритмах. И при 125кбит 20 одновременных запросов положит сеть.

какие 20 одновременных запросов? это ты про что именно? запрос один, широковещательный. А отвечают все в разное время, относительно получения этого запроса.

riv
Offline
Зарегистрирован: 20.07.2017

Кстати я помаленьку интегрирую CAN через шлюзы мастер/слейв в Majordomo.

Потом просто возьмешь мой форк https://github.com/graynet-dev/OkBitUDP

И кусок кода https://github.com/graynet-dev/aHomeBus/blob/master/ahb_gw_can_to_okbit.cpp либо здесь https://github.com/graynet-dev/ESP8266WiFiOkBit

 

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

riv пишет:
Помнишь я долго бился об ошибки в сети. Так вот 99% проблема в алгоритмах. И при 125кбит 20 одновременных запросов положит сеть.

какие 20 одновременных запросов? это ты про что именно? запрос один, широковещательный. А отвечают все в разное время, относительно получения этого запроса.

Если так то хорошо. Важно чтобы они все одновременно не начали отвечать.

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

Кстати если будешь делать web сразу делай AJAX https://github.com/graynet-dev/aHomeBus/blob/master/ahb_WEB.cpp см. только void AHB_WEB::loop_web() (void AHB_WEB::loop_web2() и далее тестовые)

MaksVV
Offline
Зарегистрирован: 06.08.2015

по идее у меня гибрид понятий heartbeat и nodeguard.  Грубо говоря взято от обоих лучшее ))

MaksVV
Offline
Зарегистрирован: 06.08.2015

ну не знаю на счёт того что , проблема как ты говоришь в алгоритмах. Ты простейший скетч #965 заливал? там супер простая логика:

MaksVV пишет:
мастер шлёт запрос один, широковещательный. А отвечают все в разное время, относительно получения этого запроса.

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

ну не знаю на счёт того что , проблема как ты говоришь в алгоритмах. Ты простейший скетч #965 заливал? там супер простая логика:

MaksVV пишет:
мастер шлёт запрос один, широковещательный. А отвечают все в разное время, относительно получения этого запроса.

Я пошел дальше, заливал примеры прямо из библиотеки, и пакеты по по таймеру. И дальше начал увеличивать кол-во узлов. Если их больше 5-6 начинаются проблемы с ошибками.

Причем это не ошибки физики а слишком сильно нагруженная сеть.

Тем более это не вопрос а утверждение. Сейчас проблем нет. Причем сеть работает при периоде HB 1 секунда.

НО! Иногда высыпаются ошибки в нескольких контроллерах. Думаю просто баги в железе либо как выше говорил Demid это проблемы с SPI и нужно уходить в STM либо ESP32.

MaksVV
Offline
Зарегистрирован: 06.08.2015

не понимаю, как может быть нагружена сеть от 6-ти МК, которые по одному сообщению шлют. И уж тем более, когда по времени эти ответы разнесены.  Если от этого виснет,  нах такая мультимастерная сеть вообще нужна, которая по факту нихера не мультимастерная, а  получается уговаривать её надо, сообщения по времени разносить и т.д. Трафик то вообще ниочём и то уже проблемы.   В автомобилях вон песец  трафик:  с периодичностью 10 мс десяток сообщений, 50 мс десяток и ещё куча, которые помедленнее. Хрень какая-то . 

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

MaksVV
Offline
Зарегистрирован: 06.08.2015

вот реальный трафик с моторной шины форд транзит. на ней от 4 до 8 блоков .  Time это периодичность, мс

  хотя ладно не хорошее сравнение , тут 500кбит/c. 

Вот трафик с салонной шины 125кбит/с:

все равно это тебе не раз в секунду запрос и 6 ответов слать. Тут тоже большинство кадров сыплется 30...150мс.  

 

MaksVV
Offline
Зарегистрирован: 06.08.2015

возьми  поставь только два узла и нагрузи шину - налепи кучу сообщений. И посмотри будут ли ошибки от как ты говоришь "шина загружена" .Имхо всё будет нормально. А вот если ошибки начинаются при добавлении узлов, то имхуется всё таки аппаратная проблема, а не загруженность шины.  

sadman41
Offline
Зарегистрирован: 19.10.2016

У меня mcp-шки фейлились, когда я наваливал в них все метрики подряд, без паузы. Не то, что они вешались - просто не успевали отправить и библиотека возвращала состояние "фейл", которое так же при обрыве линии возникает. Т.е. "доброкачественная" ошибка выглядела как "злокачественная".

MaksVV
Offline
Зарегистрирован: 06.08.2015

ну с этим да , так низя. Получается таким образом забивается TX буфер mcp шки . Я метрики разнёс через 5 мс. Но у RIV то проблема , даже когда всего одно сообщение от узла исходит. Я думаю тут совсем другое. 

demid.net
Offline
Зарегистрирован: 02.12.2019

Хочу напомнить, что когда я тестировал хаб, гонял температуру каждые 275мс с 50 датчиков, то есть в секунду отправляется и принимается всеми блоками 1000/275*50=181 пакет, что грубо около 11кбит/c реальных данных при выставленной скорости 250кбит/с.

О какой загруженности сети вы говорите ? Потолок у CAN шины чуть больше 19000 пакетов в секунду. Без данных конечно. 181 это ни о чем. Вопрос только в обработке такого потока. Сомневаюсь что в форде стоят 8-битные МК с CAN-контроллером через SPI. А вот передатчики +/- те же самые MCP2551.

riv
Offline
Зарегистрирован: 20.07.2017

Я думаю, что проблемы в следующем:

1.связка 2560 <-> MCP2515 по SPI где могут быть сбои от помех наводимых ESP8266 (я заметил что контроллеры в дальних комнатах с низким RSSI сбоят чаще)

2.помехи на самой линии CAN

3.низкое быстродействие МК за счет чего данные не успевают обработаться. (по RX поставил прерывание) но его можно в MCP ставить только на 1 событие.

Для уменьшения этого сделал:

1. Просмотрел осциллографом всю сеть, поставил где надо терминаторы, объединил землю

2. Снизил скорость до 125

Попробую вынести подальше esp

sadman41
Offline
Зарегистрирован: 19.10.2016

riv пишет:

3.низкое быстродействие МК за счет чего данные не успевают обработаться. (по RX поставил прерывание) но его можно в MCP ставить только на 1 событие.

Вот это может быть. Особенно, если всякие веб-морды тудыть совать. Потому как скорость SPI явно выше 250Kbps.

riv
Offline
Зарегистрирован: 20.07.2017

sadman41 пишет:

riv пишет:

3.низкое быстродействие МК за счет чего данные не успевают обработаться. (по RX поставил прерывание) но его можно в MCP ставить только на 1 событие.

Вот это может быть. Особенно, если всякие веб-морды тудыть совать. Потому как скорость SPI явно выше 250Kbps.

У меня веб морды только на шлюзе, а там due. Тем более что сделано на AJAX. Так что скорее невозможность передать так как по прерыванию идёт прием.

riv
Offline
Зарегистрирован: 20.07.2017

Хотел маски использовать, но тогда маршрутизацию потеряю

sadman41
Offline
Зарегистрирован: 19.10.2016

riv пишет:
У меня веб морды только на шлюзе, а там due. Тем более что сделано на AJAX. Так что скорее невозможность передать так как по прерыванию идёт прием.

В обработчике прерывания прямо с MCP читается?

riv
Offline
Зарегистрирован: 20.07.2017

Регистрами выставляю тип прерывания в MCP и читаю прерывание GPIO МК.

И кстати esp8266 реально вносит ошибки в сеть. Пока не понял на SPI или на CAN влияет.

На SPI скорее всего какая нибудь гармоника от ESP вылетает.

riv
Offline
Зарегистрирован: 20.07.2017

Реализовал дистанционный Reboot, надпись на кнопке это количество ребутов.

MaksVV
Offline
Зарегистрирован: 06.08.2015

но ведь на малом количестве узлов нет ошибок? значит не есп причина. может формирователи шины перепаять на mcp2551? и  производительность ардуины тоже тут не причем - говорю трафик вообще ниочем!!! возьми сделай на малом количестве узлов (когда ошибок нет), столько сообщений , эквивалентное такому, как на бОльшем количестве узлов (при котором возникают ошибки).  если будет все хорошо - производительность МК не при чем. Главный симптом - появление ошибок при добавлении в сеть участников. надо тут искать причину

MaksVV
Offline
Зарегистрирован: 06.08.2015

нужно подключить can hacker и затестить, что происходит в момент сбоев на шине. и я так и не помню,  RIV ты гонял на столе все свои МК при коротком кабеле? Все было хорошо? Может банально  всё дело в твоих отклонениях от требуемой шинной топологии?

riv
Offline
Зарегистрирован: 20.07.2017

У меня сеть бывает стоит неделю без сбоев. А потом внезапно начинает сбоить один контроллер и постепенно убивает сеть, причем у него tx error а у остальных rx. И при добавлении новых узлов возникает затухающий сбой, у всех по 100-150 ошибок приема, затем они спадаю до 0 за пару минут.

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

нужно подключить can hacker и затестить, что происходит в момент сбоев на шине. и я так и не помню,  RIV ты гонял на столе все свои МК при коротком кабеле? Все было хорошо? Может банально  всё дело в твоих отклонениях от требуемой шинной топологии?


Canhacker и осциллограф уже рабочим инструментом стали.Но проблема не постоянная. Я и веб морду прикрутил для этого. Чувствую скоро до syslog дойду.не могу выявить из-за чего начинается шторм в сети.

MaksVV
Offline
Зарегистрирован: 06.08.2015

я думаю, что нужно исследовать на примерах с  библиотеки , на которых чаще глюк проявляется или на том скетче #965. На них тоже должно всё нормально работать. А если глючит , значит есть косяк. просто на них чаще проявляется. А heartbeat -ом возможно ты не решил проблему, а получился некий костыль,  немного маскирующий проблему. 

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

я думаю, что нужно исследовать на примерах с  библиотеки , на которых чаще глюк проявляется или на том скетче #965. На них тоже должно всё нормально работать. А если глючит , значит есть косяк. просто на них чаще проявляется. А heartbeat -ом возможно ты не решил проблему, а получился некий костыль,  немного маскирующий проблему. 

Так я и не спорю. Ищу помаленьку откуда уши торчат. Вот и наделал костылей.

riv
Offline
Зарегистрирован: 20.07.2017

Интегрировал шину с Majordomo

MaksVV
Offline
Зарегистрирован: 06.08.2015

есть ссылка где толково описано про настройку мажордомо? Я чето  с ходу не могу понять, как что-нибудь туда на ардуине подключить. 

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

есть ссылка где толково описано про настройку мажордомо? Я чето  с ходу не могу понять, как что-нибудь туда на ардуине подключить. 

У MD есть Маркет дополнений, оттуда ставишь модули сопряжения, 

Из интересных есть Modbus TCP, MQTT и OKBIT UDP.

К сожалению вся информация обрывочная. Есть инфа на yotube и форуме

https://mjdm.ru/forum/viewtopic.php?f=5&t=1675&hilit=ModBusTCP

https://mjdm.ru/forum/viewtopic.php?f=5&t=3350

https://mjdm.ru/forum/viewtopic.php?f=5&t=5851#p91062

https://mjdm.ru/forum/viewtopic.php?f=4&t=595

Сам пока разбираюсь.

riv
Offline
Зарегистрирован: 20.07.2017

Макс приветствую. Начал реализовывать совместимость библиотеки с твоим скетчем по протоколу.

Мне для управления маршрутизацией и управлением сетью не хватает 16 адресов в msg_type поэтому решил его не трогать для совместимости с тобой.

Хочу свои команды управления загнать наверх dev_type. Можешь зарезервировать адреса с 128 по 255?

Судя по enum Parameter_addr_enum на 60, тебе адресов хватает. Не против?

Ну и тебе поначалу сначала  фильтрация моих dev_type, а потом возможно мои функции внесешь к себе.

MaksVV
Offline
Зарегистрирован: 06.08.2015

Здоров. у меня реально гораздо меньшее количество адресов. Поэтому не вопрос. 

MaksVV
Offline
Зарегистрирован: 06.08.2015

а какие например команды управления? 

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

а какие например команды управления? 


При запуске устройства оно отдает onboot
Reboot устройства
Сердцебиение
Nodeguard
Sdo пока не реализовал и пр. Из canopen
Вот здесь описание.
https://github.com/graynet-dev/aHomeBus/blob/master/ahb_proto.h

MaksVV
Offline
Зарегистрирован: 06.08.2015

Дак это вроде не команды а статус, не?

riv
Offline
Зарегистрирован: 20.07.2017

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

Сюда же лягут команды конфигурации узла.

P.S. 

Функции установки времени из твоего протокола брать не буду. У меня в сердцебиении мастер отдает аппаратное время которое устанавливается на узлах, а узлы кидают свой аптайм по которым мастер и слейв в web интерфейсе показывают, + мастер отдает для слейва свой аптайм.

riv
Offline
Зарегистрирован: 20.07.2017

Макс, приветствую.

Совсем запутался в твоих функциях и мануал не помогает. Распиши пожалуйста логику настройки.

Что нужно настроить на узле генераторе команд (какие массивы и какие функции их вызывают)

Что нужно настроить на узле исполнителе команды (какие массивы device, timeoutsArray, parametrs_quontity, parametr)

Структура команды в CAN_ID и DATA (msg_type и dev_type)

Какие массивы нужно заполнить на передатчике какие на приемнике команд.

Где настраиваются ответчики на запрос, а где автогенерация периодическая.

Где указывается кому отправлять.

Получаю ответ

"Ошибка выполнения команды. Устройство или параметр, которым пытаемся управлять данной командой, не укомплектованы на узле!"

 
MaksVV
Offline
Зарегистрирован: 06.08.2015

Вечером позже видео запишу

MaksVV
Offline
Зарегистрирован: 06.08.2015

Давай всё по порядку и будем максимально точными в своих изречениях, чтобы не запутаться. 

riv пишет:
Мне для управления маршрутизацией и управлением сетью не хватает 16 адресов в msg_type поэтому решил его не трогать для совместимости с тобой.

Хочу свои команды управления загнать наверх dev_type. Можешь зарезервировать адреса с 128 по 255?

вот эти две фразы я не понял в принципе. Маршрутизацией чего? управлением чем? Что значит загнать команды наверх dev_type ? Адреса резервировать не нужно. Сколько ты написал девайсов, столько и будет, но не более 254. 

riv пишет:
Судя по enum Parameter_addr_enum на 60, тебе адресов хватает. Не против?

вот тут ты, наверное, немного не понял. 60 это не я выбирал, оно получилось само по себе, т.к. всего записали параметров 59 штук (и ещё нулевой адрес, поэтому получилось 60). Соответственно в енуме последняя идёт строка "SIZE_PARAM_ARRAY".  В ней и лежит количество сконфигурированных нами параметров (енум сам и подсчитывает), это используется в скетче, чтобы знать количество в списке адресов параметров.  Т.е. если, например, сконфигурируешь в списке только 3 параметра, то SIZE_PARAM_ARRAY будет равно 4 (т.к. плюс нулевой ещё). 

riv пишет:
MaksVV пишет:

а какие например команды управления? 

При запуске устройства оно отдает onboot Reboot устройства Сердцебиение Nodeguard Sdo пока не реализовал и пр. Из canopen Вот здесь описание. https://github.com/graynet-dev/aHomeBus/blob/master/ahb_proto.h

riv пишет:
Там в перемешку команды, сервисные сообщения, статусы. Относящиеся к состоянию узлов. Сюда же лягут команды конфигурации узла.

Где там, куда сюда? Не путай, команды это команды, статусы это статусы.

riv пишет:
Что нужно настроить на узле генераторе команд (какие массивы и какие функции их вызывают)

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

SendCommand (приоритет, тип команды, значение, значение_2, значение_3, значение _4,  адрес получателя,  тип девайса, № датчика )

Понятно, что эту функцию стоит вызывать, если речь идёт о типах команд «управление GPIO», либо «удалённое изменение значения параметра». Для последующих придуманных типов команд, например «рестарт узла» и т.д. нужно добавлять в мой протокол куски кода.

riv пишет:
Что нужно настроить на узле исполнителе команды (какие массивы device, timeoutsArray, parametrs_quontity, parametr)

команды могут быть разные. Если речь идёт о прилетании типа команды "управление GPIO". то для правильной работы команды , предварительно настраиваешь на целевом узле только массив device. Там указываешь какой девайс, к какому пину подключен, и вид управления (шим, диджитал и т.д.). Если устройство импульсное (например, как у тебя свет уже сделан), то указывается ещё пин ардуино, которым отслеживается текущее состояние девайса (например свет в данный момент включен или нет. Если он включен и прилетает команда "ВКЛ", то импульса на девайс НЕ последует).  

Если прилетела команда "изменение значение параметра", то нужно, чтобы данный параметр который хотим изменить был сконфигурирован на этом узле (ну то бишь, что он тут присутствует) и номер датчика не забываем правильно указывать. 

Остальные типы команд, такие как инициирование рестарта и т.д. ещё в моем протоколе не реализованы. 

riv пишет:
Структура команды в CAN_ID и DATA (msg_type и dev_type)

В приложении мануала ведь четко расписана структура ID  и тела кадра команды, читай внимательно .  (dev_type содержится в последнем разряде ID, а msg_type это 3 байт тела кадра.

riv пишет:
Какие массивы нужно заполнить на передатчике какие на приемнике команд.

Передатчик и приёмник команд тут ни при чём, потому что, каждый узел может быть и передатчиком, и приёмником команд.  Для каждого конкретного узла заполняется два массива «parameter»r и «device». (эти массивы у каждого будут свои в зависимости от наличия датчиков и исполнительных механизмов). А вот енумы в файле name_addresses.h общие (одинаковые) для всех узлов (там указываются в принципе какие узлы, параметры и девайсы (ну т.е. их адреса) существуют в умном доме). А уж применять или нет их на данном конкретном узле, уже дело десятое. Главное, чтобы у всех участников сети адресация узлов, параметров и девайсов была единая. 

riv пишет:
Где настраиваются ответчики на запрос, а где автогенерация периодическая.

Где указывается кому отправлять.

Это настраивается в массиве «parameter». Смотри там в комментах в скетче столбец  «таргет адрес 1-го узла», если не нужна автоматическая периодическая отправка данных, ставишь в этом столбце NOT_SENT  или (если нужна) ставишь тут какому узлу отправлять. Если нужно нескольким узлам, то добавляешь ещё один столбец (да, при добавлении столбца для одного параметра, для остальных, если им это не надо,  будет оверхэд в массиве тогда. ничё страшного).

При этом нужно до массива «parameter» указывать максимальное количество узлов автоматической отправки

riv пишет:
Получаю ответ

"Ошибка выполнения команды. Устройство или параметр, которым пытаемся управлять данной командой, не укомплектованы на узле!"

потому что, не настроил правильно на данном узле массивы "parameter" и/или "device"

 

 

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

вот эти две фразы я не понял в принципе. Маршрутизацией чего? управлением чем? Что значит загнать команды наверх dev_type ? Адреса резервировать не нужно. Сколько ты написал девайсов, столько и будет, но не более 254. 

Я уже писал выше мне не хватает msg_type для всех статусов и команд. Поэтому для них буду использовать адреса 128-255 из dev_type. Обработкой разделю

        if (temp.dev_type > 127) {
          temp.cmd = temp.dev_type;
        }

MaksVV пишет:

вот тут ты, наверное, немного не понял. 60 это не я выбирал, оно получилось само по себе, т.к. всего записали параметров 59 штук (и ещё нулевой адрес, поэтому получилось 60). Соответственно в енуме последняя идёт строка "SIZE_PARAM_ARRAY".  В ней и лежит количество сконфигурированных нами параметров (енум сам и подсчитывает), это используется в скетче, чтобы знать количество в списке адресов параметров.  Т.е. если, например, сконфигурируешь в списке только 3 параметра, то SIZE_PARAM_ARRAY будет равно 4 (т.к. плюс нулевой ещё). 

Я говорю о принудительном ограничении количества параметров с 0 до 127

MaksVV пишет:

Где там, куда сюда? Не путай, команды это команды, статусы это статусы.

Естественно там и команды и статусы я написал об этом выше.

MaksVV пишет:

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

Send  Command (приоритет, тип команды, значение, значение_2, значение_3, значение _4,  адрес получателя,  тип девайса, № датчика )

Понятно, что эту функцию стоит вызывать, если речь идёт о типах команд «управление GPIO», либо «удалённое изменение значения параметра». Для последующих придуманных типов команд, например «рестарт узла» и т.д. нужно добавлять в мой протокол куски кода.

Ты говоришь о 

void SendCommand(bool Priority, byte Command_Type, byte Command_Value, byte Command_Value_2, byte Command_Value_3, byte Command_Value_4, byte Target_Address,  byte Device_Type, byte Sensor_numb)

MaksVV пишет:

В приложении мануала ведь четко расписана структура ID  и тела кадра команды, читай внимательно .  (dev_type содержится в последнем разряде ID, а msg_type это 3 байт тела кадра.

То что ты описал, очевидно. Не очевидно как идет связка msg_type, dev_type, data.

В общем ладно, не разберусь так свой код напишу.

MaksVV пишет:

Передатчик и приёмник команд тут ни при чём, потому что, каждый узел может быть и передатчиком, и приёмником команд.  Для каждого конкретного узла заполняется два массива «parameter»r и «device». (эти массивы у каждого будут свои в зависимости от наличия датчиков и исполнительных механизмов). А вот енумы в файле name_addresses.h общие (одинаковые) для всех узлов (там указываются в принципе какие узлы, параметры и девайсы (ну т.е. их адреса) существуют в умном доме). А уж применять или нет их на данном конкретном узле, уже дело десятое. Главное, чтобы у всех участников сети адресация узлов, параметров и девайсов была единая. 

Видимо ты не понял вопрос. То что каждый узел и передатчик и приемник как бы ну совсем очевидно. Я спросил последовательность передачи о обработки одной команды с настройкой двух узлов.

MaksVV пишет:

Это настраивается в массиве «parameter». Смотри там в комментах в скетче столбец  «таргет адрес 1-го узла», если не нужна автоматическая периодическая отправка данных, ставишь в этом столбце NOT_SENT  или (если нужна) ставишь тут какому узлу отправлять. Если нужно нескольким узлам, то добавляешь ещё один столбец (да, при добавлении столбца для одного параметра, для остальных, если им это не надо,  будет оверхэд в массиве тогда. ничё страшного).

При этом нужно до массива «parameter» указывать максимальное количество узлов автоматической отправки

Спасибо.

MaksVV пишет:

потому что, не настроил правильно на данном узле массивы "parameter" и/или "device"

В общем я и спрашивал как правильно.

 

 

riv
Offline
Зарегистрирован: 20.07.2017

Вообще не очевидна иерархия, вложенность свойств и методов.

Что первично устройство и у него параметры а у параметров pin?

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:
Я уже писал выше мне не хватает msg_type для всех статусов и команд. Поэтому для них буду использовать адреса 128-255 из dev_type.

Наконец, я понял про что ты говоришь. В общем ты прав. В ID (заголовке кадра) последний разряд dev_type используется только в типе кадра "параметр" и "команда". Да и то в "команде" он используется только в типах команды "управление GPIO" и удалённое изменение значения параметра". Во всех остальных случаях этот разряд ID не используется, поэтому можешь использовать его на свое усмотрение. Например, в типе кадра "авария",  я загнал на место dev_type адрес узла, про который сообщается, что у него авария. 

Так что не обязательно начинать со 127. Это ведь совсем другая адресация, никакой это не dev_type, хоть и стоИт на том же месте в ID. 

Только вот не могу понять как может не хватить в типе кадра "команда"  254 типа команд? ведь в каждом типе команды у тебя до 4-х байт подтипов можно сделать. Ну правильнее, конечно, сказать  до 3-х байт подтипов, т.к. один байт на само значение команды. Это ж ппц какое количество команд. 

 

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:
Что первично устройство и у него параметры а у параметров pin?

"параметры" - это метрики (данные с датчиков, датастрим если хочешь). К устройствам  никакого отношения не имеют, т.к. устройства не являются датчиками, а являются исполнительными механизмами. У устройства (девайса) закладывается информация заранее (в массиве device), к какому пину оно подключено.

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:
Ты говоришь о 

void SendCommand(bool Priority, byte Command_Type, byte Command_Value, byte Command_Value_2, byte Command_Value_3, byte Command_Value_4, byte Target_Address,  byte Device_Type, byte Sensor_numb)

да

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

riv пишет:
Я уже писал выше мне не хватает msg_type для всех статусов и команд. Поэтому для них буду использовать адреса 128-255 из dev_type.

Наконец, я понял про что ты говоришь. В общем ты прав. В ID (заголовке кадра) последний разряд dev_type используется только в типе кадра "параметр" и "команда". Да и то в "команде" он используется только в типах команды "управление GPIO" и удалённое изменение значения параметра". Во всех остальных случаях этот разряд ID не используется, поэтому можешь использовать его на свое усмотрение. Например, в типе кадра "авария",  я загнал на место dev_type адрес узла, про который сообщается, что у него авария. 

Так что не обязательно начинать со 127. Это ведь совсем другая адресация, никакой это не dev_type, хоть и стоИт на том же месте в ID. 

Только вот не могу понять как может не хватить в типе кадра "команда"  254 типа команд? ведь в каждом типе команды у тебя до 4-х байт подтипов можно сделать. Ну правильнее, конечно, сказать  до 3-х байт подтипов, т.к. один байт на само значение команды. Это ж ппц какое количество команд. 

Вот структура ID

//ID structure   e.d.cc.bb.aa

//     E                D              CC            BB                 AA            

// priority         msg type     target addres    source addres     dev type

//  1^2=2             2^4=16       2^8=256         2^8=256           2^8=256

Насколько я понял ты AA используешь не только для dev type но и для аварий (подскажи кстати в каком месте, с ходу не нашел)

Ты делаешь вариативную структуру CAN_ID? В коде этого не нашел.

Судя по структуре см. выше,   E  D CC  BB  AA жестко зафиксированы по местоположению, и емкости в части передаваемых сообщений.

Или ты имеешь ввиду что на msg type = command у нас 8 байт данных?

Я это понимаю, просто мне нужны все поля данных, пытаюсь в ID все выбросить.