Ну и в продолжение вчерашнего: #знаетеливы что "удалённый репозиторий" в разнообразных "сетевых" командах git (clone, fetch, push, ...) — это не обязательно гитхаб не обязательно какой-то хитрый сервер, настроить который под силу только профессиональному админу. Речь о неожиданно банальных, бытовых конфигурациях, от использования которых отделяет, скорее, незнание, что "а так можно было". Ключевая особенность — не надо настраивать никаких серверов.

Команду git clone можно "натравить" на самую обычную локальную копию репозитория: вместо git clone git@github.com:username/repo можно выполнить git clone file:///home/username/projects/repo (с абсолютным путём к каталогу репозитория и тремя слешами после file:). Ну разве что, если оригинал и копия находятся в одном каталоге, то придётся передать git clone ещё один аргумент: "куда клонировать" — просто потому, что последний компонент исходного пути будет именем клона по умолчанию, а оно кто бы мог подумать уже занято:

$ cd ~/projects
$ git clone file:///home/username/projects/repo
fatal: destination path 'repo' already exists and is not an empty directory.
$ git clone file:///home/username/projects/repo new-repo-copy
Cloning into 'new-repo-copy'...

В новом репозитории git remote -v будет честно указывать file:///... в качестве origin. Ну и, конечно, никто не мешает регистрировать новые remotes с локальными URL и работать с ними, как с любыми другими:

$ git remote add my-local-fork file:///home/username/projects/second-repo
$ git fetch my-local-fork

Если же у вас есть доступная по ssh машина other-desktop, на которую вы заходите как remoteuser, то можно взаимодействовать с репозиториями оттуда:

$ git clone ssh://remoteuser@other-desktop:/path/to/repo

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

Наконец, вместо использования URL со схемой file:// можно и просто указать локальный путь. Насколько я понимаю, отличие будет в том, что при указании источника по URL в новом клоне в "скрытом" каталоге .git будут "загруженные" копии исходных объектов, а при использовании обычного пути к каталогу — по умолчанию будут создаваться жёсткие ссылки на исходные файлы, если возможно. С одной стороны — экономия места, с другой — если сильно поломать оригинал, есть возможность разломать и копию: в общем, думайте сами, решайте сами, читайте документацию.

Можно, кстати, даже именованных remotes не добавлять, а вместо этого передавать URL целиком прямо в git fetch! Правда, тогда придётся проявлять некоторую ловкость, чтобы добраться до результата — локального "зеркала" удалённых веток никто уже создавать не будет:

$ git fetch file:///some/repo
remote: Enumerating objects: 1234, done.
...
From file:///some/repo
 * branch              HEAD       -> FETCH_HEAD
$ git log FETCH_HEAD
... тут какие-то коммиты ...
$ git fetch file:///some/repo other-remote-branch
remote: Enumerating objects: 4321, done.
...
From file:///some/repo
 * branch              other-remote-branch    -> FETCH_HEAD
$ git log FETCH_HEAD
... тут какие-то другие коммиты ...

Неочевидно, но факт: радиус кривизны рук — это величина типа "больше — лучше".

Давно было пора рассказать о полезном проекте ESPHome, да как-то хорошего примера не попадалось. И вот на новогодних праздниках пример наконец-то появился. Рассказ будет состоять из двух частей: костыльной аппаратной и, собственно, красивой программной на ESPHome.

Недавно я купил кольцевую лампу с питанием от USB и закрепил её за монитором. Днём позади монитора у меня окно, а вечером позади монитора у меня темно и грустно, так что лампа сглаживает контраст между ярким экраном и "фоном" шторы.

Я уже давно использую "умную" лампу (обычную "свечу" с цоколем E14) в качестве светового будильника: HomeAssistant получает с моего смартфона время срабатывания ближайшего будильника и постепенно зажигает лампу за 20 минут до. Вот я и решил попрактиковаться, и организовать управление замониторной лампой из HA, чтобы её пульт на столе не валялся.

План заключался в том, чтобы аккуратно (ну, почти) вывести из пульта лампы питание USB и необходимые сигналы, и присоединить к мелкой плате с ESP32 вроде этой — в общем, задача на полдня (ага, щаз...):
* GND и 5V питания от USB
* "входные" сигналы для четырёх кнопок ("вкл-выкл", "тёплый-холодный свет", "яркость +" и "яркость -")
* "выходные" сигналы: питание "тёплой" и "холодной" секций светодиодов для обратной связи (иначе я бы смог только "удалённо клацать по кнопкам" — такой себе интерфейс).

#esphome

Итак, часть аппаратная, костыльная.

