Komrus

> какой модуль выбрать?
Чтобы без экспериментов - тот, который указан в datasheet'е от производителя
https://www.dlink.ru/ru/products/1/2422.html
Это - DEM-410T

Если брать сторонний - пусть поставщик подтвердит, что предлагаемый SFP+ - совместим с Dlink'ом...

1) Определиться - планируете использовать Modbus-RTU (по RS-485) или Modbus-TCP (по Ethernet)
2) Убедиться, что у обоих железок соответствующие порты в наличии, не заняты подо что-то другое и между выбранными портами есть связь.
3) Для настройки Modbus TCP на Siemenes Logo - почитать
https://habr.com/ru/articles/651329/
4) Для ПР103 - см
https://owen.ru/uploads/516/protokol_modbus_v_oven...

Есть модели коммутаторов (заточеных под видеонаблюдеие), которые по стандартной UTP 5 обещают 200 метров. В общем-то - получается. Правда - путём снижения скорости до 10 мбит/с.
А так - можно попробовать подключитьсяна 150 метров на любых железках, где с обоих сторон можно принудительно вкючить режим 10 мбит/с FDX, и убедиться, что Green Ethernet (IEEE 802.3az) отключен.

Зависит, конечно от критичности задачи и имеющгося бюджета. На случайных неуправляемых коммутаторах - ерунда получится. Если в продакшн в энтерпрайзе - оптика и только оптика (это я ещё про 32G FibreChannel не вспоминаю, с его OM5 оптикой...)
. Если в общаге с друзьями надо линк прокинуть на годик- можно смело поэкспериментировать...

И вот зачем создавать дублирующий вопрос, не ответив на уточняющие запросы в этом?

Есть, говорите 10...15 датчиков. Это очень далеко от "высоких нагрузок"

1) На чём они сидят?
На кабеле? (Fast Ethernet, Gig или что?)
На радио? WiFi? Какой именно и какой диапазон?

2) Запускайте на смартфоне "WiFi Analyzer" и смотрите, что творится в WiFi радиоэфире.
Обычно- там полнейшая каша.
Плюс, в наше непростое время - запросто какая-нибудь глушилка может по сосседству стоять и убивать диапазон 2.4 ГГц

3) При пропадании WiFi связи и её восстановлении - датчик сам может корретно отработать это событие и продолжить отправлять

До MQTT тут ещё далеко - неплохо бы вначале со связью разобраться.

PPS. В продолжение к дублирующему вопросу - можно ведь прямую ссылку дать на книгу
https://www.hivemq.com/static/ebooks/hivemq-ebook-...

Глобально - требования в запросе похоже на то, что делают DCIM системы (Data Center Infrastructure Management)

Можно посмотреть, например на OpenDCIM - но она не сильно балует красивыми картинками.

Решения-то существуют уже много ДЕСЯТКОВ лет.
Искать не в рубрике "умный дом", а в "автоматизация инженерных систем здания".
Ключевые слова "организация автоматического и локального управления".
Основная идея - при выходе управляющего контура из строя должна остаться возможность локального управления каждым элементом.
Побочный эффект (как в любых системах) - девятка к надёжности (надёжность 0.999 вместо 0.99) запросто может дать нолик к цене...

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

Но, как побочный эффект - никто не заморачивается разработкой более сложных (и дорогих) ГОТОВЫХ решений и с облачным, и с локальным управлением.
Это всё надо прорабатывать самостоятельно на уровне электрических схем в процессе разработки проектной документации (а Вы как думали? :))) и прикидывать - от выхода ЧЕГО из строя мы защищаемся?

Вариант решения 1
Защищаемся от выхода из строя центрального хаба (контроллера) - можно устанавливать умное реле в подрозетники за выключателем (тут выше вариает от Aqara приводили). При корректно функционирующей системе - можно управлять как с центрального пульта (в т.ч. - голоссом), так и непосредственно с выключателя.
При выходе хаба (центрального контроллера) из строя - остаётся локальное управление. Но при выходе реле из строя - "Ой!". Эта группа - отвалится. Купируется наличием в ЗИПе (холодном резерве в тумбочке) такого же реле.
(Соответственно - автор упоминаемых в вопросе статей предпочёл построить чуть более сложное решение, зато с горячим резервированием)

