Arduino.ru

логичнее надо было бы назвать последний разряд ID не "dev-type" , а "подтип кадра". и тогда уж переставить этот байт рядом с msg_type Тогда непонятки бы ушли. Но работы с переделкой всего этого тогда много будет. 

ну какбы не 8. нулевой байт тела данных это глоб счётчик , например. А вообще так-то да. У каждого типа сообщения своя структура тела кадра (см. карты в приложении мануала).  

Давай определимся с терминологией. Просто ты код писал тебе все понятно. А я по разным файлам бегаю картину складываю.

byte device [4][5] это устройства подключенные к GPIO на которые выдаются команды

(тогда зачем там пин ардуино считывания статуса)

byte parameter [2][second_dimension] это уже не GPIO а параметры получаемые из функций обработки датчиков 
(а как обработать датчик GPIO геркон например? И есть ли связка с пин ардуино считывания статуса?)

Вопросов больше чем ответов.

Я как раз поэтому и просил настройку узла запросчика параметров - передатчика команд и узла ответчика параметров и исполнителя команд.

Вот вот,я и так день убил интеграцию с твоим скетчем. Так что держим в голове что dev-type это байт типов, статусов и пр, которые идут в паре с msg_type и его дополняют.

да, не только. Отправка аварии с помощью функции void SendAccident (byte AlarmAddr)

там смотри: 

TX (1  , ACCIDENT , MonitoringAddr  , AlarmAddr , EXTENDED ,DATA_CANFRAME , 1, Data);

Дак вот, где указано жирным AlarmAddr, там должно  быть dev-type  по идее, т.к. функция TX() так задумывалась изначально.

Это была твоя идея так-то. Я сопротивлялся изначально))) 

Могу только посыпать голову пеплом )

Закинь в документацию структуру байт ID и DATA.

значит переделываем структуру ID? 

Эээ, тут торописа не надо.

Давай обсудим как менять либо пока костылями как я сделал.

Закинь в документацию структуру байт ID и DATA

дак вроде я ж в приложении мануала  эту инфу указал, просто ещё не на все типы сообщений. 

ID предлагаю такой:    A  B  CC  DD EE 

A - приоритет (1 бит),  B - тип кадра (4 бита),  СС - подтип кадра (8 бит),  DD - адрес отправителя (8бит), EE - адрес получателя (8 бит)

Это не вопрос, перестановка это просто. Делаем.

У меня кстати почти так и было. 

//ID structure   e.dd.cc.b.aa

//     E                DD             CC              B            AA            

// pocket type     command&ansver  target addres  target port  source address

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

8 - command&ansver 

8 – target

4 – port

8 – source

Я старой версией пользовался. ((

Поэтому и затупил с использованием. Начал по коду структуру кадров рисовать (((

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

Что выбираешь в организации приоритета? типы кадров или адреса узлов? 

И кстати как все же device и параметры разделяются если в устройстве есть описания пина съема статуса и есть сложные устройства управляемые например через Bee, IRDA, RF24, RF433 ....?

ну ты даёшь, теперь понятно почему столько вопросов было)) тут последнее

Логичнее тип кадра. Проще ввести тип кадра критичная авария (протечка, пожар, проникновение ...)

P.S.

Не совсем понял про приоритет в части месторасположения в CAN ID, он принимается целиком. Речь о порядке разбора кадра? Хочешь микросекунды выиграть?

никак не разделяются. Сложные устройства управляются через тип команды "удалённое изменение значение параметра". Эти сложные устройства отсутствуют в массиве device в принципе. Так как работают просто с переменной, находящейся в массиве "параметры". 

ок, также думаю. 

нет . Все дело в физике CAN шины. Кадры с меньшим ID всегда выигрывают арбитраж. А арбитраж идёт от старшего к младшему (слева направо). Поэтому первый контролируется наш priority , ну и т.д. вправо. 

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

Честно говоря не придавал раньше значение принципам арбитража. 

Тогда тем более.

все до безобразия просто. "0" на шине убивает "1".  "1" можно передать в шину, если в данный момент ни один из узлов не передаёт "0". А вот "0" хоть когда можно передать (доминантный бит). 

Узел отправляет бит и слушает шину сразу. Если на шине то, что отправил -  всё хорошо , идём дальше. Если отправляем "1", а на шине "0" - значит кто-то уже говорит, он выиграл, мы прекращаем передавать и ждём. 

да

(тогда зачем там пин ардуино считывания статуса)

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

тут пишешь для каждого датчика свой код и закатываешь данные датчика в соответствующую ячейку массива parameter. Поэтому файл  Update_param пустой. Он как бы для этого сделан был. 

вообще, если устройства "сложные" (Bee, IRDA, RF24, RF433 DMX512, Dali и т.д)  можно добавлять "виды подключения " (последний столбец массива device). И в скетче сделать ветвление в зависимости от вида подключения, GPIO это будет или шина какая. 

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

Меня запутало честно говоря смешение уровней абстракции, в разных случаях протокол то работает с железом напрямую, то через функции прокладки. Нужно как то привестись к одному уровню, а то это путаницу вносит. Давай прикинем какой процент исполнительных устройств работает по gpio а какой через прокладки. И насколько много датчиков работает с gpio напрямую.
По первому (ИУ) у меня:
- свет (короткие импульсы на бистабильные реле через реле преобразователь); да и то под это выделена специализированная под это 2560, которая отрабатывает команду выдать короткий импульс и через преобразователь читает наличие 220 в на лампе.
- ? Пока не придумал.
По второму:
- герконы (датчики открытия окон и дверей)
- датчик движения

Все остальное работает не напрямую а через библиотеки обработчики.

Распиши пожалуйста, какие у тебя сенсоры и иу

Это нормально :)))

 изначально я так и хотел. Это тоже была твоя идея ))))  напрямую пинами рулить .

