// ПРОШИВКА

Прошивка
TMesh

Специальная прошивка для шлюзов и устройств TMesh. Основана на официальной прошивке Meshtastic с дополнительными функциями для городских сетей.

Поддержка кириллицы Force Next Hop Favorite Router TMesh MQTT Meshtastic совместима

Что такое прошивка TMesh

Прошивка TMesh — это специальная сборка на основе официальной прошивки Meshtastic для устройств, работающих в сети TMesh. Она полностью совместима с обычными узлами Meshtastic, но содержит ряд доработок, повышающих качество работы в плотных городских сетях и при подключении к MQTT-серверу TMesh.

💡
Прошивка необходима для работы в качестве шлюза TMesh. Для обычного использования — по желанию.

Отличия от официальной прошивки

🔁
Режим ретрансляции KNOWN_ONLY работает иначе: ретранслируются только пакеты от узлов из списка избранных, а не от любых известных узлов.
🖥️
Если таймаут экрана установлен на 30 секунд, устройство не будет будить экран при входящих сообщениях — только по нажатию кнопки.
🇷🇺
Добавлена поддержка кириллических символов на дисплее устройства.
🎯
Функция Force Next Hop — принудительный выбор узла-ретранслятора для всех пакетов, включая публичные каналы и Node Info.
🔀
Функция Favorite Router — принудительная ретрансляция пакетов через указанный узел и сохранение счётчика хопов при ретрансляции через него.

При подключении к MQTT-серверу TMesh

📡
Все пакеты, принятые устройством, отправляются на MQTT — независимо от флага ok_to_mqtt.
📊
Если включена телеметрия устройства, она отправляется раз в час — вне зависимости от текущей загруженности канала и числа онлайн-узлов в сети.
🔽
Пакеты, полученные с downlink-топика MQTT-сервера TMesh, ретранслируются в сеть без флага via_mqtt — как если бы они пришли напрямую по радио.
🔒
Пакеты с флагом ok_to_mqtt = false всё равно отправляются на MQTT-сервер TMesh для обеспечения связи через шлюз.

Force Next Hop

В стандартной прошивке Meshtastic NextHop используется только для личных сообщений (DM) и автоматически выбирается маршрутизатором. Функция Force Next Hop позволяет принудительно указать, через какой из соседних узлов будут ретранслироваться пакеты от вашего устройства — включая сообщения на публичные каналы, Node Info, позицию и всё остальное.

ℹ️
Доступно начиная с версии прошивки TMesh 2.7.23. Функция полезна, если вы хотите направить трафик через конкретный шлюз с хорошим покрытием, а не через любого случайного соседа.

Настройка

Force Next Hop настраивается через модуль «Счётчик прохожих» (Paxcounter) — эти поля не используются по основному назначению и перепрофилированы для данной функции.

Модуль: Счётчик прохожих (Paxcounter)
Paxcounter включён
Нет
Порог WiFi RSSI
Значение NextHop — последний байт ID целевого узла в десятичном виде.
Возьмите два последних символа из HEX-ID ноды и переведите из HEX в DEC.
Пример: ID !a3f2c84e → 0x4e → 78
Конвертер HEX → DEC →
BLE RSSI порог
Режим работы: 1, 2 или 3 — см. ниже

Режимы работы (BLE RSSI порог)

1
Только свои пакеты · мягкий
NextHop устанавливается только на пакеты от вашего устройства. Если при первых двух попытках никто не ретранслировал пакет — третья попытка будет без принудительного NextHop.
2
Свои и ретранслируемые · мягкий
NextHop устанавливается на пакеты от вашего устройства и на все пакеты, которые вы ретранслируете. Как и в режиме 1, последняя попытка ретрансляции будет без NextHop.
3
Свои и ретранслируемые · строгий
NextHop устанавливается на все пакеты как в режиме 2, но все попытки ретрансляции — включая последнюю — будут с принудительным NextHop.
⚠️
Если указанный NextHop-узел недоступен или не слышит ваш пакет — доставка может не состояться. Режимы 1 и 2 дают запасную попытку без NextHop, режим 3 — нет.

Favorite Router

Проблема 1: две ноды с направленными антеннами

У вас две ноды с направленными антеннами в разные стороны. Вы хотите, чтобы пакеты соседей, принятые одной из нод, всегда ретранслировались обеими нодами — в обе стороны — и чтобы счётчик хопов уменьшался только на 1 суммарно для обеих ретрансляций.

