Bug: Sidebar hides encrypted custom channels on fresh/empty database (v3.0.8) #69

New Issue

2026-10-05T06:04:47+02:00

adam commented

2026-10-05 06:04:47 +02:00

Hi! There is a critical UI/UX bug in version 3.0.8 when starting with a fresh, empty database (packets.db at 4.0KB) while utilizing secondary encryption keys for custom channels via MQTT.

The Problem

When a node sends a packet from a secondary encrypted channel (e.g., custom channel name), the Meshtastic upstream often broadcasts it under the raw root or default topic path (.../LongFast/...). Because of this, the mqtt_reader.py processes it, but the web UI filters in web.py strict-check the database for channel activity.

Since channels = await store.get_channels() and active_channels = await store.get_active_channels() return empty lists for a fresh DB, the sidebar completely hides all configured custom channels from the UI sidebar, locking the user into viewing only the default "LongFast" channel. Even if encrypted text messages arrive, they fail to force-render the channel on the sidebar navigation.

The Temporary Fix

We had to hardcode the channels and active_channels arrays directly inside meshview/web.py to bypass the database check and force-render the custom channels on the sidebar navigation, which immediately fixed the issue and allowed encrypted packets to decrypt and map properly.

Expected Behavior

Please update the sidebar rendering logic to natively honor featured_channels from config.ini even if the database table or packet schema contains 0 rows for those channels.

Hi! There is a critical UI/UX bug in version 3.0.8 when starting with a fresh, empty database (`packets.db` at 4.0KB) while utilizing secondary encryption keys for custom channels via MQTT. ### The Problem When a node sends a packet from a secondary encrypted channel (e.g., custom channel name), the Meshtastic upstream often broadcasts it under the raw root or default topic path (`.../LongFast/...`). Because of this, the `mqtt_reader.py` processes it, but the web UI filters in `web.py` strict-check the database for channel activity. Since `channels = await store.get_channels()` and `active_channels = await store.get_active_channels()` return empty lists for a fresh DB, the sidebar completely hides all configured custom channels from the UI sidebar, locking the user into viewing **only** the default "LongFast" channel. Even if encrypted text messages arrive, they fail to force-render the channel on the sidebar navigation. ### The Temporary Fix We had to hardcode the `channels` and `active_channels` arrays directly inside `meshview/web.py` to bypass the database check and force-render the custom channels on the sidebar navigation, which immediately fixed the issue and allowed encrypted packets to decrypt and map properly. ### Expected Behavior Please update the sidebar rendering logic to natively honor `featured_channels` from `config.ini` even if the database table or packet schema contains 0 rows for those channels.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/meshview#69