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

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

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

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

riv пишет:
Или ты имеешь ввиду что на msg type = command у нас 8 байт данных? Я это понимаю, просто мне нужны все поля данных, пытаюсь в ID все выбросить.

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

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

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

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

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

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

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

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

 

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

MaksVV пишет:

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

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

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

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

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

там смотри: 

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

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

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

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

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

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

MaksVV пишет:

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

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

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

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

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

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

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

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

MaksVV пишет:

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

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

 

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

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

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

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

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

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

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

  

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

MaksVV пишет:

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

 

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

MaksVV пишет:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MaksVV пишет:

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

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

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

P.S.

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

 

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

riv пишет:

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

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

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

riv пишет:
Логичнее тип кадра.

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

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

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

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

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

MaksVV пишет:

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

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

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

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

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

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

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

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

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

да

riv пишет:

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

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

riv пишет:
byte parameter [2][second_dimension] это уже не GPIO а параметры получаемые из функций обработки датчиков 

(а как обработать датчик GPIO геркон например? И есть ли связка с пин ардуино считывания статуса?)

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

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

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

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

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

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

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

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

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

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

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

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

demid.net пишет:

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

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


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

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

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

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

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

riv пишет:
Проще четко сказать, протоколу работать только с абстракцией устройство, даже если это геркон или лампа И отдельно сделать настройки железа для устройств.

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

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

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

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

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

MaksVV пишет:

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

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


Готов опять посыпать голову пеплом.
Видимо нужно как то додумывать.

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

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

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

MaksVV пишет:

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


Готов поработать совместно, я займусь функциями датчиков и иу. Как раз дошел до этого уровня.
Нужно продумать универсальный вызов функции и возврат параметров. Чтобы была одна функция запросчик параметров сенсоров, одна запросчик состояния иу, одна командная
А внутри в зависимости от типа устройства вызывались функции обработчики.

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

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

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

MaksVV
Offline
Зарегистрирован: 06.08.2015
sadman41 пишет:
А то так в сети будут ноды одного типа, но разных годов выпуска. .. сиди, потом вспоминай, что в 2019-м тебе логичней казалось держать реле на D2, а в 2021-м уже понадобился D2 под прерывание и реле уехало на A2....
 
нет , ну вообще то у меня была реализация не то, чтобы пинами прям рулить. Было сделано управление устройством, которое подключено именно к GPIO (а не I2c и т.д.) А уж к какому GPIO, это уже на узле конфигурируется - сверху это знать не обязательно. Сверху нужно только знать принцип управления - digital устройство , либо PWM.  
 
Но в любом случае, есть над чем поработать. У меня в конфигурации есть такое понятие как "вид подключения" Думаю, нужно просто добавить видов подключения. 
riv
Offline
Зарегистрирован: 20.07.2017

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

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

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

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

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

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

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

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

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

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

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

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

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

riv пишет:
Настройки пинов есть но нужно разносить с сенсорами их.

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

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

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

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

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

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

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

sadman41 пишет:
байты туда-сюда  трусить
?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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