iarv/mc-webui
1
0
Fork 1
mirror of https://github.com/MarekWo/mc-webui.git synced 2026-03-28 17:42:45 +01:00
Code Issues Packages Projects Releases Wiki Activity

chore: Remove outdated documentation files for channels, limits, meshcore-cli, and smart refresh feature

Browse Source
This commit is contained in:
MarekWo
2025-12-24 11:02:42 +01:00
parent 2e6d09421e
commit 78c59f6bc7
4 changed files with 0 additions and 586 deletions
Download Patch File Download Diff File Expand all files Collapse all files

72
technotes/channels.md
View File

@@ -1,72 +0,0 @@
## Pytanie do Gemini:
```
Jak działają kanały meshcore? Załóżmy, że dodam nowy kanał:
$ meshcli -s /dev/serial/by-id/usb-Espressif_Systems_heltec_wifi_lora_32_v4__16_MB_FLASH__2_MB_PSRAM__90706984A000-if00 add_channel Malopolska
INFO:meshcore:Serial Connection started
INFO:meshcore:Connected to MarWoj running on a v1.11.0-6d32193 fw.
INFO:meshcore:Executing device init script : /home/marek/.config/meshcore/MarWoj.init
Potem widzę ten kanał za pomocą komenendy get_channels:
$ meshcli -s /dev/serial/by-id/usb-Espressif_Systems_heltec_wifi_lora_32_v4__16_MB_FLASH__2_MB_PSRAM__90706984A000-if00 get_channels
INFO:meshcore:Serial Connection started
INFO:meshcore:Connected to MarWoj running on a v1.11.0-6d32193 fw.
INFO:meshcore:Executing device init script : /home/marek/.config/meshcore/MarWoj.init
0: Public [8b3387e9c5cdea6ac9e5edbaa115cd72]
1: Malopolska [485af7e164459d280d8818d9c99fb30d]
W jaki sposób mogę użyć kanału? Jak zaprosić do niego innych użytkowników?
```
## Odpowiedź
To, co zrobiłeś, to stworzenie **prywatnego, szyfrowanego "pokoju"**. W świecie MeshCore (i ogólnie LoRa) kanały nie działają jak grupy na Facebooku czy Discordzie, gdzie klikasz "zaproś". Tutaj kluczem do wspólnej rozmowy jest **wspólny klucz kryptograficzny**.
Oto instrukcja, jak korzystać z nowego kanału i jak "wpuścić" do niego znajomych, oparta na dokumentacji `meshcore-cli`.
### 1. Jak używać kanału? (Wysyłanie wiadomości)
Masz teraz dwa kanały:
* **0: Public** (Otwarty dla wszystkich).
* **1: Malopolska** (Twój prywatny, szyfrowany).
Aby napisać wiadomość na nowym kanale, masz dwie metody:
**Metoda A: Tryb interaktywny (Zalecana)**
Będąc w trybie czatu (`mc chat` lub po prostu uruchomieniu bez argumentów), musisz przełączyć się na ten kanał komendą `to`.
```bash
to Malopolska
```
(lub `to 1`, jeśli nazwa nie zadziała).
Od teraz wszystko, co wpiszesz i zatwierdzisz Enterem, poleci na kanał "Malopolska". Aby wrócić na ogólny, wpisz `to Public` lub `to 0`.
**Metoda B: "Z zewnątrz" (One-Liner)**
Jeśli chcesz wysłać szybką wiadomość bez wchodzenia w tryb czatu, użyj komendy `chan` z numerem kanału:
```bash
meshcli chan 1 "Cześć, to test kanału Malopolska"
```
### 2. Jak zaprosić innych użytkowników?
To najważniejszy punkt. Ponieważ MeshCore jest siecią zdecentralizowaną, nie ma serwera, który wyśle zaproszenie. Musisz **ręcznie przekazać klucz** swojemu rozmówcy inną drogą (np. SMSem, na Signal, czy podając kartkę z kodem).
Klucz Twojego kanału to ten ciąg znaków w nawiasie kwadratowym, który pokazał Ci się w logu:
`485af7e164459d280d8818d9c99fb30d`
**Instrukcja dla Twojego znajomego:**
Twój kolega musi skonfigurować swój kanał nr 1 (lub inny wolny slot) tak, aby miał **identyczną nazwę i identyczny klucz**. Jeśli użyje samej komendy `add_channel`, jego radio wygeneruje losowy klucz i nie będziecie się słyszeć (zobaczy tylko "krzaki" lub nic).
Musi użyć komendy `set_channel`, która przyjmuje format: `set_channel <numer> <nazwa> <klucz>`.
Niech Twój znajomy wpisze u siebie:
```bash
set_channel 1 Malopolska 485af7e164459d280d8818d9c99fb30d
```
### Podsumowanie techniczne
* **Szyfrowanie:** Tylko radia posiadające ten konkretny klucz (`485af...`) będą w stanie odszyfrować treść wiadomości. Dla wszystkich innych użytkowników sieci pakiety te będą wyglądać jak cyfrowy szum i zostaną zignorowane.
* **Numer slotu:** Nie ma znaczenia, czy Ty masz ten kanał na pozycji `1`, a kolega na pozycji `2`. Ważne, aby **nazwa** i **klucz** były identyczne.
* **Zasięg:** Kanały prywatne nadal korzystają z "floodingu", więc wiadomości będą przenoszone przez repeatery, ale repeatery nie będą w stanie podejrzeć ich treści.

