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

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

Внес изменения.

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

ещё тот видос навеял такую тему. Вместо 1-wire устройств сделать эдакие CAN-датчики и CAN-ИУ. Они будут на ардуино про мини и MCP2515 что в сумме 200р. Программа у них будет довольно тупая и слать в шину будет  11-битные сообщения. Так мы будем понимать, что перед нами "мелкота".  

Ну что решил со статусами?

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

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

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

Или ты с датчиками тоже хочешь на мастере ждать ответов от МК о состоянии датчиков?

Не забывай что команды они полюбому инициатива. Так что там без пин-понга не обойтись. Я понимаю проще просто слушать и на основании полученого создавать картину сети. Но без опроса никуда.

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

Посмотри идею разбивки мастер, слейв, МК, мониторинг https://yadi.sk/d/zkejlJ3K3Td48S

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

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

MaksVV пишет:

ещё тот видос навеял такую тему. Вместо 1-wire устройств сделать эдакие CAN-датчики и CAN-ИУ. Они будут на ардуино про мини и MCP2515 что в сумме 200р. Программа у них будет довольно тупая и слать в шину будет  11-битные сообщения. Так мы будем понимать, что перед нами "мелкота".  

При таком раскладе плату надо свою делать ;-)

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

riv пишет:

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

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

Или ты с датчиками тоже хочешь на мастере ждать ответов от МК о состоянии датчиков?

Не забывай что команды они полюбому инициатива. Так что там без пин-понга не обойтись. Я понимаю проще просто слушать и на основании полученого создавать картину сети. Но без опроса никуда.

дак как ты не понимаешь, что я совсем не против запрос-ответ. То что ты пишешь это уже сделано. Читай внимательно сообщение #439 то то жирным написано. 

Статусы будут сами высылаться на мастер по умолчанию, но если тебе надо - запроси с любого МК, и на него и придёт РАЗОВО ответ статуса. Соотвественно если постоянно запрашивать, постоянно и будет отвечать статусом. 

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

Данные с датчиков , как ты сам говорил, будут высылаться :

- при изменении значений ,

- периодически,

- по запросу. 

В зависимости от того,  что раньше наступит. 

 

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

riv пишет:
Свой запросчик уже затачиваю под перекличку мастер слейв и рассулку с перезапросом от слейва что он стал мастером. Так что он нужен полюбому, только его оптиизировать нужно.

тут почти нечего затачивать. Слейв, как и все подчинённые, шлёт периодически статус мастеру. Так мастер узнает, если слейв лёг (что при этом будем делать?). 

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

 

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

Короче написал я часть программы, которая отвечает за отправку команд и получение отчетов . Т.е. для типов сообщений COMMAND_SEND и COMMAND_ANSWER. 

Суть такая. Название команды  я пока сделал в виде двух байт. Например 12 56. Далее, когда нам надо, мы, из любого места в скетче, отправляем название команды и адрес получателя в специальную функцию, которая ставит отправку данной команды в очередь. А точнее в определённую ячейку в очереди.  

Другая же функция крутится постоянно в лупе. Она проверяет, есть ли что-нибудь у нас в очереди на отправку. Если есть положительные ячейки на отправку , отпраляет в CAN их одну за другой, в каждой включается таймер. Ячейки при этом НЕ высвобождаются.

При следующем проходе,  опять находятся занятые ячейки , если таймер кончился опять отправляется сообщение в CAN и так 5 раз для каждой ячейки. 

В функции RX( ) мы постоянно ждём прихода отчетов о выполнении назначенных до этого нами команд. Если такой отчет пришёл, название команды сравнивается с занятыми ячейками. При совпадении ячейка высвобождается. Данная команда прекращает отправляться к CAN. 

Соотвественно если отчёта в RX() мы так и не дожидаемся, то  

После 5 раз отправки одной и той же ячейки, она высвобождается, данная команда прекращает отправляться в CAN, высвечивается сообщение об ошибке отправки команды - "кончился таймаут принятия отчета!". 

Но, как всегда, ничего ещё не проверял. Позже выложу. 

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

MaksVV пишет:

