Russian Users MikroTik | Форум пользователей MikroTik

В качестве шины для периферии лучше всего подойдёт Modbus
viewtopic.php?p=96285#p96285

Датчики и релюшки - родная среда модбаса, много всего готового. Интересно изготовить устройства с интерфейсом ввода, клавиатуру, попросту говоря. Микротик может выступать только мастером в сети модбас, нет возможности инициализировать к нему подключение, он может только опрашивать устройства в сети с заданным интервалом времени и читать данные с регистров или писать их. Есть RS485 клавиатуры, главным образом они работают как мастер модбас управляя подчинёнными устройствами, что логично, может, есть среди них и способные работать как слэйв. В любом случае, не дёшевы они, да и для себя, для дома можно что-то и смастерить, для Ардуины про модбас много сказано. Тумблеры/переключатели, слайдеры и крутилки прекрасно подходят для бытовых целей и для них достаточно только передавать текущее состояние. Дисплей с Ардуинкой на модбасе, mp3 плеер, шлюз блутуз или лора датчиков, есть варианты применения технологии и себя занять :)

DenSyo писал(а): ↑12 дек 2024, 09:35 Датчики и релюшки - родная среда модбаса, много всего готового.

так ведь много всего готового с Modbus-TCP.
и есть более дешевые, чем микротик шлюзы Modbus-TCP / Modbus-RTU.

Конечная цель то какая у вас?
Есть некий программный пульт, который умеет посылать/принимать сигналы Modbus-TCP? Или вы из интерфейса винбокса собираетесь руками скрипты запускать?

Erik_U писал(а): ↑12 дек 2024, 12:33 Конечная цель то какая у вас?

Навести на мысль, какие ещё есть возможности взаимодействия Микротика с различными устройствами. Речь не о решении имеющихся задач, это к пониманию, что некоторые задачи можно решить без отдельного Modbus шлюза, обойтись адаптером за 100 рублей. Идеи увлечённым людям, что ещё можно сделать своими руками и как связать с Микротиком некоторые из которых реализовал.

Какие есть возможности в документации описано. Попробуйте иметь это в виду.

Erik_U писал(а): ↑12 дек 2024, 13:47 Какие есть возможности в документации описано. Попробуйте иметь это в виду.

Совершенно не понял комментария, но спасибо за поддержку, преодолел лень и перешёл от теории к практике. Как пользоваться функцией чтения регистров привёл в топике про KNOT, оставалось проверить как работает запись.

Готового модбас устройства с функцией записи под рукой не оказалось, наскоро скрутил Ардуинку с MAX485

Взял первую попавшуюся библиотеку
https://github.com/CMB27/ModbusRTUSlave

Всё сразу завелось, запись регистров с Микротика работает, пока только функцией 6 понял как пользоваться, 16 надо разобраться с передачей данных, но, тем не менее, все идеи жизнеспособны.

Код: Выделить всё

/iot modbus transceive address=1 function=6 values=a2,a1,b2,b1

address=1 - адрес устройства в сети модбас
function=6 - write single holding register - записать один регистр
values=a2,a1,b2,b1 - a2,a1 - старший и младший байты адреса записываемого регистра, b2,b1 - старший и младший байты передаваемого значения

чтение input регистров делается так же как holding

Код: Выделить всё

/iot modbus transceive address=1 function=4 values=a2,a1,с2,с1

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

Код: Выделить всё

[admin@MikroTik] > /iot modbus transceive address=1 function=3 values=0,0,0,2
   address: 1
  function: 3
      data: 01030400030005
    values: 3,5
      time: 2024-12-13 06:31:34
    status: ok

[admin@MikroTik] > /iot modbus transceive address=1 function=6 values=0,0,0,9
   address: 1
  function: 6
      data: 010600000009
    values: 0,0,9
      time: 2024-12-13 06:31:44
    status: ok

[admin@MikroTik] > /iot modbus transceive address=1 function=3 values=0,0,0,2
   address: 1
  function: 3
      data: 01030400090005
    values: 9,5
      time: 2024-12-13 06:31:47
    status: ok

Повадился центральными шлюзами RouterOS x86 держать - дёшево и сердито. Производительности и ресурсов на всё хватает, на плате куча портов, в том числе RS485, почему не использовать?..