53
technotes/limity.md
View File

@@ -1,53 +0,0 @@
W **MeshCore** obowiązuje **dość rygorystyczny limit długości pojedynczej wiadomości**, wynikający bezpośrednio z ograniczeń LoRa.
### 🔹 Limit długości wiadomości
* **Maksymalnie ~200–240 bajtów payloadu**
* W praktyce **bezpiecznie przyjmuj ~180–200 bajtów**, bo część danych zajmują:
* nagłówki protokołu MeshCore,
* adresowanie,
* metadane routingu,
* CRC / kontrola integralności.
To oznacza:
* **kilkadziesiąt znaków tekstu** (zależnie od kodowania),
* raczej **krótkie komunikaty**, nie „SMS-y” ani tym bardziej bloki tekstu.
### 🔹 Co się dzieje przy dłuższej wiadomości?
* MeshCore **tnie ją na fragmenty (fragmentation)**,
* fragmenty są wysyłane osobno i składane u odbiorcy,
* **każdy fragment zwiększa czas transmisji i ryzyko utraty**, szczególnie:
* przy niskim SF,
* w zatłoczonej sieci,
* na dalekich hopach.
Dlatego:
> **zalecenie praktyczne:** traktuj MeshCore jak **pager / radio tekstowe**, a nie komunikator.
### 🔹 Porównanie (dla intuicji)
* 1 znak ASCII ≈ 1 bajt
* 180 bajtów ≈
* ~180 znaków ASCII
* ~90–120 znaków UTF-8 (polskie znaki, emoji → szybciej zjadają limit)
### 🔹 Dobre praktyki
* używaj **krótkich, rzeczowych komunikatów**,
* unikaj emoji i znaków narodowych, jeśli zasięg/stabilność jest krytyczna,
* jeśli musisz przesłać więcej danych:
* podziel treść logicznie (kilka wiadomości),
* rozważ **out-of-band** (np. MeshCore tylko do „powiadomień”).
Jeśli chcesz, mogę:
* rozpisać **dokładną strukturę ramki MeshCore (ile bajtów na co)**,
* porównać to z **Meshtastic** (tam limity są trochę inne),
* albo pomóc dobrać **SF/BW/CR**, żeby fragmentacja była możliwie bezpieczna.

342
technotes/meshcore-cli.md
View File