И сразу не лишним будет напомнить о технике безопасности: да, на USB пять вольт (если не быстрая зарядка). Но это между GND и Vbus пять вольт, а относительно, например, радиатора центрального отопления там может быть 100-200 вольт, просто ток микроскопический, если блок питания исправен. Несколько лет назад я осознал это внезапно, когда возился с какой-то подключённой к USB платой и ткнул ногой в тёплую батарею. Тут-то палец слегка кольнуло. К счастью, БП компьютера был исправен, так что ток оказался мизерный.

Ну так вот, методом осторожного тыка мультиметром я выяснил, что "управляющие" выводы "пультовой" микросхемы подтянуты к 5V, а нажатие кнопки замыкает их на GND. Питание светодиодов тоже между 0 и 5V. Вот и первая проблема: судя по документации, ESP32 не 5V tolerant. Ну, со входом (со стороны ESP32) сигнала питания светодиодов проблем нет, поможет делитель напряжения: ставим два резистора на десять килоом, посередине снимаем сигнал 0-2.5V. С выдачей сигнала на кнопки сложнее: сам я тривиальной схемы не придумал, а "в интернетах" тоже советуют либо забить, поставить токоограничительный резистор, и надеяться, что ESP32 не сгорит, либо соорудить нехитрый конвертер уровней. Я выбрал второй вариант, решив не срезать углы в учебном проекте, и вместо этого заняться традиционной русской забавой: новогодним поиском транзисторов.

Пожалуй, не буду строить из себя специалиста-электронщика и рекомендовать кому-то конкретный дизайн своих костылей, скажу лишь, что на каждую кнопку у меня приходится по одному полевому транзистору BSS138 и одному резистору (между истоком и затвором, чтобы статикой не побило), а питание каждого из двух каналов светодиодов измеряется при помощи делителя на двух 10k резисторах и сглаживающего фильтра из конденсатора и ещё одного резистора.

#esphome

Теперь часть красивая, программная. Иногда в интернете можно встретить ругань на скетчи Arduino, мол непрофессионально это всё. Что ж, не будем писать кривой-косой код в Arduino IDE. Вместо этого будем, как взрослые серьёзные люди, код вообще не писать, а вместо него пользоваться YAML-конфигурацией!

ESPHome — это такой инструмент, который на вход принимает очень компактное декларативное описание подключённой "периферии" и требуемые автоматизации (а в простейшем случае — просто выставляет "крутилочки" наружу). Потом вы передаёте этот YAML питоновской тулзе, которая сама генерирует требуемый код "прошивки" на C, скачивает тулчейн для требуемого микроконтроллера и заливает прошивку (а при последующем обновлении даже можно заливать прошивку "по воздуху"!). Как говорится, просто откиньтесь на спинку табуретки :)

esp32:
  board: esp32-c3-devkitm-1
  framework:
    type: esp-idf

wifi:
  domain: .lan
  fast_connect: true
  ssid: "mywifinetwork"
  password: "RovOgsovhed9" # ... is not my password :)

esphome:
  name: monitor-lamp

logger:
  # тут пусто

... и вот уже esphome знает 1) какое у нас железо и, соответственно, какой компилятор качать, 2) к какой сети подключаться и 3) как представиться местному DHCP-серверу. Плюс прошивка будет печатать стандартные логи. Но правильнее будет создать отдельный файл secrets.yaml

wifi_ssid: "mywifinetwork"
wifi_password: "RovOgsovhed9"

а в основной конфигурации (которую можно положить, например, в гит) указать

wifi:
  domain: .lan
  fast_connect: true
  ssid: !secret wifi_ssid
  password: !secret wifi_password

Каждый возможный параметр я описывать не буду, поскольку есть довольно удобная документация.

Теперь можно каким-нибудь способом установить питоновский пакет esphome (я для этих целей относительно недавно открыл для себя pipenv) и подключить плату по USB для первоначальной прошивки. Важно: в описании моей платы явно указано, что нужно питать плату либо от USB, либо "через пины", но не одновременно двумя способами.

Прошиваем (текстовый скринкаст):

pipenv run esphome run backlight-lamp.yaml

#esphome

Итак, минимальная конфигурация готова. Поскольку, как я уже говорил, при подключении к лампе мне придётся отключить питание от USB, то и перепрошивать придётся, постоянно переключаясь туда-сюда. Поэтому сразу добавим OTA-обновления и "api" (без него, как я понял, не получится по сети прочитать лог работы прошивки). Ещё раз перешьём по кабелю:

api:

ota:
- platform: esphome
  port: 4321
  password: !secret ota_password

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

Итак, плата при подключении не сгорела, аппаратные кнопки на пульте также работают штатно. Попробуем снять показания АЦП: добавим в конфиг первое описание сенсора и перешьем:

sensor:
- platform: adc
  pin: GPIO03
  update_interval: 1s
  attenuation: auto
  id: adc_led_warm
  name: "Warm LEDs output level"