DenSyo писал(а): ↑13 дек 2024, 08:19 наскоро скрутил Ардуинку с MAX485

Все. Остальное - лишнее. Абсолютно самодостаточная конфигурация железа.

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

Вы пытаетесь собрать велосипед из гнилого валежника, когда рядом бесплатные мопеды раздают.
Оставьте роутеру маршрутизацию.

Erik_U писал(а): ↑13 дек 2024, 09:36 Вы пытаетесь собрать велосипед из валежника, когда рядом бесплатные мопеды раздают.

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

Erik_U писал(а): ↑13 дек 2024, 09:36 Все. Остальное - лишнее. Абсолютно самодостаточная конфигурация железа.

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

Мне Ардуинка потребовалась для экспериментов с записью регистров, любой блок реле или датчик с RS485 можно подключить на Микротик и использовать это в скриптах, разве не здорово? Как минимум, блок реле подключенный на центральный шлюз может быть полезен в серверной для физического нажатия кнопок на серверах. У всех есть в серверной такой сервер, который надо периодически пинать ;)

DenSyo писал(а): ↑13 дек 2024, 09:53 Ардуинка должна уметь принимать решения, безусловно, но так же должна уметь быть простым подчинённым устройством, решения она начнёт принимать после потери связи с центральным шлюзом. В роли центрального шлюза у меня везде Микротик и он тоже должен уметь принимать решения в случае потери связи с центральным сервером IoT. Каждое звено должно уметь принимать данные сети и хранить хоть небольшую историю на случай возникновения нештатной ситуации. Именно такой принцип заложен в скрипте сбора телеметрии приведённом мной по ссылке в топике KNOT.

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

И сколько разных устройств мобдас рту вы сможете подключить к 1 микротику?

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

DenSyo писал(а): ↑13 дек 2024, 09:53 Мы на форуме Микротика, где увлечённые люди делятся опытом использования любимых устройств.

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

Erik_U писал(а): ↑13 дек 2024, 10:10 В случае с мобдас рту у вас нет такой возможности. Управалять будет один. Тот, который кабелем подключен.

К Микротику подключены устройства по линии модбас, он ими может управлять напрямую. Сервер IoT управляет устройствами через Микротика по локальной сети обращаясь к уже прочитанным с устройств данным и передавая инструкции на исполнение. Сами устройства могут принимать самостоятельные решения. Речь не идёт об одновременном обращении к устройству модбас, речь о цепочке разных API.

Erik_U писал(а): ↑13 дек 2024, 10:10 И сколько разных устройств мобдас рту вы сможете подключить к 1 микротику?

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

Erik_U писал(а): ↑13 дек 2024, 10:10 ну не на уровне же восторгов от проверки работоспособности функции, которая давно в релизе...

Так если бы хоть где-то об этом было сказано. Понадобилось мне потестировать ICP DAS CON i-7561U на тике, полез забытые команды гуглить, поиск в первых рядах выдал топик про KNOT в котором вы с Sertik ни о чём поговорили, да ещё в заблуждение людей вводите, что модбас на тиках только шлюзом может быть. А пацаны то и не знали, оказывается. Постарался внести ясности.

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

У микротика один тип - INT16 2 байта.
https://help.mikrotik.com/docs/spaces/U ... figuration

Длина строки данных составляет 4 байта. «0x2000» — это команда регистру (длина 2 байта), а «0x0001» (длина 2 байта) — адрес устройства.

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

Вы бы лучше задумались, почему людей, реально работающих с модбасом так и не появилось на форумах микротика за последние 2 года.

DenSyo писал(а): ↑13 дек 2024, 10:22 Понадобилось мне потестировать ICP DAS CON i-7561U на тике,

Ну и как? Увидел его микротик на юсб без драйверов?

Russian Users MikroTik | Форум пользователей MikroTik

USB GPIO EXTENDER

Re: USB GPIO EXTENDER

Re: USB GPIO EXTENDER

Re: USB GPIO EXTENDER

Re: USB GPIO EXTENDER

Re: USB GPIO EXTENDER

Re: USB GPIO EXTENDER

Re: USB GPIO EXTENDER

Re: USB GPIO EXTENDER

Re: USB GPIO EXTENDER

Re: USB GPIO EXTENDER