Kompleksowa konfiguracja urządzeń Meshtastic
Strategia dla dużego miasta (Warszawa) i małego miasteczka w Polsce
Meshtastic to system komunikacji mesh działający w paśmie 868 MHz, który w Polsce zyskuje coraz większą popularność – zarówno w dużych aglomeracjach jak Warszawa, jak i w małych miastach 5–20 tys. mieszkańców.
Jednak ta sama konfiguracja nie sprawdzi się wszędzie.
To, co działa w gęstej zabudowie bloków, będzie nieoptymalne w małym miasteczku z jednym kościołem i kilkoma wysokimi punktami.
Ten artykuł to praktyczny, rozbudowany przewodnik po:
- Rolach urządzeń (Device Role)
- Trybach retransmisji (Rebroadcast Mode)
- Oszczędzaniu energii
- Konfiguracjach GPIO
- Ustawieniach NodeInfo i czasu
- Strategii budowy sieci w dużym i małym ośrodku
1. Device Configuration – co naprawdę kontrolujesz?
Konfiguracja urządzenia w Meshtastic obejmuje:
- Role (Rola urządzenia)
- Rebroadcast Mode (Tryb retransmisji)
- GPIO dla przycisku
- GPIO dla buzzera
- NodeInfo Broadcast Seconds
- Double Tap as Button
- Disable Triple Click
- TZDEF (strefa czasowa)
- LED Heartbeat Disabled
- Power Saving (ESP32)
- Parametry uśpienia
Każda z tych opcji ma inne znaczenie w Warszawie niż w małym miasteczku.
2. Role urządzeń – analiza praktyczna
CLIENT – klasyczny użytkownik
Opis:
Standardowa rola. Forwarduje pakiety tylko gdy nikt inny tego nie zrobił.
Warszawa
W dużym mieście:
- często działa wiele routerów
- jest wysoka gęstość węzłów
- eter jest obciążony
👉 CLIENT jest dobry dla użytkowników mobilnych.
Nie powinno się robić z niego infrastruktury.
Małe miasteczko
Tutaj CLIENT często:
- staje się głównym przekaźnikiem
- wspiera budowę zasięgu
W małej sieci forwarding przez klienta bywa kluczowy.
CLIENT_MUTE – minimalizacja ruchu
Nie retransmituje pakietów.
Warszawa
Bardzo zalecany dla:
- urządzeń EDC
- telefonów
- urządzeń kieszonkowych
Zmniejsza:
- kolizje
- zużycie baterii
- zapychanie airtime
Małe miasteczko
Często nieopłacalny.
Każdy forwarding ma znaczenie.
CLIENT_HIDDEN – tryb dyskretny
Nadaje tylko gdy musi.
Nie pojawia się w liście węzłów.
Warszawa
Idealny dla:
- urządzeń testowych
- instalacji balkonowych
- node’ów niskiej mocy
Małe miasteczko
Dobrze sprawdza się:
- w solar node
- przy bardzo oszczędnej pracy
CLIENT_BASE – prywatna stacja bazowa
Zawsze forwarduje pakiety ulubionych węzłów.
Warszawa
To najlepsza rola dla:
- node’a na strychu
- anteny dachowej
- prywatnego „mini-routera”
Strategia:
- Twoje mobilne → CLIENT_MUTE
- Node na dachu → CLIENT_BASE
To ogranicza obciążenie całej sieci.
Małe miasteczko
Może pełnić rolę pół-infrastrukturalną.
Często zastępuje ROUTER.
TRACKER
Nadaje pozycję GPS jako priorytet.
Warszawa
Używać ostrożnie.
Częste broadcasty GPS mogą:
- obciążać sieć
- zwiększać kolizje
Dobrze ustawić dłuższy interval.
Małe miasteczko
Świetne rozwiązanie dla:
- OSP
- turystyki
- wypraw terenowych
LOST_AND_FOUND
Nadaje lokalizację cyklicznie na kanał domyślny.
W praktyce:
- działa tylko tam, gdzie istnieje aktywna sieć
- bez routerów – nieskuteczny
SENSOR
Nadaje telemetrię jako priorytet.
Warszawa
Ustaw interwał rozsądnie (np. 10–30 min).
Zbyt częste raporty = problem dla sieci.
Małe miasteczko
Można pozwolić sobie na większą częstotliwość.
TAK i TAK_TRACKER
Role dedykowane do integracji z systemem ATAK.
W Polsce używane głównie w środowiskach:
- SAR
- eksperymentalnych
- taktycznych
W mieście – redukują zbędne broadcasty.
W małych miejscowościach – rzadziej potrzebne.
REPEATER
Forwarduje raz.
Nie widać go w topologii.
Warszawa
Idealny:
- na dachach
- na wysokich blokach
- w punktach strategicznych
Nie zaśmieca listy node’ów.
Małe miasteczko
Jeden repeater w najwyższym punkcie może pokryć całe miasto.
ROUTER
Pełnoprawna infrastruktura.
Warszawa
Powinny być:
- 3–10 routerów w różnych dzielnicach
- anteny 5–8 dBi
- stałe zasilanie
Małe miasteczko
Często wystarczy jeden dobrze umieszczony router.
ROUTER_LATE
Forwarduje po innych rolach.
Warszawa
Idealny do:
- wypełniania dziur
- osiedlowych klastrów
- balkonowych instalacji
Nie dominuje sieci.
Małe miasteczko
Rzadko potrzebny – klasyczny ROUTER wystarczy.
3. Rebroadcast Mode – kontrola ruchu
Opcja decyduje, jakie pakiety urządzenie retransmituje.
ALL (domyślny)
Forwarduje wszystko, nawet inne meshe.
👉 W Warszawie może powodować niepotrzebny ruch.
ALL_SKIP_DECODING (Repeater)
Forward bez dekodowania.
Najlepsze dla czystej infrastruktury.
LOCAL_ONLY
Forward tylko lokalnego mesha.
👉 Idealne dla:
- dużego miasta
- sieci prywatnych
KNOWN_ONLY
Forward tylko znanych węzłów.
👉 Bardzo dobre dla:
- zamkniętych społeczności
- prywatnych meshów
NONE
Brak retransmisji.
Działa jak CLIENT_MUTE.
CORE_PORTNUMS_ONLY
Forward tylko podstawowych typów danych.
Świetne w Warszawie, by:
- odciąć eksperymentalne porty
- ograniczyć TAK / RangeTest
4. Power Saving – ogromna różnica między ESP32 a NRF52
ESP32
Większość ról może przechodzić w:
- light sleep
- deep sleep
Radio LoRa zostaje w standby (oprócz TRACKER i SENSOR).
W Warszawie
Power Saving:
- bardzo ważny
- zmniejsza interferencje
- poprawia kulturę sieci
W małym miasteczku
Można pozwolić sobie na mniejsze restrykcje.
TRACKER i SENSOR – specjalny tryb
W tych rolach:
- radio nie nasłuchuje w sleep
- urządzenie budzi się tylko do transmisji
To czyni je idealnymi dla solar node.
5. NodeInfo Broadcast Seconds
To interwał wysyłania informacji o węźle.
Warszawa
Ustaw dłuższy (np. 10800 sek).
Nie ma potrzeby częstych broadcastów.
Małe miasteczko
Można ustawić krótszy – sieć jest mniejsza.
6. TZDEF – strefa czasowa
Dla Polski:
CET-1CEST,M3.5.0,M10.5.0/3
To zapewnia:
- poprawne logi
- poprawny czas na ekranie
7. GPIO – przycisk i buzzer
W małym mieście często buduje się własne node’y – wtedy:
- GPIO Button – np. alarm
- PWM Buzzer – sygnał przy wiadomości
W Warszawie rzadziej używane w infrastrukturze.
8. Strategia dla Warszawy
Optymalny podział:
Użytkownicy:
- CLIENT_MUTE
- CLIENT
Balkony / dachy prywatne:
- CLIENT_BASE
- ROUTER_LATE
Infrastruktura:
- ROUTER
- REPEATER
Rebroadcast:
- LOCAL_ONLY lub CORE_PORTNUMS_ONLY
Cel:
- minimalizacja airtime
- kontrola ruchu
- stabilność
9. Strategia dla małego miasteczka
Prosty model:
1 główny ROUTER wysoko
1 REPEATER
Użytkownicy jako CLIENT
Sensory jako SENSOR
Rebroadcast:
- ALL lub LOCAL_ONLY
Cel:
- maksymalny zasięg
- budowa podstawowej siatki
- mniej restrykcyjna kontrola ruchu
10. Najczęstsze błędy
❌ Każdy jako ROUTER
❌ Krótkie interwały GPS w mieście
❌ ALL w gęstej sieci
❌ Zbyt częste NodeInfo
Podsumowanie
Rola urządzenia w Meshtastic to nie tylko „tryb pracy”.
To decyzja wpływająca na:
- stabilność sieci,
- zużycie energii,
- kulturę radiową,
- zasięg całej społeczności.
W Warszawie kluczowe jest zarządzanie ruchem.
W małym miasteczku – maksymalizacja zasięgu.
