Це я відкрив для себе офігезний проект MediaMTX. Там в документації вже є все потрібне. Але про всяк випадок зберу докупи свої знахідки, щоб не забути.

Загальна концепція: є передавач відеопотоку, є отримувач, між ними є медіасервер. Це може бути три різних компа. Може два, якщо медіасервер запустити там же, де й передавач. Для перших експериментів, нехай це буде один localhost.

Моя мета: дивитися через веб-камеру на блимаючий світлодіод, ха-ха.

Запуск сервера

Запускаю MediaMTX в Docker, якось так, як описано в документації. (Звісно, замість 192.168.xx.xx вказую свою IP-адресу в локальній мережі). Це достатньо надійний варіант.

docker run --rm -it \
  -e MTX_RTSPTRANSPORTS=tcp \
  -e MTX_WEBRTCADDITIONALHOSTS=192.168.xx.xx \
  -p 8554:8554 \
  -p 1935:1935 \
  -p 8888:8888 \
  -p 8889:8889 \
  -p 8890:8890/udp \
  -p 8189:8189/udp \
  bluenviron/mediamtx:1

Або, якщо можу собі дозволити, то запускаю ось так:

docker run --rm -it --network=host bluenviron/mediamtx:1

Також я запускав готові бінарники MediaMTX на своїй старенькій Raspberry Pi Model 2. Ок норм.

Трансляція RTSP

Штатна документація пропонує запускати ffmpeg прямо під час запуску MediaMTX. Мені більше до смаку тримати медіасервер постійно запущеним, а трансляції розпочинати окремою командою.

Ось варіант команди, який транслює відео з веб-камери, використовуючи кодек H.264:

ffmpeg -f v4l2 -framerate 30 -video_size 640x480 -i /dev/video0 \
  -pix_fmt yuv420p -c:v libx264 -preset ultrafast -b:v 600k \
  -tune zerolatency -bf 0 -g 15 -keyint_min 30 \
  -f rtsp rtsp://localhost:8554/mystream

Або те саме з апаратним прискоренням через VAAPI:

ffmpeg -f v4l2 -framerate 30 -video_size 640x480 -i /dev/video0 \
  -c:v h264_vaapi -vaapi_device /dev/dri/renderD128 \
  -vf 'format=nv12,hwupload' -qp 24 -quality 1 -bf 0 -g 30 \
  -f rtsp rtsp://localhost:8554/mystream

Тут всюди 640×480, бо звичайні веб-камери майже ніколи не дають 30 кадрів на секунду на більших розмірах картинки. Чесно, мені для моїх задач той HD чи FullHD не дуже потрібний, а от відсутність гальм справді важлива.

Звісно, замість localhost може бути потрібна IP-адреса. Також шлях /mystream — це на ваш вибір, щоб якось вказати даний конкретний відеопотік. Через один медіасервер може одночасно йти декілька різних відеопотоків з різними шляхами.

Можна робити трансляцію з VP8, але не сьогодні, бо моя відеокарта не робе апаратне прискорення кодування саме для VP8 (ну або я не знайшов як), а софтварний енкодер жере проц. Після експериментів і роздумів, я вирішив зупинитися на H.264 як на оптимальному варіанті.

Перегляд RTSP

Ну, наприклад, можна якось так:

ffplay \
  -fflags nobuffer \
  -flags low_delay \
  -framedrop \
  -probesize 32 \
  -analyzeduration 0 \
  -sync ext \
  -rtsp_transport udp \
  rtsp://localhost:8554/mystream

Або так:

mpv rtsp://localhost:8554/mystream --profile=low-latency --untimed

Перегляд WebRTC

Просто відкриваю в браузері http://localhost:8889/mystream/ і бачу там відео. Магія!

Є певний нюанс з кодеками. Chrome/Chromium нормально грає H.264, а Firefox його грати не хоче. Треба полізти в about:config, знайти там media.webrtc.hw.h264.enabled і увімкнути його. Саме через це я експериментував з VP8, але вирішив що не на часі.

Вбудувати стрім у довільну веб-сторінку

Теж все робиться просто і зрозуміло, як в документації:

<iframe src="http://localhost:8889/mystream" scrolling="no"></iframe>

Можна додати CSS за смаком:

