Контроллеры своими руками для умного дома

Умный дом с нуля своими руками или путешествие длиною в год

Данную статью пишу для думающих, стоит оно того или нет, и начинающих построение своего умного дома, надеюсь она поможет сделать вам свой выбор. Для тех кто думает, я не программист у меня ничего не получится, я тоже, хотя имею техническое (теплоэнергетик) образование, но никогда не работал в IT, не знаю ни одного языка программирования. Дорогу осилит идущий. Начнем с рассуждений что такое умный дом, поверьте на слово он не решит все ваших бытовых и семейных проблем, но точно сделает жизнь немного комфортней. Что такое умный дом в моем представлении год назад: 1. Красивый планшет со схемой дома висящий на стене в прихожей с которого можно управлять всем в доме; 2. Управление всем чем можно голосом. Откровение через год: планшет не нужен, так как бегать со второго этажа на первый, чтобы по управлять, неудобно. Что бы хорошо работало голосовое управление, требуется установка умной колонки в каждую комнату, когда их две — это одно. А когда значительно больше — вопрос. Сейчас для меня умный дом это то, что работает само без моего участия, и не требует управления. Все о чем пойдет речь далее сделано мною лично, может можно сделать по-другому, может проще и лучше. Но таков путь.

Краткий ликбез

Системы умного дома

1.1 Mi Home

+ красивые сенсоры и устройства; хорошее мобильное приложение; простое построение автоматизаций;

— закрытая экосистема; данные хранятся на облачных серверах; автоматизации работают через облачные сервера.

1.2 Google home

+ это google, интерфейс на высшем уровне;

— закрытая экосистема; автоматизации работают через облачные сервера; в приложении есть поддержка таких решений, о которых вообще не слышал.

1.3 Domoticz

+ открытая экосистема; большое русскоговорящие сообщество; облако через которое ты можешь зайти на свой сервер; язык для автоматизаций blockly — удобный и понятный;

— не которые вещи в нем реализовать очень сложно (или я не разобрался); не успевает обновляться документация; делаешь по написанному в Вики, а не работает, так как все поменялось; частые обновления.

1.4 HomeBridge — для поклонников apple, а так как я сторонник светлой стороны силы, прошел мимо

+ это Apple, интерфейс на высшем уровне и работать должно как часы;

— как мне сделать вот так? — А вам это не надо, мы в Apple решили, что вам нужно только так.

1.5 ioBroker — открыл интерфейс, закрыл и больше не открывал

+ были первооткрывателями много чего, хорошая поддержка многих устройств;

— такой интерфейс в 2020 году преступление.

1.6 MajorDomo — честно говоря как-то прошел мимо

+разработчики наши, мелочь, а приятно;

1.7 Home Assistant — вишенка на торте умного дома

+ открытая экосистема, нормальный интерфейс, который можно настроить самому как угодно, актуальная документация, поддержка всего чего угодно, может интегрироваться с Яндекс Алиса, Mi Home, Google home, HomeBridge, нет ничего невозможного для реализации, автоматизации ограничены только вашей фантазией;

— сложность освоения на первоначальном этапе.

Как вы уже догадались, мой выбор пал на Home assistant и далее речь пойдет о нем.

Железо

2.1 Роутер

Я живу в частном секторе, и у нас один провайдер местного масштаба, который тянет оптику и всем выдает изделие ZTE F660. Два месяца я с ним мучился, каждый день что-то отваливалось и не работало, пока не поменял его на Keenetic Ultra. Все проблемы с отвалами умных устройств как рукой сняло. Так что роутер ключевой элемент умного дома. Цена вопроса зависит от стоимости роутера.

2.2 Сервер