То что ты пишешь это уже сделано. Читай внимательно сообщение #439 то то жирным написано. 

Здесь у тебя автоответчик у NODE, т.е если на него пришел запрос он ответил. Это понятно.

У меня же мастер крутит цикл и по прошедствии определенного времени опрашивает кого то. Если убрать цикл то будет тоже самое. В чем вопрос то?

Я же сказал в базе использую твой механизм он эффективнее. Но мой тоже оставляю. Он мне нужен.

P.S.

Хотя глядя на твои идеи в следующих сообщениях понимаю что скорее всего мой алгоритм не понадобится.

Глань я структуру своей сети отрисовал. https://yadi.sk/d/zkejlJ3K3Td48S

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

MaksVV пишет:

riv пишет:
Свой запросчик уже затачиваю под перекличку мастер слейв и рассылку с перезапросом от слейва что он стал мастером. Так что он нужен полюбому, только его оптимизировать нужно.

тут почти нечего затачивать. Слейв, как и все подчинённые, шлёт периодически статус мастеру. Так мастер узнает, если слейв лёг (что при этом будем делать?). 

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

 

Excellent!

Если мастер узнал что слейв лег, то шлет серверу мониторинга (серверу УД с Мажордомо там или еще с чем)

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

MaksVV пишет:

Короче написал я часть программы, которая отвечает за отправку команд и получение отчетов . Т.е. для типов сообщений COMMAND_SEND и COMMAND_ANSWER. 

Ты просто монстр программирования! Будет интересно глянуть.

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

riv пишет:

MaksVV пишет:

Короче написал я часть программы, которая отвечает за отправку команд и получение отчетов . Т.е. для типов сообщений COMMAND_SEND и COMMAND_ANSWER. 

Ты просто монстр программирования! Будет интересно глянуть.

Короче крутяк, всё заработало с первого раза!!! Ща покажу. 

Скетч SEND ANSWER COMMAND

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

размер очереди по умолчанию у меня стоял 5 ячеек.  И как бы я часто не пытался команды отправлять - местА в очереди всё равно были, сделал для прикола размер очереди - 2 ячейки. Стали появляться сообщения об ошибке, что очередь забита:

1No empty cells in the queue for TX message!!!

Короче взял на всякий с запасом размер очереди - 10 ячеек, читай 10 сообщений.

Я там не исправлял дебаг TX и RX -  поправишь. Вот видос как я проверял работоспособность этой части программы. 

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

Сейчас нужно ещё добавить часть программы принимающей стороны - если мы получили, какую нибудь команду (ну помимо того что, чтонибудь там будем делать по команде) отправляем отчёт о том, что команда принята - 3 раза . Думаю трёх хватит. 

Тут, видимо , тоже придётся свою очередь сделать на COMMAND_ANSWER.

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

MaksVV пишет:

Сейчас нужно ещё добавить часть программы принимающей стороны - если мы получили, какую нибудь команду (ну помимо того что, чтонибудь там будем делать по команде) отправляем отчёт о том, что команда принята - 3 раза . Думаю трёх хватит. 

Тут, видимо , тоже придётся свою очередь сделать на COMMAND_ANSWER.

Вот ты и пришел к тому что я начал. Только ты реализовал эффективнее. Т.е ты отправляешь команду. Та сторона получает. И отправляет ответ.

Причем ты отправляешь n раз пока не дождешься квитанции. 

Кстати вот интересный вопрос. Отправил я увеличить яркость света. Отчет запоздал. Я отпавил еще раз. И еще.

Нужно думать.

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

riv пишет:
Вот ты и пришел к тому что я начал. Только ты реализовал эффективнее. Т.е ты отправляешь команду. Та сторона получает. И отправляет ответ.

Причем ты отправляешь n раз пока не дождешься квитанции. 

Кстати вот интересный вопрос. Отправил я увеличить яркость света. Отчет запоздал. Я отпавил еще раз. И еще.

Нужно думать.

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

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

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

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

И я сформулировал что меня немного напрягает в твоей идеологии. У тебя UDP (отправил забыл) а нужен TCP. Вот с той же командой.

1 узел  запустил счетчик повтора команды, отправил команду ->  узлу 2

