This is probably more along the lines of a BBS, but the ability to send out a message to which people must DM a check-in would be great for building a network map

We want to be able to comment in configurations, but you can't with JSON. This configuration format is convenient, but not user friendly.

https://mui.com/

On the map page, it currently does not extend to the full height of the browser, nor does it resize.

Currently the sidebar is not drawn for mobile screens. This is from a cutoff in layout.html.j2 with a threshold of 1024px.

This should be reduced to allow mobile clients to navigate from page to page. Especially since index.html has no meaningful information.

Something like this would be super nice to get more information out there about each node.

Initial capability to backup data.

1. On some (configurable in config.json) interval, backup all the JSON data (eventually include DB(s))
2. Optionally allow for backing up of the statically rendered HTML too

if node and chat['text'].contains('TC2 BBS') and chat['text'].contains('Available commands')

Log attached:

20240718-1945.txt

In the Node view, there are links to "Elsewhere".

Example:
https://info.mtnme.sh/node_6eb383a5.html

Elsewhere
Armooo's MeshView
Bay Mesh Explorer
Liam's Map
MeshMap

Currently these links are hardcoded in frontend/src/pages/Node.tsx and frontend/src/pages/Map.tsx to values that are unique to the Bay Area.
Please allow these links to be customized in the config.

Right now we can only ever see DX information from the single node configured int the config.json. It'd be great to have the ability to store a selection so you can see the mesh from your node's POV

We should be validating the config and providing default values where necessary

We will want a redis component to cache some fragments and/or even pages to improve general performance, eventually. The API and the main loop would make the most use of this, but the bot might as well.

Neighbor nodes on the node detail popup on the map need to link to the node detail pages.

We need to create some kind of an app icon for MeshInfo. And then we need to put it in place for:

• public/favicon.ico
• public/apple-touch-icon.png
• public/apple-touch-icon-precomposed.png

Totally fine to put something quick and random as a temporary stopgap.

Current default client_id is meshinfo, which is totally fine if only a single client with this ID will connect to a MQTT server. If it collides with another, it disconnects that client. Therefore, we should make client_id in the Config be renamed to client_id_prefix and then have it generate a dynamic (or saved) suffix, perhaps a UUID (one with the timestamp decodable perhaps).

We need some tests, it's only right for us to do this when there's more than 1 dev. First dev to implement some tests gets 3 cookies.

Right now the save() functionality (which persists to JSON files and/or renders HTML files) is blocking and will interrupt the MQTT queue/stream, and also will block API requests. We need to make this an async operation.

We will likely need to make not only the method call async, but also do a .copy() on the objects so that other operations do not modify the contents of the references while it iterates.

Somehow emojis are just translating to an empty unicode char

Links in responses of Mesh Bot directs to https://svm1.meshinfo.network/ instead of source / intended network.

We need someone with design chops to make a logo for MeshAddicts and also for meshinfo.

From time to time, without any (for me) apparent reason, meshinfo crashes.

There appear to be several errors. The log file is attached.

meshinfo-1 ERROR Exceptio.txt

Add the option to use MapBox. This might be challenging to maintain two map implementations, but the value is that the host can benefit from more premium map features if willing to pay for MapBox (though the free tier offers a ton of value, especially for small sites, which these Meshtastic mesh sites should be).

@daviesgeek I will coordinate with you when this becomes a need in the React app (and can help a lot).

Need to make this more friendly for users.

• move Caddyfile to Caddyfile.sample
• add Caddyfile to .gitignore
• update README.md with cp Caddyfile.sample Caddyfile and instructions to edit during setup steps

For example see https://github.com/meshtastic/firmware/pull/4331/files#diff-9e0b139e1608f3cb528b6290c117286feb6102f2051567d2ffa8f0670c3ab107R72-R78

Feature request:

Add the ability to generate unique per-node username/password combos, possibly either using SQLite or MySQL. Integrate with MQTT container.

This would allow better access and control throughout a regional mesh network.

