WebUI shows no messages when MC_DEVICE_NAME mismatches node name — no user feedback, only hidden logs #4

New Issue

2026-10-05T03:11:29+02:00

adam commented

2026-10-05 03:11:29 +02:00

When MC_DEVICE_NAME in .env does not match the actual device name reported by meshcli infos, the WebUI does not store messages under the expected .msgs filename.

Parser only warns "Messages file not found", which is not informative enough.
Would be good to auto-detect or provide explicit error.

When `MC_DEVICE_NAME` in `.env` does not match the actual device name reported by `meshcli infos`, the WebUI does not store messages under the expected `.msgs` filename. Parser only warns "Messages file not found", which is not informative enough. Would be good to auto-detect or provide explicit error.

adam closed this issue

2026-10-05 03:11:29 +02:00

adam commented

2026-10-05 03:11:30 +02:00

Great point! I will add such functionality in one od the future versions soon.

Great point! I will add such functionality in one od the future versions soon.

adam commented

2026-10-05 03:11:30 +02:00

Thank you for reporting this issue! You're absolutely right - having to manually configure MC_DEVICE_NAME and the silent failure when it doesn't match was a poor user experience.

Good news: This has been fixed!

What changed

The system now automatically detects your device name from meshcli. Here's how it works:

meshcore-bridge detects the device name from the meshcli prompt (DeviceName|*) at startup
The detected name is exposed via the /health endpoint
mc-webui fetches this name from the bridge when it starts
All file operations (.msgs file, archives) now use the detected name

How to use it

Simply set MC_DEVICE_NAME=auto in your .env file (this is now the recommended default):

MC_DEVICE_NAME=auto

The system will automatically detect your actual device name and use it. No more mismatches!

Fallback behavior

If auto-detection fails for any reason (e.g., device not connected), the system falls back to the value specified in MC_DEVICE_NAME. So you can still use a manual name if needed.

Try it out

To test this fix:

cd ~/mc-webui
git pull
# Update .env: change MC_DEVICE_NAME to "auto"
docker compose down && docker compose up -d --build

You can verify the detection is working by checking:

The navbar should show your correct device name
curl http://localhost:5000/api/status should return "device_name_source": "detected"

Let me know if you have any questions or run into any issues!

Technical Details (for reference)

Commits:

c7163aa - feat: Auto-detect device name from meshcli prompt
4814b43 - fix: Handle status prefixes in meshcli prompt detection
b8a7728 - docs: Add MC_DEVICE_NAME=auto as recommended setting

Files changed:

meshcore-bridge/bridge.py - Added prompt detection and /health extension
app/config.py - Added RuntimeConfig class for dynamic device name
app/meshcore/cli.py - Added fetch_device_name_from_bridge() function
app/main.py - Added initialization at startup
app/routes/views.py, api.py, parser.py, archiver/manager.py - Updated to use RuntimeConfig

Detection flow:

meshcli prompt ("DeviceName|*")
  → bridge detects name
  → /health exposes it
  → mc-webui fetches at startup
  → RuntimeConfig stores for app-wide use

Thank you for reporting this issue! You're absolutely right - having to manually configure `MC_DEVICE_NAME` and the silent failure when it doesn't match was a poor user experience. **Good news: This has been fixed!** ### What changed The system now **automatically detects your device name** from meshcli. Here's how it works: 1. **meshcore-bridge** detects the device name from the meshcli prompt (`DeviceName|*`) at startup 2. The detected name is exposed via the `/health` endpoint 3. **mc-webui** fetches this name from the bridge when it starts 4. All file operations (`.msgs` file, archives) now use the detected name ### How to use it Simply set `MC_DEVICE_NAME=auto` in your `.env` file (this is now the recommended default): ```bash MC_DEVICE_NAME=auto ``` The system will automatically detect your actual device name and use it. No more mismatches! ### Fallback behavior If auto-detection fails for any reason (e.g., device not connected), the system falls back to the value specified in `MC_DEVICE_NAME`. So you can still use a manual name if needed. ### Try it out To test this fix: ```bash cd ~/mc-webui git pull # Update .env: change MC_DEVICE_NAME to "auto" docker compose down && docker compose up -d --build ``` You can verify the detection is working by checking: - The navbar should show your correct device name - `curl http://localhost:5000/api/status` should return `"device_name_source": "detected"` Let me know if you have any questions or run into any issues! --- ## Technical Details (for reference) **Commits:** - `c7163aa` - feat: Auto-detect device name from meshcli prompt - `4814b43` - fix: Handle status prefixes in meshcli prompt detection - `b8a7728` - docs: Add MC_DEVICE_NAME=auto as recommended setting **Files changed:** - `meshcore-bridge/bridge.py` - Added prompt detection and `/health` extension - `app/config.py` - Added `RuntimeConfig` class for dynamic device name - `app/meshcore/cli.py` - Added `fetch_device_name_from_bridge()` function - `app/main.py` - Added initialization at startup - `app/routes/views.py`, `api.py`, `parser.py`, `archiver/manager.py` - Updated to use RuntimeConfig **Detection flow:** ``` meshcli prompt ("DeviceName|*") → bridge detects name → /health exposes it → mc-webui fetches at startup → RuntimeConfig stores for app-wide use ```

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/mc-webui#4