Packet display #47

New Issue

2026-10-04T23:10:21+02:00

adam commented

2026-10-04 23:10:21 +02:00

Is there an undocumented trick to getting the packet info to display in meshcore-hub? (example: https://ipnt.uk/packets)

I assumed this feature wouldn't be available when using the meshcore-packet-capture because it would require access to raw packet data, so I switched over to using mescoretomqtt with a debug-enabled repeater build.

I've made sure FEATURE_PACKETS=true is set in the .env

I've tried explicitly setting RAW_PACKET_CAPTURE_ENABLED=true separately.

I've done a complete wipe and re-do of the entire stack from scratch.

I've got auth set up with keycloak.

All other functionality works amazingly. I just can't get that packets tab of the site to display no matter what I do. I've spent literally days trying.

Apologies for opening an issue for this.. it may not even be an issue with the codebase, but may be a docs issue.

Is there an undocumented trick to getting the packet info to display in meshcore-hub? (example: https://ipnt.uk/packets) I assumed this feature wouldn't be available when using the meshcore-packet-capture because it would require access to raw packet data, so I switched over to using mescoretomqtt with a debug-enabled repeater build. I've made sure FEATURE_PACKETS=true is set in the .env I've tried explicitly setting RAW_PACKET_CAPTURE_ENABLED=true separately. I've done a complete wipe and re-do of the entire stack from scratch. I've got auth set up with keycloak. All other functionality works amazingly. I just can't get that packets tab of the site to display no matter what I do. I've spent literally days trying. Apologies for opening an issue for this.. it may not even be an issue with the codebase, but may be a docs issue.

adam closed this issue

2026-10-04 23:10:21 +02:00

adam commented

2026-10-04 23:10:22 +02:00

No need for apology, I always appreciate the feedback. Let me review the codebase and get back to you.

Enabling FEATURE_PACKETS should be enough, but I need to confirm.

No need for apology, I always appreciate the feedback. Let me review the codebase and get back to you. Enabling `FEATURE_PACKETS` should be enough, but I need to confirm.

adam commented

2026-10-04 23:10:23 +02:00

Are you using Docker Compose? Did you download/pull the latest docker-compose.yml file that includes the passthrough of the .env variables into the container?

https://github.com/ipnet-mesh/meshcore-hub/blob/main/docker-compose.yml#L396

I often do this myself. The deployment instructions recommend downloading the docker-compose.*.yml files, but they do get updated occasionally on most releases, so its always best practice to pull the latest versions?

Are you using Docker Compose? Did you download/pull the latest `docker-compose.yml` file that includes the passthrough of the `.env` variables into the container? https://github.com/ipnet-mesh/meshcore-hub/blob/main/docker-compose.yml#L396 I often do this myself. The deployment instructions recommend downloading the `docker-compose.*.yml` files, but they do get updated occasionally on most releases, so its always best practice to pull the latest versions?

adam commented

2026-10-04 23:10:24 +02:00

I've just checked and there aren't no other gates that would prevent the display of the "Packets" navigation item (and access to the page), other than the new SYSTEM_MAINTENANCE flag which effectively blocks all access and returns a "Site Under Maintenance" page, which you obviously aren't seeing.

Can you confirm whether you are using Docker deployment or not? The Docker setup performs an npm run build task that rebuilds the JS/CSS assets, so if you aren't using Docker, you may need to run npm run build manually.

Other than that, it could be a caching issue, but I presume you've cleared your browser cache? And have you pulled the latest Docker image and restarted the stack with docker compose ... up -d --force-recreate?

FYI: This feature works fine with meshcore-packet-capture as we use that ourselves, but meshcoretomqtt uses the same format, so should work as well. But, neither would prevent the "Packets" navigation/page being available.

Thanks for the feedback with Keycloak. I hadn't had a chance to test it thoroughly with Keycloak and thought they may had been an issue with how the claims/roles were handled. I'm really glad it works with Keycloak.

I've just checked and there aren't no other gates that would prevent the display of the "Packets" navigation item (and access to the page), other than the new `SYSTEM_MAINTENANCE` flag which effectively blocks all access and returns a "Site Under Maintenance" page, which you obviously aren't seeing. Can you confirm whether you are using Docker deployment or not? The Docker setup performs an `npm run build` task that rebuilds the JS/CSS assets, so if you aren't using Docker, you may need to run `npm run build` manually. Other than that, it could be a caching issue, but I presume you've cleared your browser cache? And have you pulled the latest Docker image and restarted the stack with `docker compose ... up -d --force-recreate`? FYI: This feature works fine with `meshcore-packet-capture` as we use that ourselves, but `meshcoretomqtt` uses the same format, so should work as well. But, neither would prevent the "Packets" navigation/page being available. Thanks for the feedback with Keycloak. I hadn't had a chance to test it thoroughly with Keycloak and thought they may had been an issue with how the claims/roles were handled. I'm really glad it works with Keycloak.

adam commented

2026-10-04 23:10:24 +02:00

I'll be happy to include your MeshCore site on the README for the repo if you want, feel free to submit a PR or just let me know the website URL and preferred site name.

If you want to remain private, I totally understand.

I'll be happy to include your MeshCore site on the README for the repo if you want, feel free to submit a PR or just let me know the website URL and preferred site name. If you want to remain private, I totally understand.

adam commented

2026-10-04 23:10:25 +02:00

I've just checked and there aren't no other gates that would prevent the display of the "Packets" navigation item (and access to the page), other than the new SYSTEM_MAINTENANCE flag which effectively blocks all access and returns a "Site Under Maintenance" page, which you obviously aren't seeing.

Can you confirm whether you are using Docker deployment or not? The Docker setup performs an npm run build task that rebuilds the JS/CSS assets, so if you aren't using Docker, you may need to run npm run build manually.

Yup, using the production docker stack as it is with the exception of commenting out the meshcore-packet-capture and inserting mctomqtt's yaml entries in its place just to keep the stack all together. I don't believe any of those changes would impact the packet display as it's otherwise correctly parsing incoming packets.

Other than that, it could be a caching issue, but I presume you've cleared your browser cache? And have you pulled the latest Docker image and restarted the stack with docker compose ... up -d --force-recreate?

Yes, I've cleared browser cache and even tried viewing on other devices that hadn't previously visited the site.

Just --force-recreate'ed the whole stack again just to be sure.

FYI: This feature works fine with meshcore-packet-capture as we use that ourselves, but meshcoretomqtt uses the same format, so should work as well. But, neither would prevent the "Packets" navigation/page being available.

Yeah, I don't understand it. Here's the relevant part of the .env I'm running:

# -------------------
# Feature Flags
# -------------------
# Control which pages are visible in the web dashboard
# Set to false to completely hide a page (nav, routes, sitemap, robots.txt)

FEATURE_DASHBOARD=true
FEATURE_NODES=true
FEATURE_ADVERTISEMENTS=true
FEATURE_MESSAGES=true
FEATURE_MAP=true
FEATURE_MEMBERS=true
FEATURE_PAGES=true
FEATURE_CHANNELS=true
FEATURE_RADIO_CONFIG=true
# Packets page is ON by default. This var also drives raw-packet capture
# on the collector via Compose (RAW_PACKET_CAPTURE_ENABLED=${FEATURE_PACKETS}).
FEATURE_PACKETS=true

Thanks for the feedback with Keycloak. I hadn't had a chance to test it thoroughly with Keycloak and thought they may had been an issue with how the claims/roles were handled. I'm really glad it works with Keycloak.

I haven't had any real issues with it. For some reason on the meshcore-hub's profile page the roles show up twice, but that's it.

I guess I'll keep poking at it... eventually I'll beat this into submission and make it display the packets page 😂

> I've just checked and there aren't no other gates that would prevent the display of the "Packets" navigation item (and access to the page), other than the new `SYSTEM_MAINTENANCE` flag which effectively blocks all access and returns a "Site Under Maintenance" page, which you obviously aren't seeing. > > Can you confirm whether you are using Docker deployment or not? The Docker setup performs an `npm run build` task that rebuilds the JS/CSS assets, so if you aren't using Docker, you may need to run `npm run build` manually. Yup, using the production docker stack as it is with the exception of commenting out the meshcore-packet-capture and inserting mctomqtt's yaml entries in its place just to keep the stack all together. I don't believe any of those changes would impact the packet display as it's otherwise correctly parsing incoming packets. > Other than that, it could be a caching issue, but I presume you've cleared your browser cache? And have you pulled the latest Docker image and restarted the stack with `docker compose ... up -d --force-recreate`? Yes, I've cleared browser cache and even tried viewing on other devices that hadn't previously visited the site. Just --force-recreate'ed the whole stack again just to be sure. > FYI: This feature works fine with `meshcore-packet-capture` as we use that ourselves, but `meshcoretomqtt` uses the same format, so should work as well. But, neither would prevent the "Packets" navigation/page being available. Yeah, I don't understand it. Here's the relevant part of the .env I'm running: ``` # ------------------- # Feature Flags # ------------------- # Control which pages are visible in the web dashboard # Set to false to completely hide a page (nav, routes, sitemap, robots.txt) FEATURE_DASHBOARD=true FEATURE_NODES=true FEATURE_ADVERTISEMENTS=true FEATURE_MESSAGES=true FEATURE_MAP=true FEATURE_MEMBERS=true FEATURE_PAGES=true FEATURE_CHANNELS=true FEATURE_RADIO_CONFIG=true # Packets page is ON by default. This var also drives raw-packet capture # on the collector via Compose (RAW_PACKET_CAPTURE_ENABLED=${FEATURE_PACKETS}). FEATURE_PACKETS=true ``` > Thanks for the feedback with Keycloak. I hadn't had a chance to test it thoroughly with Keycloak and thought they may had been an issue with how the claims/roles were handled. I'm really glad it works with Keycloak. I haven't had any real issues with it. For some reason on the meshcore-hub's profile page the roles show up twice, but that's it. I guess I'll keep poking at it... eventually I'll beat this into submission and make it display the packets page 😂

adam commented

2026-10-04 23:10:26 +02:00

Does your docker-compose.yml contain FEATURE_PACKETS? See previous comment: https://github.com/ipnet-mesh/meshcore-hub/issues/262#issuecomment-4722015868

You may need to pull the latest version:

wget https://raw.githubusercontent.com/ipnet-mesh/meshcore-hub/refs/heads/main/docker-compose.yml -O docker-compose.yml

Does your `docker-compose.yml` contain `FEATURE_PACKETS`? See previous comment: https://github.com/ipnet-mesh/meshcore-hub/issues/262#issuecomment-4722015868 You may need to pull the latest version: ```bash wget https://raw.githubusercontent.com/ipnet-mesh/meshcore-hub/refs/heads/main/docker-compose.yml -O docker-compose.yml ```

adam commented

2026-10-04 23:10:26 +02:00

Does your docker-compose.yml contain FEATURE_PACKETS? See previous comment: #262 (comment)

You may need to pull the latest version:

wget https://raw.githubusercontent.com/ipnet-mesh/meshcore-hub/refs/heads/main/docker-compose.yml -O docker-compose.yml

The currently running docker stack is from a github clone of the repo last evening.

> Does your `docker-compose.yml` contain `FEATURE_PACKETS`? See previous comment: [#262 (comment)](https://github.com/ipnet-mesh/meshcore-hub/issues/262#issuecomment-4722015868) > > You may need to pull the latest version: > > wget https://raw.githubusercontent.com/ipnet-mesh/meshcore-hub/refs/heads/main/docker-compose.yml -O docker-compose.yml The currently running docker stack is from a github clone of the repo last evening. <img width="672" height="441" alt="Image" src="https://github.com/user-attachments/assets/b5a8b51d-142f-4823-96b6-38c19e836135" />

adam commented

2026-10-04 23:10:27 +02:00

That looks fine. How strange, I'm a bit stumped. I'll keep looking into it, but I'm unable to recreate it locally.

That looks fine. How strange, I'm a bit stumped. I'll keep looking into it, but I'm unable to recreate it locally.

adam commented

2026-10-04 23:10:28 +02:00

Can you run this in your browser debug console?

console.log(window.__APP_CONFIG__.features.packets);

It should output true.

Also, check the Docker logs for the web component:

docker compose ... logs -f web

Can you see a line that starts: Disabled features:

Can you run this in your browser debug console? ``` console.log(window.__APP_CONFIG__.features.packets); ``` It should output `true`. Also, check the Docker logs for the `web` component: ``` docker compose ... logs -f web ``` Can you see a line that starts: `Disabled features:`

adam commented

2026-10-04 23:10:29 +02:00

Can you run this in your browser debug console?
console.log(window.__APP_CONFIG__.features.packets);
It should output true.

It shows undefined, other features do report as 'true'

Also, check the Docker logs for the web component:
docker compose ... logs -f web
Can you see a line that starts: Disabled features:

No. I even went as far as using --tail 3000 which gave the complete log from time of startup and did a grep -i for 'feature' or 'disabled'. No such log entry exists.

There's nothing sensitive there, I can toss the full log into a pastebin or attach it here if it would help at all.

> Can you run this in your browser debug console? > > ``` > console.log(window.__APP_CONFIG__.features.packets); > ``` > > It should output `true`. It shows undefined, other features do report as 'true' > > Also, check the Docker logs for the `web` component: > > ``` > docker compose ... logs -f web > ``` > > Can you see a line that starts: `Disabled features:` No. I even went as far as using --tail 3000 which gave the complete log from time of startup and did a grep -i for 'feature' or 'disabled'. No such log entry exists. There's nothing sensitive there, I can toss the full log into a pastebin or attach it here if it would help at all.

adam commented

2026-10-04 23:10:30 +02:00

There appears to be a discrepancy in how the "packet" feature tests it logic. I'm going to make it consistent with other features and test.

Are you using anything like direnv to automatically source the .env file in your project directory? Docker Compose will natively read and parse your .env file if you run the docker compose command from the same directory as your .env file.

If you are using something like direnv or are manually sourcing/exporting the .env variables, it may export the value as a string (e.g. "true" instead of true). I've updated the code to align the logic with the other features, but that will require a new release.

There appears to be a discrepancy in how the "packet" feature tests it logic. I'm going to make it consistent with other features and test. Are you using anything like `direnv` to automatically source the `.env` file in your project directory? Docker Compose will natively read and parse your `.env` file if you run the `docker compose` command from the same directory as your `.env` file. If you are using something like `direnv` or are manually sourcing/exporting the `.env` variables, it may export the value as a string (e.g. `"true"` instead of `true`). I've updated the code to align the logic with the other features, but that will require a new release.

adam commented

2026-10-04 23:10:30 +02:00

Could you inspect the environment variables inside the web container?

docker compose ... exec web env | grep FEATURE_

Could you inspect the environment variables inside the `web` container? ```bash docker compose ... exec web env | grep FEATURE_ ```

adam commented

2026-10-04 23:10:31 +02:00

Could you inspect the environment variables inside the web container?

docker compose ... exec web env | grep FEATURE_

ric@rockpro64:~/meshcore-hub$ docker compose exec web env | grep FEATURE_
FEATURE_PAGES=true
FEATURE_NODES=true
FEATURE_MESSAGES=true
FEATURE_MAP=true
FEATURE_RADIO_CONFIG=true
FEATURE_DASHBOARD=true
FEATURE_MEMBERS=true
FEATURE_ADVERTISEMENTS=true
FEATURE_PACKETS=true
FEATURE_CHANNELS=true

No direnv or anything. It's a bone stock armbian install on a rockpro64 board. I imaged the board specifically to spin up meshcore-hub.

> Could you inspect the environment variables inside the `web` container? > > docker compose ... exec web env | grep FEATURE_ ``` ric@rockpro64:~/meshcore-hub$ docker compose exec web env | grep FEATURE_ FEATURE_PAGES=true FEATURE_NODES=true FEATURE_MESSAGES=true FEATURE_MAP=true FEATURE_RADIO_CONFIG=true FEATURE_DASHBOARD=true FEATURE_MEMBERS=true FEATURE_ADVERTISEMENTS=true FEATURE_PACKETS=true FEATURE_CHANNELS=true ``` No direnv or anything. It's a bone stock armbian install on a rockpro64 board. I imaged the board specifically to spin up meshcore-hub.

adam commented

2026-10-04 23:10:32 +02:00

Just to confirm:

Are you pulling the :latest (release) or :main (current) image from GHCR or are you building locally?

The arm might be a clue, maybe the ARM image isn't being built correctly. Can you run this to see if the actual container image contains the packet code?

docker compose ... exec web grep -ir features.packet /opt/venv

It should return something like:

/opt/venv/lib/python3.14/site-packages/meshcore_hub/web/static/js/spa/app.js:if (features.packets !== false) {
/opt/venv/lib/python3.14/site-packages/meshcore_hub/web/static/js/spa/app.js:    if (features.packets !== false) titles['/packets'] = composePageTitle('entities.packets');
/opt/venv/lib/python3.14/site-packages/meshcore_hub/web/static/js/spa/app.js:    if (features.packets !== false) {
/opt/venv/lib/python3.14/site-packages/meshcore_hub/web/static/js/spa/pages/advertisements.js:    const packetsEnabled = features.packets !== false;
/opt/venv/lib/python3.14/site-packages/meshcore_hub/web/static/js/spa/pages/messages.js:    const packetsEnabled = features.packets !== false;
/opt/venv/lib/python3.14/site-packages/meshcore_hub/web/static/js/spa/pages/home.js:                ${features.packets !== false ? renderNavCard({
/opt/venv/lib/python3.14/site-packages/meshcore_hub/web/templates/spa.html:                {% if features.packets %}

Just to confirm: * Are you pulling the `:latest` (release) or `:main` (current) image from GHCR or are you building locally? The `arm` might be a clue, maybe the ARM image isn't being built correctly. Can you run this to see if the actual container image contains the packet code? ```bash docker compose ... exec web grep -ir features.packet /opt/venv ``` It should return something like: ``` /opt/venv/lib/python3.14/site-packages/meshcore_hub/web/static/js/spa/app.js:if (features.packets !== false) { /opt/venv/lib/python3.14/site-packages/meshcore_hub/web/static/js/spa/app.js: if (features.packets !== false) titles['/packets'] = composePageTitle('entities.packets'); /opt/venv/lib/python3.14/site-packages/meshcore_hub/web/static/js/spa/app.js: if (features.packets !== false) { /opt/venv/lib/python3.14/site-packages/meshcore_hub/web/static/js/spa/pages/advertisements.js: const packetsEnabled = features.packets !== false; /opt/venv/lib/python3.14/site-packages/meshcore_hub/web/static/js/spa/pages/messages.js: const packetsEnabled = features.packets !== false; /opt/venv/lib/python3.14/site-packages/meshcore_hub/web/static/js/spa/pages/home.js: ${features.packets !== false ? renderNavCard({ /opt/venv/lib/python3.14/site-packages/meshcore_hub/web/templates/spa.html: {% if features.packets %} ```

adam commented

2026-10-04 23:10:33 +02:00

Just to confirm:

Are you pulling the :latest (release) or :main (current) image from GHCR or are you building locally?

It's pulling the latest images. I haven't changed that in the docker-compose.yml

 web:
    image: ghcr.io/ipnet-mesh/meshcore-hub:${IMAGE_VERSION:-latest}
    build:
      context: .
      dockerfile: Dockerfile
    container_name: ${COMPOSE_PROJECT_NAME:-hub}-web

The arm might be a clue, maybe the ARM image isn't being built correctly. Can you run this to see if the actual container image contains the packet code?

docker compose ... exec web grep -ir features.packet /opt/venv
It should return something like:

Oddly, it returns nothing.

Doing similar with features.messages, etc does return entries.

> Just to confirm: > > * Are you pulling the `:latest` (release) or `:main` (current) image from GHCR or are you building locally? It's pulling the latest images. I haven't changed that in the docker-compose.yml ``` web: image: ghcr.io/ipnet-mesh/meshcore-hub:${IMAGE_VERSION:-latest} build: context: . dockerfile: Dockerfile container_name: ${COMPOSE_PROJECT_NAME:-hub}-web ``` > > The `arm` might be a clue, maybe the ARM image isn't being built correctly. Can you run this to see if the actual container image contains the packet code? > > docker compose ... exec web grep -ir features.packet /opt/venv > It should return something like: > Oddly, it returns nothing. Doing similar with features.messages, etc does return entries.

adam commented

2026-10-04 23:10:33 +02:00

That suggests the version you are pulling doesn't actually contain the packet code. Give me a minute to pull the :latest image on an Arm64 Raspberry Pi. I'll be back in a bit...

That suggests the version you are pulling doesn't actually contain the packet code. Give me a minute to pull the `:latest` image on an Arm64 Raspberry Pi. I'll be back in a bit...

adam commented

2026-10-04 23:10:34 +02:00

That suggests the version you are pulling doesn't actually contain the packet code. Give me a minute to pull the :latest image on an Arm64 Raspberry Pi. I'll be back in a bit...

Then it isn't just me.. yay!

That also makes me wonder what else might be missing from the current arm image... how far behind in commits it might be

> That suggests the version you are pulling doesn't actually contain the packet code. Give me a minute to pull the `:latest` image on an Arm64 Raspberry Pi. I'll be back in a bit... Then it isn't just me.. yay! That also makes me wonder what else might be missing from the current arm image... how far behind in commits it might be

adam commented

2026-10-04 23:10:35 +02:00

The code is present when I pull :latest on a RPi 4. It sounds like Docker caching, can you force a pull?

docker compose ... pull web
docker compose ... up -d --force-recreate

And then re-run the above command:

docker compose ... exec web grep -ir features.packet /opt/venv

The code is present when I pull `:latest` on a RPi 4. It sounds like Docker caching, can you force a pull? ```bash docker compose ... pull web docker compose ... up -d --force-recreate ``` And then re-run the above command: ```bash docker compose ... exec web grep -ir features.packet /opt/venv ```

adam commented

2026-10-04 23:10:35 +02:00

Or if you prefer to do it in one command:

docker compose ... up -d --force-recreate --pull always

Or if you prefer to do it in one command: ```bash docker compose ... up -d --force-recreate --pull always ```

adam commented

2026-10-04 23:10:36 +02:00

The code is present when I pull :latest on a RPi 4. It sounds like Docker caching, can you force a pull?

docker compose ... pull web
docker compose ... up -d --force-recreate
And then re-run the above command:

docker compose ... exec web grep -ir features.packet /opt/venv

That did it.. but I'm still completely stumped as to why...

The initial pull (which was <48h ago) was for the latest image... but I apparently didn't actually get the latest

Uptime on the board is only 46h 12m currently and that was the reboot following my initial apt update of the system and installation of docker.

¯\(ツ)/¯

Whatever.. thanks for the assist and now you know if anyone else encounters a similar issue

> The code is present when I pull `:latest` on a RPi 4. It sounds like Docker caching, can you force a pull? > > docker compose ... pull web > docker compose ... up -d --force-recreate > And then re-run the above command: > > docker compose ... exec web grep -ir features.packet /opt/venv That did it.. but I'm still completely stumped as to why... The initial pull (which was <48h ago) was for the latest image... but I apparently didn't actually get the latest Uptime on the board is only 46h 12m currently and that was the reboot following my initial apt update of the system and installation of docker. ¯\\_(ツ)_/¯ Whatever.. thanks for the assist and now you know if anyone else encounters a similar issue

adam commented

2026-10-04 23:10:37 +02:00

No problem whatsoever. This is a known quirk of Docker Compose. It should compare the SHA digest of the image and pull a new version if the checksum has changed, but it doesn't (out of the box).

The last release was v0.13.4 which as of now was just 47h 30m ago, so looks like you may have pulled the previous image by a matter of minutes.

I've added a pull_policy: daily to all the MeshCore Hub services in the Compose file, e.g.

services:
  api:
    image: ghcr.io/ipnet-mesh/meshcore-hub:${IMAGE_VERSION:-latest}
    pull_policy: daily

This will force Docker Compose to pull a new image if it was last pulled over 24h ago. I'll commit this to main and will part of the next release (later this week).

PR: #266

No problem whatsoever. This is a known quirk of Docker Compose. It should **compare** the SHA digest of the image and pull a new version if the checksum has changed, but it doesn't (out of the box). The last release was `v0.13.4` which as of now was just 47h 30m ago, so looks like you may have pulled the previous image by a matter of minutes. I've added a `pull_policy: daily` to all the MeshCore Hub services in the Compose file, e.g. ```yaml services: api: image: ghcr.io/ipnet-mesh/meshcore-hub:${IMAGE_VERSION:-latest} pull_policy: daily ``` This will force Docker Compose to pull a new image if it was last pulled over 24h ago. I'll commit this to `main` and will part of the next release (later this week). PR: #266

Sign in to join this conversation.

main

renovate/anomalyco-opencode-2.x

renovate/i18next-26.x-lockfile

renovate/react-router-monorepo

renovate/vitest-monorepo

renovate/jsdom-30.x-lockfile

renovate/tanstack-query-monorepo

renovate/react-i18next-17.x-lockfile

renovate/react-monorepo

renovate/daisyui-5.x-lockfile

renovate/python-3.x

next-gen

feat/react-frontend-phase1

feat/ui-improvements

opencode/issue152-20260418072426

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/meshcore-hub#47