<iframe
 src="http://localhost:8889/mystream"
 style="border: none;
        aspect-ratio: 4 / 3;
        width: 100%;
        height: 100%;
        max-width: 100vw;
        max-height: 100vh"
 scrolling="no"></iframe>

Для дашборда Node-RED можна створити UI Template node і прямо туди це все покласти. Власне, саме задля цього я занурився у ці нетрі: дуже захотілося поєднати телеметрію та елементи керування моїх саморобних IoT проектів з живим відео. І це заслуговує окремого поста.

Додаткова краса

Коли трансляція не ведеться, можна показувати щось красиве, наприклад телевізійну тест-таблицю SMPTE чи Philips. Для цього треба з картинки зробити відео довжиною, гммм, 1 секунду.

wget https://upload.wikimedia.org/wikipedia/commons/6/66/SMPTE_Color_Bars.svg
rsvg-convert SMPTE_Color_Bars.svg -w 640 -h 480 > smpte.png
ffmpeg -loop 1 -framerate 30 -t 1 -i smpte.png -c:v libx264 -pix_fmt yuv420p smpte.mp4

Або так:

wget https://upload.wikimedia.org/wikipedia/commons/a/aa/Philips_PM5544.svg
rsvg-convert Philips_PM5544.svg -w 640 -h 480 > pm5544.png
ffmpeg -loop 1 -framerate 30 -t 1 -i pm5544.png -c:v libx264 -pix_fmt yuv420p pm5544.mp4

Власне, далі треба буде лізти в конфігураційний файл mediamtx.yml, і якщо у вас MediaMTX все ще запускається через Docker, то вам доведеться з цим розбиратися окремо.

Просто дописую в кінець таку секцію:

paths:
  mystream:
    alwaysAvailable: true
    alwaysAvailableFile: "pm5544.mp4"

Проброс портів

Якщо є бажання поділитися своєю трансляцією в WebRTC з усім світом, то треба буде десь на роутері налаштувати port forwarding:

• 8889/TCP → 192.168.xx.xx:8889
• 8189/UDP → 192.168.xx.xx:8189

Далі дивлюся трансляцію так само, тільки в якості хоста вказую реальну IP-адресу.

Відкриті питання

Треба буде розібратися з питаннями безпеки:

1. Обмежити можливість трансляції, дозволити лише «кому треба»
2. Обмежити можливість перегляду (JWT?)
3. Убезпечити транспорт WebRTC від MitM (https?)

Треба більше RTFM.

Треба всерйоз подумати, як би то його точніше виміряти затримку. Візуально бачу що вона відрізняється для різних конфігурацій, зокрема для різних кодеків і різних транспортів. Можливо, параметри запуску ffmpeg та ffplay можна ще вдосконалити.

Висновки

Маю офігенний інструмент в своєму арсеналі, от!

Сказати мені нічого. Ну тобто насправді багато чого можу сказати, але не хочу. У мене в житті останнім часом багато подій, турбулентність.

Закинув свої хобі-проекти.

Одна з останніх штук, яку я колупав заради розваги та душевного спокою, була якась «читалка» тексту на мікроскопічних екранчиках SSD1306, типу 128×32 пікселів чи щось подібне; наразі з цієї «читалки» мало що є, окрім шрифта. (Насправді це мав бути переважно апаратний проект, але якось не склалося). Є фото читалки у мене в Mastodon. Може колись я продовжу цей проект.

Колись один мій друг зробив сам для себе книжкочиталку на J2ME. Він читав усякі книжки на чорно-білих кнопкових телефонах в ті часи, коли смартфони ще не винайшли, а КПК були дорогими і незручними. Мій проект частково натхненний тим його досвідом.

По приколу пишу ці рядки через вбудовану у GitHub веб-версію VS Code, та що запускається по натисканню на кнопку . і це по-своєму прикольно.

Хоча і тупо. Я міг би без гальм і без споживання зайвого трафіку написати цей текст у Vim на найменшому зі своїх ноутів, і теж було б непогано.

Гм. Треба буде якось написати пост про економію ресурсів. Щось у цьому є таке, що складно висловити словами. Мені не важко запустити VSCode в браузері і не важко запустити його локально. Зазвичай я пишу текст і код в Geany. Але часто буваю в Vim. Чому так?

