generated/mesh.pb
library
Classes
-
ChunkedPayload
-
-
ChunkedPayloadResponse
-
Responses to a ChunkedPayload request
-
ClientNotification
-
A notification message from the device to the client
To be used for important messages that should to be displayed to the user
in the form of push notifications or validation messages when saving
invalid configuration.
-
Compressed
-
Compressed message payload
-
Constants
-
Shared constants between device and phone
-
CriticalErrorCode
-
Error codes for critical errors
The device might report these fault codes on the screen.
If you encounter a fault code, please post on the meshtastic.discourse.group
and we'll try to help.
-
Data
-
(Formerly called SubPacket)
The payload portion fo a packet, this is the actual bytes that are sent
inside a radio packet (because from/to are broken out by the comms library)
-
DeviceMetadata
-
Device metadata response
-
DuplicatedPublicKey
-
-
ExcludedModules
-
Enum for modules excluded from a device's configuration.
Each value represents a ModuleConfigType that can be toggled as excluded
by setting its corresponding bit in the
excluded_modules bitmask field.
-
FileInfo
-
Individual File info for the device
-
FirmwareEdition
-
Enum to indicate to clients whether this firmware is a special firmware build, like an event.
The first 16 values are reserved for non-event special firmwares, like the Smart Citizen use case.
-
FromRadio
-
Packets from the radio to the phone will appear on the fromRadio characteristic.
It will support READ and NOTIFY. When a new packet arrives the device will BLE notify?
It will sit in that descriptor until consumed by the phone,
at which point the next item in the FIFO will be populated.
-
HardwareModel
-
Note: these enum names must EXACTLY match the string used in the device
bin/build-all.sh script.
Because they will be used to find firmware filenames in the android app for OTA updates.
To match the old style filenames, _ is converted to -, p is converted to .
-
Heartbeat
-
A heartbeat message is sent to the node from the client to keep the connection alive.
This is currently only needed to keep serial connections alive, but can be used by any PhoneAPI.
-
KeyVerification
-
The actual over-the-mesh message doing KeyVerification
-
KeyVerificationFinal
-
-
KeyVerificationNumberInform
-
-
KeyVerificationNumberRequest
-
-
LogRecord
-
Debug output from the device.
To minimize the size of records inside the device code, if a time/source/level is not set
on the message it is assumed to be a continuation of the previously sent message.
This allows the device code to use fixed maxlen 64 byte strings for messages,
and then extend as needed by emitting multiple records.
-
LogRecord_Level
-
Log levels, chosen to match python logging conventions.
-
LowEntropyKey
-
-
MeshPacket
-
A packet envelope sent/received over the mesh
only payload_variant is sent in the payload portion of the LORA packet.
The other fields are either not sent at all, or sent in the special 16 byte LORA header.
-
MeshPacket_Delayed
-
Identify if this is a delayed packet
-
MeshPacket_Priority
-
The priority of this message for sending.
Higher priorities are sent first (when managing the transmit queue).
This field is never sent over the air, it is only used internally inside of a local device node.
API clients (either on the local node or connected directly to the node)
can set this parameter if necessary.
(values must be <= 127 to keep protobuf field to one byte in size.
Detailed background on this field:
I noticed a funny side effect of lora being so slow: Usually when making
a protocol there isn’t much need to use message priority to change the order
of transmission (because interfaces are fairly fast).
But for lora where packets can take a few seconds each, it is very important
to make sure that critical packets are sent ASAP.
In the case of meshtastic that means we want to send protocol acks as soon as possible
(to prevent unneeded retransmissions), we want routing messages to be sent next,
then messages marked as reliable and finally 'background' packets like periodic position updates.
So I bit the bullet and implemented a new (internal - not sent over the air)
field in MeshPacket called 'priority'.
And the transmission queue in the router object is now a priority queue.
-
MeshPacket_TransportMechanism
-
Enum to identify which transport mechanism this packet arrived over
-
MqttClientProxyMessage
-
This message will be proxied over the PhoneAPI for the client to deliver to the MQTT server
-
MyNodeInfo
-
Unique local debugging info for this node
Note: we don't include position or the user info, because that will come in the
Sent to the phone in response to WantNodes.
-
Neighbor
-
A single edge in the mesh
-
NeighborInfo
-
Full info on edges for a single node
-
NodeInfo
-
The bluetooth to device link:
Old BTLE protocol docs from TODO, merge in above and make real docs...
use protocol buffers, and NanoPB
messages from device to phone:
POSITION_UPDATE (..., time)
TEXT_RECEIVED(from, text, time)
OPAQUE_RECEIVED(from, payload, time) (for signal messages or other applications)
messages from phone to device:
SET_MYID(id, human readable long, human readable short) (send down the unique ID
string used for this node, a human readable string shown for that id, and a very
short human readable string suitable for oled screen) SEND_OPAQUE(dest, payload)
(for signal messages or other applications) SEND_TEXT(dest, text) Get all
nodes() (returns list of nodes, with full info, last time seen, loc, battery
level etc) SET_CONFIG (switches device to a new set of radio params and
preshared key, drops all existing nodes, force our node to rejoin this new group)
Full information about a node on the mesh
-
NodeRemoteHardwarePin
-
RemoteHardwarePins associated with a node
-
Position
-
A GPS Position
-
Position_AltSource
-
How the altitude was acquired: manual, GPS int/ext, etc
Default: same as location_source if present
-
Position_LocSource
-
How the location was acquired: manual, onboard GPS, external (EUD) GPS
-
QueueStatus
-
-
resend_chunks
-
Wrapper message for broken repeated oneof support
-
RouteDiscovery
-
A message used in a traceroute
-
Routing
-
A Routing control Data packet handled by the routing module
-
Routing_Error
-
A failure in delivering a message (usually used for routing control messages, but might be provided in addition to ack.fail_id to provide
details on the type of failure).
-
ToRadio
-
Packets/commands to the radio will be written (reliably) to the toRadio characteristic.
Once the write completes the phone can assume it is handled.
-
User
-
Broadcast when a newly powered mesh node wants to find a node num it can use
Sent from the phone over bluetooth to set the user id for the owner of this node.
Also sent from nodes to each other when a new node signs on (so all clients can have this info)
The algorithm is as follows:
when a node starts up, it broadcasts their user and the normal flow is for all
other nodes to reply with their User as well (so the new node can build its nodedb)
If a node ever receives a User (not just the first broadcast) message where
the sender node number equals our node number, that indicates a collision has
occurred and the following steps should happen:
If the receiving node (that was already in the mesh)'s macaddr is LOWER than the
new User who just tried to sign in: it gets to keep its nodenum.
We send a broadcast message of OUR User (we use a broadcast so that the other node can
receive our message, considering we have the same id - it also serves to let
observers correct their nodedb) - this case is rare so it should be okay.
If any node receives a User where the macaddr is GTE than their local macaddr,
they have been vetoed and should pick a new random nodenum (filtering against
whatever it knows about the nodedb) and rebroadcast their User.
A few nodenums are reserved and will never be requested:
0xff - broadcast
0 through 3 - for future use
-
Waypoint
-
Waypoint message, used to share arbitrary locations across the mesh