А через функции прокладки это получается типа как  в Blynk  - есть виртуальные пины. Похожее понятие. 

Так у себя я это делаю путем выставления первого же бита в ID. NET_MODE который.

С более высоким приоритетом "0" - работа на низком уровне с входами/выходами/памятью/настройками. Типа подать 1 на выход такой-то или считать вход такой-то.

С более низким приоритетом "1" - работа с устройствами, уже настроенными на некий функционал с помощью низкого уровня. Типа "включить свет там-то", "считать давление там-то".

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

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

Мне тоже кажется, что если функционал нод детерминирован (у годы определенного типа всегда один и тот же набор датчиков/актуаторов), то имеет смысл только командование на верхнем уровне. Это создаст устойчивый уровень API, абстрагированный от версий железа.

А то так в сети будут ноды одного типа, но разных годов выпуска. .. сиди, потом вспоминай, что в 2019-м тебе логичней казалось держать реле на D2, а в 2021-м уже понадобился D2 под прерывание и реле уехало на A2, а затем и вообще на I2C-expander.

Думаю должны быть уровни абстракции.
Контроллер с типом.
У контроллера сенсоры и ИУ.
Прослойка составное у-во. Например BME280 это 3 в одном. ( Это спорно возможно его стоит в модели ниже сенсоров поставить)
У сенсоров и ИУ типы термо датчик, датчик давления давление, датчик влажности, диммер света, реле света ....
Устройство - уже конкретное железо с типом
Протокол устройства
Пины устройства

У нас пока нет типов узлов (функциональные названия есть а реальноименно их аппаратных реализаций нет типизации их нет, например у меня зал, спальня, детская будут однотипные контроллеры, кухня немного будет отличаться, контроллер света в коридором и кухонном шкафу идентичные и пр.).
Типы сенсоров и ИУ есть.
Типов их аппаратных реализаций нет. Составных устройств нет. Настройки пинов есть но нужно разносить с сенсорами их.

Весь топик я не читал, может зайду на очередной круг... Я так понял, что концептуально контролируется некая условная точка в пространстве (дома) например. Т.е. важно знать, что в кладовке перегрев крупы... Важно ли при этом знать какая нода (тип) с какими наборами датчиков находится в этой кладовой? Наверное, нет. Достаточно, чтобы метрики были привязаны ко времени измерения и его точке.

Таким образом - нода, при посылке данных (или коллектор метрик) должна всего лишь оперировать адресом и набором метрик, которые она способна породить.

Например, в кладовке с адресом N стоит нода и отсылает метрику “температура“. Нужна влажность - добавляем ноду с адресом N, отсылающую метрику "влажность". Если есть желание - совмещаем ноды в одном устройстве с адресом N, которое отсылает обе метрики. Нужно работать по запросу - коллектор шлёт команду "отчитаться точке N", ноды опознают свой адрес (один и тот же), отчитываются разными метриками.

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

Sadman, всё именно так и работает на данном этапе. Просто (как это называет RIV) абстракция отсутствует. Пока ИУ настроены работать только по GPIO. А физика генерации метрик (массив parameter) дак и вообще протоколом никак не оговариваются (для них пишем свой кусок кода и загоняем данные в массив метрик - parameter). Вот и всё.  Сверху по метрикам обращение к массиву parameter (Пофиг как там на узле датчики подключены). 