Вариант 2
Вспоминаем "проходной выключатель". Только электрическая фаза по пути до лампочки проходит не через два выключателя, а через:
(а) реле, управляемое контроллером умного дома и
(б) через настенный выключатель (переключатель; простой, не умный)
В идеале - приделать к выключателю ещё и информационный хвост "контроль положения" и завести его в контроллер.
Чтобы не отвалилось - локальное управление остаётся . Ибо сугубо электрическое, без электроники.
Но разводку электрических проводов - надо изначально под такое решение прокладывать.

Ну и по любому для проектов такого масштаба:
1) написать ТЗ:
что должно получиться в итоге; требования всяческие к тому, что должно получиться; критерии оценки получилось/не очень...
Расписать ограничения: технические, организационные (например - наличие тех.поддержки, время реакции, время восстановления, время замены оборудования.); политические (например - допустим ли параллельный импорт; будет ли закупаться по 223 ФЗ или сугубо коммерческая закупка).
Согласовать со смежными системами - какие требования на локальную сеть они возлагают. (Например от мультимедиа может прилететь требования поддержки не самых распространённых протоколов типа AVB или Dante).
Продумать - взаимные ЧТЗ и разграничение зон ответственности между строителями кабельной системы (какие кабели нужны); инженерными системами (например - сколько тепла выделяют PoE коммутаторы в кроссовых); дизайнером (уберите с глаз долой эту точку доступа!); общестроем (как, вообще &^%$ подлезть к этой WiFI ТД !!!? :))) и теми, кто будет монтировать/настраивать оборудование

Согласовать внутри организации - Заказчика

2) Выбрать нескольких потенциальных поставщиков (системных интеграторов)
Обсудить с ними ТЗ. Уточнить упущенные моменты.
Согласовать - кто на на каком оборудовании готов предложить решение.
Отправить RFP
Получить КП (а лучше - ТКП)

3) Наслаждаться муками выбора :))) Но уже - обоснованными, с цифрами и аргументами от разных вендоров.

PS. Могу поучаствовать в процессе подготовки всех этих бумаг...

> Цены на те и другие датчики без герметичных гильз +/- одинаковые.

Датчик с RS-485 зачастую это аналоговый датчик + микросхемка :)
Так что во многих случаях датчик с RS-485 - дороже. (Особенно - если бренды брать)
Датчику на RS-485 надо ещё и питание притаскивать...
Зато его можно вдали расположить.

В общем - я бы проектом определял.
Если надо датчики не очень далеко от щита автоматики - ставим аналоговые и берем контроллер с какими-нибудь входами типа Pt1000/Ni1000.

Если подальше надо датчик утащить или надо многофункциональный датчик - то RS-485
Или KNX :) В нём хоть питание штатно по тому же кабелю передаётся. Или Bus77 от Iridi.

PS. Это всё - про автоматизацию инженерных систем зданий, не промку...

PPS. И вообще - лучше вначале прикинуть ВСЕ требования к датчикам/исполнительным механизмам в проекте, а потом принять идеологичнеско-технически-коммерчекское решение, на чём строить будем. (Протокол/вендор)
А уже из этого будут вылезать всякие частности, типа - какие там датчики....

В общем - вначале ТЗ; потом, в процессе разработки проектной документации, - принятие проектных решений; а написание скриптов - где-то сильно потом...

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

2) Система управления. Мозг системы.
Все алгоритмы, сценарии - тут.
Если хотите оренсорсную и размещаемую дома - настоятельно рекомендую
OpenHab. (https://www.openhab.org/)
Сценарии - продумывать головой. Своей.

3) Плагин голосового управления для этого OpenHab

Или, как вариант - отдать всё на откуп чужЫм дядям и поставить облачную Алису...

4) исксттвенный интеллект...
Да вроде и не нужен в данном сценарии :)
Наверно, когда-нибудь для настройки системы его можно будет использовать...

На каком ПОРТУ настроено управление OBS'ом?
Дефолтный - 4455
И вообще - оно настроено?

Open OBS Studio and navigate to Tools > WebSocket Server Settings

Ну и в настройках Windows защитника/файрвола - ручками правило, позволяющее подключаться к этому порту, кто-нибудь создал?

А менеджерам проекта - нужна аналитика, статистика и сбор данных. Что удобнее делать в своём приложении. Увы, как бы не было это печально, но таковы нонешние реалии...

