Valentin V. Bartenev a9273f02bb Redesign approach for CPU usage tracking
The previous implementation maintained three exponential moving averages
(1/5/15-minute) of CPU busy-fraction, sampled every 5 seconds. This had
two problems:

1. Wrong semantics: the metric was labelled "load_avg" (a Unix concept
   measuring run-queue depth), but the tracker actually measures CPU
   busy-time as a fraction of FreeRTOS ticks — i.e. utilization, not
   load.  The name was misleading.

2. Poor responsiveness: the 1-minute EMA (DECAY = exp(-5/60) ≈ 0.920)
   has a ~60-second time constant.  On a live web panel, this made the
   metric appear frozen, especially during short bursts of activity
   (e.g. an HTTP request from the panel itself).

This commit replaces the EMA with a 64-sample simple moving average
(SMA) over a compact uint8_t circular buffer. The sample interval is
60 s / 64 = 937,500 µs, so the window covers exactly 60 seconds:

Algorithm:
- Every 937,500 µs (= 60 s / 64), the FreeRTOS tick delta (busy vs
  idle ticks on core 0) is computed and stored as a uint8_t
  (0–255 = 0–100% utilization).
- The circular buffer holds 64 samples, spanning exactly 60 seconds
  (64 × 937,500 µs = 60,000,000 µs). The timer interval is derived
  directly from the window size: 60 000 000 / SMA_WINDOW µs.
- The index wraps with a bitwise AND (& 63) instead of modulo, since
  64 is a power of 2.
- The running sum is a uint16_t (max 64 × 255 = 16 320, fits easily).
- The result _sma_avg is a volatile float written atomically by the
  esp_timer task (core 0) and read from the main loop (core 1).
  No spinlock is needed: on Xtensa LX7, a 32-bit aligned float store
  is a single instruction.

The 60-second window smooths out short bursts (e.g. WiFi/HTTP spikes)
while reacting to sustained load changes within ~10–15 seconds.

Naming:
- The public API is now getCore0Util() returning a float in [0.0, 1.0].
  The name explicitly identifies which core is measured (core 0, which
  runs WiFi, MQTT, HTTP, and LwIP — see task_pinning.c).
- JSON keys: "load_avg" (array) → "core0_util" (scalar float, percent)
- HistorySample field: load_avg1_pct → core0_util_pct
- StatsHistory series key: "cpu_load" → "core0_util"
- Web panel label: "Load Avg" → "Core0 Util"

The history snapshot (once per minute) reads the same _sma_avg value,
which at that point represents the rolling average of the last 60
seconds — exactly one history interval.
2026-05-10 06:26:08 +03:00
2025-01-13 14:07:48 +11:00
2025-01-13 14:07:48 +11:00
2025-06-05 20:35:40 +12:00
2026-03-20 10:23:51 +11:00
2026-03-23 14:26:56 +01:00
2025-01-25 23:09:09 +11:00
2026-05-02 21:43:36 +03:00
2026-04-10 18:01:38 +10:00
2026-04-23 09:49:51 +10:00
2026-04-10 18:01:38 +10:00

Прошивка MeshCore-репитеров с WEB и MQTT

Это форк прошивки MeshCore-EastMesh, в котором поддержка австралийского сервиса телеметрии EastMesh AU заменена на поддержку сервиса MeshCoreTel, а также выполнен ряд других доработок и адаптация.

В остальном прошивка базируется на официальных версиях прошивок МеshCore. Благодарность Scott Powell / Ripple Radios и всем контрибьюторам MeshCore за оригинальную прошивку и основу проекта, а также Jared Dohrman за доработки, выполненные в рамках EastMesh.

Ключевые особенности прошивки

Дополнения ретранслятора

  • поддержка Wi-Fi в клиентском режиме
  • автонастройка сети через DHCP
  • синхронизация времени по NTP
  • поддержка MQTT-брокеров:
    • meshcoretel
    • letsmesh-eu
    • letsmesh-us
  • транспорт plain TCP и WSS по пути /mqtt
  • JWT-аутентификация с использованием идентификации устройства для WSS
  • CLI-команды для:
    • учётных данных WiFi
    • энергосбережения WiFi
    • отчётов о заряде батареи на поддерживаемых платформах
    • включения конечной точки MQTT
    • отправки пакетов MQTT и публикации сырых данных
    • публичного ключа владельца и адреса электронной почты
    • включения локальной веб-панели
    • управления вентилятором на TBeam 1W
  • все сетевые процессы (включая обработку MQTT и веб-панели) вынесены на отдельное ядро и не вносят задержек в обработку LoRa-пакетов и функционирование ретранслятора

Локальная веб-панель

Дополнительно на поддерживаемых устройствах (с достаточным количеством памяти) ретранслятор может предоставлять локальную панель конфигурации по HTTPS через WiFi.

Возможности:

  • доступ по паролю, используя существующий административный пароль ретранслятора
  • выполнение CLI-команд
  • изменение основных настроек репитера и MQTT через веб-интерфейс
  • сгруппированные быстрые действия
  • вся ключевая статистика по репитеру
  • список последних услышанных соседий с показателями качества сигнала
  • хранение истории показателей за последние несколько часов (только на устройствах с PSRAM)
  • светлая и тёмная темы
  • возможность отключения командой set web off

Подробнее в документации: Использование веб-панели ретранслятора

Веб-API по HTTPS

На устройствах с поддержкой веб-панели также возможно использование встроенного API по Wi-Fi.

Возможности:

  • авторизация по паролю администратора с получением временного токена
  • выполнение любых CLI-команд для управления, настройки и статуса
  • получение всей доступной телеметрии

Данный API может быть использован для мониторинга с хранением долгосрочной истории (например с использованием таких инструментов как Prometheus и Grafana), а также автонастройки и управления устройством с помощью скриптов.

Подробнее в документации: Использование веб-API ретранслятора

Релизы

Готовые прошивки публикуются на GitHub Releases:

А также доступны в веб-прошивальщике от MeshCoreTel:

Документация

Основные разделы пользовательского руководства:

S
Описание
Клон репозитория от VBart с моими добавлениями касательно устройств
Readme
11 MiB
Languages
C 55.2%
C++ 43.5%
Python 0.7%
Shell 0.3%
CSS 0.2%
Разное 0.1%