Что касается ИУ. Сверху посылается команда что делать. На узле проверяется вид подключения ИУ (взятый из конфигурации узла) и способ управления,  который указан в команде, и если идет не соответствие вида подключения способу управления - формируется код неисправности  и отчет об этом узлу, пославшему команду.  Если соответствует -  выполняем, на номер пина сверху пофиг. номер пина данного ИУ знает  сам узел (эта инфа в конфигурации узла).  Я хочу добавить виды подключения ИУ , не только по GPIO , но и виртуальное обращение к ИУ (команда сверху говорит только что делать, а как - уже  программируем на узле сами). думаю добавить почти теже виды подключения, только с приставкой virtual. 

Спросите зачем способ управления нужен в команде ? получается сверху все таки нужно знать способ управления?  Тут имеется ввиду способы - булевый, либо с градацией 0...100, либо с 0...255.  Это по-любому сверху должно быть известно. 

нечего разносить, у сенсоров пины не настраиваются. Сенсоры абстрактны

можно кстати "адрес отправителя" разделить по нибблам. Левый - номер помещения, правый - тип контроллера. Хватит 15 комнат и 15 типов контроллеров? 

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

а в каком случае будут:   

приведи пример. Не понял про что речь. Какая разница какие будут сценарии. 

Ну, вот ты сейчас 4+4 хочешь делить адрес. А через полгода, во время пути, выяснится, что "помещений" больше, но типов - меньше. И надо бы делить на 6+2

это да. пишите возможные типы контроллеров. будем считать. думаю 4+4 самое то. У меня 10 помещений в доме, +гараж, +баня, +участок-улица. итого 13. почти впритык, а что делать. Типов МК тоже может быть много, например, мелкие МК ведь могут быть в сеть подключены , типа выключателя или розетки или тфт+тач модуль, да мало ли что. И тогда типов стопицот получается. в payload залазить? 

Поэтому и нужно через типовые сценарии разделить ноды на реальные и на фантастические. Фантастические - это типа "нода для включения нижнего света по вечерам пятниц". Оно, конечно, прикольно, но на кой нужно ID тратить на такую хрень?

ну вообще , для этого у нас есть ведь отдельная  адресация ещё (тип параметра или тип ИУ). То есть если МК простой , аля выключатель света , тип контроллера будет свет . А уж данные, которые он гонит, будут адресоваться уже в другом разряде ID - тип параметра. Так что, не так уж и много типов контроллеров тогда надо. Поэтому нижний свет по пятницам   это будет "тип свет". 

Короче я считаю , нужно просто ввести порядковый номер контроллера в помещении (аля физический MAC адрес) в рамках одного помещения. Нафиг этот тип МК вообще нужен. И главное,чтобы сообщения, которые летят в одно помещение, принимали все контроллеры этого помещения. Всё остальное решает адресация типа параметра (или типа ИУ). А физический номер нужен просто для системных сообщений, чтобы понимать какому узлу или от какого узла одного помещения идет системное сообщение.  

UPDATE.  А если на разных узлах одной комнаты нужны параметры одного типа, помним у нас ещё есть "номер датчика". Это нужно главное граммотно конфигурировать на узлах одного помещения. Например есть два концевика окна. Тип параметра будет "датчик окна".  Один концевик подключен к 1-му (по физ. номеру) узлу этой комнаты, второй - пусть будет к 3-му (по физ номеру) узлу.  На узле №1 на типе параметра "датчик окна"конфигурируем № датчика = 1. На узле №3 на типе параметра "датчик окна"конфигурируем № датчика = 2. Таким образом, сверху не нужно знать к какому физически узлу подключен датчик и №1 и №2. Нужно знать только адресацию  помещения, типа параметра и номера датчика. 

То есть физический адрес узла в помещении как бы не участвует  в полезной адресации параметров или ИУ. Он нужен,  например, для диагностики узлов, каких то системных команд, адресованных именно этому узлу, heartbeat, nodeguard и т.д.

Или только он и участвует. Просто представь, что это не адрес помещения + субадрес датчика, а просто адрес абстрактной области контроля. Эта область может быть окном в гостиной, а может и всей гостиной.

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

В больших системах мониторинга это решается тэгами (дополнительно к уникальному адресу). Например тэг "окно" адресует все датчики во всех помешениях, с которым они связаны. Но где выгодней тэгировать ноды - на уровне конечных МК или на уровне коллектора/диспетчера?

я думаю можно диагностировать сверху. Подать команду в определенное помещение, отдать все датчики нужного типа параметра. Т.к. в ID будет присутствовать физический адрес МК мы увидим в принятых от помещения данных, во первых, какой датчик к какому узлу подключен, ну и какие номера датчиков вообще ответили. Смотрим какого не хватает. 

получается адрес помещения + адрес типа параметра+ №датчика эта связка из трёх адресов и будет являться абстрактной областью контроля. Абстрактной, потому что физически тот или иной № датчика может быть подключен к разным узлам комнаты.