Теперь в логах можно наблюдать изменение яркости:

pipenv run esphome logs backlight-lamp.yaml

Светодиоды в лампе подключены с общим анодом, а измеряем мы, соответственно, напряжение на катодах, поэтому максимальная яркость — это 0, а минимальная, получается, примерно 1.3V (кажется, с расчётом то ли делителя напряжения, то ли фильтра, я всё-таки налажал...).
#esphome

Осталось научиться работать с кнопками. Тут описание в ESPHome состоит из двух частей: компонента GPIO Output и самой Generic Output Button:

output:
- platform: gpio
  pin: GPIO20
  id: pin_button_on_off

button:
- platform: output
  name: "Power on/off"
  output: pin_button_on_off
  duration: 100ms

Вот только как на эту кнопку нажать? Если есть настроенный сервер Home Assistant, то добавить в него новое устройство и нажимать :) А если нет? Тогда просто добавляем на верхний уровень конфига web_server: с настройками по умолчанию, и можно заходить в браузере на http://backlight-lamp.lan/, вот так вот просто!

Остались мелочи: добавить в конфиг встроенный в ESP32 датчик температуры и распаянный на плате светодиод:

sensor:
- platform: internal_temperature
  name: "Internal temperature"

output:
- platform: gpio
  pin:
    number: GPIO08
    inverted: true
  id: pin_status_led

light:
- platform: binary
  name: "Status LED"
  output: pin_status_led

и пересчитывать в проценты значения измеренной яркости (обратите внимание на именованную ссылку led_output_filters — это стандартная возможность в yaml):

- platform: adc
  # ...
  name: "Warm LEDs output level"
  unit_of_measurement: "%"
  accuracy_decimals: 0
  filters: &led_output_filters
  - calibrate_linear:
      - 0.0 -> 100.0
      - 1.3 -> 0.0
  - clamp:
      min_value: 0.0
      max_value: 100.0
- platform: adc
  # ...
  name: "Cold LEDs output level"
  unit_of_measurement: "%"
  accuracy_decimals: 0
  filters: *led_output_filters

Если честно, пока всё работает не настолько гладко, как хотелось бы, и кое-что придётся ещё отладить, но уже "за кадром". Впрочем, думаю, мне удалось хотя бы немного продемонстрировать выразительность ESPHome.
#esphome

Не поспоришь...

А вот и обещанный способ упростить себе установку питоновского софта (как пользователю) при помощи pipenv.

Раньше, когда в документации какой-нибудь программы мне говорили, что нужно сделать pip install <чтототам>, а в репозитории убунты этот пакет отсутствовал или был устаревшей версии, я нехотя начинал пляски с бубном. Систему-то замусоривать не хочется, да и личный профиль пользователя — тоже (а вдруг завтра я решу ещё что-то поставить, а там окажутся какие-нибудь конфликты версий общих библиотек).

Пляски выглядели примерно так:
1) выбрать, где будет валяться установочный каталог этой конкретной программы
2) инициализировать там Python virtual environment: virtualenv ~/installdir
3) активировать конкретный virtual environment в текущем терминале: source ~/installdir/bin/activate
4) находясь в нужном терминале выполнить pip install <чтототам>
5) радостно пользоваться установленным софтом

В итоге на первом шаге я вынужден задуматься, а какой каталог мне сегодня не так жалко замусорить. На третьем — в текущем сессии терминала появляется нестандартное глобальное состояние. Перепутал вкладку терминала на четвёртом шаге — и в лучшем случае получаешь ошибку, что для замусоривания системы не хватает прав. А почему не запускается-то?.. а, это я на пятом шаге опять терминал перепутал. В общем, весело. Бонусом, мне обычно тревожно удалять что-то, не глядя, так что каталог, созданный на первом шаге ещё напомнит о себе через пару месяцев необходимостью увлекательных размышлений "а тут у меня точно ничего полезного не лежало? точно ведь?.."

К счастью, есть более удобный способ: pipenv. Правда, в нём также придётся выбрать некий каталог в качестве "установочного", но лишь условно: в нём будет лежать лишь один короткий файл Pipfile с полностью человекочитаемым списком установленного софта и ещё один более длинный и полностью автосгенерированный Pipenv.lock. В остальном каталог полностью в моём распоряжении, и в него можно, например, положить файлы, с которыми я работаю при помощи этой программы. В этом варианте тоже будет инициализирован virtualenv, но он будет лежать где-то во временных файлах — а когда я вижу, что некий каталог полностью "вторичен" по отношению к лежащему отдельно "первичному" описанию (Pipenv + Pipenv.lock), то и удалять его обычно не так страшно :)

