Здравствуйте. Подскажите пожалуйста кто реально имел дело. Ардуино нано китай атмега 328, rs485 + modbus rtu, библиотеки SimpleModbusSlave.h и SimpleModbusMaster.h, функция 3 и 16. Вопросы: 1. Сколько реально можно открыть регистров? Количество. 2. Какой длины может быть строка с данными? Хочу гонять мастер <-> слейв показания датчиков (температура, влажность, освещенность) и состояние реле (0 или 1), разделитель - запятая. Сколько символов можно напихать в оодну строку? благодарю
Разделитель запятая? Вы собираетесь гонять это по Modbus RTU? А сколько памяти можете выделить? Даже если переделаете указанную "библиотеку" (Заголовочный файл). Фактически в однной посылке до 253 байта... но уверяю Вас многие (если не все) слейвы очень неохотно обрабатывают такой размер. У меня более 32 регистра (64 байта) промышленные устройства начинали просто тупить и именно с командами 3,4,16. А кроме них надо ещё "шапку" пакета и в конце контрольную сумму. Сами посудите... на лету опознать, что хочет мастер, подготовить данные сформировать пакет ответа и ответить. И это только если читаете (команды 3 и 4) а для записи (команда 16) надо разложить старшие и младшие байты регистров, записать и сформировать ответ. Про контрольную сумму пока не сказал. И интервал ожидания по стандарту 3,5 байта... хотя для устройств и выставляется время дополнительное время ожидания. За частую проще общаться размером до 16 регистров. И это для Modbus RTU, а если вы возмёте Modbus ASCII то потребуется ещё и преобразовывать текстовые данные в значения для чтения и записи. А Когда слейв работать будет? Между посылками... при этом прослушивать линию вылавливая свой адрес и контролируя тайминг на линии. Множество устройств собраны на PIC и AVR... а потому и достаточно просты. А DIYMan справедливо сказал: Код (C++): 001 //#include <SimpleModbusMaster.h> 002 #include "Arduino.h" 003 #include "HardwareSerial.h" 004 // state machine states 005 #define IDLE 1 006 #define WAITING_FOR_REPLY 2 007 #define WAITING_FOR_TURNAROUND 3 008 #define BUFFER_SIZE 64 // размер буфера 009 //////////////////// Макроопределения портов и настройки программы /////////////////// 010 #define baud_1 9600 // скоростьобмена по последовательному интерфейсу. (UART) 011 #define timeout_1 1000 // Длительность ожидание ответа (таймаут modbus) 012 #define polling_1 200 // скорость опроса по modbus 013 #define retry_count_1 10 // количесво запросов modbus до ошибки и останова обмена 014 #define TxEnablePin_1 2 // Tx/Rx пин RS485 015 #define TOTAL_NO_OF_REGISTERS 4 016 017 #define COIL_OFF 0x0000 // Function 5 OFF request is 0x0000 018 #define COIL_ON 0xFF00 // Function 5 ON request is 0xFF00 019 #define READ_COIL_STATUS 1 // Reads the ON/OFF status of discrete outputs (0X references, coils) in the slave. 020 #define READ_INPUT_STATUS 2 // Reads the ON/OFF status of discrete inputs (1X references) in the slave. 021 #define READ_HOLDING_REGISTERS 3 // Reads the binary contents of holding registers (4X references) in the slave. 022 #define READ_INPUT_REGISTERS 4 // Reads the binary contents of input registers (3X references) in the slave. Not writable. 023 #define FORCE_SINGLE_COIL 5 // Forces a single coil (0X reference) to either ON (0xFF00) or OFF (0x0000). 024 #define PRESET_SINGLE_REGISTER 6 // Presets a value into a single holding register (4X reference). 025 #define FORCE_MULTIPLE_COILS 15 // Forces each coil (0X reference) in a sequence of coils to either ON or OFF. 026 #define PRESET_MULTIPLE_REGISTERS 16 // Presets values into a sequence of holding registers (4X references). 027 028 unsigned char state; 029 unsigned char retry_count; 030 unsigned char TxEnablePin; 031 unsigned char buffer; 032 long timeout; // интервал таймаута(timeout interval) 033 long polling; // циклический интервал задержки (turnaround delay interval) 034 unsigned int T1_5; // inter character time out in microseconds 035 unsigned int frameDelay; // frame time out in microseconds 036 long delayStart; // init variable for turnaround and timeout delay 037 unsigned int total_no_of_packets; 038 //****************************************************************************** Там действительно есть определение размера буфера, хоть и можно по своему перепилить... была бы память. У мастера задача гораздоооооооооооооо проще, чем у слейва. Удачи во всём!
Свой "безумный дом" делаю. Концепция следующая: множество ардуинок нано разбросаны по дому. Он пока в фазе младенца. Почему нано - не умею делать платы, а у китайцев есть шилды для нано под винтовые зажимы - некоторая надежность. До ESP не дорос пока. Каждая отвечает за свой сегмент и работает независимо. Но часть данных приходится гонять между ардуинками, например с датчика освещенности, время, температуру. Эти данные важны для некоторой автоматизации, например включить в сумерках свет вокруг дома. Если их не будет, то легко эти действия можно сделать вручную. Для этого обмена выбрал rs485 и modbus rtu. В роли мастера все та же нано - перегоняет данные между ардуинками, например, основное освещение на участке включается по "чужому" датчику освещенности, выключается по времени или при выключении света в гараже - тоже другая ардуинка. В сети натыкался на информацию о количестве регистров не более 30, что и подтвердили посты выше. Но этого мало. Поэтому сделал определение регистров не в setup, а в loop по циклу: Код (C++): //сборка пакетов регистров Modbus if (currentMillis_regs - previousMillis_regs > interval_regs) { previousMillis_regs = currentMillis_regs; i++; if (i > 6)(i = 1); packet_mod = true; } //пакет 1 if (i == 1 && packet_mod == true) { modbus_construct(&packets[PACKET1], i, PRESET_MULTIPLE_REGISTERS, 0, 15, 0); // запись данных master-slave (slave адрес 1, регистр 2) modbus_construct(&packets[PACKET2], i, READ_HOLDING_REGISTERS, 15, 15, 15); // чтение данных slave-master (slave адрес 1, регистр 0) modbus_configure(&Serial, baud, SERIAL_8N2, timeout, polling, retry_count, TxEnablePin, packets,TOTAL_NO_OF_PACKETS, regs); packet_mod = false; } if (i == 1) { //запись в регистры для передачи regs[0] = time.Hours; regs[1] = time.minutes; regs[2] = raw; //получение из регистров температуры t_banya=regs[10]; } //пакет 2 свет веранда if (i == 2 && packet_mod == true) { modbus_construct(&packets[PACKET1], i, PRESET_MULTIPLE_REGISTERS, 0, 15, 0); // запись данных master-slave (slave адрес 1, регистр 2) modbus_construct(&packets[PACKET2], i, READ_HOLDING_REGISTERS, 15, 15, 15); // чтение данных slave-master (slave адрес 1, регистр 0) modbus_configure(&Serial, baud, SERIAL_8N2, timeout, polling, retry_count, TxEnablePin, packets, TOTAL_NO_OF_PACKETS, regs); packet_mod = false; } if (i == 2) { //запись в регистры для передачи regs[0] = time.Hours; regs[1] = time.minutes; //получение из регистров температуры raw = regs[10]; } Суть: мастер пересобирает регистры по циклу с интервалом 5 сек. Также хочу вывести данные в веб - majordomo, но без фанатизма, типа могу из любой точки мира включить свет в туалете. Вот тут затык пошел. Вижу 2 пути: 1. еще один слейв с w5100\w5500 на борту. Через MQTT симафорит MJD, принимает команды от MJD. Всплывает проблема недостатка регистров. 2. мастер с w5100\w5500 на борту сам кидает\получает данные с MJD. Здесь не знаю как стабильна будет связка nano + w5100\w5500 + rs485. Второй вариант более логичен, как мне кажется. Первый более стабилен. Может кто еще что посоветует? Вопрос: задал мастеру Код (C++): #define baud 19200 // скоростьобмена по последовательному интерфейсу. (UART) #define timeout 200 // Длительность ожидание ответа (таймаут modbus) #define polling 100 // скорость опроса по modbus #define retry_count 100000 // количесво запросов modbus до ошибки и останова обмена Эти значения рациональны? С учетом пересобирания регистров раз в 5 сек. (1 сек). Благодарю
Имхо. Упритесь и дорастите. Неправильный фундамент гарантирует кривое здание. Начали Вы правильно - много независимых устройств. Добавьте к каждому из них ОДИНАКОВЫЙ протокол mqtt и агрегатор, коих полно, тот же Мажордомо. При выборе агрегатора исходите не из красоты картинок, а сразу размышляйте о том, на каком языке Вы будете там писать правила жизни для ваших устройств. Все ИМХО. Из нежелания разобраться и подучиться Вы уже сделали много лишнего железа и все равно вынуждены тратить время на обучение. Обучение дело хорошее и знания всегда пригодятся, но путь к стандарту Вы выбрали чрезвычайно длинный. esp-8266 сами по себе чуть слабее нано (по количеству ног) но добавьте к ним один старый роутер и у Вас уже есть сеть и информация о каждом. Извините, что не ответил на вопрос. Дело в том что автоматизацией дома занимаюсь давно а с такой проблемой никогда не сталкивался - там без нее хватает. Просто хотел предупредить Вас от неоптимального направления. Ну и тучи проводов. Включать свет в туалете с Мадагаскара конечно глупо, но знать что происходит дома и не пора ли послать кого-то перезапустить котел как в прошлые праздники, неплохо. Вот что я сейчас вижу за 4000 км: И это только часть. Могу добавить картинок. Вот из другой оперы - работа Телеграм: Прикиньте, сколько провода ушло бы на сбор этих данных.
Я за MQTT, присоединяюсь к Игорю. Мало того, что удобно, так и любого агрегатора к брокеру можно подключить, и чего только не вытворять. Modbus, при всём уважении, так сказать - промышленный стандарт, конечно, но, исходя из этого - заточен как раз под промышленное применение, имхо. MQTT для целей не realtime телеметрии представляется гоораздо более удобным.
Благодарю за развернутый комментарий. Долго думал. Пока в сомнениях, но идея переметнуться с нано + rs485 на esp прочно засела в голову. Тем более летом развернул бесшовный wifi во всем доме + участок с помощью mikrotik. Вопрос: как думаете, китайские модули Вемос D1 подойдут? https://ru.aliexpress.com/item/WeMo...id=e188a505-3fc0-4d6b-8999-2769fb795ae5&tpp=1 Других источников получения "железа" у меня нет, поэтому для "пощупать" стоит позаботиться о приобретении заранее.
Я их в руках не держал. Но отзывы о них хорошие. В любом случае USB и стабилизатор - дело хорошее. А устройство у них у всех одинаковое.
Я тоже, в свое время, начинал автоматизацию на даче по схеме: Мастер с GSM-> RS-485 -> локальные контроллеры. Локальные контроллеры - устройства с портами ввода вывода, термостаты на ATMega32 с ЖКИ. Термостатами можно управлять как локально, с кнопок, так и по RS-485. Долго писал код для этого всего безобразия, причем без ардуино и ардуиновских библиотек . Потом наткнулся на OpenHAB и понял, что это то, что мне нужно, в плане визуализации, простоты расширения и подключения различных устройств. Сейчас все устройства, включая дачные, завожу по MQTT на домашний OpenHAB, работающий на raspberry. А начинал с OpenHAB-> RS485 MODBUS -> порт ввода вывода. Он и до сих пор работает. Разобраться не сложно, у Игоря все прекрасно описано здесь. По крайней мере, мне эта тема много нового открыла.
Благодарю. У меня есть свободный ПК, поставил на него Ubuntu 16.04, Majordomo (пока с нее начну). Вопрос: 1. MQTT брокер свой завести (на том же ПК что и MJD) или воспользоваться облаком? 2. Питание 5в развести витой парой с центрального блока питания?
Переберите все возможные варианты и определитесь с языком написания внутренних скриптов. Это САМОЕ важное. Не смотрите на красивые картинки - они ничто. Вам нужно быстро взглянуть на текущее состояние дел и получить аларм информацию. Красивые планы квартир и домов удивляют друзей, но со временем начинают раздражать. Вот, кстати, самый лучший интерфейс умного дома.
Благодарю. Железо под MJD или OpenHAB + MQTT брокер возможно использовать ПК? Чисто из экономических соображений. Raspberry 2 китай стоит 3000. У нас 1 квт\ч свет стоит 1 рупь. Или кроме энергопотребления есть еще подводные камни?
Я в начале наигрался с ардуинкой - она у меня свои режимы работы показывала мигая по-разному светодиодами. Потом поймал себя на мысли, что это мне на фиг не нужно. Сейчас хочу датчик движения охранный к модулю, отвечающему за свет, подключить. Сидишь такой на горшке, ардуинке по времени пора перейти в ночной режим, она гасит свет, зажигает ночники. Первая мысль - свет отключили, сердце ёкает. На хрен эти кардиотренировки - переключай некоторые режимы тогда когда меня\семьи там нет или только когда я хочу. Поэтому красивости\понтам я мало внимания уделяю. От визуализации мне нужно, чтобы система показывала, если какие-то параметры вышли за допустимые пределы и она это устранить не может. Я несколько лет назад трубу от скважины переморозил. Летом копался с ней и пакетник подогрева отключил. Включить забыл. Зимой вода кончилась. Долго ходил морщил лоб, искал причину. Сценарий с автоматизацией выглядел бы так: система увидела критическое снижение Т, несмотря на то что релюшка, отвечающая за подогрев, включена, сообщила бы мне об этом. А каждый день мне симафорить Т в скважине не надо.
Понимаете, умный дом - это надолго. Выбор железа дело непростое. Большей частью, все системы и разработки доступны для Linux. А на чем этот линукс расположен - дело ваше. Нужно будет периодически резервировать состояние системы. С этой точки зрения, малина с ОС на sd карте проигрывает любому железному компу. Эту задачу тоже придется решать. В общем, есть ПК - пусть ПК. Но не забывайте о резервировании. Если "свалится" агрегатор и не будет бэкапа - все ваши миньоны разбегутся
Если ModbusRTU, то Вам уже всё сказали... либо Вы знакомитесь с протоколом, либо делаете свои (полностью свои) исполнительные устройства. Значения не имеет умное каждое из них или нет!