@@ -1,342 +0,0 @@
# meshcore-cli
meshcore-cli : CLI interface to MeschCore companion app over BLE, TCP or Serial
## About
meshcore-cli is a tool that connects to your companion radio node (meshcore client) over BLE, TCP or Serial and lets you interact with it from a terminal using a command line interface.
You can send commands as parameters to the meshcore-cli command (from your shell) either interactively or through a script.
There is also an interactive mode (this is the default when no command is passed). In interactive mode you can enter a contact (another client a repeater, a sensor or a room) and interact with it. For clients, interaction consists in sending/receiving messages. For repeaters, rooms or sensors it will directly give you the remote cli (you can still send messages to rooms using double quote prefix or msg command).
Note that meshcore-cli only interacts with companion radios (through BLE, Serial or TCP), you can't connect to a repeater using its serial interface.
Also, most meshcore companions only have one interface compiled in at a time. So you can't connect via Serial to a node, which has been compiled as a BLE companion.
## Install
Meshcore-cli depends on the [python meshcore](https://github.com/fdlamotte/meshcore_py) package. You can install both via `pip` or `pipx` using the command:
<pre>
$ pipx install meshcore-cli
</pre>
It will install you `meshcore-cli` and `meshcli`, which is an alias to the former.
You can use the flake under [nix](https://nixos.org/):
<pre>
$ nix run github:meshcore-dev/meshcore-cli#meshcore-cli
</pre>
If you want meshcore-cli to remember last BLE device, you should have some `$HOME/.config/meshcore` where configuration for meschcore-cli will be stored (if not it will use first device it finds).
## Usage
<pre>
$ meshcli &lt;args&gt; &lt;commands&gt;
</pre>
If using BLE, don't forget to pair your device first (using `bluetoothctl` for instance on Linux) or meshcli won't be able to communicate. There is a device selector for BLE, you'll just have to use `meshcli -S` to select your device, subsequent calls to meshcli will be send to that device.
### Configuration
Configuration files are stored in `$HOME/.config/meshcore`
If the directory exists, default ble address and history will be stored there.
If there is an initialization script file called `init`, it will be executed just before the commands provided on command line are executed (and after evaluation of the arguments).
Init files can also be defined for a given device, meshcore-cli will look for `&lt;device-name>.init` file in configuration directory (usefull to specify timeout for contacts that are behind bridges with `contact_timeout` command).
### Arguments
Arguments mostly deals with connection to the node
<pre>
-h : prints this help
-v : prints version
-j : json output (disables init file)
-D : debug
-S : scan for devices and show a selector
-l : list available ble/serial devices and exit
-T &lt;timeout&gt; : timeout for the ble scan (-S and -l) default 2s
-a &lt;address&gt; : specifies device address (can be a name)
-d &lt;name&gt; : filter meshcore devices with name or address
-P : forces pairing via the OS
-t &lt;hostname&gt; : connects via tcp/ip
-p &lt;port&gt; : specifies tcp port (default 5000)
-s &lt;port&gt; : use serial port &lt;port&gt;
-b &lt;baudrate&gt; : specify baudrate
-C : toggles classic mode for prompt
-c &lt;on/off&gt; : disables most of color output if off
</pre>
### Available Commands
Commands are given after arguments, they can be chained and some have shortcuts. Also prefixing a command with a dot `.` will force it to output json instead of synthetic result.
<pre>
?&lt;cmd&gt; may give you some more help about cmd
General commands
chat : enter the chat (interactive) mode
chat_to &lt;ct&gt; : enter chat with contact to
script &lt;filename&gt; : execute commands in filename
infos : print informations about the node i
self_telemetry : print own telemtry t
card : export this node URI e
ver : firmware version v
reboot : reboots node
sleep &lt;secs&gt; : sleeps for a given amount of secs s
wait_key : wait until user presses &lt;Enter&gt; wk
apply_to &lt;f&gt; &lt;cmds&gt; : sends cmds to contacts matching f at
Messaging
msg &lt;name&gt; &lt;msg&gt; : send message to node by name m {
wait_ack : wait an ack wa }
chan &lt;nb&gt; &lt;msg&gt; : send message to channel number &lt;nb&gt; ch
public &lt;msg&gt; : send message to public channel (0) dch
recv : reads next msg r
wait_msg : wait for a message and read it wm
sync_msgs : gets all unread msgs from the node sm
msgs_subscribe : display msgs as they arrive ms
get_channels : prints all channel info
get_channel &lt;n&gt; : get info for channel (by number or name)
set_channel n nm k : set channel info (nb, name, key)
remove_channel &lt;n&gt; : remove channel (by number or name)
scope &lt;s&gt; : sets node's flood scope
Management
advert : sends advert a
floodadv : flood advert
get &lt;param&gt; : gets a param, \"get help\" for more
set &lt;param&gt; &lt;value&gt; : sets a param, \"set help\" for more
time &lt;epoch&gt; : sets time to given epoch
clock : get current time
clock sync : sync device clock st
node_discover &lt;filter&gt; : discovers nodes based on their type nd
Contacts
contacts / list : gets contact list lc
reload_contacts : force reloading all contacts rc
contact_info &lt;ct&gt; : prints information for contact ct ci
contact_timeout &lt;ct&gt; v : sets temp default timeout for contact
share_contact &lt;ct&gt; : share a contact with others sc
export_contact &lt;ct&gt; : get a contact's URI ec
import_contact &lt;URI&gt; : import a contact from its URI ic
remove_contact &lt;ct&gt; : removes a contact from this node
path &lt;ct&gt; : diplays path for a contact
disc_path &lt;ct&gt; : discover new path and display dp
reset_path &lt;ct&gt; : resets path to a contact to flood rp
change_path &lt;ct&gt; &lt;pth&gt; : change the path to a contact cp
change_flags &lt;ct&gt; &lt;f&gt; : change contact flags (tel_l|tel_a|star)cf
req_telemetry &lt;ct&gt; : prints telemetry data as json rt
req_mma &lt;ct&gt; : requests min/max/avg for a sensor rm
req_acl &lt;ct&gt; : requests access control list for sensor
pending_contacts : show pending contacts
add_pending &lt;pending&gt; : manually add pending contact
flush_pending : flush pending contact list
Repeaters
login &lt;name&gt; &lt;pwd&gt; : log into a node (rep) with given pwd l
logout &lt;name&gt; : log out of a repeater
cmd &lt;name&gt; &lt;cmd&gt; : sends a command to a repeater (no ack) c [
wmt8 : wait for a msg (reply) with a timeout ]
req_status &lt;name&gt; : requests status from a node rs
req_neighbours &lt;name&gt; : requests for neighbours in binary form rn
trace &lt;path&gt; : run a trace, path is comma separated
</pre>
### Interactive Mode
aka Instant Message or chat mode ...
Chat mode lets you interactively interact with your node or remote nodes. It is automatically triggered when no option is given on the command line.
You'll get a prompt with the name of your node. From here you can type meshcore-cli commands. The prompt has history and a basic completion (pressing tab will display possible command or argument options).
The `to` command is specific to chat mode, it lets you enter the recipient for next command. By default you're on your node but you can enter other nodes or public rooms. Here are some examples :
- `to <dest>` : will enter dest (node or channel)
- `to /`, `to ~` : will go to the root (your node)
- `to ..` : will go to the last node (it will switch between the two last nodes, this is just a 1-depth history)
- `to !` : will switch to the node you received last message from
When you are in a node, the behaviour will depend on the node type, if you're on a chat node, it will send messages by default and you can chat. On a repeater or a room server, it will send commands (autocompletion has been set to comply with the CommonCli class of meshcore). To send a message through a room you'll have to prefix the message with a quote or use the send command.
The `/` character is used to bypass the node you have currently selected using `to`:
- `/<cmd>` issues cmd command on the root
- `/<node>/<cmd>` will send cmd to selected node
- `/<dest> <msg>` will send msg to dest (channel or node)
#### Flood Scope in interactive mode
Flood scope has recently been introduced in meshcore (from `v1.10.0`). It limits the scope of packets to regions, using transport codes in the frame.
When entering chat mode, scope will be reset to `*`, meaning classic flood.
You can switch scope using the `scope` command, or postfixing the `to` command with `%<scope>`.
Scope can also be applied to a command using `%` before the scope name. For instance `login%#Morbihan` will limit diffusion of the login command (which is usually sent flood to get the path to a repeater) to the `#Morbihan` region.
#### Channel echoes
It's sometimes interesting to know the path taken by a message received from a channel or which repeaters have repeated a sent message.
The app give you the information by listening `rx_log` from the device, when obtained the information is attached to the message and can be read.
In meshcore-cli I went lower-level by implementing channel echoes. When activated (with `/set channel_echoes on`), all the channel messages will be printed on the terminal along with the SNR and path taken. When sending a message, you'll have all the repeats from 0-hop repeaters as echoes, and when a message is received, you should see information about the received message, but also all the instances of the same message that might have reached you from another path.
In the example below, a msg has been sent between two repeaters, 21 and 25. 25 repeated the message and 21 the repeat and both echoes came back to the node with different SNRs.
```
f1down/#fdl|*> 8
#fdl f1down: 8 [25] -4.75-112
#fdl f1down: 8 [2521] 1.00-109
```
### Contact management
To receive a message from another user, it is necessary to have its public key. This key is stored on a contact list in the device, and this list has a finite size (50 when meshcore started, now over 350 for most devices).
By default contacts are automatically added to the device contact list when an advertisement is received, so as soon as you receive an advert, you can talk with your buddy.
With growing number of users, it becomes necessary to manage contact list and one of the ways is to add contacts manually to the device. This is done by turning on `manual_add_contacts`. Once this option has been turned on, a pending list is built by meshcore-cli from the received adverts. You can view the list issuing a `pending_contacts` command, flush the list using `flush_pending` or add a contact from the list with `add_pending` followed by the key of the contact or its name (both will be auto-completed with tab).
This feature only really works in interactive mode.
Note: There is also an `auto_update_contacts` setting that has nothing to do with adding contacts, it permits to automatically sync contact lists between device and meshcore-cli (when there is an update in name, location or path).
### Issuing batch commands to contacts with apply to
`apply_to <f> <cmd>` : applies cmd to contacts matching filter `<f>` it can be used to apply the same command to a pool of repeaters, or remove some contacts matching a condition.
Filter is constructed with comma separated fields :
- `u`, matches modification time `<` or `>` than a timestamp (can also be days hours or minutes ago if followed by `d`,`h` or `m`)
- `t`, matches the type (1: client, 2: repeater, 3: room, 4: sensor)
- `h`, matches number of hops
- `d`, direct, similar to `h>-1`
- `f`, flood, similar to `h<0` or `h=-1`
Commands should be written as if in interactive mode, if writing from the commandline don't forget to use commas to clearly delimit fields.
Note: Some commands like `contact_name` (aka `cn`), `reset_path` (aka `rp`), `forget_password` (aka `fp`) can be chained. There is also a `sleep` command taking an optional time parameter. The sleep will be issued after the command, it helps limiting rate through repeaters ...
#### Examples
```
# removes all clients that have not been updated in last 2 days
at u<2d,t=1 remove_contact
# gives traces to repeaters that have been updated in the last 24h and are direct
at t=2,u>1d,d cn trace
# tries to do flood login to all repeaters
at t=2 rp login
```
## Examples
<pre>
# gets info from first ble MC device it finds (was -s but now used for serial port)
$ meshcore-cli -d "" infos
INFO:meshcore:Scanning for devices
INFO:meshcore:Found device : C2:2B:A1:D5:3E:B6: MeshCore-t114_fdl
INFO:meshcore:BLE Connection started
{
"adv_type": 1,
"tx_power": 22,
"max_tx_power": 22,
"public_key": "993acd42fc779962c68c627829b32b111fa27a67d86b75c17460ff48c3102db4",
"adv_lat": 47.794,
"adv_lon": -3.428,
"radio_freq": 869.525,
"radio_bw": 250.0,
"radio_sf": 11,
"radio_cr": 5,
"name": "t114_fdl"
}
# getting time
$ meshcli -a C2:2B:A1:D5:3E:B6 clock
INFO:meshcore:BLE Connection started
Current time : 2025-04-18 08:19:26 (1744957166)
# If you're familiar with meshcli, you should have noted that
# now output is not json only, to get json output, use -j
# or prefix your commands with a dot
$ meshcli -a C2:2B:A1:D5:3E:B6 .clock
INFO:meshcore:BLE Connection started
{
"time": 1744957249
}
# Using -j, meshcli will return replies in json format ...
$ meshcli -j -a C2:2B:A1:D5:3E:B6 clock
{
"time": 1744957261
}
# So if I reboot the node, and want to set time, I can chain the commands
# and get that kind of output (even better by feeding it to jq)
$ meshcli reboot
INFO:meshcore:BLE Connection started
$ meshcli -j clock clock sync clock | jq -c
{ "time": 1715770371 }
{ "ok": "time synced" }
{ "time": 1745996105 }
# Now check if time is ok with human output (I don't read epoch time yet)
$ meshcli clock
INFO:meshcore:BLE Connection started
Current time : 2025-04-30 08:56:27 (1745996187)
# Now you'll probably want to send some messages ...
# For that, there is the msg command, wait_ack
$ meshcli msg Techo_fdl "Hello T-Echo" wa
INFO:meshcore:BLE Connection started
Msg acked
# I can check the message on the techo
$ meshcli -d Techo sm
INFO:meshcore:Scanning for devices
INFO:meshcore:Found device : DE:B6:D0:68:D5:62: MeshCore-Techo_fdl
INFO:meshcore:BLE Connection started
t114_fdl(0): Hello T-Echo
# And reply using json output for more verbosity
# here I've used jq with -cs to get a compact array
$ meshcli msg t114_fdl hello wa | jq -cs
[{"type":0,"expected_ack":"4802ed93","suggested_timeout":2970},{"code":"4802ed93"}]
# But this could have been done interactively using the chat mode
# Here from the techo side. Note that un-acked messages will be
# signaled with an ! at the start of the prompt (or red color in color mode)
$ meshcli chat
INFO:meshcore:BLE Connection started
Interactive mode, most commands from terminal chat should work.
Use "to" to selects contact, "list" to list contacts, "send" to send a message ...
Line starting with "$" or "." will issue a meshcli command.
"quit" or "q" will end interactive mode
t114_fdl(D): Hello T-Echo
EnsibsRoom> Hi
!EnsibsRoom> to t114_fdl
t114_fdl> Hi
t114_fdl(D): It took you long to reply ...
t114_fdl> I forgot to set the recipient with the to command
t114_fdl(D): It happens ...
t114_fdl>
# Loging into repeaters and sending commands is also possible
# directly from the chat, because we can use meshcli commands ;)
$ meshcli chat (pending msgs are shown at connexion ...)
INFO:meshcore:BLE Connection started
Interactive mode, most commands from terminal chat should work.
Use "to" to selects contact, "list" to list contacts, "send" to send a message ...
Line starting with "$" or "." will issue a meshcli command.
"quit" or "q" will end interactive mode
Techo_fdl(0): Cool to receive some msgs from you
Techo_fdl(D): Hi
Techo_fdl(D): I forgot to set the recipient with the to command
FdlRoom> login password
Login success
FdlRoom> clock
FdlRoom(0): 06:40 - 18/4/2025 UTC
FdlRoom>
</pre>

119
technotes/smart-refresh-feature.md
View File

@@ -1,119 +0,0 @@
# Smart Refresh & Notifications Feature
## Zaimplementowane zmiany
### 1. Inteligentne odświeżanie
- ✅ Aplikacja sprawdza nowe wiadomości co **10 sekund** (zamiast pełnego odświeżania co 60s)
- ✅ Widok czatu odświeża się **tylko gdy faktycznie pojawiają się nowe wiadomości** na aktywnym kanale
- ✅ Znacznie zmniejszone obciążenie - zamiast pobierać 500 wiadomości co minutę, sprawdzamy tylko czy są aktualizacje
### 2. System powiadomień o nieprzeczytanych wiadomościach
#### Ikona dzwoneczka 🔔
- Dodana w navbar (między przyciskiem Refresh a selektorem kanału)
- Pokazuje **globalny licznik** wszystkich nieprzeczytanych wiadomości
- Animacja dzwonka przy nowych wiadomościach
- Czerwony badge z liczbą (np. "5" lub "99+" dla >99)
#### Badge przy nazwach kanałów
- W selektorze kanału przy każdym kanale pokazuje się liczba nieprzeczytanych (np. "Malopolska (3)")
- Badge znika gdy przełączysz się na dany kanał
- Nie pokazuje się dla aktualnie otwartego kanału
### 3. Tracking przeczytanych wiadomości
- System automatycznie śledzi timestamp ostatnio przeczytanej wiadomości per kanał
- Dane zapisywane w `localStorage` (przetrwają restart przeglądarki)
- Wiadomość jest oznaczona jako przeczytana gdy:
- Jest wyświetlona w oknie czatu
- Kanał jest aktywny (otwarty)
## API Endpoint
### `GET /api/messages/updates`
Nowy endpoint do sprawdzania aktualizacji bez pobierania pełnych wiadomości.
**Query params:**
- `last_seen` - JSON object z timestampami per kanał (np. `{"0": 1234567890, "1": 1234567891}`)
**Response:**
```json
{
"success": true,
"channels": [
{
"index": 0,
"name": "Public",
"has_updates": true,
"latest_timestamp": 1234567900,
"unread_count": 5
},
{
"index": 1,
"name": "Malopolska",
"has_updates": false,
"latest_timestamp": 1234567800,
"unread_count": 0
}
],
"total_unread": 5
}
```
## Pliki zmodyfikowane
### Backend:
- `app/routes/api.py` - dodany endpoint `/api/messages/updates`
### Frontend:
- `app/static/js/app.js` - cała logika smart refresh i notyfikacji
- `app/templates/base.html` - dodana ikona dzwoneczka w navbar
- `app/static/css/style.css` - style dla badge'ów i animacji
## Jak przetestować
1. Uruchom aplikację:
```bash
docker compose up
```
2. Otwórz aplikację w przeglądarce
3. **Test 1: Inteligentne odświeżanie**
- Otwórz konsolę przeglądarki (F12)
- Obserwuj logi - co 10s pojawi się sprawdzenie aktualizacji
- Wyślij wiadomość z innego urządzenia
- Aplikacja powinna automatycznie odświeżyć widok w ciągu 10 sekund
4. **Test 2: Powiadomienia multi-channel**
- Utwórz/dołącz do drugiego kanału
- Pozostań na kanale Public
- Wyślij wiadomość na drugim kanale (z innego urządzenia)
- Po ~10 sekundach powinieneś zobaczyć:
- Czerwony badge na ikonie dzwoneczka (np. "3")
- Badge przy nazwie kanału w selektorze (np. "Malopolska (3)")
- Dzwonek powinien się lekko "zakołysać" (animacja)
5. **Test 3: Oznaczanie jako przeczytane**
- Przełącz się na kanał z nieprzeczytanymi wiadomościami
- Badge powinien natychmiast zniknąć
- Jeśli wszystkie kanały są przeczytane, dzwonek powinien być bez badge'a
6. **Test 4: Persistence**
- Odśwież stronę (F5)
- Stan przeczytanych wiadomości powinien się zachować (dzięki localStorage)
## Zalety nowego rozwiązania
1. **Wydajność** - mniejsze obciążenie serwera i sieci (lekkie sprawdzenia vs pełne pobieranie)
2. **UX** - użytkownik od razu wie gdy są nowe wiadomości na innych kanałach
3. **Optymalizacja** - odświeżanie tylko gdy jest potrzebne
4. **Responsywność** - sprawdzanie co 10s zamiast 60s = szybsze reakcje
5. **Persistence** - stan przeczytanych zachowany między sesjami
## Uwagi techniczne
- Checking interval: **10 sekund** (można zmienić w `setupAutoRefresh()`)
- Badge nie pokazuje się dla archiwów (tylko live view)
- Auto-refresh wyłączony gdy przeglądasz archiwum
- LocalStorage key: `mc_last_seen_timestamps`