2 узел получил команду, отправил отчет о получении -> узлу 1

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

2 узел выполнил команду, отправил отчет о выполнении -> узлу 1 

1 узел получил отчет о исполнении, снял счетчик повтора команды, если не получил либо диагностика узла, либо состояния, либо повтор команды

Как то так.

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

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

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

riv пишет:

И я сформулировал что меня немного напрягает в твоей идеологии. У тебя UDP (отправил забыл) а нужен TCP. Вот с той же командой.

1 узел  запустил счетчик повтора команды, отправил команду ->  узлу 2

2 узел получил команду, отправил отчет о получении -> узлу 1

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

2 узел выполнил команду, отправил отчет о выполнении -> узлу 1 

1 узел получил отчет о исполнении, снял счетчик повтора команды, если не получил либо диагностика узла, либо состояния, либо повтор команды

Как то так.

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

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

Про яркость я например сказал. Ведь двойное исполнение команд из-за ошибок протокола может быть весьма печальным, если речь идет о котле или протечках и пр.

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

Кстати защита от не приема мастером тоже нужна.  Т.е я отправил мастеру статус, все видят а он нет, кто перегрузит мастера?

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

Ты не полный пример кинул. SendCommand вообще не используешь. 

В loop только SendCommand_queue();

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

riv пишет:
Про яркость я например сказал. Ведь двойное исполнение команд из-за ошибок протокола может быть весьма печальным, если речь идет о котле или протечках и пр.

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

MaksVV пишет:
В крайнем случае, для таких сообщений, тем более не очень-то важных, можно сразу их в кан слать, без всяких очередей, в единственном экземпляре, а на отчёт не обращать внимания.

riv пишет:
Кстати защита от не приема мастером тоже нужна.  Т.е я отправил мастеру статус, все видят а он нет, кто перегрузит мастера?

Можно чтобы мастер слал всё время слейву, что получил статус (от каждого подчинённого). 

 

 

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

riv пишет:

Ты не полный пример кинул. SendCommand вообще не используешь. 

В loop только SendCommand_queue();

Дак это уже на твоё творчество, я же говорил в любом месте скетча, если нужно команду какую нибудь отправить -  берёшь вызываешь эту функцию. 

А вообщето там закоментировано в приеме RX

01case COMMAND_SEND: //выполняется, когда мне прислали команду от удаленного контроллера
02 
03 
04              /*
05             if (rxBuf_can[0] ==0xFB) {SendCommand(raz1,raz2,adres);
06              raz1 ++; raz2 ++; adres ++;}                               // это было для проверки , то что на видео
07              if (rxBuf_can[0] ==0xFA) SendCommand(0x67,0x67,0x13);
08               
09              */                                   
10              break;

Т.е. я инициировал отправку команд, тоже как бы по команде с CANHACKER. Т.е. шлю с CANHackera 0xFB, вызывается эта функция и отправляет команду в кан. FA делает чуть другое - видос то смотрел?

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

На видео плохо слышно. Попробую в наушниках.

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

Эээх уже путаться начали везде send

Я специально в двух файлах send и answer храню. Send это отправка своя инициативная а Answer это отправка на чужой запрос.

В итоге SendCommand у тебя лежит в RX и срабатывает когда придет COMMAND_SEND (т.е прилетит команда от другого узла) и она отправляет ответ. Так что она send_answer_command видимо должна называться а то запутаемся.

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

Да и сообщение не по теме. У меня сегодня СЫН родился.

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

Хех, поздравляю !!!!

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

riv пишет:
В итоге SendCommand у тебя лежит в RX и срабатывает когда придет COMMAND_SEND (т.е прилетит команда от другого узла) и она отправляет ответ. Так что она send_answer_command видимо должна называться а то запутаемся.

Да это я просто для примера сделал, чтобы отправлять команды от тестируемого МК не со скетча, а как бы с канХакера. 

Т.е. с канхакера посылаем команду тестируемуму МК (для него в RX она и будет как COMMAND_SEND)- отправить уже свою команду в CAN. 

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

я это сделал, чтобы регулировать самому вызов функции SendCommand(). Надо почаще кликаешь, надо - пореже

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