Вот, как теперь выглядит мой типичный способ использования питоновского софта. Допустим, я хочу начать работать с esphome. Мне в любом случае придётся создать некий "каталог проекта", куда я буду складывать yaml-конфигурации устройств. Возможно, этот каталог даже будет положен в гит.

На самом деле, изменить глобальное состояние всё-таки придётся, но лишь единожды: потребуется установить сам pipenv, если его ещё нет. В убунте можно поставить системный пакет pipenv. Или можно воспользоваться официальной рекомендацией: pip install --user pipenv.

Итак допустим, что я решил складывать все наработки в ~/esphome. Но мне же не жалко, если в этом каталоге дополнительно будет валяться всего-то два текстовых файла, правда? Поэтому я перехожу в ~/esphome и выполняю там команду pipenv install:

$ mkdir esphome
$ cd esphome
$ pipenv install
$ ls
Pipfile  Pipfile.lock

Как видим, в каталоге появилось два файла: Pipfile и Pipfile.lock. Первый является кратким описанием "что требуется получить", второй — машиночитаемым json-ом, перечисляющим конкретные версии всех пакетов (включая зависимости) для воспроизводимости окружения при переустановке. Не беспокойтесь, lock-файл многословен, но нам туда лезть не потребуется. И да, официальная документация рекомендует коммитить в гит оба этих файла. До начала установки конкретных пакетов Pipfile выглядит так:

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]

[dev-packages]

[requires]
python_version = "3.13"

Теперь, находясь всё в том же каталоге, я могу скомандовать pipenv install esphome, и через некоторое время esphome будет установлен, в Pipfile в секции [packages] добавится единственная строчка esphome = "*" (мы ведь попросили поставить esphome неважно какой версии), а вот Pipfile.lock разрастётся с 454 байт аж до 106 килобайт — но нам-то что, не нам же его редактировать.

Обычно установка esphome при помощи pip install добавила бы нам в PATH команду esphome. Но поскольку у нас может быть много разных окружений, каждое со своим набором пакетов, то для использования esphome через pipenv нужно 1) перейти в "установочный" каталог (или куда-нибудь ещё ниже по дереву) и 2) приписать перед требуемой командой esphome run — всё!

~/esphome$ pipenv run esphome --version
Version: 2026.1.4
~/esphome$ cd subdir
~/esphome/subdir$ pipenv run esphome --version
Version: 2026.1.4

Разумеется, каждый отдельный Pipfile не ограничен единственным "пользовательским" пакетом, и можно установить ещё что-нибудь при помощи pipenv install <имя>. Также есть команды, чтобы обновлять пакеты, удалять пакеты или, например, запустив pipenv shell, можно свести задачу к предыдущей всё-таки запустить shell с настроенным virtualenv, как привыкли — но тут уже лучше читать документацию.

С точки зрения использования SD-карт сначала я был наивным пользователем цифровой "мыльницы", потом чуть менее наивным пользователем недорогих смартфонов с недостаточным объёмом встроенного накопителя. В те годы в основном я выбирал карты памяти по "классу скорости", ну и по отзывам.

Когда же я начал достаточно активно возиться с одноплатными компьютерами (да-да, тот самый #маленький_но_гордый_сервер), то с удивлением узнал, что SD-карты гораздо интереснее, чем казалось. Конечно понятно, что поддельная карточка или USB-флешка может обманывать не то, что со скоростью, а даже с объёмом — речь сейчас не о них. Оказалось, что даже заявляемые производителем характеристики сейчас иногда, если можно так выразиться, двумерные.

По одной "оси" уже давно совершенствуется скорость чтения и записи. Иногда — вместе с необходимостью аппаратной поддержки на стороне устройства, вплоть до добавления новых контактов в разъём. Грубо говоря, если вы в 2010 году купили цифровой фотоаппарат, умеющий писать видео в достаточно высоком разрешении, а вставленная в него карточка не успевает стабильно "поглощать" столько данных в единицу времени, сколько "отправляет" камера — то ой. Но скорость скорости рознь — важно, в каких конкретно условиях её требуется достигать.

В некоторый момент важным "потребителем" SD-карт стали смартфоны. И если для фото- и видеокамер была важна скорость линейного доступа, то у смартфонов аппетиты разнообразнее: теперь на карту можно установить тяжёлое приложение. Или, может, какое-то приложение запишет на карту большие по объёму данные, но будет читать их в случайном порядке. Поэтому стандартизовали ещё одну "ось" измерения "хорошести" карты памяти: Application Performance Class, характеризующий скорость произвольного доступа маленькими блоками: A1 и более продвинутый A2. А может не заявляться никакого A-класса: по C- или V-рейтингу карта вполне шустрая, а в качестве "системного диска" одноплатного компьютера — как повезёт.