Для работы Home Assistant требуется сервер, на котором будут хранится все данные и управляться устройства умного дома. Тут есть несколько путей: можно установить Home Assistant на компьютер, старый ноутбук под Windows или на мини компьютеры под Linux или Ubuntu, которых сейчас бескрайнее множество, или на NAS. Тут все зависит от вашего желания и возможностей. Так как сервер должен работать в режиме 24/7, то я для себя выбрал вариант Raspberry pi 4b 4Gb. Потому что у него низкое энергопотребление, он бесшумный (эксплуатирую в безвентиляторном корпусе). У меня на нем работает Home Assistant и Plex (медиа сервер) в режиме 24/7 уже полгода, проблем с производительностью нет. Но если вы кроме этого хотите использовать какие-то еще ресурсы, то советую посмотреть в сторону NUC. Хотя начинал знакомиться с системой на Windows 10, но у меня вызывает вопросы ее стабильность с криворукими обновлениями, от которых больше вреда, чем пользы. При использовании Raspberry pi 4b, есть несколько нюансов, должен быть хороший блок питания, который выдает честные 3 А и нельзя устанавливать в безвентиляторном корпусе в закрытые ящики, так как ее рабочая температура около 50 градусов. Цена вопроса Raspberry pi 4b 4Gb около 4 тыс. руб. на Али.

2.3 Стандарты беспроводной связи умных устройств для умного дома

WiFi — он и в Африке WiFi. Для работы нужен WiFi роутер и чтобы устройство умного дома находилось в одной локальной сети с сервером. Большое количестве WiFi устройств особенно видеокамер, может влиять на скорость WiFi не умных устройств. Для стабильной работы умного дома нужен хороший WiFi роутер, причину описал ранее.

Zigbee- энергоэффективный (устройство может несколько лет работать от одной батарейки) стандарт беспроводной связи, позволяет строить ячеистые надежные сети. Для связи умных устройств Zigbee с сервером умного дома нужен координатор (шлюз). Без него умные устройства работать не будут, нужен именно Zigbee шлюз. В Zigbee несколько поколений стандартов, самые распространенные сейчас 2.0 и 3.0. Будьте внимательны шлюзы с поддержкой Zigbee 2.0 не будут работать с устройствами Zigbee 3.0. Новые Шлюзы Zigbee 3.0. имеют обратную совместимость и будут работать с устройствами старого стандарта.

Bluetooth — энергоэффективный (устройство может несколько лет работать от одной батарейки) стандарт беспроводной связи, последние его разновидности в частности Mesh, так же позволяет строить ячеистые надежные сети. Для связи умных устройств Bluetooth с сервером умного дома нужен координатор (шлюз). Без него умные устройства работать не будут, причем нужен именно Bluetooth шлюз.

2.4 Координатор или шлюз. Координатором в Home Assistant могут быть

Шлюзы различных производителей Xiaomi , Тuуа, Sonoff и д. р. Работают через облако (китайские сервера). В основном работают с умными устройствами своей экосистемы. Не поддерживают или не полностью поддерживают умные устройства других производителей. Цена вопроса около 2-3 тыс. руб. на Али.

Stick СС2531, СС2538, СС2652, вставляются в usb сервера, работают по протоколу zigbee2mqtt, поддерживают работу с устройствами большого количества различный производителей, поддержку конкретного устройства можно посмотреть у них на сайте. Работают в локальной сети, даже без интернета. Stick СС2531 не поддерживает больше 32 устройств, если планируете больше умных устройств в своей сети, обратите внимание на Stick СС2538, СС2652, они уже поддерживают более 100 устройств. Цена вопроса около 2 тыс. руб. продают их в Telegram.

SLS шлюз отдельно устройство, такое же как шлюзы Xiaomi , Тuуа, Sonoff, но так же работает по протоколу zigbee2mqtt. И работает со большим количеством различных производителей. Работают в локальной сети, даже без интернета. Цена вопроса около 3 тыс. руб. продают их в Telegram.

Мой путь

В конце 2019 года начитавшись статей на различных сайтах про умный дом приобрел стартовый набор Xiaomi для умного дома и один выключатель решил протестировать умный дом у себя в квартире. Все подключил установил Mi Home и счастливый начал эксплуатировать, так как набор был приобретен в Китае на Али, то работать в регионе Россия он отказался и пришлось его настраивать в регионе Китай. И автоматизация работала через китайские сервера, работала громко сказано. Складывалось впечатление, что майор в Китайском КГБ согласовывал включение света в моей квартире. Задержки в автоматизациях доходили до 5 секунд и работали через раз, 5 раз сработает на шестой нет (видно майор не разрешил). Помучившись неделю, поставил крест на умном доме, снял все датчики и положил в ящик. Тут бы могла история и закончится.