Ряд производителей (в т.с. - Kingston) занимаются выпуском совме тимой памяти для брендовых серверов.
У них на сайте можно вбить вендора/модель сервера и получить список артикулов DIMM'ов альтернативного производителя, которые совместимы.

Если говорить про шкафы, теплоизбытки с каждого шкафа.

0) Современные 19" сервера рассчитаны на подачу к ним холодного воздуха спереди и выдув горячего воздуха (уже силами собственых вентиляторов) - сзади.
Используется термин Airflow Front-to-back.
Исходя из этого и серверные 19" шкафы делают: достаточно глубокие и с СИЛЬНО перфорированными передней и задней дверью (чтобы не мешать движению воздуха).
Размер шкафа - глубина - не менее 1000 мм (лучше - 1200 мм); ширина - 800 мм (чтобы спокойно установить вертикальные PDU и расположить все кабели) Высота - 42 или 47U.
Всякие вертикальные органайзеры, PDU, подсветка, полочки - настоятельно рекомендуются.
Требуемое место спереди шкафа - чтобы выкатить на штатных салазках сервер. Сзади - чтобы подойти человеку и скоммутировать, что надо. Желательно полтора метра - спереди и метр - сзади.

Шкафы с вентиляторами в крыше (и стеклянной дверью) - это для коммутационных шкафов. Где много-много патч-панелей и парочка коммутаторов с непонятным airflow и тепловыделением в пределах сотен Ватт.

1) Холодные/горячий коридоры - это когда есть достаточное количество шкафов, чтобы их в линию выстроить. И подавать холодный воздух тем либо иным способом к передней стороне ряда шкафов.
Изолировать какой-либо из этих коридоров - когда тепловыделение с отдельного шкафа велико, а также - когда боремся за энергоэффективность (увеличиваем кап.затраты, уменьшаем операционные затраты)

2) Куда и какие вешать кондиционеры, как расставить шкафы - зависит от фактического (и перспективного) тепловыделения от серверов/СХД/коммутаторов...

2.1) Если "просто серверная" с несколькими серверами и тепловыделением в пару киловатт со стойки - вешаем сплит систему. Полупром или даже хорошую бытовую. Но ОБЯЗАТЕЛЬНО с зимним пакетом до -30. Ибо серверам не объяснишь, что за стенкой - зима :). Учесть, что летом, в +30 фактическая холодопроизводительность кондея несколько меньше заявленой. Плюс стенки/потолок помещения нагреваются и тоже дают теплопритоки. В общем - раза в полтора запас по холодопроизводительности надо иметь от перспективных теплоизбытков от серверов. Плюс - кондеев неплохо бы парочку поставить. С блоком ротации.
Вешаем так, чтобы дуло более-менее на лицевую сторону шкафа. Шкафы ставим, как позволяет имеющееся помещение (с учетом сказанного в п.1)

2.2) Если более 5 КВТ на стойку намечается - то с висящими на стенке кондиционерами могут начаться чЮдеса. Из серии "верхние сервера в 19" шкафу хорошо охлаждаются, а у нижних датчик перегрева орёт". И с постоянными танцами с оптимизацией воздушных потоков тем либо иным способом. Надо бы или раскидать на бОльшее количество стоек, либо начинать думать о чём-то вроде фальш-пола. Из под которого будет холодный воздух дуть. И прецизионные кондеи, которые будут под этот фальш-пол холодный воздух загонять.
Или изолировать холодный коридор и туда канальными кондиционерами холодный воздух загонять.

2.3) Если более 10 КВт на стойку - лучше на специализированные внутрирядные кондиционеры смотреть. В комплекте с изоляцией коридора. Которые устанавливаются с один ряд в 19" серверными шкафами между этими шкафами (кондеи имеют высоту как серверный шкаф, а ширину - 300 либо 600 мм). Кондеи забирают горячий воздух из горячего коридора, охлаждают его и закидывают в холодный коридор.
Если речь об одном-двух шкафах идёт, места мало, а напихать надо много - бывают готовые решения "ЦОД-в-шкафе". Шкаф с внутришкафным кондиционером, кабель-менеджментом, блоками PDU (розеток) и даже - опциональным газовым пожаротушением.

2.4) Ну а больше 20 Квт на стойку - ОЧЕНЬ внимательно проектировать надо. Airflow, CFD-моделирование воздушных потоков, отказоустойчивость и т.п. Ибо случись что - перегреется в момент...