weighing-controller/RECOVERY.md

Восстановление Orange Pi на новой SD-карте

Runbook на случай, когда карта деградировала и устройство надо поднять с нуля. Составлен во время инцидента 22.07.2026: ФС ушла в read-only — захват кадра и SSH отвалились, при этом heartbeat и публикация веса в MQTT продолжали работать.

Что взять на пост

• новая SD-карта, high-endurance (Samsung PRO Endurance / SanDisk Max Endurance); 32 ГБ хватает с запасом — занято ~12%
• образ Armbian для Orange Pi PC, записанный заранее
• orange_pi/scales.py, orange_pi/outbox.py, orange_pi/scales.service из этого репозитория
• старую карту НЕ выбрасывать: с неё может понадобиться вытащить остатки очереди outbox

1. Система

apt update
apt install -y python3 python3-pip ffmpeg
pip3 install paho-mqtt        # на свежих Debian/Armbian добавить --break-system-packages

Больше внешних зависимостей нет — всё остальное в скрипте из stdlib.

2. Файлы

Рабочий файл на устройстве — именно /root/scales.py; репозиторий на OPi не клонируется, файл доставляется вручную. outbox.py кладётся рядом, в /root.

cp scales.py outbox.py /root/

Актуальную версию можно скачать прямо с сервера:

curl -s -o /root/scales.py https://scales.zeroday.su/testphotos/scales.py

3. Сервис

cp scales.service /etc/systemd/system/scales.service
systemctl daemon-reload
systemctl enable --now scales.service
systemctl status scales.service --no-pager

4. Проверки после старта

# в логе должны появиться MQTT1/MQTT2, GPIO, OUTBOX, HEARTBEAT
journalctl -u scales.service -n 30 --no-pager

# весовой терминал
ls -l /dev/ttyUSB0

# камера — тот же вызов, что внутри grab_frame()
ffmpeg -y -loglevel error -rtsp_transport tcp -i "<RTSP_URL из scales.py>" \
  -frames:v 1 -update 1 -q:v 2 -f image2 /tmp/scale_frame.jpg && ls -l /tmp/scale_frame.jpg

# офлайн-распознавание на боксе
curl -s http://192.168.20.4:5010/health

# сервер принимает (ожидаемый ответ: {"error":"event_id required"})
curl -s -X POST -H "Content-Type: application/json" -d '{}' https://scales.zeroday.su/api/local-plate

Финальная проверка — кнопка «Тест-снимок» в панели: фото должно появиться в заездах.

5. Чтобы карта прожила дольше

Главный убийца SD-карт — постоянная запись логов.

mkdir -p /etc/systemd/journald.conf.d
printf '[Journal]\nStorage=volatile\nRuntimeMaxUse=32M\n' > /etc/systemd/journald.conf.d/volatile.conf
systemctl restart systemd-journald

Убедиться, что /tmp — tmpfs (туда пишется кадр перед отправкой):

findmnt /tmp

Если нет — добавить в /etc/fstab:

tmpfs /tmp tmpfs defaults,nosuid,nodev,size=128M 0 0

На перспективу: перенос системы на USB-SSD или eMMC снимает проблему целиком.

Диагностика без SSH

Устройство управляется через MQTT-брокер даже когда SSH недоступен (на сервере: localhost:1883, пользователь scales-server).

# живой heartbeat раз в 30 с — значит процесс жив
mosquitto_sub -h 127.0.0.1 -p 1883 -u scales-server -P '<пароль>' -t 'scale/device/status' -v

# команды: ping (мгновенный статус), test-shot (проверка камеры), reboot
mosquitto_pub -h 127.0.0.1 -p 1883 -u scales-server -P '<пароль>' -t 'scale/device/cmd' -m '{"cmd":"ping"}'

Как читать симптомы:

признак	что значит
heartbeat идёт, на ping отвечает мгновенно	процесс жив, ресурсы в порядке
outbox_pending: 0, но заездов на сервере нет	capture_and_send вышел до постановки в очередь — не получен кадр
test-shot не даёт фото, а RTSP из VLC играет	причина локальная на OPi: запись в /tmp или ffmpeg
SSH рвёт соединение на key exchange	sshd не может создать сессию — характерно для read-only ФС

Совпадение последних трёх — почти наверняка карта.

Известная недоработка

capture_and_send() при неудачном захвате кадра выходит по return до постановки события в очередь. Значит отказ камеры теряет не фото, а всю запись о взвешивании — именно так были потеряны заезды 20.07.2026. Вес должен доезжать до сервера и без фото; поправить при ближайшем доступе к устройству.