From b435a38092ba0c774fdd0db3861f3cfb7efb74c7 Mon Sep 17 00:00:00 2001 From: Kalle <15094562+ThatKalle@users.noreply.github.com> Date: Wed, 26 Feb 2025 18:39:36 +0100 Subject: [PATCH 1/2] sekunder och tidszon --- content/sv/docs/settings.md | 49 +++++++++++++++++++------------------ 1 file changed, 25 insertions(+), 24 deletions(-) diff --git a/content/sv/docs/settings.md b/content/sv/docs/settings.md index b217176..3a61171 100644 --- a/content/sv/docs/settings.md +++ b/content/sv/docs/settings.md @@ -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 %}}) \ No newline at end of file +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 %}}) \ No newline at end of file From 17cdc20943f5b6e33dbb6fb46160b0984f38646a Mon Sep 17 00:00:00 2001 From: Kalle <15094562+ThatKalle@users.noreply.github.com> Date: Wed, 26 Feb 2025 18:42:15 +0100 Subject: [PATCH 2/2] uppdaterat textformattering --- content/sv/docs/device_role.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/sv/docs/device_role.md b/content/sv/docs/device_role.md index d842ff4..fefe655 100644 --- a/content/sv/docs/device_role.md +++ b/content/sv/docs/device_role.md @@ -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. \ No newline at end of file