Komrus

Если бюджет есть - смотреть на промышленные решения... С защитой IP65 или лучше...

Если расстояние от Zyxel'я до стенки - небольшое (в пределах метра-двух), и хочется сделать максимально колхозно и бюджетно :) - то можно взять USB шнурок-удлинитель, просверлить в стенке небольшую дырку и просто существующий USB-модем вытащить на улицу.
Для пущей сохранности - нацепив на него резиновое изделие или пакет :)
(Своими глазами видел - такая "система" работала года два на одном объекте :)

Повесив публичный IP адрес на комп - будьте готовы к мощным вирусным атакам. Причём это делается буднично, рутинно - скриптами. Просканировали адреса и порты от XXX до YYY. По вот таким получили сигнатуру ответа, имеющууюся в базе. Ага. Туда ещё поболее сканировать полезут. Попробуют применить зловредов, эксплуатирующих вот такие и этакие уязвимости...
И всё это - на автомате, с ботнетов...

> какой модуль выбрать?
Чтобы без экспериментов - тот, который указан в 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) исксттвенный интеллект...
Да вроде и не нужен в данном сценарии :)
Наверно, когда-нибудь для настройки системы его можно будет использовать...