Но в марте 2020 году удалось приобрести частный дом в черновой отделке и решил умному дому быть начал изучать вопрос, перелопатив весь интернет приобрел stick СС2538 и установил Home Assistant на компьютер с Windows 10, сделал копипаст со статей в интернете. И о чудо все заработало задержек нет все включается моментально и работает.

Далее распланировал размещение основного электрооборудования в доме (розетки и выключатели), угадал расположение на 90 процентов, остальное решил купив накладные розетки. Приобрел Raspberry pi 4b 4Gb на Али, купил умные розетки и выключатели Xiaomi (дизайн понравился). Смонтировал все это хозяйство. Установил Home Assistant на Raspberry по урокам Alex Kvazis на youtube, кстати огромное ему спасибо на начальном этапе его уроки были не заменимы делал с них полную копию. Так как другой информации взять было неоткуда, есть хорошее русскоязычное сообщество по Home Assistant в Telegram, но на первом этапе и спросить то не понимаешь чего, и на 90% вопросов получал ответ читай документацию. Я ее честно читал но ничего понять не мог, злился. Сейчас понимаю парней, так же сижу в чате и ежедневно одни и те же вопросы повторяются. Так и хочется сказать читайте документацию. На первом этапе очень помог блог https://ivan.bessarabov.ru/, за что спасибо Ивану.

Начал эксплуатировать на stick СС2538, все работало четко и стабильно. Но тут решил купить светильники на али Xiaomi bluetooth mesh красивый дизайн, регулируется яркость и цветовая температура, так как stick не поддерживает данные устройства был куплен шлюз третий версии от Xiaomi. О нем расскажу отдельно благодаря усилиям @AlexxIT и его интеграции Xiaomi Gateway 3 для Home Assistant, данный шлюз превращается в уникальный продукт, позволяет одновременно параллельно работать умным устройствам и в Home Assistant и MiHome, только умные устройства должны быть Xiaomi. Так же Home Assistant с данным шлюзом можно интегрировать с Яндекс Алисой, Google home и HomeBridge. Так же отдельное спасибо хотел сказать @AlexITон сделал для развития популярности Home Assistant в русскоязычном сообществе очень много, является автором интеграций Sonoff LAN, Yandex.Station. Но есть ложка дегтя в бочке меда шлюза третий версии от Xiaomi, к сожалению производитель в новых прошивках шлюза даты производства с 10.2020 г. закрыл Telnet и теперь без паяльника шлюз в Home Assistant не интегрировать (говорят 10 минут работы и все сделано), но будьте в курсе.

Как вы уже догадались начиная с сентября я переехал на Xiaomi Gateway 3, уже более полугода все работает стабильно, сейчас у меня в эксплуатации 77 устройств Xiaomi, розетки, выключатели, различные датчики.

4. Сейчас уже реализовано

Управления всеми розетками и выключателями кухня

управления всеми розетками и выключателями, из любой точки мира

автоматизировано освещение туалета, ванной, коридора, прихожей, лестницы;

настроено адаптивное освещение, когда автоматически в течении дня меняется яркости и цветовая температура;

Мониторинг погоды

мониторинг погоды и микроклимата в доме

автоматизировано управление батареями в зависимости от температуры;

Мониторинг сервера

мониторинг наличия интернета и сервера;

автоматизировано управление подачи воды в зависимости от времени суток;

Датчики безопасности

сделаны датчики безопасности и уведомления в телеграмм протечка воды, задымления, загазованность, движение в доме, выключить все розетки, выключить весь свет в доме;

уведомления о нежелательных событиях в доме остановился котел, с работка датчиков безопасности;

Учет электроэнергии по группам

учет электроэнергии по группам потребителей;

Робот пылесос, увлажнитель