Це не тільки питання зручності. Я відчуваю, що Vim мене може врятувати, умовно кажучи, «на пустельному острові». (Або навіть не повноцінний потужний Vim, а його злий брат-близнюк busybox vi, у якого не все добре з Unicode). О, до речі, про свої експерименти з Debian-Live теж треба написати.

Колись про все це напишу.

Оновлення 12:07. Щодо економії: іноді кількість переходить в якість. Можливість досягати мети різними шляхами, в тому числі короткими і мінімалістичними, дає свободу вибору.

Одразу уточнюю: 1) не через OBS Studo, 2) не на YouTube.

Я просто хочу дивитися відео зі своєї веб-камери з мінімальною затримкою. Комп з камерою і комп для перегляду обидва знаходяться в локальній мережі. Ніякого інтерактивного GUIшного софта, тільки ffmpeg та інші scriptable консольні програми.

Раніше я знав лише один супер-простий метод, про який писав колись:

ssh -Y foohost mplayer -vo x11 tv://

(Не робіть так, це страшенні гальма + великий overhead).

Як можна зробити краще

Погнали.

В принципі у нас може бути три різних хоста: комп з камерою, комп для перегляду і проміжний хост з RTMP-сервером. В моєму випадку RTMP-сервер може бути там же, де знаходиться камера.

Сервер

Перше, що нам треба — запустити сервер RTMP. Можна зробити RTMP-сервер через Nginx та mod_rtmp. А у найпростіших випадках (і щоб погратися) достатньо взяти готовий контейнер:

docker run --rm -p 1935:1935 tiangolo/nginx-rtmp 

Йому треба лише 1935 порт.

Припустимо, що це хост з адресою 192.168.0.99, тоді адреса нашої трансляції буде rtmp://192.168.0.99/live/123 (де /live/123 це довільний обраний мною шлях).

Камера

Мені потрібна трансляція без звуку. Нехай це камера /dev/video0. Тоді на компі з камерою запускаємо таку магію, де крім /dev/video0 та адреси трансляції для початку краще нічого не чіпати:

ffmpeg -f v4l2 -i /dev/video0 -c:v libx264 \
  -pix_fmt yuv420p -framerate 15 -g 30 -b:v 500k \
  -preset ultrafast -tune zerolatency \
  -f flv rtmp://192.168.0.99/live/123

Я нагуглив перший-ліпший випадковий howto і прибрав згадки про звук. Якщо вам буде треба звук (і якщо у вас ALSA), то йдіть подивіться оригінальний пост.

Перегляд

Ну найпростіше, що можна зробити, це щось типу такого:

mplayer rtmp://192.168.0.99/live/123

Воно працює. Але ну його до біса! Затримка більше 10 секунд мені абсолютно не підходить. Ось кращий варіант:

mpv --no-cache --untimed --no-demuxer-thread \
  --video-sync=audio --vd-lavc-threads=1 \
  rtmp://192.168.0.99/live/123

або такий:

ffplay -autoexit -flags low_delay -framedrop \
  -strict experimental -vf setpts=0 -tcp_nodelay 1 \
  rtmp://192.168.0.99/live/123

І от тут, нарешті, я починаю бачити в цьому всьому профіт. Я можу дивитися в камеру+екран як в дзеркало і не відчувати затримку.

P.S. Що я не знайшов, так це нормального рішення для перегляду стріму на Android. Запускаю там VLC, воно все працює, але лаг 15 секунд (upd.: вони про це знають і їм похуй). Може хтось порадить рішення краще.

Upd.: ще я нагуглив якийсь стрьомний Larix Player, це дуже мерзенний freemium з обмеженням у 5 хвилин перегляду відео на безкоштовній версії. З того, що я спробував і що вдалося змусити працювати на burner phone, у цього додатку поки що виявився найменший лаг. Треба ще пошукати.

Так, це анахронізм часів PHP4. І так, за замовчанням кольори там розраховані на світле тло. Якщо у вас сайт з темним фоном, то можна поміняти кольори на щось відповідне, але це все трошки бісить.

А що як у нас сучасна адаптивна кольорова схема?

<meta name="color-scheme" content="light dark">

Тоді у нас взагалі не може бути фіксованих кольорів, бо має одночасно існувати і варіант для темної схеми, і варіант для світлої.

Спробував через змінні CSS. Погнали.

Пишемо в php.ini щось таке:

highlight.default = "var(--php-default)"
highlight.html = "var(--php-html)"
highlight.keyword = "var(--php-keyword)"
highlight.string = "var(--php-string)"
highlight.comment = "var(--php-comment)"

Або, якщо змінювати php.ini незручно, робимо це в runtime в PHP:

foreach (['default', 'html', 'keyword', 'string', 'comment'] as $key) {
    ini_set('highlight.' . $key, 'var(--php-' . $key . ')');
}

І тепер нам треба приблизно отакий CSS:

:root {
  --php-comment: #f80;
  --php-default: #00b;
  --php-html: #000;
  --php-keyword: #070;
  --php-string: #d00;
}

@media (prefers-color-scheme: dark) { 
  :root {
    --php-comment: #860;
    --php-default: #66f;
    --php-html: #ccc;
    --php-keyword: #0f3;
    --php-string: #fc0;
  }
}

Всьо, пофарбували, порядок :)

Вбудований світлодіод Raspberry Pi Pico світиться, якщо подати на відповідний GPIO високий рівень сигналу, і не світиться якщо встановити низький рівень сигналу. Поведінка ESP8266 протилежна: високий рівень сигналу там вимикає світлодіод.

Тобто, клас BlinkingLED з попередьного посту в режимі «не блимати» має різну поведінку на Raspberry Pi Pico та ESP8266: для RP2 вимикання режиму блимання робить світлодіод неактивним, а для ESP8266 вимикання режиму блимання врубає світлодіод на повну. (В режимі «блимати» вони все ж виглядають однаково). Тож треба з цим щось зробити, чи не так?

Окей, давайте і тут зробимо щось сумнівне…

class InvertedPinOut:
    def __init__(self, pin):
        self.pin = pin

    def value(self, new_value):
        self.pin.value(1 - new_value)

Об’єкт цього класу можна передавати в BlinkingLED замість machine.Pin. Норм чи крінж?

Альтернативно, ми можемо додати в клас BlinkingLED властивість is_inverted і додаткову логіку:

     async def main(self):
         while True:
-            self.pin.value(int(self.blinking))
+            self.pin.value(int(self.blinking ^ self.is_inverted))
             await asyncio.sleep_ms(500)