We need the ability to see how a node got to us. Much like Meshmap, we need to know who reported or "gated" the packet(s).

Now that we are looking to start moving to the SPA using React, we want to expose the data via an API. This API could also be used by the community of users that a MeshInfo is serving, perhaps to help power other projects.

Initial batch of endpoints considered are:

• /v1/nodes - Paginated array of all known nodes (or with some params, a filtered array of nodes)
• /v1/nodes/:id - Gets a node info (intelligently between hex and int ids)
• /v1/nodes/:id/texts
• /v1/nodes/:id/telemetry
• /v1/nodes/:id/traceroutes
• /v1/server/config - The server's configuration (useful for showing server details on UI)
• /v1/telemetry - Paginated array of telemetry (filterable)
• /v1/traceroutes - Paginated array of traceroutes (filterable)

I have some values like -4.47034800288293e-08% for relative humidity will make round(2) fail in the template.

Some of the pages will use the hardware info of the nodes in order to display an image of the hardware. Preferably these should all go in public/images/hardware and be named based on their corresponding hardware integer ID (defined at https://buf.build/meshtastic/protobufs/docs/main:meshtastic#meshtastic.HardwareModel), thus a Heltec V3 is 43.png.

The images should have the following requirements:

• consistent sizing
• named NUM.png
• put in public/images/hardware/
• consistent in style as much as possible (though I recognize this is not perfect)
• alpha for the background if possible, otherwise white

We currently have JSON based decoding from MQTT, but we should add support for handling protobuf messages as well.

This is confusing when we see nodes with green/gray colors and no lines.

We should also clarify that online = last 2 hrs.

Right now config is defined in config.py as a dict, but realistically this is not ideal.

We probably need something that combines a standard JSON/YAML plus some additional dynamic massaging.

This is "neat"

but it doesn't work well for anyone running their own instance.

We need to dynamically style this based on the Mesh Name defined in the config.json.

Nodes that exclusively use encrypted channels and therefore only send encrypted messages will not be included in the database.

Getting a somewhat consistent crash of the meshinfo docker container with the following error:
UnicodeDecodeError: 'utf-8' codec can't decode bytes in position 1-2: invalid continuation byte

Full log: https://pastebin.ai/je0yo8ckb2

The container then restarts itself. Seems to happen somewhat consistently a few times per hour.
If you need to see the actual message being processed when it crashes, I may be able to retrieve that from the mqtt server before another one comes in and I become unsure which one is correct.

Any ideas?

A new node had some invalid telemetry today on .328

meshinfo_1 | | File "templates/static/node.html.j2", line 43, in block 'content'
meshinfo_1 | | {{ node.telemetry.temperature | round(1) }}°C
meshinfo_1 | | ^^^^^^^^^^^^^^^^^
meshinfo_1 | | File "/usr/local/lib/python3.12/site-packages/jinja2/filters.py", line 1169, in do_round
meshinfo_1 | | return round(value, precision)
meshinfo_1 | | ^^^^^^^^^^^^^^^^^^^^^^^
meshinfo_1 | | TypeError: type str doesn't define round method

nodes.json had;

"telemetry": {
  "relative_humidity": "NaN",
  "temperature": "NaN"
}

It also ended up in telenetry.json

meshinfo_1 | | File "templates/static/telemetry.html.j2", line 173, in block 'content'
meshinfo_1 | | {{ item.payload.temperature | round(2) }} °C

I've started this, but we need to refine it.

Hey, this is cool, thanks.

I have the desire for unicode but the arduino json currently does not support it. I was going a different path with a preprocessing solution of sorts.

Anyway i quickly knocked this up from what I've found and thought I'd share.

https://gist.github.com/quimnut/c5ae707c627ed5434b300f6e8a40ccf7

The main.py has bloated significantly, which was expected since this first started as an exploration but as become a real project since. We need to refactor it so that things are more modular and potentially testable.

Specifically add neighbors (both heard and heard by).