Идеологическая организация сети

Доброго времени суток. Делаю простой умный дом, с элементами охранной системы (или наоборот, не суть важно). Чтобы не тянуть кучу охранных шлейфов, решил организовать кучу умных датчиков (ATtiny13A) на базе RS-485, поэтому связь полудуплексная, формат обмена: запрос мастера - ответ слейва. Протокол обмена придумываю свой (хочеться лучше понять это дело). Но сейчас ломаю голову над более высоким уровнем абстракции, а именно как идеологически организовать сеть. Варианты:
1. Центральный блок должен иметь битовое поле, по выставленным битам которого поставленные под охрану датчики опрашиваются. Не поставленные датчики (биты в битовом поле не выставлены) не опрашиваются, либо опрашиваются, просто, чтобы знать что они в сети (исправны), но их показания не принимаются к сведению. То есть контроль состояния сети на стороне мастера.
2. Центральный блок просто раздает команды нужным датчикам перейти в охранный режим, и в дальнейшем опрашивает все датчики. Те датчики, которые по команде мастера включили охранный режим передают свое состояние (норма/тревога), те что не включили просто сообщают о своем наличии. То есть контроль состояния сети передан на откуп каждому датчику (каждый отвечает сам за себя).

Второй момент. В каком виде лучше организовать передачу инфы мастеру. Датчики передают просто сырые данные (показания АЦП), а мастер уже решает, норма это, или нет. Или датчик внутри себя решает, норма или тревога, и формирует сообщение для мастера согласно протокола.

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

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

Перед этим читал много тем по организации сети на этом форуме, но именно эти вопросы все равно остались после прочтения.

0

Придумывая свое вы учИтесь, за это плюс. Но сразу делаете свое оборудование несовместимым, это минус.
Лучше бы использовать чужие наработки, как в смысле железа, так и библиотек...
Например:

<Изображение удалено>
Это только пример, и он явно не для самодельщика, но как пример того на что ориентироваться...
P.S. Есть три вида протокола ModBus, это RTU, ASCII, и TCP. Они очень разные, просто все называются ModBus. Вы какой имели в виду?

0

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

0

Про модель OSI уже читал, но свою сеть могу представить в ней не до конца. Я четко вижу физический уровень (RS-485) и протокольную часть (буду писать сам). А вот по поводу более высоких уровней и возникли эти вопросы.
Про модбас я упомянул просто для примера. Там нет ответа на широковещательные сообщения, и я вот думаю, а надо ли мне такое.
По поводу количества точек, расстояния и скорости обмена:
1. На данный момент в моей простейшей реализации протокола количество слейвов - до 15, в будущем планирую расширить. До скольки - пока сказать не готов, будет видно по обстоятельствам.
2. Расстояние - планирую обкатывать на частном доме с отдельным гаражом, всего до 100 м.
3. Скорость обмена - стандартный UART на 9600 б/с.

0

Для "умного дома" ModBus RTU поверх RS-485, по мне очень здравая мысль.
Можно самому подумать, подучиться, можно воспользоваться промышленными/любительскими схемными решениями/библиотеками...

0

Сообщение от Kmusmos Про модель OSI уже читал, но свою сеть могу представить в ней не до конца.

Неудивительно. Раз уж даже вездесущий TCP/IP в эту модель не вписывается (см. модель DOD).

0

Как интересно это совпадает с охранной системой, про которую тут уже писал в подобных темах )). Кроме физического уровня - ну ничего хорошего не давал (RS-485) по сравнению с однопроводной линией и самопальным протоколом.
Не ясно сколько вы собираетесь байт в пакете передавать, но если взять два байта запроса и два на ответ, то получится более 15-ти сеансов в секунду с каждой точкой, что явно достаточно для простого циклического опроса.
Вот и весь верхний уровень.
(У меня пульт отсылал запрос в виде байта с адресом в младшей тетраде и нулями в старшей, соответствующий объект присылал назад тот же байт с четырьмя битами состояния датчика охраны - звук, движение, дверь, концевик вскрытия самого датчика. Н незарегистрированные адреса запрос не посылался, отсутствие ответа в течении миллисекунды вызывало трехкратный повторный запрос, после чего индицировалось отсутствие связи.)

0

Сообщение от инкер ... Кроме физического уровня - ну ничего хорошего не давал (RS-485) по сравнению с однопроводной линией и самопальным протоколом. Не ясно сколько вы собираетесь байт в пакете передавать, но если взять два байта запроса и два на ответ, то получится более 15-ти сеансов в секунду с каждой точкой, что явно достаточно для простого циклического опроса. Вот и весь верхний уровень. (У меня пульт отсылал запрос в виде байта с адресом в младшей тетраде и нулями в старшей, соответствующий объект присылал назад тот же байт с четырьмя битами состояния датчика охраны - звук, движение, дверь, концевик вскрытия самого датчика. Н незарегистрированные адреса запрос не посылался, отсутствие ответа в течении миллисекунды вызывало трехкратный повторный запрос, после чего индицировалось отсутствие связи.)

Я за использование RS-485 по одной причине, протокольную часть легко отлаживать через обычный USB-UART. Вот я датчики уже практически наполовину написал, они прекрасно откликаются и работают.

Вы не поверите, но у меня сейчас почти так же организовано, пакет состоит из 1 байта: младшая тетрада - адрес, старшая - команда. Отсутствие контрольной суммы компенсируется квитированием - ответ должен придти с того же адреса, на который отправлен запрос, код возвращаемой команды должен быть идентичен отсылаемому коду команды. Я просто думаю, что это очень по-дилетантски)) Потому что например пересылка сырых данных (у меня это старшая тетрада показаний АЦП, младшую я упраздняю) подвергаются потенциальной порче. Думаю перейти на фиксированный 4-х байтный пакет: адрес, команда, данные, и 1 байт контрольной суммы 3 предыдущих байт. Но тут на горизонте уже начинает маячить Модбас))

0

Нет, не по дилетантски, а нормально, от простого - к сложному. На каком-то этапе понимаешь, что достигнута необходиния достаточность и ничего лишнего.
Кстати, в другом использовании, с пакетом побольше, у меня похожая на вашу планируемую организация обмена. В этом нет ничего удивительного, все велосипеды тоже похожи.
Удобство УАРТ для отладки существенно, мне пришлось сделать простейший переходник со своего интерфейса на СОМ, но не для отладки сети, а наблюдения и настройки самих устройств. Связь отлаживалась тестовыми программками.

0

Я как то разбирался с древней импортной охранной системой, там в ответ на широковещательный запрос (в той или иной форме), каждое устройство, у которого произошло событие, выставляло на шину бит, соответствующий своему адресу. Далее мастер опрашивал в первую очередь устройства с событиями, а потом все остальные.
Мне этот вариант очень понравился тогда.

0

Сообщение от Kmusmos Думаю перейти на фиксированный 4-х байтный пакет: адрес, команда, данные, и 1 байт контрольной суммы 3 предыдущих байт. Но тут на горизонте уже начинает маячить Модбас))

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

0

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

Действительно интересный вариант, спасибо, подумаю.

0