-            self.pin.value(0)
+            self.pin.value(int(self.is_inverted)
             await asyncio.sleep_ms(500)

Це скоріше крінж.

Або так: зробити в класі властивості value_on та value_off (за замовчанням (для звичайних світлодіоів), значення 1 та 0, відповідно). Ще довше, але у певному сенсі наочніше.

     async def main(self):
         while True:
-            self.pin.value(int(self.blinking))
+            self.pin.value(self.value_on if self.blinking else self.value_off)
             await asyncio.sleep_ms(500)
-            self.pin.value(0)
+            self.pin.value(self.value_off)
             await asyncio.sleep_ms(500)

Зовсім крінж. Як же краще?

Увага, правильна відповідь, щойно випадково знайдена в документації: можна використати вже наявний в стандартній бібліотеці клас machine.Signal:

led = machine.Signal(machine.Pin(2, machine.Pin.OUT), invert=True)

Яка проста і прикольна штука!

Цього разу я звернуся до класичного жанру, одного з найжорстокіших та найбезглуздіших дисциплін «спеціальної олімпіади» з програмування: це DRY, «don’t repeat yourself». Міф про універсальний код, який чудово буде працювати всюди без модифікацій. Як на мене, гонитва за цим DRY буває навіть гіршою за синдромом «not invented here».

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

Опис завдання

За моїм задумом, жменька простого, тупого (місцями тривіального) коду на Python має працювати більш-менш однаково на двох достатньо різних платформах:

• на якійсь ESP8266 (WeMos D1 mini) через MQTT + Wi-Fi, та
• на Raspberry Pi Pico через /dev/ttyACM0, shell-скрипти та socat

Що має робити цей код? Те саме, що я вже робив півтора роки тому:

• блимати світлодіодом
• вмикати/вимикати блимання світлодіодом по команді, отриманій з MQTT
• вмикати/вимикати блимання через натискання на кнопку локально
  • в тому числі при втраті зв’язку з брокером MQTT
• передавати брокеру MQTT поточний стан (блимає/не блимає)

Додатковий бонус для ESP8266:

• звітувати брокеру MQTT про свою наявність онлайн
• звітувати (через last will) про перехід в офлайн
• використовувати флаг retain для індикації стану онлайн/офлайн

Заради цього мені знадобиться купа допоміжного коду. Ну шо, погнали.

Реалізація

У мене було декілька спроб зробити це нормально. Я починав з налаштування мережі, комунікації з брокером MQTT, і виходило якось кострубато і некрасиво.

Але потім я підійшов з іншого боку. Взагалі відклав всю цю возню з мережею. У центрі мають бути не технічні деталі підключення до брокера, а внутрішні процеси і зв’язки. А, забув сказати, це має бути асинхронний код. Тож архітектура важлива.

Почнемо з головного, зі світлодіода.

Чернетка

Просто поблимаємо світлодіодом. Повільно і спокійно, на частоті 1 Гц, з затримкою 0,5 секунди.

import asyncio
import machine

class BlinkingLED:
    def __init__(self, gpio):
        self.gpio = gpio
        self.is_blinking = True

    async def main(self):
        while True:
            await asyncio.sleep_ms(500)
            self.gpio.value(int(self.is_blinking))
            await asyncio.sleep_ms(500)
            self.gpio.value(0)

try:
    # WeMos D1 mini: built-in LED = pin D4 = GPIO2
    led = machine.Pin(2, machine.Pin.OUT)
    
    # Raspberry Pi Pico: built-in LED = GPIO25
    #led = machine.Pin(25, machine.Pin.OUT)

    led_task = BlinkingLED(led)
    asyncio.run(led_task.main())
except KeyboardInterrupt:
    print('Stopped')

Окей. Це один процес. Мені знадобиться декілька різних процесів, які будуть щось робити: блимати світлодіодом, зчитувати стан кнопки, комунікувати з зовнішнім світом. Кожен з цих процесів — якийсь об’єкт з методом main, всередині якого нескінченний цикл.

Додамо ще один процес, який кожні 5 секунд буде вмикати або вимикати режим блимання цього світлодіода. І ще додамо якийсь клас, який запускатиме декілька різних процесів разом. І, звісно, зміниться шматок кода для запуска цього. Але клас BlinkingLED з попереднього лістингу кода залишається без змін.

class DemoScenario:
    def __init__(self, led_task):
        self.led_task = led_task

    async def main(self):
        while True:
            await asyncio.sleep(5)
            self.led_task.is_blinking = not self.led_task.is_blinking

class App:
    tasks = []

    async def main(self):
        tasks = [task.main() for task in self.tasks]
        await asyncio.gather(*tasks)

try:
    led = machine.Pin(2, machine.Pin.OUT)
    led_task = BlinkingLED(led)
    demo = DemoScenario(led_task)
    app = App()
    app.tasks.append(led_task)
    app.tasks.append(demo)
    asyncio.run(app.main())
except KeyboardInterrupt:
    print('Stopped')

Вже цікавіше! Але тут я бачу одну слабку ділянку архітектури: сильну зв’язаність між об’єктами класів DemoScenario та BlinkingLED. Клас сценарію напряму керує станом світлодіода. Хочу, щоб керування це відбувалося не напряму, а через повідомлення, як з брокером MQTT.

Про повідомлення MQTT

Вся ця фігня задумана для використання з красивими дашбордами на Node-RED. Має бути вимикач на дашборді, в який можна ткнути мишкою.

Кожен пристрій має своє ім’я, наприклад board98 та board99. Всі повідомлення в MQTT, що стосуються певної плати, повинні мати топік з певним префіксом — dev/board99, home/kitchen/board99 або просто board99.

Традиційно, вся комунікація з одним світлодіодом має відбуватися через два різних топіки: назвемо їх board99/led та board99/led/set.

Префікс потрібний для комунікації з зовнішнім світом, а внутрішні зв’язки (наприклад, між кнопкою і світлодіодом) обходяться без префіксу.

Локальний хаб повідомлень

Задум такий: без всякого зовнішнього брокера MQTT передавати повідомлення всім зацікавленим процесам. Кожен з процесів, в свою чергу, може щось з цим зробити на свій розсуд.

Цього разу всі класи змінилися, включаючи BlinkingLED.

import asyncio
import machine

class App:
    tasks = []
    listeners = []

    def add(self, obj):
        if hasattr(obj, 'main'):
            self.tasks.append(obj)
        if hasattr(obj, 'handle'):
            self.listeners.append(obj)

    async def main(self):
        tasks = [task.main(self) for task in self.tasks]
        await asyncio.gather(*tasks)

    def handle(self, topic, payload):
        for listener in self.listeners:
            listener.handle(topic, payload)

class BlinkingLED:
    def __init__(self, gpio, topic):
        self.gpio = gpio
        self.is_blinking = True
        self.topic = topic

    async def main(self, app):
        while True:
            await asyncio.sleep_ms(500)
            self.gpio.value(int(self.is_blinking))
            app.handle(self.topic, int(self.is_blinking))
            await asyncio.sleep_ms(500)
            self.gpio.value(0)
            app.handle(self.topic, 0)

    def handle(self, topic, payload):
        if topic == self.topic+'/set':
            self.is_blinking = bool(int(payload))

class DemoScenario:
    def __init__(self, led_topic):
        self.led_topic = led_topic

    async def main(self, app):
        while True:
            await asyncio.sleep(5)
            app.handle(self.led_topic, 0)
            await asyncio.sleep(5)
            app.handle(self.led_topic, 1)

class DebugMessages:
    def handle(self, topic, payload):
        print(topic, payload)

try:
    app = App()
    led = machine.Pin(2, machine.Pin.OUT)
    app.add(BlinkingLED(led, 'led'))
    app.add(DemoScenario('led/set'))
    app.add(DebugMessages())
    asyncio.run(app.main())
except KeyboardInterrupt:
    print('Stopped')

Є певна асиметричність у поведінці цих класів. Клас BlinkingLED як приймає повідомлення, так і відправляє. Клас DemoScenario лише відправляє повідомлення. Клас DebugMessages лише приймає, і у нього немає метода main.

У попередній версії я намагався на рівні класа App визначати, які процеси мають отримати кожне окреме повідомлення. Цього разу я відправляю всі повідомлення всім слухачам, а вони розбираються, що їм треба. Наприклад, клас DebugMessages опрацьовує всі повідомлення.

Коли я в IDE Thonny запускаю на мікроконтролері цей код, то бачу в консолі щось таке:

led 1
led 0
led 1
led 0
led 1
led 0
led 1
led 0
led 1
led/set 0
led 0
led 0
led 0
led 0

Спочатку блимали світлодіодом, потім не блимаємо. Видно як стан світлодіода, так і команду, яка переменула режим.

Дико переускладнений варіант: 64 рядки асинхронного коду там, де того ж самого результату можна було б досягти в три рядки і два цикли :) але, на мою думку, це має бути більш-менш правильний підхід, з точки зору мого задуму. Бо далі буде більше коду.

