Нужен проект (скетчи) с использованием ModBus по RS485: мастер на Esp8266, slave - Arduino nano. Slave: это будут 7 устройств. Отличий в сектче не будет, только разве что идентификация конкретного устройства. Это 7 выключателей, на которых будет по две кнопки. Слейв должен рапортовать о нажатии: однократное, двукратное, трехкратное (промежуток между кликами задается через дефайн), удержание. Мастер должен опрашивать эти устройства. Полученные данные должен выводить в сериалпорт или сохранять в какую-либо структуру - не имеет значение, т.к. далее вместо этого будет добавлена отправка в mqtt. В общем-то всё. Кто уже работал с ModBus, для того вроде задачка простая.
Если домашнее освещение, то 485 будет чуть подтормаживать. У меня дома просто выключатель без фиксации подаёт сигнал на аналоговый порт через оптопару. Вам тогда хватит одной нано на все 7 выключателей. Если, конечно, кроме кнопок ничего более там не будет. Извините за оффтоп, так, вам для размышления.
Если, как задумал ТС, опрашивать поочередно выключатели ESPшкой, а потом ещё отправлять всё это по MQTT на исполнительные устройства, без фризов не обойдется. Не спорю, может профи и смогут всё оформить красиво, но уж точно это будет не 5К. А самое главное - нафига?
В системе modbus, опрашиваемые устройства являются слейвами (ведомыми), так как самостоятельно они ничего не могут и не должны делать. Мастер (ведущий) - это головное устройство, которое опрашивает слейвы о статусе. Слейв может ответить, только когда ему разрешит мастер. Тут все указано: https://ru.m.wikipedia.org/wiki/Modbus
7 устройств. У каждого может быть от 1 до 4 кнопок. Можно конечно на резистивной сборке было сделать, но там же на шине планируются и другие устройства в будущем. Сейчас свет уже управляется через mqtt, HA и Яндекс.Алиса. осталось сделать выключатели. Но прошивку уже сделал, тестовый стенд тоже. Надо будет замерить скорость работы. Но субъективно пока что это совершенно не заметно. Я уже на модбасе реализовывал кокпит самолёта. Там более 50 устройств было и всё было моментально.
чувак, я занимаюсь очень сложной промышленной автоматикой (даже не автоматизацией) и прекрасно понимаю, о чём говорю. Если ты думаешь, что в сети не может быть несколько мастеров, то глубоко ошибаешься. Всё давным-давно придумано. И зачем здесь ModBus? Делай на ProfiBus - там гораздо больше плюшек. Ну и ничего не мешает выдумать свой протокол. Лично я бы смотрел в сторону CAN шины.
Все так делают, все ведущие и престижные системы домашней автоматизации, вплоть до самой престижной и качественной Crestron (это системы уровня здания, Пентагон, например, оборудован Crestron) сделаны так что каждый выключатель - слейв. И работают на RS485 и ничего не подтормаживает даже в системах уровня зданий. https://www.crestron.com
Да похоже паровоЗЗ путает определения мастер-слейв и клиент-сервер. Определения клиент-сервер определены в модбас несколько непривычно. Мастер - это клиент. А слэйвы - это серверы. Поэтому обмен всегда инициализируются одним клиентом, которому отвечают много серверов ( слейвов )
Не надо сказок. Пентагон на Apollo Security. Уровень здания типа гостиницы - это KNX. Я ничего не путаю. Мастер в ModBus инициирует общение. На полностью загруженной шине и низкой скорости опрос всех устройств занимает весьма значительное время. А если какое-то устройство выпало из сети - это вообще труба. Абсолютно устаревшая технология. Но до сих пор используется из-за очевидной простоты. Правда, адресная емкость шины ограничивается 2-3 устройствами и в некритичных по временному лагу местах. Сам лично столкнулся с ситуацией, когда шлюз ModBus RTU <-> ModBus TCP сбрасывает соединение порядка 5 секунд, если на подключенной к нему шине 485 не ответил слейв. От бренда шлюза никак не зависит. Феникс контакт и моха работают одинаково.
Так а что есть такого в Appollo, того что нет у других СКД? Стоит Apollo в одном из офисов, ничего особенного, только запредельная цена. Софт специфичный, порой у более дешевых систем - софт более гибкий. Все решается на программном уровне. Не проблемно. Я три раза, с очередностью опроса отвечающих устройств, опрашиваю отвалившееся устройство, потом ставлю его в список недоступных. Опрашиваю его с большим таймаутом, чтобы не тормозить шину, один раз, на 100 - 300 запросов работающих устройств. Пока не ответит. Ответило устройство, перевел на нормальный режим.
Софт не может быть лучшим или худшим. Софт должен удовлетворять ТЗ. Автоматизация прикручивается к любому софту по API, если API есть по ТЗ.
Автоматизация через софт на промке не делается. Только в железе. А итриум - да, это лучший софт для сферы безопасности, что я видел.
