mirror of
https://github.com/Roslund/sthlm-mesh.git
synced 2026-08-07 01:13:09 +02:00
Merge pull request #4 from ThatKalle/feat/settingsupdate
Uppdaterad text. Docs
This commit is contained in:
Anton Roslund
@@ -11,7 +11,7 @@ Att välja rätt roll är avgörande för ett välfungerande meshnätverk. Om en
|
||||
## Client
|
||||
`CLIENT` är _standardrollen_ för Meshtastic och fungerar bäst i de flesta fall. Det är först när nätverket blir större som det blir viktigt att noggrant välja rätt roller.
|
||||
|
||||
En nod med rollen `CLIENT` deltar aktivt i meshnätverket och vidarebefordrar meddelanden enligt en [algoritm](https://meshtastic.org/docs/overview/mesh-algo/). Förenklat innebär det att den nod som tar emot ett meddelande med svagast signal styrs att skicka det vidare. Om en Client-nod hör ett meddelande men inte uppfattar att någon annan vidarebefordrar det, kommer den själv att skicka vidare.
|
||||
En nod med rollen `CLIENT` deltar aktivt i meshnätverket och vidarebefordrar meddelanden enligt en [algoritm](https://meshtastic.org/docs/overview/mesh-algo/). Förenklat innebär det att den nod som tar emot ett meddelande med svagast signal styrs att skicka det vidare. Om en `CLIENT`-nod hör ett meddelande men inte uppfattar att någon annan vidarebefordrar det, kommer den själv att skicka vidare.
|
||||
|
||||
I teorin innebär detta att noder längre bort oftast vidarebefordrar först. Men om en `CLIENT`-nod har dålig mottagning, exempelvis om den är placerad inomhus, kan den felaktigt sända vidare innan en mer optimalt placerad nod gör det. Detta kan leda till att nätverkets _hopp_ förbrukas snabbare, vilket begränsar räckvidden.
|
||||
|
||||
@@ -20,18 +20,18 @@ Därför är det viktigt att `CLIENT`-noder i större meshnätverk placeras väl
|
||||
## Client Mute
|
||||
`CLIENT_MUTE`-rollen liknar `CLIENT` men med en viktig skillnad – den vidarebefordrar eller routar inga meddelanden. Detta gör den idealisk för större meshnätverk med hög nätverkstrafik, där extra routing kan orsaka överbelastning.
|
||||
|
||||
För de som har flera enheter på samma plats rekommenderas att **max en** enhet sätts som `CLIENT` medan resten får rollen CLIENT_MUTE för att minska onödig trafik och optimera nätverkets prestanda.
|
||||
För de som har flera enheter på samma plats rekommenderas att **max en** enhet sätts som `CLIENT` medan resten får rollen `CLIENT_MUTE` för att minska onödig trafik och optimera nätverkets prestanda.
|
||||
|
||||
I Stockholm bör portabla noder och noder man har inomhus primärt vara `CLIENT MUTE`.
|
||||
|
||||
## Router
|
||||
`ROUTER`-rollen är designad för enheter som främst ska vidarebefordra meddelanden till andra enheter på meshet. Denna roll är **ENDAST** lämplig för stationära enheter placerade på extremt strategiska platser.
|
||||
|
||||
Routrar vidarebefordrar meddelanden från andra enheter direkt, medan andra noder väntar en liten stund innan de sänder. En strategiskt placerad ROUTER kan öka både räckvidden och stabiliteten i nätverket.
|
||||
Routrar vidarebefordrar meddelanden från andra enheter direkt, medan andra noder väntar en liten stund innan de sänder. En strategiskt placerad `ROUTER` kan öka både räckvidden och stabiliteten i nätverket.
|
||||
|
||||
Routrar vidarebefordrar alltid, medan andra roller kan välja att inte vidarebefordra om de hör en granne vidarebefordra först.
|
||||
|
||||
För att optimera nätverkets prestanda och undvika kollisioner bör ROUTER-noder placeras så att **så få noder som möjligt når mer än en ROUTER samtidigt.** Detta då om ett meddelanden når flera routrar, så kommer de alla vidarebefordra meddelande samtidigt och störa ut varandra.
|
||||
För att optimera nätverkets prestanda och undvika kollisioner bör `ROUTER`-noder placeras så att **så få noder som möjligt når mer än en ROUTER samtidigt.** Detta då om ett meddelanden når flera routrar, så kommer de alla vidarebefordra meddelande samtidigt och störa ut varandra.
|
||||
|
||||
{{% alert title="Tips" color="primary" %}}
|
||||
Sänk `max_hops`. En välplacerad router når långt med bara **ett eller två hopp**. Din router bör nå en nod med MQTT uplink, så att du kan få den telemetri du behöver via [kartan](https://meshtastic.liamcottle.net/)
|
||||
@@ -42,6 +42,6 @@ Sänk `max_hops`. En välplacerad router når långt med bara **ett eller två h
|
||||
`ROUTER_LATE`-rollen är lik `ROUTER`, den vidarebefordrar alla meddelanden, men den gör det under samma tidsfönster som `CLIENT` noder. Detta kan vara mycket användbart i områden där man når ut till meshen, men har svårt att ta emot alla meddelanden.
|
||||
|
||||
## Repeater
|
||||
REPEATER-rollen fungerar liknande ROUTER-rollen, men går ett steg längre genom att enbart vidarebefordra den meddelanden den tar emot. Den skickar inte ut några paket om sig själv, tex. nod-info.
|
||||
`REPEATER`-rollen fungerar liknande `ROUTER`-rollen, men går ett steg längre genom att enbart vidarebefordra den meddelanden den tar emot. Den skickar inte ut några paket om sig själv, tex. nod-info.
|
||||
|
||||
Detta är en mycket effektiv roll. Men vi rekommenderar istället att använda `ROUTER` med optimerade inställningar, så att noden syns och registreras som en aktiv del av meshnätverket.
|
||||
+25
-24
@@ -29,33 +29,34 @@ För routrar rekommenderas det att ha ett lågt antal max hops. En välplacerad
|
||||
|
||||
## Device Configuration
|
||||
|
||||
| Inställning | Värde | Beskrivning |
|
||||
|---------------------|----------------------------|-------------|
|
||||
| Role | CLIENT_MUTE eller CLIENT | För mer info, se [enhetsroll]({{% ref device_role.md %}}) |
|
||||
| Rebroadcast Mode | ALL | Vidarebefordrar även krypterade meddelanden |
|
||||
| Node Info Broadcast | 6h | Kommer ändå skicka Node info när det efterfrågas[^3] |
|
||||
| Inställning | Värde | Beskrivning |
|
||||
|---------------------|--------------------------------|-------------|
|
||||
| Role | `CLIENT_MUTE` eller `CLIENT` | För mer info, se [enhetsroll]({{% ref device_role.md %}}) |
|
||||
| Rebroadcast Mode | ALL | Vidarebefordrar även krypterade meddelanden |
|
||||
| NodeInfo Broadcast | 6h (21600s) | Kommer ändå skicka Node info när det efterfrågas[^3] |
|
||||
| POSIX Timezone | `CET-1CEST,M3.5.0,M10.5.0/3` | Tidszon för enhetsklocka och loggar |
|
||||
|
||||
[^3]: Enheten kommer fortfarande att svara ad hoc på NodeInfo-meddelanden när det efterfrågas.
|
||||
[^3]: Enheten kommer fortfarande att svara ad hoc på NodeInfo-meddelanden när det efterfrågas.
|
||||
När en enhet hör ett paket från en nod den ännu inte känner till, kommer den att skicka sin NodeInfo och automatiskt be om ett svar.
|
||||
|
||||
## Position
|
||||
| Inställning | Värde | Beskrivning |
|
||||
|---------------------|-------|--------------------|
|
||||
| Broadcast Interval | 12h | För statiska noder |
|
||||
| Inställning | Värde | Beskrivning |
|
||||
|---------------------|----------------|--------------------|
|
||||
| Broadcast Interval | 12h (43200s) | För statiska noder |
|
||||
|
||||
Position inställningar är luriga, för mer info se [position]({{% ref position.md %}})
|
||||
|
||||
|
||||
## Telemetry
|
||||
| Inställning | Värde | Beskrivning |
|
||||
|--------------------------------|----------|--------------------|
|
||||
| Device Metrics Update Interval | 3h | Battery Level, Voltage, Channel Utilization and Airtime |
|
||||
| Environment Telemetry Enabled | false |
|
||||
| Environment Telemetry | 6h |
|
||||
| Power Metrics Enabled | false |
|
||||
| Power Metrics Interval | 6h |
|
||||
| Air Quality Enabled | false |
|
||||
| Air Quality Interval | 6h |
|
||||
| Inställning | Värde | Beskrivning |
|
||||
|--------------------------------|---------------|--------------------|
|
||||
| Device Metrics Update Interval | 3h (10800s) | Battery Level, Voltage, Channel Utilization and Airtime |
|
||||
| Environment Telemetry Enabled | false |
|
||||
| Environment Telemetry | 6h (21600s) |
|
||||
| Power Metrics Enabled | false |
|
||||
| Power Metrics Interval | 6h (21600s) |
|
||||
| Air Quality Enabled | false |
|
||||
| Air Quality Interval | 6h (21600s) |
|
||||
|
||||
|
||||
Notera att batterinivå är inkluderad i Device Metrics. Power Metrics är enbart till för externa strömsensorer, så som: [MPPT Solar Battery Charger for IoT & Meshtastic](https://www.etsy.com/listing/1609406536/mppt-solar-battery-charger-for-iot)
|
||||
@@ -64,11 +65,11 @@ Notera att batterinivå är inkluderad i Device Metrics. Power Metrics är enbar
|
||||
|
||||
|
||||
## Neighbor Info
|
||||
| Inställning | Värde |
|
||||
|---------------------|----------|
|
||||
| Enabled | True |
|
||||
| Transmit over LoRa | False |
|
||||
| Update interval | 1h |
|
||||
| Inställning | Värde |
|
||||
|---------------------|--------------|
|
||||
| Enabled | True |
|
||||
| Transmit over LoRa | False |
|
||||
| Update interval | 1h (3600s) |
|
||||
|
||||
Om en nod är är uppkopplad mot en MQTT server så kan man skicka neighbor info frekvent.
|
||||
Om man vill skicka neighbor info över LoRa så bör man inte skicka oftare än var 12:e timme. Dock så är detta begränsat i firmware. För mer detaljer se [Neighbor Info]({{% ref neighbor_info.md %}})
|
||||
Om man vill skicka neighbor info över LoRa så bör man inte skicka oftare än var 12:e timme (43200s). Dock så är detta begränsat i firmware. För mer detaljer se [Neighbor Info]({{% ref neighbor_info.md %}})
|
||||
Reference in New Issue
Block a user