` 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
-
-
-# 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>
-
\ No newline at end of file
diff --git a/technotes/pending-contacts-api.md b/technotes/pending-contacts-api.md
deleted file mode 100644
index 8b8ed94..0000000
--- a/technotes/pending-contacts-api.md
+++ /dev/null
@@ -1,515 +0,0 @@
-# Pending Contacts API - Technical Notes
-
-## Overview
-
-This document describes the implementation of pending contacts management API in `meshcore-bridge`. This feature enables manual approval of new contacts when `manual_add_contacts` mode is enabled in meshcli.
-
-**Branch**: `dev-2`
-**Status**: Implemented β
(API only, no UI yet)
-**Date**: 2025-12-29
-
-## Problem Statement
-
-When meshcli runs with `manual_add_contacts on`, new contacts attempting to connect are placed in a "pending" state instead of being automatically added to the contacts list. This provides security benefits:
-
-- **Control over network access** - Only approved contacts can communicate with the node
-- **Prevention of spam/unwanted contacts** - Filter out random nodes attempting connection
-- **Explicit trust model** - User decides who to trust on the mesh network
-
-However, managing pending contacts required manual meshcli commands, which was inconvenient for web interface users.
-
-## Solution
-
-Added two new HTTP endpoints to `meshcore-bridge` for programmatic pending contact management:
-
-1. **`GET /pending_contacts`** - List all contacts awaiting approval
-2. **`POST /add_pending`** - Approve and add a specific pending contact
-
-Both endpoints use the existing persistent meshcli session architecture (no new processes spawned).
-
-## Implementation Details
-
-### 1. Session Initialization
-
-Modified `_init_session_settings()` in [meshcore-bridge/bridge.py:122-136](meshcore-bridge/bridge.py#L122-L136) to enable manual contact approval:
-
-```python
-def _init_session_settings(self):
- """Configure meshcli session for advert logging, message subscription, and manual contact approval"""
- if self.process and self.process.stdin:
- self.process.stdin.write('set json_log_rx on\n')
- self.process.stdin.write('set print_adverts on\n')
- self.process.stdin.write('set manual_add_contacts on\n') # NEW
- self.process.stdin.write('msgs_subscribe\n')
- self.process.stdin.flush()
-```
-
-**Why in init?**
-- Persistent setting - applies to entire session lifetime
-- No need to re-enable after watchdog restart
-- Consistent behavior across all API calls
-
-### 2. GET /pending_contacts Endpoint
-
-**Location**: [meshcore-bridge/bridge.py:499-565](meshcore-bridge/bridge.py#L499-L565)
-
-**Purpose**: Retrieve list of contacts awaiting manual approval
-
-**Request**:
-```http
-GET /pending_contacts HTTP/1.1
-Host: meshcore-bridge:5001
-```
-
-**Response** (success):
-```json
-{
- "success": true,
- "pending": [
- {
- "name": "Skyllancer",
- "public_key": "f9ef123abc456..."
- },
- {
- "name": "KRA Reksio mob2π",
- "public_key": "41d5789def012..."
- }
- ],
- "raw_stdout": "Skyllancer: f9ef123abc456...\nKRA Reksio mob2π: 41d5789def012..."
-}
-```
-
-**Response** (no pending contacts):
-```json
-{
- "success": true,
- "pending": [],
- "raw_stdout": ""
-}
-```
-
-**Response** (error):
-```json
-{
- "success": false,
- "error": "meshcli session not initialized",
- "pending": []
-}
-```
-
-**Implementation Notes**:
-
-- Executes `pending_contacts` command via `MeshCLISession.execute_command()`
-- Parses meshcli output format: `"ContactName: "`
-- Removes spaces from public key hex (meshcli may insert spaces for readability)
-- Only parses lines containing colon `:`
-- Trims whitespace from contact names
-- Returns empty array if no pending contacts exist
-- Includes `raw_stdout` for debugging/troubleshooting
-
-**Parsing Logic**:
-```python
-for line in stdout.split('\n'):
- line = line.strip()
- if ':' in line:
- parts = line.split(':', 1)
- if len(parts) == 2:
- name = parts[0].strip()
- public_key = parts[1].strip().replace(' ', '')
- if name and public_key:
- pending.append({'name': name, 'public_key': public_key})
-```
-
-### 3. POST /add_pending Endpoint
-
-**Location**: [meshcore-bridge/bridge.py:568-629](meshcore-bridge/bridge.py#L568-L629)
-
-**Purpose**: Approve and add a pending contact to the contacts list
-
-**Request**:
-```http
-POST /add_pending HTTP/1.1
-Host: meshcore-bridge:5001
-Content-Type: application/json
-
-{
- "selector": "Skyllancer"
-}
-```
-
-**Selector formats supported** (by meshcli):
-- Full contact name: `"Skyllancer"` (works for CLI contacts)
-- Public key prefix: `"f9ef123"` (works for CLI contacts, may not work for ROOM)
-- Full public key: `"f9ef123abc456..."` (**RECOMMENDED - works for all contact types**)
-
-**Response** (success):
-```json
-{
- "success": true,
- "stdout": "Contact added successfully",
- "stderr": "",
- "returncode": 0
-}
-```
-
-**Response** (validation error):
-```json
-{
- "success": false,
- "stdout": "",
- "stderr": "selector must be a non-empty string",
- "returncode": -1
-}
-```
-
-**Implementation Notes**:
-
-- Validates `selector` is non-empty string
-- Trims whitespace from selector before execution
-- Executes `add_pending ` command via persistent session
-- Returns full command result (stdout, stderr, returncode)
-- Uses default timeout (10 seconds)
-
-**Validation**:
-```python
-if not isinstance(selector, str) or not selector.strip():
- return jsonify({
- 'success': False,
- 'stderr': 'selector must be a non-empty string',
- 'returncode': -1
- }), 400
-```
-
-### Important Discovery: Contact Type Differences
-
-**π Testing revealed different behavior for different contact types:**
-
-#### CLI Contacts (Clients)
-**Examples**: `StNMobile T1000e`, `ML2056`, `olekstomek`
-
-β
**All selector formats work:**
-- Full name: `"StNMobile T1000e"` β **SUCCESS**
-- Name prefix: `"StN"` β **SUCCESS**
-- Public key prefix: `"2ce5514"` β **SUCCESS**
-- Full public key: `"2ce5514826d39a44d23eb8eb9539676b57cae234528573c45d44bdd6ed01eeb5"` β **SUCCESS**
-
-#### ROOM Contacts (Group Rooms)
-**Examples**: `TK room cwiczebnyπ`
-
-β **Name-based selectors DO NOT work:**
-- Full name: `"TK room cwiczebnyπ"` β **FAILED** (also UTF-8 encoding issues in shell)
-- Name prefix: `"TK room"` β **FAILED**
-
-β **Public key prefix DOES NOT work:**
-- Prefix: `"b3fec489"` β **FAILED**
-
-β
**Only FULL public key works:**
-- Full public key: `"b3fec489e1ee2d0277bd16de957253c8f5aa44a721df722224bbdc1edc5829b6"` β **SUCCESS**
-
-#### Root Cause Analysis
-
-The `add_pending` command in meshcli appears to use different matching logic for different contact types:
-
-- **CLI contacts**: Flexible matching - accepts name prefix, key prefix, or full key
-- **ROOM contacts**: Strict matching - requires exact full public key
-
-This may be intentional behavior to prevent accidental approval of group rooms, which have different security/privacy implications than individual client contacts.
-
-#### Recommendation for UI Implementation
-
-**Always use full public key for `add_pending` calls:**
-
-```javascript
-// Good - works for all contact types
-fetch('/add_pending', {
- method: 'POST',
- body: JSON.stringify({
- selector: pendingContact.public_key // Full key from GET /pending_contacts
- })
-})
-
-// Bad - may fail for ROOM contacts
-fetch('/add_pending', {
- method: 'POST',
- body: JSON.stringify({
- selector: pendingContact.name // Won't work for ROOMs
- })
-})
-```
-
-**UI Design Consideration:**
-
-Since `GET /pending_contacts` already returns both `name` and `public_key`, the UI should:
-1. Display human-readable name for user
-2. **Send full public_key to API** (not name)
-3. This ensures compatibility with all contact types
-
-Example UI flow:
-```
-User sees: "TK room cwiczebnyπ" [Approve button]
-User clicks: Approve
-Frontend sends: {"selector": "b3fec489e1ee...5829b6"} β Full public key
-```
-
-## Testing
-
-### Prerequisites
-
-The bridge container must have:
-1. `manual_add_contacts on` enabled (automatic in session init)
-2. Pending contacts available (requires other nodes trying to connect)
-
-### Test Commands
-
-**From host or inside mc-webui container**:
-
-```bash
-# List pending contacts
-curl -s http://meshcore-bridge:5001/pending_contacts | jq
-
-# Add a CLI contact by name (works for CLI, not ROOM)
-curl -s -X POST http://meshcore-bridge:5001/add_pending \
- -H 'Content-Type: application/json' \
- -d '{"selector":"ML2056"}' | jq
-
-# Add by full public key (RECOMMENDED - works for all types)
-curl -s -X POST http://meshcore-bridge:5001/add_pending \
- -H 'Content-Type: application/json' \
- -d '{"selector":"b3fec489e1ee2d0277bd16de957253c8f5aa44a721df722224bbdc1edc5829b6"}' | jq
-```
-
-**Real-world test results** (2025-12-29):
-
-1. **CLI contacts** - flexible matching:
- ```bash
- # All worked successfully
- curl -d '{"selector":"StNMobile T1000e"}' β β
SUCCESS
- curl -d '{"selector":"ML2056"}' β β
SUCCESS
- curl -d '{"selector":"2ce5514"}' β β
SUCCESS (prefix)
- ```
-
-2. **ROOM contact** - strict matching:
- ```bash
- # Failed attempts
- curl -d '{"selector":"TK room cwiczebnyπ"}' β β FAILED (UTF-8 encoding)
- curl -d '{"selector":"TK room"}' β β FAILED (name prefix)
- curl -d '{"selector":"b3fec489"}' β β FAILED (key prefix)
-
- # Success
- curl -d '{"selector":"b3fec489e1ee...5829b6"}' β β
SUCCESS (full key)
- ```
-
-**Expected workflow**:
-1. New node attempts connection
-2. `GET /pending_contacts` shows the node in pending list with `name` and `public_key`
-3. `POST /add_pending` with **full `public_key`** (not name!) approves the contact
-4. `GET /pending_contacts` no longer shows the approved contact (moved to regular contacts)
-
-**Best Practice**: Always use full `public_key` from the `GET /pending_contacts` response to ensure compatibility with all contact types (CLI, ROOM, REP, SENS).
-
-## Architecture Benefits
-
-### Reuses Persistent Session
-- No new subprocess spawning
-- Uses existing command queue (FIFO serialization)
-- Same event-based synchronization mechanism
-- Consistent error handling with other endpoints
-
-### Thread-safe
-- Commands queued through `queue.Queue()`
-- Protected by `pending_lock` during response handling
-- No race conditions with other CLI commands
-
-### Consistent with /cli Endpoint
-- Same request/response format
-- Same timeout handling
-- Same error reporting structure
-
-## Future Work
-
-### UI Integration (Next Phase)
-
-**Planned features**:
-1. **Pending Contacts Badge** - Notification icon showing count of pending contacts
-2. **Pending Contacts Modal** - List view with approve/reject buttons
-3. **Auto-refresh** - Poll `/pending_contacts` every 30-60 seconds
-4. **Notifications** - Toast when new pending contacts appear
-
-**UI Mockup**:
-```
-βββββββββββββββββββββββββββββββββββββββ
-β Pending Contact Requests [X] β
-βββββββββββββββββββββββββββββββββββββββ€
-β Skyllancer β
-β f9ef123abc... β
-β [Approve] [Reject] β
-βββββββββββββββββββββββββββββββββββββββ€
-β KRA Reksio mob2π β
-β 41d5789def... β
-β [Approve] [Reject] β
-βββββββββββββββββββββββββββββββββββββββ
-```
-
-### Additional API Endpoints (Consideration)
-
-**`POST /reject_pending`** - Reject a pending contact
-```json
-{
- "selector": "Skyllancer"
-}
-```
-
-**`DELETE /pending_contacts`** - Flush all pending contacts
-- Executes `flush_pending` meshcli command
-- Useful for mass-reject after scanning for unwanted connections
-
-### Settings Integration
-
-Add UI toggle in Settings modal:
-```
-β Manual Contact Approval
- Require explicit approval for new contacts
-```
-
-This would execute:
-```bash
-# Enable
-curl -X POST /cli -d '{"args":["set","manual_add_contacts","on"]}'
-
-# Disable
-curl -X POST /cli -d '{"args":["set","manual_add_contacts","off"]}'
-```
-
-## Security Considerations
-
-### Why Manual Contact Approval?
-
-1. **DoS Prevention** - Prevents flooding with fake contact requests
-2. **Network Privacy** - Control who can see your node
-3. **Trust Model** - Explicit approval creates stronger trust relationships
-4. **Spam Filtering** - Reject unwanted contact attempts
-
-### Trade-offs
-
-**Pros**:
-- Enhanced security and privacy
-- User controls network access
-- Prevents automatic addition of random nodes
-
-**Cons**:
-- Requires user interaction for every new contact
-- May miss legitimate contacts if user doesn't check pending list regularly
-- Additional management overhead
-
-### Recommendation
-
-**Use manual approval when**:
-- Running on public/shared networks
-- Privacy is a concern
-- Network has history of spam/unwanted contacts
-- Small, controlled mesh network
-
-**Use auto-approval (default) when**:
-- Private/trusted network environment
-- Ease of use is priority
-- Large mesh network where manual approval is impractical
-
-## Meshcli Command Reference
-
-### pending_contacts
-```bash
-meshcli> pending_contacts
-Skyllancer: f9ef123abc456def789012345678901234567890abcdef
-KRA Reksio mob2π: 41d5789def012345678901234567890abcdefabcdef012
-```
-
-### add_pending
-```bash
-# By name
-meshcli> add_pending Skyllancer
-Contact added successfully
-
-# By public key prefix (first few chars)
-meshcli> add_pending f9ef123
-Contact added successfully
-
-# By full public key
-meshcli> add_pending f9ef123abc456def789012345678901234567890abcdef
-Contact added successfully
-```
-
-### flush_pending
-```bash
-meshcli> flush_pending
-All pending contacts removed
-```
-
-### Manual mode toggle
-```bash
-# Enable manual approval
-meshcli> set manual_add_contacts on
-manual_add_contacts set to on
-
-# Disable (auto-approve)
-meshcli> set manual_add_contacts off
-manual_add_contacts set to off
-
-# Check current setting
-meshcli> get manual_add_contacts
-manual_add_contacts: on
-```
-
-## Deployment
-
-### Files Modified
-
-1. **meshcore-bridge/bridge.py**
- - Added `manual_add_contacts on` to session init ([line 131](meshcore-bridge/bridge.py#L131))
- - Added `GET /pending_contacts` endpoint ([lines 499-565](meshcore-bridge/bridge.py#L499-L565))
- - Added `POST /add_pending` endpoint ([lines 568-629](meshcore-bridge/bridge.py#L568-L629))
-
-2. **Dockerfile**
- - Added `curl` package for testing ([line 7](Dockerfile#L7))
-
-3. **README.md**
- - Added "Testing Bridge API" section ([lines 362-406](README.md#L362-L406))
- - Documented endpoints with examples
-
-### Commit
-
-**Branch**: `dev-2`
-**Commit**: `815adb5` - "feat(bridge): Add pending contacts management API endpoints"
-
-### Deployment Steps
-
-```bash
-# On server
-cd ~/mc-webui
-git fetch
-git checkout dev-2
-git pull origin dev-2
-docker compose up -d --build
-```
-
-### Verification
-
-```bash
-# Check logs for successful init
-docker compose logs meshcore-bridge | grep manual_add_contacts
-# Should see: "Session settings applied: ... manual_add_contacts=on ..."
-
-# Test endpoint
-docker exec mc-webui curl -s http://meshcore-bridge:5001/pending_contacts | jq
-```
-
-## References
-
-- **meshcore-cli documentation**: [technotes/meshcore-cli.md](technotes/meshcore-cli.md)
-- **Persistent session architecture**: [technotes/persistent-meshcli-session.md](technotes/persistent-meshcli-session.md)
-- **Meshcli command reference**: `meshcli -h | grep pending` or `meshcli> ? pending_contacts`
-
----
-
-**Author**: Claude Code (Anthropic)
-**Date**: 2025-12-29
-**Status**: API Implemented β
| UI Pending β³
diff --git a/technotes/persistent-meshcli-session.md b/technotes/persistent-meshcli-session.md
deleted file mode 100644
index 547edfd..0000000
--- a/technotes/persistent-meshcli-session.md
+++ /dev/null
@@ -1,504 +0,0 @@
-# Persistent meshcli Session Architecture - Technical Notes
-
-## Overview
-
-This document describes the architectural refactor from per-request subprocess spawning to a **persistent meshcli session** in the `meshcore-bridge` container. This fundamental change enables real-time message reception, advert logging, and advanced features like pending contact management.
-
-## Previous Architecture (Before Refactor)
-
-### How it Worked
-
-The original `meshcore-bridge` implementation used **subprocess.run()** for each HTTP request:
-
-```python
-def run_meshcli_command(args, timeout=DEFAULT_TIMEOUT):
- result = subprocess.run(
- ['meshcli', '-s', MC_SERIAL_PORT] + args,
- capture_output=True,
- text=True,
- timeout=timeout
- )
- return result
-```
-
-### Limitations
-
-1. **Serial Port Conflicts** - Each command spawned a new meshcli process, risking USB device locking
-2. **No Real-time Messages** - Required periodic `recv` polling (inefficient, 30-60s delay)
-3. **No Advert Logging** - JSON adverts from the mesh network were discarded
-4. **No Interactive Features** - Commands like `msgs_subscribe` or `manual_add_contacts` require persistent session
-5. **Higher Overhead** - Process spawn/teardown for every command added latency
-
-### Why Change Was Needed
-
-User reported: **"od czasu zmian, czyli od ponad 1.5 godziny, nie dotarΕa ANI JEDNA wiadomoΕΔ"**
-
-In non-interactive mode (subprocess.run), meshcli doesn't automatically receive new messages. The `recv` command only reads what's already in the `.msgs` file, it doesn't fetch NEW messages from the radio.
-
-## New Architecture (Persistent Session)
-
-### Core Concept
-
-Instead of spawning a new process per request, the bridge maintains a **single long-lived meshcli process** with:
-- **stdin pipe** - Send commands
-- **stdout pipe** - Receive responses and adverts
-- **stderr pipe** - Monitor errors
-
-### Key Components
-
-#### 1. MeshCLISession Class
-
-The `MeshCLISession` class encapsulates the entire persistent session:
-
-```python
-class MeshCLISession:
- def __init__(self, serial_port, config_dir, device_name):
- self.process = subprocess.Popen(
- ['meshcli', '-s', serial_port],
- stdin=subprocess.PIPE,
- stdout=subprocess.PIPE,
- stderr=subprocess.PIPE,
- text=True,
- bufsize=1 # Line-buffered
- )
-```
-
-#### 2. Worker Threads (4 Concurrent Threads)
-
-**a) stdout_thread** - Reads stdout line-by-line
-- Parses each line as JSON
-- If `payload_typename == "ADVERT"` β log to `.adverts.jsonl`
-- Otherwise β append to current CLI command response buffer
-
-**b) stderr_thread** - Reads stderr and logs errors
-- Monitors `meshcli stderr: ...` messages
-- TTY errors are harmless (meshcli tries to use terminal features that don't exist in pipes)
-
-**c) stdin_thread** - Sends queued commands to stdin
-- Pulls commands from thread-safe `queue.Queue`
-- Writes to `process.stdin`
-- Starts timeout monitor thread for each command
-
-**d) watchdog_thread** - Monitors process health
-- Checks `process.poll()` every 5 seconds
-- If process crashed β cancels pending commands, restarts session
-
-#### 3. Command Queue System
-
-Commands are executed serially through a thread-safe queue:
-
-```python
-self.command_queue = queue.Queue()
-
-# Client calls execute_command()
-self.command_queue.put((cmd_id, command, event, response_dict))
-
-# stdin_thread pulls from queue
-cmd_id, command, event, response_dict = self.command_queue.get(timeout=1.0)
-```
-
-#### 4. Event-based Synchronization
-
-Each command gets a `threading.Event` for completion notification:
-
-```python
-event = threading.Event()
-response_dict = {
- "event": event,
- "response": [],
- "done": False,
- "error": None,
- "last_line_time": time.time()
-}
-
-# Queue command
-self.command_queue.put((cmd_id, command, event, response_dict))
-
-# Wait for completion
-if not event.wait(timeout):
- return {'success': False, 'stderr': 'Command timeout'}
-```
-
-#### 5. Timeout-based Response Detection
-
-Since meshcli doesn't provide end-of-response markers, we use **idle timeout detection**:
-
-- Monitor `last_line_time` timestamp for each command
-- If no new lines arrive for **300ms** β command is complete
-- `event.set()` signals completion to waiting client
-
-```python
-def _monitor_response_timeout(self, cmd_id, response_dict, event, timeout_ms=300):
- while not self.shutdown_flag.is_set():
- time.sleep(timeout_ms / 1000.0)
-
- with self.pending_lock:
- time_since_last_line = time.time() - response_dict["last_line_time"]
-
- if time_since_last_line >= (timeout_ms / 1000.0):
- logger.info(f"Command [{cmd_id}] completed (timeout-based)")
- response_dict["done"] = True
- event.set()
- return
-```
-
-### Session Initialization Commands
-
-On startup, the bridge configures the meshcli session:
-
-```python
-def _init_session_settings(self):
- self.process.stdin.write('set json_log_rx on\n')
- self.process.stdin.write('set print_adverts on\n')
- self.process.stdin.write('msgs_subscribe\n')
- self.process.stdin.flush()
-```
-
-#### Command Breakdown:
-
-1. **`set json_log_rx on`** - Enable JSON output for received messages
-2. **`set print_adverts on`** - Print advertisement frames to stdout
-3. **`msgs_subscribe`** - Subscribe to real-time message events (critical for instant message reception!)
-
-### Multiplexing Logic
-
-The `_read_stdout()` thread routes each line to the correct destination:
-
-```python
-def _read_stdout(self):
- for line in iter(self.process.stdout.readline, ''):
- line = line.rstrip('\n\r')
-
- # Try to parse as JSON advert
- if self._is_advert_json(line):
- self._log_advert(line) # β .adverts.jsonl
- continue
-
- # Otherwise, append to current CLI response
- self._append_to_current_response(line) # β HTTP response
-```
-
-### Advert Logging
-
-JSON adverts are logged to `{device_name}.adverts.jsonl`:
-
-```python
-def _log_advert(self, json_line):
- data = json.loads(json_line)
- data["ts"] = time.time() # Add timestamp
-
- with open(self.advert_log_path, 'a', encoding='utf-8') as f:
- f.write(json.dumps(data, ensure_ascii=False) + '\n')
-```
-
-**File format**: JSON Lines (.jsonl) - one JSON object per line:
-```json
-{"payload_typename":"ADVERT","from_id":"abc123",...,"ts":1735425678.123}
-{"payload_typename":"ADVERT","from_id":"def456",...,"ts":1735425680.456}
-```
-
-## Command Argument Quoting
-
-meshcli in interactive mode requires proper quoting for arguments with spaces:
-
-```python
-def execute_command(self, args, timeout=DEFAULT_TIMEOUT):
- quoted_args = []
- for arg in args:
- # If argument contains spaces or special chars, wrap in double quotes
- if ' ' in arg or '"' in arg or "'" in arg:
- escaped = arg.replace('"', '\\"')
- quoted_args.append(f'"{escaped}"')
- else:
- quoted_args.append(arg)
-
- command = ' '.join(quoted_args)
-```
-
-**Why not shlex.quote()?**
-- `shlex.quote()` uses single quotes (`'message'`)
-- meshcli treats single quotes literally, so they appear in sent messages
-- **Solution**: Custom double-quote wrapping with escaped internal double quotes
-
-## Real-time Message Reception
-
-### The Problem (Before msgs_subscribe)
-
-With periodic `recv` polling:
-- `recv` command only reads from `.msgs` file
-- It doesn't fetch NEW messages from the radio
-- User reported: "od ponad 1.5 godziny, nie dotarΕa ANI JEDNA wiadomoΕΔ"
-
-### The Solution (msgs_subscribe)
-
-User insight: **"W trybie interaktywnym, `msg_subscribe` wΕΔ
cza wyΕwietlanie wiadomoΕci w momencie ich nadejΕcia"**
-
-When `msgs_subscribe` is active in interactive mode:
-- meshcli listens for message events from the radio
-- New messages are immediately printed to stdout
-- No polling needed - true event-driven architecture
-
-### How It Works
-
-1. Session init sends `msgs_subscribe\n` to stdin
-2. meshcli subscribes to radio message events
-3. When new message arrives:
- - meshcli writes message to `.msgs` file
- - meshcli prints message to stdout (captured by `_read_stdout` thread)
-4. mc-webui detects change in `.msgs` file (file watcher or periodic stat check)
-5. UI updates in real-time
-
-## Watchdog and Auto-restart
-
-The watchdog thread monitors process health:
-
-```python
-def _watchdog(self):
- while not self.shutdown_flag.is_set():
- time.sleep(5)
-
- if self.process and self.process.poll() is not None:
- logger.error(f"meshcli process died (exit code: {self.process.returncode})")
-
- # Cancel all pending commands
- with self.pending_lock:
- for cmd_id, resp_dict in self.pending_commands.items():
- resp_dict["error"] = "meshcli process crashed"
- resp_dict["done"] = True
- resp_dict["event"].set()
- self.pending_commands.clear()
-
- # Restart
- self._start_session()
-```
-
-**Benefits:**
-- Automatic recovery from crashes
-- No manual intervention required
-- Pending commands receive error responses instead of hanging
-
-## Thread Safety
-
-### Locks Used
-
-1. **`self.pending_lock`** - Protects `pending_commands` dict and `current_cmd_id`
-2. **`self.process_lock`** - Protects process handle (currently unused, reserved for future)
-
-### Thread-safe Data Structures
-
-- **`queue.Queue()`** - Thread-safe command queue (built-in locking)
-
-## Docker Configuration Changes
-
-### Environment Variables Added
-
-```yaml
-# docker-compose.yml
-meshcore-bridge:
- environment:
- - MC_CONFIG_DIR=/root/.config/meshcore # For advert log path
- - MC_DEVICE_NAME=${MC_DEVICE_NAME} # For .adverts.jsonl filename
- - TZ=${TZ:-UTC} # Configurable timezone
-```
-
-### .env Configuration
-
-```bash
-# .env
-TZ=Europe/Warsaw # Timezone for container logs (default: UTC)
-```
-
-## Benefits of Persistent Session
-
-### Immediate Benefits
-
-1. **Real-time Messages** - `msgs_subscribe` enables instant message reception
-2. **Advert Logging** - Network advertisements logged to `.adverts.jsonl`
-3. **Better Stability** - Single USB session, no serial port conflicts
-4. **Lower Latency** - No process spawn/teardown overhead
-
-### Future Possibilities
-
-The persistent session enables advanced features that were impossible before:
-
-1. **Pending Contact Management**
- ```bash
- set manual_add_contacts on # Disable auto-add
- pending_contacts # List pending contact requests
- add_pending # Approve specific contact
- ```
-
-2. **Interactive Configuration**
- ```bash
- set