В первой части я рассказывал, как из Flask + SNMP за пару вечеров собрать простую страницу со статусами принтеров.
С тех пор проект вырос — появилась база для склада, журнал изменений, страница «парк устройств», улучшенный SNMP‑сервис и UI.

В этой части — что конкретно изменилось, с какими проблемами я столкнулся и что планирую делать дальше.

Что изменилось — новые функции

Склад картриджей

Учёт типов картриджей и их остатков.
На главной странице «Мониторинг» у каждого устройства отображается текущий запас по соответствующему типу картриджа.
Журнал изменений (кто / когда / почему добавил или списал картридж).
UI: просмотр, фильтр «только используемые картриджи», быстрые кнопки «−1» (списать со склада), модалки для редактирования и создания типов.
Кнопка «+1» тоже есть, но по факту ей почти не пользуемся — жизнь показала, что большинство операций идёт через модалку с комментарием.

Как выглядит склад картриджей

Небольшой скриншот текущего интерфейса:

Парк устройств

Раньше список принтеров брался только из CSV. Сейчас есть отдельная страница «Парк устройств», а SNMP‑опрос уже опирается на парк, а не на сырой CSV.

Таблица парка: серийный номер, модель, IP, здание, кабинет, инв.№, статус (в работе / склад / ремонт / списан).
Можно добавлять / редактировать / удалять устройства через веб‑интерфейс.
Есть импорт / синхронизация с «старым» списком.
В записи устройства хранятся метаданные: display_name, building, room, ip — это всё дальше используется в мониторинге и отчётах.

Как выглядит парк устройств

Небольшой скриншот текущего интерфейса:

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

Небольшой скриншот текущего интерфейса:

Скриншот главной страницы мониторинга МФУ

ТО / журнал ремонтов

Фиксация выполненных ТО и ремонтов с сохранением «снимка» на момент операции: имя принтера, здание, кабинет, серийный.
Отдельная страница с фильтрами (период, здание, тип записи) и экспортом в Excel.
На главной странице есть кнопка «ТО» — можно быстро зафиксировать, что техработа по конкретному принтеру выполнена.

Мониторинг по SNMP (улучшения)

SNMP‑опрос теперь работает в фоне и складывает данные в кеш. Интерфейс читает этот кеш и не ждёт каждого запроса.
Есть поддержка множественных каналов (BK/Y/C/M) и старых OID’ов (legacy).
При опросе делается попытка распознать модель и привязать её к справочнику models_map.json, чтобы понять, какие картриджи реально стоят в аппарате.

Экспорт в Excel

Выгрузки: остатки склада, сколько было использовано за период, журнал изменений склада, парк устройств (разные режимы), журнал ТО.
Генерация xlsx на сервере — получаются готовые таблицы, которые можно отдать менеджерам или прикрепить к письму.

Управление пользователями и роли

Пользователи и роли хранятся в config.json, управляются через веб‑страницу.
Роли: просмотр склада, изменение склада, редактирование принтеров, экспорт, доступ к настройкам, админ.
Таким образом можно разделить: кому только смотреть, а кому разрешено что‑то менять.

Проблемы, с которыми столкнулся (и что пришлось делать)

1. Цветные МФУ: как привязать цвет к «нашему» картриджу на складе

Задача: для цветного аппарата нужно понять не только «тонер 10%», но и:

какой картридж стоит в BK/Y/C/M;
к какому типу на складе это всё относится.

Что всплыло на практике:

Одна и та же модель цветного МФУ на разных прошивках может:
- на одной прошивке отдавать 4 отдельных значения (BK/Y/C/M);
- на другой — только один общий счётчик;
- иногда — значения, которые вообще не похожи на проценты (max = 65535 и т.п.).
Строки с типом картриджа в SNMP выглядят по‑разному:
- TK‑1170,
- Canon C‑EXV54 Y,
- Black: CB436A,
- плюс свои локализации и «украшения».

Что сделал в итоге:

Ввёл свой справочник моделей (models_map.json), где для каждой модели руками описал:
- какие цвета есть (BK/Y/C/M);
- какой «человеческий» тип картриджа соответствует каждому цвету.
При опросе:
- пытаюсь вытащить модель из SNMP (sysDescr, hrDeviceDescr);
- ищу её в справочнике;
- если нашёл — понимаю, какой цвет к какому типу картриджа привязать на складе.
Если модель не найдена или SNMP отдаёт ерунду — такие устройства отдельно смотрю и дописываю в справочник вручную.

2. Одинаковая модель, разное поведение SNMP

На одних аппаратах условной «Kyocera XYZ» нужные OID читаются без проблем, на других — те же OID либо не работают, либо возвращают другой набор значений.

Вывод:

Универсальной схемы вида «всегда берём вот эти OID» не существует.
Пришлось сделать ступенчатую логику:
- сначала пробуем один набор OID (новый формат),
- если не сработало — откатываемся на старый (legacy),
- если и там нет нормальных данных — устройство попадает в список «под разбор».

Дальше уже смотрю руками, что оно там на самом деле отдаёт.

3. Параллельные правки и CSV

Изначально остатки и журнал жили в CSV‑файлах. При параллельной работе получалось классическое:

один человек что‑то меняет,
второй в это же время нажимает «списать −1»,
в итоге файл перезаписывается поверх, часть изменений теряется.

Что сделал:

Перешёл на SQLite (data.db) для склада, расходников и журнала ТО.
Любое изменение остатков:
- пишет новые значения в таблицу,
- тут же добавляет строку в журнал, всё в рамках одной транзакции.

Планы — что хочу доделать

1. Настройки для конкретных устройств (отдельные OID и правила)

Проблема: часть принтеров «говорит» по‑своему: нужные OID другие, формат значений отличается, стандартная схема не работает.

Что хочу сделать:

В таблицу printers_park добавить поле с настройками для конкретного устройства (JSON с набором OID, форматом значений, таймаутом и числом попыток).
В SNMP‑слое:
- при опросе сначала смотреть, есть ли у устройства свои настройки;
- если есть — использовать их;
- если нет — работать по текущей общей схеме.
В UI (/park):
- в карточке устройства сделать раздел «Расширенные настройки»:
  - режим «по умолчанию» / «свои OID»;
  - поля для OID и параметров опроса;
  - кнопку «Сбросить на значения по умолчанию».

Идея в том, чтобы один раз «докрутить» проблемные МФУ и далее не трогать их в коде.

2. Автоматическое списание картриджей со склада

Сейчас списание делается руками: нажимаем «−1» на складе или в нужном месте интерфейса. Хочется убрать часть рутины.

Идея: автоматическое списание картриджа при выполнении набора условий, с возможностью включать эту опцию отдельно для каждого МФУ.

Пример условий:

уровень тонера у конкретного принтера упал ниже порога (например, ≤ 5%);
видно, что картридж был заменён (например, по скачку счётчика страниц или смене серийника картриджа — если удастся это надёжно определять);
на складе есть хотя бы 1 штука соответствующего типа.

Как это может выглядеть:

В настройках устройства:
- флажок «Автоматически списывать картридж при замене»;
- выбор, по какому событию считать картридж заменённым.
В логике:
- при очередном опросе, если условия выполняются и опция включена:
  - уменьшать остаток на складе на 1 для нужного типа;
  - добавлять запись в журнал склада с пометкой, что списание произошло автоматически.

По умолчанию опция будет выключена, чтобы ничего не списалось неожиданно.

3. Автоматическая синхронизация списка устройств с print‑server / AD

Сейчас схема такая:
один раз собрал список принтеров через скрипт, положил его в CSV/базу, а новые устройства добавляю уже руками через веб‑страницу. Работает, но это чистый ручной режим.

Что хотелось бы в идеале:

периодически получать список принтеров:
- напрямую с print‑server (через скрипт/API),
- либо из AD (список опубликованных принтеров);
сравнивать его с текущим парком:
- новые устройства показывать как «кандидаты на добавление»;
- те, что пропали с сервера, — как «кандидаты на списание/склад».

Технически это может быть:

фоновая задача, которая раз в N часов:
- опрашивает print‑server или AD,
- складывает результат во временную таблицу,
- строит «дифф» с printers_park.
Страница «Синхронизация», где:
- блок «найдены новые устройства» с кнопкой «Добавить в парк»;
- блок «в парке есть устройства, которых больше нет на print‑server» — с возможностью сменить им статус (например, «списан» или «на складе»).

Когда будет на это время доделаю, пока что устраивает текущий функционал.

Зачем всё это и где проект уместнее всего

Сейчас это просто рабочий инструмент для эксплуатации парка принтеров:

показывает статусы и уровень тонера;
знает, что лежит на складе и кто что списал;
помнит, когда и по какому принтеру делали ТО;
даёт готовые Excel‑отчёты.

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

Если сравнивать с тем, что обычно используют:

SaaS (PaperCut, PrinterLogic и т.п.)
Там много аналитики, учёта отпечатков, интеграций и коммерческой поддержки. Но за всё это платите подпиской и обычно тянете данные куда‑то наружу.
Здесь всё локально, разворачивается за вечер и решает именно задачи эксплуатации: мониторинг, склад, ТО, отчёты.
Классический мониторинг (Zabbix, Nagios + шаблоны)
Zabbix и подобные системы сильнее в алертинге и масштабе, но требуют настройки SNMP‑шаблонов и времени на тюнинг.
При этом склада картриджей, журнала ТО и «одним кликом в Excel» там нет — это придётся городить отдельно.

В таком окружении этот проект хорошо закрывает повседневные вещи:

быстро увидеть, у кого кончается тонер и есть ли запас на складе;
понять, когда последний раз что‑то делали с конкретным МФУ;
выгрузить в один файл картриджи, парк или журнал ТО и отдать тем, кто «жить в системе» не собирается.

Если парк небольшой или средний и нужна прозрачность без лишних движений, текущей функциональности уже достаточно, чтобы каждый день экономить время.
Если же нужна глубокая интеграция со всем ИТ‑ландшафтом и глобальный мониторинг, это задача для других инструментов, а этот проект вполне может остаться лёгким локальным помощником рядом.

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

ЧАСТЬ 2 — Мониторинг МФУ на Flask: новые функции, проблемы и планы