интегрированы различные устройства, с возможностью их управления;

время прибытия транспорта на остановку;

управление умным домом голосовыми командами Алиса и Эй google.

В планах

автоматизировать уличное освещение;

интегрировать ворота Алю тех в Home assistant;

автоматизировать полив растений

5. Где я ошибся

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

Покупка видеодомофона с камерами с Али, сейчас бы купил ip камеры и интегрировал в Home assistant.

Приобретение WiFi видеокамеры Xiaomi внутри дома, которая не интегрируется в Home assistant, сейчас бы купил Reolink.

Заключение

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

Это первая моя статья на habr, если тема умного дома интересна пишите в комментариях о чем хотите узнать все расскажу, просто Home assistant целая планета и в одной статье все не рассказать. Какие темы интересны, что хотите узнать подробней, если будет интерес напишу более подробный материал.

Источник

Делаем контроллер для умного дома

Делаем контроллер для умного дома и не только.

В предыдущей статье я описывал разработку системы в целом. В этой я опишу разработку контроллера, который отвечает за опрос датчиков и модулей ввода-вывода. «Зачем изобретать велосипед?» — спросите вы. Во-первых, это интересно, во вторых, как ни странно, нет OpenSource решения для подобного контроллера, покрывающего как программную так и аппаратную часть. Статья ориентирована на людей немного разбирающихся как в электронике так и в embedded linux development.

Сделать контроллер, скажете вы, это же так сложно — нужно делать плату, писать софт, печатать корпус. Но в реалии всё чуть-чуть ещё сложнее, вот во что это вылилось для меня, но вы в принципе правы:

1. аппаратная часть контроллера

— выбор cpu платы для контроллера
— выбор IO контроллера
— выбор блока питания
— структурная схема контроллера
— разработка кросс платы для контроллера
— разработка плат для RS-485 модулей
— производство плат

2. софт для контроллера

— выбор системы сборки для ядра linux и rootfs
— структура разделов SD карты
— выбор бутлоадера и загрузка нужного rootfs
— изменения в device tree
— выбор системы сбора дебажных трейсов
— написание билдсистемы
— написание коммуникационного ядра
— написание mqtt гейтвея (дискретные/аналоговые точки контроллера -> топики mqtt)
— написание парсера гуглтаблицы и построение конфигурационного json файла для гейтвея
— написание point monitor для доступа к точкам контроллера
— монтирование readonly файловой системы

3. корпус контроллера

— какой должен быть, разъёмы, охлаждение, посадочные места под плату, закладные под клипсы для скоб на динрейку.
— конструирование и печать

Пару слов о аппаратной части.

Наверно только самые отчаянные сейчас берут отдельно процессор, память, флеш, контроллер питания, еще пару сот компонентов и начинают лепить это всё вместе. Остальные же пользуются плодами трудов других людей, так быстрее и проще. Нужно всего лишь открыть браузер и написать «одноплатный компьютер» и весь остаток дня провести в выборе нужного. Мне нужно было много последовательных портов и желательно что бы плата поддерживала -40°C до +85°C, поэтому выбор пал на BeagleBone Black(BBB). Также на ВВВ вся периферия выведена на два разъёма PBD по 46 пинов с шагом 2.54, что удобно для макетирования и разработки кросс платы. Кросс плата нужна что бы объединить все компоненты на одной плате, у меня это — cpu плата, блок питания, IO контроллер, и платы каналов RS485. Также именно кросс плату нужно крепить к корпусу и на ней стоят разъемы для подключения питания и кабеля RS485.

Так, с cpu платой разобрались, следующее что надо решить — нужно ли на кросс плату ставить Input/Output(IO) контроллер или можно и без него. Я его заложил на плату, и успешно им пока не пользуюсь. Единственное что он делает это откладывает старт BBB на 1с после подачи питания и обслуживает кнопку reset.

Блок питания для контроллера я взял уже готовый MeanWell NSD10-12S5, разрабатывать его для единичного девайса — бессмысленная затея, просто подобрал его по потреблению и всё. На ЖКИ не обращайте внимание, он есть на плате, но поддержку я не реализовал.