Я ещё не делал  send_answer_command, не успел

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

Так совсем запутал. Какой смысл в SendCommand и куда ее поместить в коде?

Если она не ответчик на принятую команду т.е не send_answer то тогда что она такое?

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

Вот тебе нужно включить свет . Допустим Свет находится на МК адрес 2. Выключатель на МК адрес 1. 

Нам нужно с МК адрес 1 отправить команду на включение света на МК адрес 2.    Пусть будет название команды "01 05"

В скетче МК адрес 1 так вызываешь  функцию так SendCommand (01, 05 , 02)

Собственно говоря, название функции буквально отображает то, что она делает - отправляет команду в CAN

 

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

Бллиин ты меня тестированием своим смутил. Положил ее в RX. Спасибо. 

SendCommand (01, 05 , 02) заполняет массив комманд с адресами получателей. Ее вызываем откуда угодно.

SendCommand_queue();  читает массив и отправляет команду. Ее крутим в loop

Так?

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

riv пишет:
SendCommand (01, 05 , 02) заполняет массив комманд с адресами получателей.

Да, SendCommand ставит в очередь команду на отправку - ищет свободную ячейку, как нашла - записывает два байта названия команды, и адрес получателя в эту ячейку массива очереди. 

riv пишет:
SendCommand_queue();  читает массив и отправляет команду.

это верно

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

А в примере ты просто с канхакера отправлял команду которую МК отправлял куда ты задал в адресе?

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

да , просто для примера, чтобы фунцкию SendCommand с канхакера повызывать. 

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

Да чужой код распутывать тяжелее чем свой запутывать.

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

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

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

Теперь вот смотри должно быть 2 механизма на каждый тип сообщения

1. периодическая отправка 

2. мгновенный ответ на запрос статуса, получение команды, опрос датчика.

Причем по сложному многоступенчатому алгоритму

Например команду то я принял, но выполнить не смог, в итоге принятие получил и можно дальше мне ее не отправлять. 

Т.е 2 сообщения 1. Принял команду. 2 Выполнил или не выполнил команду.

Ну и ENUM  с командами на все узлы один будешь делать? Или памяти жалко?

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

riv пишет:

Причем по сложному многоступенчатому алгоритму

Например команду то я принял, но выполнить не смог, в итоге принятие получил и можно дальше мне ее не отправлять. 

Т.е 2 сообщения 1. Принял команду. 2 Выполник или не выполнил команду.

Это понятно, уже обсудили, что разовьём эту тему. 

 

 

riv пишет:

Теперь вот смотри должно быть 2 механизма на каждый тип сообщения

1. периодическая отправка 

2. мгновенный ответ на запрос статуса, получение команды, опрос датчика.

это не понял. 

 

 

riv пишет:
Ну и ENUM  с командами на все узлы один будешь делать? Или памяти жалко?

Да, наверное ENUM пойдёт. Причем два нужно. Для каждого разряда названия команды. 

Например первый байт - это род устройств (свет, отопление, шторы и т.д.), второй байт - конкретный экземпляр (свет какой комнаты, какой из радиаоторов отопления, какая штора и т.д. ). В общем с этим тебе уже думать

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

MaksVV пишет:

riv пишет:

Теперь вот смотри должно быть 2 механизма на каждый тип сообщения

1. периодическая отправка 

2. мгновенный ответ на запрос статуса, получение команды, опрос датчика.

это не понял. 

Все контроллеры отправляют статус на мастер. Если долго не получен статус, Мастер может поросить статус любого МК инициативно. И кстати как проверить что мастер не получает сам из-за себя? Тужно через Ethernet обмен мастер, слейв и мониторинг-УД продумать.

Все контроллеры шлют состояние датчиков и ИУ на мастер. Мастер может запросить статус датчика или ИУ

Ну наверное для команд может быть только инициатива

Для Аварии тоже только в одну сторону.

Я имел ввиду в принципе предусмотреть эти типы отправок. 

MaksVV пишет:

Да, наверное ENUM пойдёт. Причем два нужно. Для каждого разряда названия команды. 