З’єднання з зовнішнім світом

Це буде розповідь про ESP8266, яку ми любимо за її Wi-Fi.

Припустимо, весь попередній код ми писали в main.py, що є цілком традиційним підходом. Нехай у нас також є boot.py, і там ми напишемо пароль від вайфаю:

import network

wlan = network.WLAN(network.STA_IF)
wlan.active(True)
if not wlan.isconnected():
    wlan.connect('ssid', 'password')

Оцей от wlan.connect лише розпочинає процес з’єднання. Тобто весь цей фрагмент коду не заблокує нам виконання програми на декілька секунд.

Тепер в основному main.py додамо ось такий клас:

import umqtt.simple

class WirelessMQTT:
    def __init__(self, server, prefix, **kwargs):
        self.wlan = network.WLAN(network.STA_IF)
        self.prefix = prefix+'/'
        kwargs['keepalive'] = 2
        self.mq = umqtt.simple.MQTTClient(prefix, server, **kwargs)
        self.mq.set_last_will(self.prefix+'online', b'0', retain=True)
        self.mq.set_callback(self.mqtt_callback)
        self.nodup_t = self.nodup_p = None

    async def main(self, app):
        self.app = app
        while not self.wlan.isconnected():
            await asyncio.sleep(0)
        self.mq.connect()
        self.mq.publish(self.prefix+'online', b'1', retain=True)
        self.mq.subscribe(self.prefix+'+/set')
        await asyncio.gather(self.ping(), self.check_msg())

    async def ping(self):
        while True:
            self.mq.ping()
            await asyncio.sleep(1)

    async def check_msg(self):
        while True:
            self.mq.check_msg()
            await asyncio.sleep(0)

    def mqtt_callback(self, topic, payload):
        topic, payload = topic.decode(), payload.decode()
        if topic.startswith(self.prefix):
            topic = topic[len(self.prefix):]
            self.nodup_t, self.nodup_p = topic, payload
            self.app.handle(topic, payload)
            self.nodup_t = self.nodup_p = None

    def handle(self, topic, payload):
        if self.mq and self.mq.sock:
            if isinstance(payload, int):
                payload = str(payload)
            if topic != self.nodup_t or payload != self.nodup_p:
                self.mq.publish(self.prefix+topic, payload)

