### Summary
- Added a new method `get_channels_with_hash()` to the `Node` class.
- This method returns a list of dictionaries, each containing the channel index, role, name, and a hash value derived from the channel name and PSK.
- The hash is calculated using the existing `generate_hash` utility, ensuring consistency with other parts of the codebase.
- This utility makes it easier to programmatically access channel metadata, including a unique hash, for scripting, debugging, or integration purposes.
### Motivation
- The protobuf `Channel` objects do not include a hash value by default.
- This addition provides a Pythonic, easy-to-use way to access channel info and a unique hash for each channel, which can be useful for diagnostics, scripting, or UI display.
### Example Usage
```python
channels = node.get_channels_with_hash()
for ch in channels:
print(f"Index {ch['index']}: {ch['role']} name='{ch['name']}' hash={ch['hash']}")
```
### Impact
- No breaking changes; existing APIs and CLI output remain unchanged.
- The new method is additive and can be used where needed for enhanced channel introspection.
Overview
This small library (and example application) provides an easy API for sending and receiving messages over mesh radios. It also provides access to any of the operations/data available in the device user interface or the Android application. Events are delivered using a publish-subscribe model, and you can subscribe to only the message types you are interested in.
Call for Contributors
This library and CLI has gone without a consistent maintainer for a while, and there's many improvements that could be made. We're all volunteers here and help is extremely appreciated, whether in implementing your own needs or helping maintain the library and CLI in general.
If you're interested in contributing but don't have specific things you'd like to work on, look at the roadmap below!
Roadmap
This should always be considered a list in progress and flux -- inclusion doesn't guarantee implementation, and exclusion doesn't mean something's not wanted. GitHub issues are a great place to discuss ideas.
- Types
- type annotations throughout the codebase, and upgrading mypy running in CI to
--strict
- type annotations throughout the codebase, and upgrading mypy running in CI to
- async-friendliness
- CLI completeness & consistency
- the CLI should support all features of the firmware
- there should be a consistent output format available for shell scripting
- CLI input validation & documentation
- what arguments and options are compatible & incompatible with one another?
- can the options be restructured in a way that is more self-documenting?
- pubsub events should be documented clearly
- helpers for third-party code
- it should be easy to write a script that supports similar options to the CLI so many tools support the same ways of connecting to nodes
- data storage & processing
- there should be a standardized way of recording packets for later use, debugging, etc.
- a persistence layer could also keep track of nodes beyond nodedb, as the apps do
- a sqlite database schema and tools for writing to it may be a good starting point
- enable maps, charts, visualizations