Пару слов о платах каналов RS485.

На кросс плату выведены 4 последовательных интерфейса BBB. Так что туда можно поставить любой тип канала который нужно, RS485, CAN, Zigbee модуль…

Мне нужны были каналы RS485, так что я сделал только их, они с автоматическим управлением приемом/передачей и с гальванической развязкой. Почему не использовать управление приёмо-передачей с ВВВ, да потому что TI официально перестали поддерживать строб для RS485 в драйвере serial устройства. Можно найти патч к драйверу, можно дописать самому, но зачем? Сделав канал самостробирующий, можно его будет ставить на любую плату, например на RaspberyPi, где никогда и не было такой поддержки, если была, то поправьте меня. Строб для драйвера rs485 формируется на attiny10, дешево и сердито.

Возвращаемся к софту.

Выбор системы сборки для ядра linux и rootfs.

Существует несколько подобного рода систем, самые популярные это Yocto и BuildRoot. Ели вам нужно разработать большой проект, если у вас много времени и желания писать рецепты, то Yocto — ваш выбор. С помощью же BuildRoot, можно собрать всё что нужно для простого запуска платы очень и очень просто, т.к. я делаю систему на Beaglebone Black (далее ВВВ) то:

1. почитать что написано здесь habr.com/ru/post/448638
2. make clean
3. make beaglebone_defconfig
4. make

Вот и всё. Теперь всё необходимое для запуска платы, лежит в папке /buildroot/output/images.

Выглядит всё очень просто и не интересно, так что можно сделать немного посложнее:

1. интегрировать buildroot в свою билдсистему, скачивать его скриптом, не забыв использовать стабильный тэг, а не брать последний develop
2. написать свой defconfig и перед сборкой buildroot подкидывать его скриптом в папку /buildroot/configs, не забываем что все дефконфиги должны заканчиваться на *_defconfig, иначе buildroot его не видит
3. копировать свой post-build.sh в board/beaglebone/post-build.sh
4. сделать prepare скрипт, который будет делать п1, п2 и п3 за вас

Как результат buildroot будет генерировать zImage и rootfs.tar

Выбор структуры разделов SD карты:

На этом, думаю, не стоит много акцентировать внимание.
Я сделал 4 раздела BOOT / ROOT_1 / ROOT_2 / DATA.
В BOOT разделе хранится всё необходимое для начальной загрузки: MLO, barebox.bin, barebox.env, am335x-boneblack.dtb, zImage, boot.txt.

ROOT_1 и ROOT_2 содержат rootfs, выбор которого вписан в файле boot.txt(см. ниже). Все эти разделы монтируются как readonly во избежания крешев файловой системы при выключении питания. DATA содержит проектные конфиги, при изменении которых нет необходимости пересобирать код.

Такая структура разделов в будущем позволит легко написать software update компоненту. Эта компонента будет перезаписывать один из разделов ROOT_1/ROOT_2, который сейчас не используется, а потом просто менять файл boot.txt, если не нужно менять ядро.

У меня было много экспериментов с бутлоадерами для BBB. Сначала я использовал, как все, U-Boot который генерирует BuildRoot. Но мне он не понравился, может быть, конечно, это дело привычки, но мне показалось что это перебор, уж очень он тяжелый и сложно конфигурируемый. Потом, я подумал что не плохо бы было стартануть систему быстро, секунды за 2-3, и подпилив X-Loader так что бы он грузил ядро, у меня это получилось, но опять же остался вопрос с конфигурированием, да и время старта для меня не критично(система на systemd грузится сама по себе медленно, даже если удалить всё не нужное).

В конце концов я остановился на barebox, его простота мне очень понравилась, плюс на сайте есть вся документация (www.barebox.org).

Например, что-бы грузить rootfs c первого или второго раздела нужно всего лишь:

1. на boot разделе сделать файл boot.txt который экспортит переменную типа «export BOOT_NUM=Х»

2. сделать два скрипта /env/boot/sdb1 /env/boot/sdb2 в которых описать параметры загрузки, например:

3. сделать скрипт /env/boot/sd в котором в зависимости от BOOT_NUM стартовать sdb1 или sdb2 скрипт

4. установить переменную boot.default

5. далее меняя BOOT_NUM в boot.txt мы будем загружать rootfs с первого или второго раздела, что в будущем можно использовать для software update.

Изменения в device tree.

Поскольку для связи с модулями я использую MODBUS RTU по RS485, то мне нужно было включить практически все существующие на ВВВ последовательные порты. Для этого надо заэнэйблить их в device tree, т.к. по умолчанию большинство из них выключены.

Правильно бы было сделать свой патч для файла am335x-bone-common.dtsi из пакета билдрута и применять его каждый раз перед его сборкой, но лень победила, и я просто вытащил все нужные файлы, поменял всё что нужно и сбилдил руками.

Т.к. это делается один раз, то можно и так:

1. Создаем папку с файлами необходимые для сборки:

2. В файле am335x-bone-common.dtsi нужно правильно настроить пины и заэнейблить драйверы портов:

3. Далее немного магии, и готовый файл am335x-boneblack.dtb лежит в этом же каталоге:

b. запускаем препроцессор:

c. запускаем сам компилятор:

4. am335x-boneblack.dtb нужно положить на boot раздел рядом с ядром и в скрипте запуска для barebox добавить следующую строчку — » global.bootm.oftree=/boot/am335x-boneblack.dtb «

Выбор системы сбора дебажных трейсов.

Как известно систем без багов не бывает, как и анализа многопоточной системы без трейсов. Очень удобно если эти трейсы не выводятся просто в консоль, а собираются чем-то специально для этого созданным, да так что бы можно было сортировать их по процессам, применять фильтры и т.д. И я как раз знаю одну неплохую систему, которую легко собрать как под host так и под target. Это DLT, если вы никогда не слышали об этом, то это не беда, все пробелы в знаниях можно легко покрыть прочитав at.projects.genivi.org/wiki/display/PROJ/Diagnostic+Log+and+Trace.
Данная система состоит из dlt-daemon и dlt-viewer. Как и понятно из названия dlt-daemon запускается на таргете, а dlt-viewer на хосте. Плюс к этому всему, к своему бинарнику, с которого мы хотим собирать трейсы, нужно прилинковать dlt либу.

В общем удобно всё, как собирать трейсы так и анализировать их, рекомендую.

Зачем писать билдсистему, ведь можно всё скачать с репозиториев, сбилдить руками, собрать на основе этого rootfs и вуалля, контроллер работает. Но повторить такой трюк через месяц будет сложнее, а через два — так вообще невозможно. Опять придётся вспоминать что, куда положить, что сбилдить и как запустить. Поэтому потратив немало времени сначала, вы экономите его потом, плюс вы получаете возможность удобно билдить под host и target. Билдсистема состоит из набора скриптов, которые сначала подготавливают host для билда, скачивают сторонние компоненты, такие как buildroot, mosquitto, DLT daemon, с их репозиториев, билдят их, раскладывают по своим местам. А уж потом можно запускать билд вашего проекта. Если билд под host, сделать не сложно, то с билдом под таргет всегда нужно повозиться, и лучше что бы это делал скрипт.

Buildroot можно сконфигурировать так что бы он вызывал post-build скрипт после того как он сформирует rootfs, которая будет лежать в buildroot/output/target. Это даёт отличную возможность вам положить туда всё то, что вам нужно. И тогда, образ файловой системы уже будет содержать всё необходимое для запуска вашей системы.

Рецепт примерно такой:

1. надо скопировать свои бинарники куда-то в buildroot/output/target, например в /opt/bin
2. если есть конфиги, то с ними сделать то же самое, только в /opt/etc
3. скопировать сторонние бинарники, для меня это mosquitto, DLT daemon, их либы и конфиги
4. Что бы при загрузке контроллера система стартанула сама — нужно скопировать ваши systemd сервисы, лучше их объединить в свой target и заэнэйблить его сделав симлинку в multi-user.
5. скопировать модифицированный fstab(зачем, расскажу позже)