Например первый байт - это род устройств (свет, отопление, шторы и т.д.), второй байт - конкретный экземпляр (свет какой комнаты, какой из радиаоторов отопления, штора какой комнаты и т.д. )

У нас же  sens_dev_enum род устройства. Он уже есть  и передается в CAN ID.

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

riv пишет:
У нас же  sens_dev_enum род устройства. Он уже есть  и передается в CAN ID.

А ну да, ну тогда один байт можно в названии команды, т.к. адрес уже есть, тип устройства есть. Этот байт будет представлять собой:

1 , 0 для булевых. -  вкл/ выкл

от 0 до 255 для ШИМ , диммеров, % включения и т.д.

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

но нужны также спец команды. Например какую команду передать всем, чтобы сменили адрес отправки статуса. 

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

1. тип устройства- это sens_dev_enum

2. класс устройства (булево, ШИМ, аналоговое etc)

3. адрес устройства № pin на контроллере 

4. тип команды

 

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

Вот тут человек свою сеть сделал на своем железе и сфте. Идеи интересные.

https://habrahabr.ru/post/160469/

https://geektimes.ru/post/258656/

https://clusterrr.com/clunet/

https://github.com/ClusterM/clunet

https://github.com/dudanov/CLUNET-2.0

У него свой бутлоадер с прошивкой по сети. Прошивка overCAN это было бы совсем круто.

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

добавил SendCommandAnswer. Проверил - работает. После принятия любой команды , отсылает отчёт три раза (с периодичностью 200 мс). Пока так. 

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

1. Ты сделал 1 ступеньку, получил команду, выполнил команду, отправил статус исполнения Правильно?

Нужно внутри еще одну ступеньку делать, получил команду, отправил квитанцию что получил чтобы больше не слали, выполнил отчитался.

А то жалюзи кинешь команду открывать или котел греть а им время нужно на отчет.

2. Посмотри как я сделал в void send_status_request(uint8_t rem_addr)  и в RX case STATUS_REQUEST_ANSWER:

Если запрос отправлен и ответ получен то стоп и ждем большой период опроса, если ответ не получен ждем малый период и перезапрос, если опять не получен перезапрос, ждем еще и если не ответ кидаем аварию на сервер УД. Просто 3 раза кидать без ожидания ответа и таймера, как раз сеть забивать. 

+ Не забывай начсчет № сообщения в последнем байте данных и возврат мне моего номера сообщения в предпоследнем байте данных.

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

Ну давай уберем посылку отчета 3 раза. Пусть отчёты отправляются только один раз. Тогда не нужно никакой очереди для отчетов. В поле данных отчета , кроме названия команды, будет инфа о том, что "команда была принята - идёт выполнение", либо "команда уже выполнена"

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

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

riv пишет:

Кстати вот интересный вопрос. Отправил я увеличить яркость света. Отчет запоздал. Я отпавил еще раз. И еще.
Нужно думать......

.......Про яркость я например сказал. Ведь двойное исполнение команд из-за ошибок протокола может быть весьма печальным, если речь идет о котле или протечках и пр.

эту проблему можно решить как раз с помощью твоего глобального счетчика. Вот ему и применение. Когда мы посылаем команду и НЕ получаем отчет, мы отправляем ещё раз ту же самую команду (и так 5 раз через 200мс), НО с таким же значением глобального счетчика. 

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

Прип отправке команды в CAN приращение глобального счетика  у команды делать один раз  - только при постановке в очередь на отправку. 

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

MaksVV пишет:

Ну давай уберем посылку отчета 3 раза. Пусть отчёты отправляются только один раз. Тогда не нужно никакой очереди для отчетов. В поле данных отчета , кроме названия команды, будет инфа о том, что "команда была принята - идёт выполнение", либо "команда уже выполнена"

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

Нет перезапрос нухно оставить, просто сделать с подтверждением. посвтор если не получил подтверждение в течении определенного времени.

Насчет таймаута выполнения самое интересное,  мы же примерно знаем время выполнения. Делаем константы с предельныим временем исполнения . И ждем это время если не получили ок то перезапрос выполненной команды. Тут именно не повтор команды а запрос что с командой из сообщения №. 

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