Comments 62
docker и rabbit для метеостанции это не "с пушки по воробьям"?
Docker - просто отличное решение, очень удобно развертывать приложения и обеспечивать совместимость. Брокер сообщений, тоже классная штука. Если есть предложения по замене RabbitMQ, давайте обсудим.
Как вариант замены RabbitMQ - https://docs.coravel.net/
Ну вместо контейнеров докера для разделения сервисов можно использовать systemd, а для обмена сообщениями - dBus. На дебиане все уже есть из коробки.
Вы посмотрите что внутри Docker-файла. Можете все это вручную устанавливать. Не проблема. Docker не создает практически никакой overhead. Поэтому не вижу никаких проблем использования Docker на подобный устройствах. Нагрузку на CPU вы сами видели.
Здесь не оверхед а оверинженеринг, и усложнение схемы не дающее никакого профита. Вы бы ещё кубер на одной ноде развернули ради пары сервисов. Замените докерфайлы на service файлы для systemd.
А по поводу кролика я пожалуй погорячился, немного погуглив я пришёл к выводу что он там к месту.
Если сравнивать напрямую с МК, то да это сложнее. Но не быть же ретроградом. А в пятерочке терминал на Windows Embedded 5.0, который сканирует штрих-код на товаре и показывает на экране стоимость товара, это не оверинженеринг? Почти прекрасно работает, иногда кэш забивается и устройство переходит в состояние недоступности, но это давняя проблема старых версий Windows Embedded. Да будет и кубер, в концепции отказоустойчивого управления устройством. Два компьютера будут управлять одним внешним устройством, для обеспечения надежности в "особых " системах. "Замените докерфайлы на service файлы для systemd." - можно подумать это решить задачу с обновлением пакетов и с откатом к предыдущей версии. Брокер сообщений оказался очень удобным средством передачи данных, единственное по ресурсам тяжеловат. Нужно заменить на что-то полегче.
Насчет оверхеда вы правы, но меня терзают некоторые сомнения в ресурсах собственно sd карты при подобном использовании. У меня сейчас в процессе ковыряния нечто похожее (home assistant в докере) и вот думаю, стоит ли в overlayfs все это загнать или не заморачиваться.
стоит отказаться от sd карточки, а танцевать с overlayfs.. ну незнаю.. вроде бы и правильно, но как-то мне не понравилось.
Ну варианты тут такие:
- В интернетах пишут, что у некоторых extreme/pro/industrial карточек сделан wear leveling разной степени приличности. Но все сводится к слухам и мутным спекам. Ну кроме industrial, тут уже от производителя спеки видел, там даже health report'ы реализованы. Но у них и цены заметно выше, и в продаже есть совсем не везде.
- Подключить нормальный SSD через USB3. Смущает надежность такого решения, плюс дополнительная коробка на проводе.
- Искать одноплатник с m.2. Читал что есть и такие, но в продаже не встречал.
первое по моему опыту не сильно помогает
второе юзаю, правда не ssd и не 3.0, обычный хард завалявшийся в столе через китайский usb2.0 бокс прелесть которого в том что питается он по отдельному шнурку от отдельного бп. проблем нэма, работает прекрастно, если сдохнет заменить быстро и дёшего, а если зарезервировать каким нибудь mdadm или btrfs mirror можно вообще расслабить булки
одноплатники с m.2 видел, но не щупал
Можно запускать систему на eMMC. На Banana Pi M64 напаяно 8 Гб, вполне достаточно. eMMC не использовал по двум причинам: 1) лишний раз не тратить ресурсы микросхемы; 2) понизить технические характеристики для явного обнаружения узких мест. На некоторых платах, таких как Cubieboard и Cubietruck размещен разъем SATA. Cubietruck с SATA показывает прирост скорости произвольного доступа по сравнению с microSD на Banana Pi M64 до 50%. Но нужно учитывать, что на Cubietruck установлен достаточно старый SoC. С m.2 продается неплохая плата ROCK PI 4C с поддержкой NVME до 2 Тб.
Дебиан с его пакетными репозиториями и был придуман, чтобы упростить администрирование всей системы, включая установку и обновление пакетов. Если уж хочется клоны дебиана на контроллер поставить, достаточно создать свой репозиторий с нужными пакетами и их установка с обновлением будут тривиальны.
Лет через 10 ждём метеостанции на базе топовых десктопов.
Я понимаю, но цена, энергопотребление, нагрев опять же, датчики надо выносить в отдельный корпус.
В самом начале - "Пример метеостанции является демонстрацией встраиваемого решения работы с GPIO, датчиками и вывода пользовательского интерфейса напрямую на LCD". Метеостанция не цель, а техническое демо-решение, которое в дальнейшем будет обрастать различными функциями. И я не скажу что плата Banana Pi M64, такая уж мощная. Да на Arduino метеостанцию сделать проще, а если вы желаете управлять домом с помощью Home Assistant? Управлять голосом, жестами, распознавание видео? Arduino тут уже явно не справится. Сейчас я уже из .NET кода получаю изображения с usb-webcam и других камер. Затем добавлю распознавание голоса. Далее, остается добавить хорошую аудио-плату, и вот тебе умная-аудиоколонка-видеоплеер-на-C#. Без утечки данных "левым структурам". Нагрев процессора, прям сейчас нагрев процессора +51 С, при комнатной +27 С.
Но здесь не решается задача по созданию решения типа mojordomo/homeassistant. Если бы решалась, то основной проблемой было бы создание инфраструктуры, а не использование докера, в качестве серебрянной пули.
Поэтому и решение выглядит очень громоздким, в то время, как можно было сделать всё проще для создания метеостанции.
Если хотелось разобраться с docker, то и заголовок лучше исправить. Типа “разбираемся с docker”.
Мне следовало сначала написать обобщенный пост, а потом уже техническую реализацию разных модулей. Исправлюсь, напишу что имелось в виду и какова конечная цель. Цель не в создание метеостанции, а в создание демо-проекта проверки технологий, проведение испытаний технологий в малых системах. Если задавать технический заголовок, то он будет очень длинным. Потому что необходимо охватить: Docker, работу с устройством Linux framebuffer, брокер сообщений RabbitMQ и AvaloniaUI. А с Docker проблем нет, он просто работает, и про него нечего писать. Единственный момент, в контейнер передается напрямую устройства /dev/fbX и другие устройства GPIO. Может быть, на этом следовало бы заострить внимание. Потому что подобный подход решает многие проблемы с безопасностью, которые в Windows Embedded решаются еще теми петлями. На Linux все получается более лаконично и просто. Но сравнение с Windows Embedded это уже другая тема.
А зачем подтягивающие резисторы на I2C?
На Banana Pi их разве нет? Да и на самой плате BME280, судя по картинке, они тоже есть.
На сколько помню у Banana Pi нет подтягивающих резисторов. На BME280 есть. Подтягивающие резисторы на I2C добавлены для "универсального" решения. В текущей конфигурации все это работает бесперебойно. Скорее всего в дальнейшем, датчик BME280 перенесу на другую плату. И к Banana Pi буду подключать другие I2C датчики, некоторые из них без подтягивающих резисторов.
Я так краем глаза видел, что в Banana Pi есть внутренние pullup/down резисторы, и режим пинов можно выбирать программно. Возможно ошибаюсь.
Подтягивающие резисторы, емнип, влияют на скорость работы шины I2C, и не стоит дополнительно ставить их просто на всякий случай.
Для I2C-1 на схеме Banana Pi M64, Pull Up/Down резисторов не нашел. Для некоторых пинов в самом SoC можно включать pullup/down, но не для пинов I2C. Согласен, момент про скорость необходимо было указать.
Не все контроллеры поддерживают подтяжку пинов в режиме I2C.
Например, с STM32 с которыми недавно работал:
STM32F4-серия - поддерживает подтяжку в I2C
STM32F1-серия - не поддерживает. Но если места в обрез на пару лишних резисторов, то можно запараллелить на неиспользуемые пины, которые включить на вход и подать подтяжку.
Самое сложное в создании метеостанции - корпус и энергопотребление. Но этот вопрос почему-то возникает когда "всё заработало".
Почему корпус является сложной задачей? Если есть доступ к 3D принтеру, то можно без проблем напечатать. Энергопотребление не замерял. Купил для платы аккумулятор на 3V3, подключу к контроллеру питания, сделаю замеры. Дополню текущий пост или опубликую данные по потреблению в следующем посте. Не все сразу)
Orange Pi тоже на SoC Allwinner потребляет где-то в районе 300-500 мА минимум, от 5В. Так что на особо длительную работу от батарей можно не расчитывать.
Потому, что от корпуса зависит достоверность данных.
Для себя я выбрал проект на ESP8266 https://habr.com/ru/post/525140/ - потребляемый ток 0,05А. В момент проведения измерений датчиком SDS011 - 0,14А
При желании к нему подключаются:
OLED SSD1306
OLED SH1106
LCD 1602 (I2C: 0x27, 0x3F)
LCD 2004 (I2C: 0x27, 0x3F)
SDS011 (Датчик пыли)
Honeywell PM (Датчик пыли)
Sensirion SPS30 (Датчик пыли)
DHT22 (Температура, Относительная влажность)
HTU21D (Температура, Относительная влажность)
BME280 (Температура, Относительная влажность, Давление воздуха)
BMP280 (Температура, Давление воздуха)
SHT3X (Температура, Относительная влажность)
Digital Noise Measuring Sensor (LAeq)
DS18B20 (Температура)
Plantower PMS
BMP180 (Температура, Давление воздуха)
GPS (NEO 6M)
Для этого вообще существует отдельная специальность - промышленный дизайн. Понятно дело, датчик спрятанный в глубине корпуса будет показывать уже температуру внутри корпуса, а не в комнате. Так всегда, напечатать на 3D принтере не проблема, хоть завтра, но вот сделать правильный и красивый корпус, тут необходимо весьма подумать.
... 2137 год.
Производитель: Новый промышленный одноплатный микрокомпьютер доступен к заказу! Новый Potato Pi 4DX содержит 64 4GHz ядра, терабайт DDR16-FX, Quadx4 USBD7.2 и оптические порты для всех доступных видов имплантов! И все это стоит всего 24.99$ и вмещается в плату размером с четвертак!
Покупатель: Отлично, наконец сделаю метеостанцию с честными 30FPS на экране...
Круто! заверните мне 10 штук. Да, вы правы, но так развивается ИТ отрасль. Просто с течением времени, стоимость железа нивелируется с затратами на разработку. И разработчику проще использовать одноплатный компьютер и разрабатывать решение на языковых средства высокого уровня, чем искать программиста который сможет оптимизировать код до пару килобайт памяти.
Берете какой-нибудь esp32 и пишете код на питоне/lua :)
Можно подключить тот же дисплей и те же датчики.
OK. А как на ESP32 развернуть Home Assistant, сделать распознавание аудио, видео, локально без отправки на удаленный сервер, красивые графики и панель на 9 дюймов как подключить? Это все будет в продолжение.
Ну речь то про ЯП высокого уровня была :)
Если вам все это нужно в одном дивайсе, то ок, никаких вопросов.
Мой подход заключается в постепенном наращивание функциональности, и создания "кубиков" приложений для универсального одноплатного компьютера. Хочешь метеостанцию, воткни датчик BME280 и загрузи нужный Docker-контейнер. Хочешь умную колонку, воткни хорошую плату с ЦАП, и загрузи Docker-контейнер. Идея заключается в конструирование устройства. Где брокер-сообщений является внутренней универсальной шиной передачи данных. А Docker-контейнеры сервисами обслуживающие периферийные устройства. Похоже это нужно было вынести в самое начало поста)
Просто с течением времени, стоимость железа нивелируется с затратами на разработку.
Если вы планируете выпуск (допустим) миллиона устройств (без наворотов с распознаванием голоса а с чистым функционалом метеостанции и графиками) то гораздо экономичней будет таки оптимизированная разработка.
Грубо говоря, железо под *pi стоит $15, а под что-то а-ля Arduino/STM32/etc — стоит $5 — вот уже вам 10 миллионов разницы в массовом производстве. И если разработчику придётся заплатить $50000 вместо $10000 — это гораздо менее существенно на фоне затрат на железо.
А для штучных товаров или хобби-проектов, или если свистелки хочется — тогда конечно ок, можно и не мучаться с оптимизациями.
Ключевое слово "Если". Ни кто не планирует продавать метеостанцию на банане. И далее будет распознавание голоса и видео с с Home Assistant. В самом начале написано: "Пример метеостанции является демонстрацией встраиваемого решения работы с GPIO...". Это техническое демо, а не законченная система для продажи. И вывод прочитайте, все же: "Данная реализация проекта была проверкой работоспособности первоначальной идеи работы с GPIO из Docker-контейнеров и вывода полноценного UI на LCD ...". Блин, похоже никто не осилил статью, и до конца не смог дочитать.
Зря вы так — я прочитал и вполне осилил, но в вашем комментарии на который я отвечал речь явно не идёт про данную конкретную разработку — поскольку вы говорите "Да, вы правы, но так развивается ИТ отрасль" и далее про нивелирование затрат — но как раз в отрасли в общем затраты далеко не всегда нивелируются, на что я и обратил внимание.
Прошу меня извинить, если быканул. Как раз таки вы написали "Если вы планируете выпуск (допустим) миллиона устройств". Вы указали на конкретную разработку, но не суть важна. Просто есть компания Toradex и ее успешный бизнес. Я очень много взял материала с их сайта. В своих системах они успешно используют Docker. И тут в комментариях начинается, вопросы про стрельбу из пушки по воробьям. Ребята, нужно понимать что мир на МК не заканчивается. Это не разработка метеостанции, это проверка технологий для использования на подобных малых одноплатных компьютерах, в тех сферах где Arduino/STM32 не будет использоваться в качестве основной системы. Да признаю, это нужно было четко написать в самом начале. Материал по факту это наработка технологий и проверка рабочих гипотез, и все. Я просто видел много систем, где брали плату на STM32 и подключали к ноутбуку. Хотя на самом деле можно было прекрасно обойтись платой в стиле банана с подключенным монитором или LCD с емкостным экраном.
Делал когда-то на простом esp8266, температура, влажность, давление. Вместо дисплея web интерфейс и modbus TCP с mqtt для внешнего доступа. Плюс еще логи на microSD.
Тут есть и прошивка и демонстрация:
Сотые доли градуса...
ЗАЧЕМ???
Кстати, может кто подскажет - есть ли готовые решения выносных метеодатчиков с передачей данных через BLE? Чтобы сразу с корпусом, работающий от AA батарей или 18650, и отдающий температуру, влажность и давление?
Есть RPi, eInk экран для нее, хочется сделать без лишних проводов. Датчик вывесить за окно в тень и получать оттуда данные на стоящий в квартире RPi.
Готовые решения будут существенно дороже самосборных и обладать один/двумя недостатками. 1) привязка передачи данных к своим облачным сервисам, как это реализуют "умные" розетки, светильники и т.д. 2) свой аппаратно/программный центр сбора данных. ИМХО, самое простое и универсальное решение это взять связку:
18650 Lithium Battery Shield V8
ESP-WROOM-32
температурный датчик BMx
В ESP-WROOM-32 загрузить прошивку ESPHome. Настроить соединение по BLE - BLE Client Sensor. На одноплатный компьютер установить Home Assistant нативно или в варианте Docker контейнера. Для отображения панели управления на экране, запускать браузер как в примере.
А вот это не то, что может подойти? Long Range IP67 NRF52820 Outdoor Bluetooth 5.2 Beacon with Temperature and Humidity Sensor
Батарейка на пару лет, температура и влажность (ладно, пусть без давления, его и дома измерять можно), и отдача данных по BT чему угодно.
Весь вопрос в сопряжение самого устройства. Как вариант можно взять устройство Tuya или Sonoff, например это. Перепрошить его на ESPHome, и подвязать к Home Assistant.
Можно декодировать датчики 433МГц. Причем они уже могут работать у соседей в метеостанциях и покупать ничего не надо.
https://github.com/merbanan/rtl_433
Есть предложение по UI:
Если данные были получены менее 10 секунд назад, то отображается надпись — «Данные получены недавно».Не уверен, что, скажем, через 5 лет Вы будете помнить, что «недавно» означает «менее 10 секунд назад».
Кроме того, другой человек может быть вообще не в курсе, что значит «недавно», и подразумевать 1 секунду, 10 секунд, минуту…
Поэтому предлагаю указать конкретно: «Данные получены менее 10 секунд назад».
Не вижу никакой необходимости писать ".. получены 4 секунды назад". Значения температуры, давления, влажности к счастью не меняются настолько часто, иначе мы просто вымерли бы как динозавры. А если данные были получены более 10 секунд назад, то отображается надпись с дискретностью в 10 секунд, а потом - 1 минута. Пользователю достаточно понаблюдать за системой и он все поймет. В крайнем случае, если не произойдет армагеддон, то всегда можно посмотреть исходники на GitHub.
Метеостанция на Banana Pi M64 (Linux, C#, Docker, RabbitMQ, AvaloniaUI)