І в кінці файлу, там де ми ініціалізуємо всі процеси і складаємо їх в один клас App, додаємо виклик цього класу:

app.add(WirelessMQTT('192.168.0.123', 'board99'))

Коли ESPшка з’єднається з мережею і підключиться до брокера MQTT, то всі наші повідомлення почнуть передаватися назовні. І, відповідно, зовнішні повідомлення передаватимуться класам, таким як BlinkingLED.

Цей код не дуже елегантний, але він працює.

З’єднання з зовнішнім світом через кабель

Тепер черга для Raspberry Pi Pico, до якої можна дістатися через /dev/ttyACM0 за допомогою програми socat та моїх скриптів. Тут все інакше і дикіше.

import sys
import select

class StdioConnector:
    def __init__(self, prefix):
        self.prefix = prefix+'/'
        self.nodup_t = self.nodup_p = None

    async def main(self, app):
        poller = select.poll()
        poller.register(sys.stdin, select.POLLIN)
        while True:
            res = poller.poll(0)
            if res:
                line = sys.stdin.readline().strip()
                if line:
                    topic, payload = line.split(' ', 1)
                    if topic.startswith(self.prefix):
                        topic = topic[len(self.prefix):]
                        self.nodup_t, self.nodup_p = topic, payload
                        app.handle(topic, payload)
                        self.nodup_t = self.nodup_p = None
            await asyncio.sleep(0)
    
    def handle(self, topic, payload):
        if topic != self.nodup_t or payload != self.nodup_p:
            print(self.prefix+topic, payload)

Отак.

Висновки

Я пропущу питання з кнопкою, тим більше що у мене нашвидкоруч зроблений варіант без debounce. Також пропущу незграбні моменти з тим, що onboard світлодіод на ESPшці інвертований, а на Pi Pico він нормальний. Просто обмежусь тим, що в «фінальній» версії (тобто фінальній на сьогодні) я блимаю світлодіодом у енергійному темпі, коли кнопка натиснена.

Головне: вся ця катавасія дійсно працює, як локально, так і з зовнішнім брокером MQTT. Як по Wi-Fi, так і по кабелю. Можна в Node-RED робити зв’язки однієї плати з іншою. Зашибісь.

• Код для ESP8266
• Код для RP2040

Невелике відео демонстрації роботи на YouTube: https://youtu.be/_cbC2cjzg2k

Якщо під’єднати якусь умовну кнопку до GPIO пристрою з прошивкою Firmata, сконфігурувати пристрій на режим читання цього GPIO, то після цього хост отримає потік сигналів зі станом кнопки. Просто рівномірний потік даних на стандартній швидкості 57600 bps. По духу як аналогова телеметрія.

Звичний для мене підхід — передавати лише зміни стану цієї клятої кнопки. Це економно, бо ми передаємо тільки те що треба і тільки тоді коли треба. Це зручно, бо легше на такі повідомлення дивитися людськими очіма під час відлагодження, бо нема «стіни» однакових рядків.

А з іншого боку, треба пам’ятати про корінь усього зла.

Прості і тупі рішення мають свої переваги.

Cross-post: https://kastaneda.kiev.ua/2025/09/06/45.html
Cross-post: https://kastaneda.dreamwidth.org/559424.html

Іноді мені сильно не вистачає швидкої енергійної електронної музики з високим BPM. Тоді я щось шукаю, іноді щось знаходжу. Ось, наприклад, кілька років тому знайшовся цікавий трек Kopophobia — Out Of Time. Бадьоро, дуже непогано, але.

Але куди йому до божественного треку Lotus III Theme.