Files
MeshTerm/config.example.toml
T
Jean-Pierre MartineauandClaude Opus 5.5 e6f6cf2621 The README and the project documents are in ASD-STE100
The README, CONTRIBUTING, SECURITY, the docs index, the development
documents, the script READMEs, the comments of config.example.toml and
pyproject.toml, and the issue and pull request forms. The legal sections
of the README (attribution and licence) stay exactly as they were, between
ste: off and ste: on markers. The SignPath attribution line, the one-line
description of MeshTerm, every code block, and every URL do not change.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-10-06 21:44:55 -04:00

98 lines
4.4 KiB
TOML

# MeshTerm configuration: where things are, and which device to talk to.
# Copy this file to ~/.meshterm/config.toml (or give --db / --port on the CLI).
#
# This file does not have the settings for how MeshTerm itself behaves. These are the
# transmit cooldown, the message retries, and how much history MeshTerm keeps. They are
# preferences. They are in ~/.meshterm/preferences.toml, and you edit them on the
# Preferences page (or with `meshterm preferences set <key> <value>`).
# Each preference has a built-in default, so that file lists only what you changed.
#
# Profiles are optional. When you give no profile and none of --port, --ble, or --tcp,
# MeshTerm discovers the serial devices that are connected and the Bluetooth companions that
# are near. It lets you select one (interactively), or it uses the one device that is
# there. It remembers the last device that connected, and uses it as the default the next
# time. A network (TCP) companion is not discoverable. To name one, use --tcp host:port, a
# TCP profile, or the "add a network device" prompt of the picker. Define profiles below
# only to give your hardware names that do not change (for example --profile yagi,
# --profile handheld for Bluetooth, or --profile wifi for TCP).
# To make one of your own profiles the default, remove the comment mark below and write
# the name of the profile. While the line is a comment, MeshTerm finds the device by
# itself, as described above.
# default_profile = "s3"
# Open the radio link when the menu appears. When the value is false, MeshTerm opens the
# link later: when you turn on monitoring, or when a tool first needs the radio.
connect_on_start = true
# db_path = "C:/Users/you/meshterm/meshterm.db"
# Make one [profiles.<name>] block for each physical companion device.
[profiles.s3]
port = "COM5"
baudrate = 115200
description = "XIAO ESP32-S3 + Wio SX1262 serial companion"
[profiles.yagi]
port = "COM6"
description = "Yagi repeater (reaching the wider mesh)"
[profiles.local]
port = "COM7"
description = "Local-range repeater"
[profiles.observer]
port = "COM8"
description = "XIAO observer running a bot"
# A Bluetooth LE companion: give an `address` (from `meshterm devices`) and not a port.
# The line `transport = "ble"` is optional. An `address` alone means Bluetooth.
[profiles.handheld]
address = "AA:BB:CC:DD:EE:FF"
# transport = "ble"
# ble_pin = "123456" # only if your device needs a pairing PIN
description = "Pocket handheld over Bluetooth"
# A network (TCP) companion, such as a WiFi board or a meshcored-style proxy, at a
# host:port. Give a `host` (and an optional `tcp_port`, which is 5000 by default). A `host`
# alone means TCP, so the line `transport = "tcp"` is optional. A TCP companion is not
# discoverable. To reach one, use a profile, or --tcp host:port, or the "add a network
# device" prompt of the picker.
[profiles.wifi]
host = "192.168.1.50"
# tcp_port = 5000
# transport = "tcp"
description = "Basestation over WiFi"
# A radio on the own SPI bus of this machine: MeshTerm runs its node while the radio is
# connected. The default pins are the pins of the uConsole AIO v1. That board needs only
# this profile. The device screen also lists it, when /dev/spidev1.0 exists.
[profiles.aio]
transport = "spi"
# [profiles.aio.spi]
# en_pins = [27] # the AIO v2 powers its radio from pin 27
#
# The number of the /dev/gpiochip<n> that has the pins does not depend on the board. A
# uConsole CM4 has its 40-pin header on chip 0. A CM5 had it on chip 4 with its early
# kernels, and on chip 0 after Raspberry Pi made an alias there. Some later kernels use
# another number. For this reason, gpio_chip is -1 by default. This value finds the chip by
# its label (pinctrl-rp1 on a CM5, pinctrl-bcm2711 on a CM4, and `gpiodetect` lists them).
# If no chip has one of these labels, MeshTerm uses chip 0. Give a number only to
# override this:
# gpio_chip = 4
# Any other board must give its complete wiring: each pin and both switches. A key that
# you omit keeps the value of the AIO. Read the values from the meshtasticd config of the
# board. The values here are only an example. docs/guide/configuration.md shows which
# key matches which value.
# [profiles.hat.spi]
# bus_id = 0 # /dev/spidev0.0
# cs_id = 0
# reset_pin = 18
# busy_pin = 20
# irq_pin = 16
# txen_pin = 6
# rxen_pin = -1
# use_dio2_rf = false
# use_dio3_tcxo = false
# python = "/opt/radio/bin/python" # only to pick the Python that has openhop-core