После этого вам достаточно распаковать buildroot/output/images/rootfs.tar на нужный раздел SD карты и включить питание.

Написание коммуникационного ядра.

Концепция этого стара как сам modbus.

У каждого устройства ввода-вывода в modbus сети есть регистры(16 bit), доступные на чтение, чтение/запись, в которых хранятся данные и через которые идет управление этими устройствами. У контроллера, в свою очередь, есть массивы дискретных(статус и byte значение) и аналоговых точек(статус и float значение), в которых он и хранит состояние всех параметров.

Так вот, задача коммуникационного ядра проста — собрать данные с устройств ввода-дывода по протоколу modbus, замапить их на точки контроллера и предоставить доступ к этим точкам для верхнего уровня. А если вам надо чем-то управлять, то всё в другую сторону — логическое устройство(об этом позже) должно быть подписано на точку контроллера и запись в эту точку инициирует трансляцию этого параметра в физическое устройство вода-вывода.

Для того, чтобы как-то структурировать данные и работу с устройствами, можно ввести понятие логического устройства, которое будет отображать состояние физического устройства в вашем софте.

Также я решил разделить логические устройства на две группы:

1. Стандартные (модули Овен дискретного ввода/вывода), для которых заранее известны номера modbus регистров с данными, и достаточно только определить точки контроллера куда сохранить эти данные.
2. Пользовательские устройства, для них надо самостоятельно описывать маппинг modbus регистров на точки контроллера.

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

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

Такой конфигурационный файл, содержащий все необходимые данные по конструированию modbus сети, позволяет не модифицировать исходный код для проекта если надо добавить/удалить/изменить устройства ввода-вывода, достаточно изменить параметры в конфигураторе и сохранить их в конфиг файл.

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

Написание mqtt гейтвея.

Собственно говоря — ваши точки контроллера как дискретные, так и аналоговые, с проприетарным интерфейсом доступа к ним, мало кому интересны. Так что выход один — mqtt. Думаю, не преувеличу если скажу, что это на данный момент самый распространенный протокол обмена небольшими сообщениями, плюс он очень прост и понятен в использовании. Так что когда мне понадобилось транслировать данные с контроллера — я не долго раздумывал что использовать.

Т.к. параметров у меня довольно много, то постоянно возникали путаницы в файле конфигурации гейтвея, где был прописан маппинг точек контроллера на mqtt топики гейтвея. Помогла гугл таблица, и написание csv парсера этой таблицы в конфигурационный json файл для гейтвея.

Написание point monitor.

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

Монтирование readonly файловой системы.

Обычно этому мало кто уделяет внимание, и даже в продакшен проектах можно встретить устройства в которых партишен с rootfs доступен на запись. Это рано или поздно приводит к крешу любой, даже самой устойчивой файловой системы. Т.к. контроллер может быть выключен в любой время, то это лишь вопрос времени/случая когда это произойдет. Что бы минимизировать эту вероятность надо немного повозиться с fstab и перед сборкой образа rootfs, положить его туда, как было описано выше. В fstab, во-первых, надо примонтировать файловую систему как readonly а во вторых всё что может меняться замапить в tmpfs.

Мой fstab таков, у вас он может отличатся:

3D принтер давно вошёл в разделы маст хэв для каждого инженера-колхозника, у меня к сожалению его нет, но он стоит на работе. Последнее время ажиотаж у других сотрудников к нему пропал, этим я и пользуюсь, печатая всё что нужно и не нужно, в этом вы могли убедится, читая мой предыдущий пост.

Рисуем в FreeCAD, генерим gcode в Cura и получаем корпус, не забыв сделать посадочные места под плату, вырезы под разъёмы и охлаждение и закладные для клипс на din рейку.

Ну вот и всё, теперь у нас есть плата, софт на SD карте и корпус. Берем напильник(не шучу) и соединяем всё вместе, подключаем питание, кабели RS485 и всё начинает работать. А вы говорили сложно, сложно…

Источник