Решение: перевести обе ноды в роль ClientBase, добавить каждую в Favorites другой и настроить на обеих режим FAVORITE_ROUTER_MODE_HOPS_AND_RELAY.

Проблема 2: сосед в роли Client

Ваша нода в роли ClientBase, и вы хотите, чтобы она не уменьшала хопы от всех пакетов, которые ретранслирует ваш сосед. Но у него нода в роли Client — и в стандартной прошивке это невозможно: не уменьшать хопы можно только если предыдущий ретранслятор сам в роутер-роли.

Решение: добавить ноду соседа в Favorites и настроить режим FAVORITE_ROUTER_MODE_HOPS_ONLY.

ℹ️
Доступно начиная с версии прошивки TMesh 2.7.25. FAVORITE_ROUTER_MODE_HOPS_ONLY требует любую роутер-роль (Router, RouterLate или ClientBase). FAVORITE_ROUTER_MODE_HOPS_AND_RELAY работает только с ролью ClientBase.

Как это работает

В стандартной прошивке нода может не уменьшать счётчик хопов при ретрансляции только если выполнены два условия одновременно: сама нода должна быть в роутер-роли (Router, RouterLate или ClientBase), и предыдущий ретранслятор тоже должен быть в одной из этих ролей и добавлен в Favorites. FAVORITE_ROUTER_MODE_HOPS_ONLY снимает второе ограничение — роль предыдущего ретранслятора больше не проверяется. Хопы не будут уменьшаться, даже если пакет пришёл от Client или любой другой роли. Ваша нода при этом всё ещё должна быть в роутер-роли.

В стандартной прошивке нода в роли ClientBase принудительно ретранслирует пакеты от Favorites в позднем окне, но только те, у которых поле from совпадает с ID из Favorites — то есть пакеты, отправленные непосредственно этой нодой. Пакеты, которые Favorites сами ретранслируют, под это не попадают. FAVORITE_ROUTER_MODE_HOPS_AND_RELAY устраняет это ограничение — ваша нода будет принудительно ретранслировать все пакеты, прошедшие через указанный узел, включая те, которые он сам ретранслирует. Требует роль ClientBase.

Настройка

Функция настраивается через модуль «Счётчик прохожих» (Paxcounter) — так же, как Force Next Hop. Поле Порог WiFi RSSI задаёт ID целевого узла, поле BLE RSSI порог — режим работы.

Модуль: Счётчик прохожих (Paxcounter)
Paxcounter включён
Нет
Порог WiFi RSSI
ID целевого узла — последний байт в десятичном виде.
Возьмите два последних символа из HEX-ID ноды и переведите из HEX в DEC.
Пример: ID !a3f2c84e → 0x4e → 78
Конвертер HEX → DEC →
BLE RSSI порог
Режим работы: FAVORITE_ROUTER_MODE_HOPS_ONLY (10) или FAVORITE_ROUTER_MODE_HOPS_AND_RELAY (11) — см. ниже

Режимы работы (BLE RSSI порог)

10
FAVORITE_ROUTER_MODE_HOPS_ONLY
Снимает ограничение на роль предыдущего ретранслятора. Ваша нода должна быть в роутер-роли (Router, RouterLate или ClientBase), но хопы не будут уменьшаться, даже если пакет пришёл от Client или любой другой роли. Работает как для собственных пакетов указанного узла, так и для пакетов, которые он ретранслирует.
11
FAVORITE_ROUTER_MODE_HOPS_AND_RELAY
Счётчик хопов не уменьшается и ваша нода принудительно ретранслирует все пакеты, прошедшие через указанный узел — не только его собственные, но и те, которые он сам ретранслирует. Требует роль ClientBase.
⚠️
Режим FAVORITE_ROUTER_MODE_HOPS_AND_RELAY увеличивает количество ретрансляций в сети. Используйте его осторожно — только если уверены, что целевой узел является ключевым ретранслятором и его пакеты регулярно теряются.

Установка прошивки

Прошивка устанавливается через веб-флешер — никаких специальных инструментов не нужно, только браузер на компьютере.

  1. Подключите устройство к компьютеру по USB.
  2. Откройте flasher.tmesh.ru в браузере Chrome или Edge.
  3. Следуйте инструкциям флешера.
  4. После прошивки настройте MQTT согласно инструкции в разделе «Настройка шлюза».
ℹ️
Исходный код прошивки доступен на GitHub.