Unable to send a message via BLE

[adria0]

Unable to send a message via BLE

Streaming for receiving packets works well, but I'm unable to send messages. When I attempt to send one, the Bluetooth connection freezes, and no other operations can be performed.

I used an example from another repository (I can’t recall which one), which I assumed was functional, but I’m not sure if there’s an issue with it.

To Reproduce

use std::time::Duration;

use anyhow::Result;
use meshtastic::api::{ConnectedStreamApi, StreamApi};
use meshtastic::protobufs::MeshPacket;
use meshtastic::protobufs::PortNum;
use meshtastic::protobufs::{mesh_packet, Data};
use meshtastic::utils;
use meshtastic::utils::stream::BleId;

async fn send_to_meshtastic(stream_api: &mut ConnectedStreamApi, text: &str) -> Result<()> {
    // Create a text message data payload
    let data = Data {
        portnum: PortNum::TextMessageApp as i32,
        payload: text.as_bytes().to_vec(),
        want_response: false,
        ..Default::default()
    };

    // Create mesh packet for broadcast
    let mesh_packet = MeshPacket {
        to: 0xffffffff, // Broadcast address
        from: 0,        // Will be filled by the device
        channel: 0,
        id: 0, // Will be assigned by the device
        priority: mesh_packet::Priority::Default as i32,
        payload_variant: Some(mesh_packet::PayloadVariant::Decoded(data)),
        ..Default::default()
    };

    // Create the payload variant
    let payload_variant = Some(meshtastic::protobufs::to_radio::PayloadVariant::Packet(
        mesh_packet,
    ));

    // Send using the stream API's send_to_radio_packet method
    println!("Attempting to send packet to Meshtastic radio...");
    match stream_api.send_to_radio_packet(payload_variant).await {
        Ok(_) => {
            println!("Successfully sent to Meshtastic: {}", text);
            Ok(())
        }
        Err(e) => {
            println!("Failed to send to Meshtastic: {}", e);
            Err(anyhow::anyhow!("Failed to send message: {}", e))
        }
    }
}

#[tokio::main]
async fn main() -> Result<()> {
    let stream_api = StreamApi::new();

    let ble_device = std::env::args().nth(1).unwrap();

    let ble_stream =
        utils::stream::build_ble_stream(&BleId::from_name(&ble_device), Duration::from_secs(5))
            .await?;

    let (mut _decoded_listener, stream_api) = stream_api.connect(ble_stream).await;

    let config_id = utils::generate_rand_id();

    let mut stream_api = stream_api.configure(config_id).await?;
    send_to_meshtastic(&mut stream_api, "Hallo world").await?;

    let _stream_api = stream_api.disconnect().await?;

    Ok(())
}

Expected behavior
"Hallo world" is broadcasted

Additional context
Tested in OSX and Raspberry Pi.

[andrewdavidmackenzie]

Are you able to send using api.send_text()?
https://docs.rs/meshtastic/latest/meshtastic/api/struct.ConnectedStreamApi.html#method.send_text

I am using that successfully on Mac OS (Tahoe 26.1)

[andrewdavidmackenzie]

I just tried the above code on my macos (Tahoe 26.1) with my T-ECHO and it worked fine:

amackenz@amackenz-mac bug % cargo run -- Meshtastic_5171
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.20s
     Running `target/debug/meshchat Meshtastic_5171`
Attempting to send packet to Meshtastic radio...
Successfully sent to Meshtastic: Hallo world

[adria0]

The same @andrewdavidmackenzie, it does not fail, but I do not see my other node to receive anything (with Meshtastic GUI works ok). Can you verify that other nodes see the message, please.

Also using OSX 26.1

Also tried to use api.send_text() as you said, no errors, but I do not see any broadcasted message in other nodes, too.

// anyhow = "1.0.100"
// meshtastic = { git = "https://github.com/meshtastic/rust.git", rev = "0a3a9dae0e206f95f8a9219d726f6e01ffe641c6", features = ["tokio", "bluetooth-le"] }
// tokio = "1.48.0"

use std::convert::Infallible;
use std::time::Duration;

use meshtastic::api::StreamApi;
use meshtastic::packet::{PacketDestination, PacketRouter};
use meshtastic::protobufs::from_radio;
use meshtastic::types::{MeshChannel, NodeId};
use meshtastic::utils::stream::{BleId, build_ble_stream};

use anyhow::{Result, bail};

struct NoOpRouter(NodeId);
impl PacketRouter<(), Infallible> for NoOpRouter {
    fn handle_packet_from_radio(
        &mut self,
        _packet: meshtastic::protobufs::FromRadio,
    ) -> std::result::Result<(), Infallible> {
        Ok(())
    }

    fn handle_mesh_packet(
        &mut self,
        _packet: meshtastic::protobufs::MeshPacket,
    ) -> std::result::Result<(), Infallible> {
        Ok(())
    }

    fn source_node_id(&self) -> NodeId {
        self.0
    }
}

#[tokio::main]
async fn main() -> Result<()> {
    // Get device from first argument
    let ble_device = std::env::args().nth(1).unwrap();

    // Initialize BLE stream
    let ble_stream =
        build_ble_stream(&BleId::from_name(&ble_device), Duration::from_secs(5)).await?;
    let stream_api = StreamApi::new();
    let (mut packet_rx, stream_api) = stream_api.connect(ble_stream).await;
    let config_id = meshtastic::utils::generate_rand_id();
    let mut stream_api = stream_api.configure(config_id).await?;

    // Get MyInfo from the first message of stream
    let Some(from_radio) = packet_rx.recv().await else {
        bail!("No MyInfo received (1)");
    };
    let Some(payload) = from_radio.payload_variant else {
        bail!("No MyInfo received (2)");
    };
    let from_radio::PayloadVariant::MyInfo(my_node_info) = payload else {
        bail!("No MyInfo received (3)");
    };

    // Broadcast a message
    let mut packet_router = NoOpRouter(NodeId::new(my_node_info.my_node_num));
    stream_api
        .send_text(
            &mut packet_router,
            "hello send_text".into(),
            PacketDestination::Broadcast,
            false,
            MeshChannel::new(0)?,
        )
        .await?;

    // Disconnect

    let _ = stream_api.disconnect().await?;

    println!("Sent.");

    Ok(())
}

cc/ @lukipuki

[andrewdavidmackenzie]

I checked, you are right, message is not see on the channel by other nodes.

I use send_text() in my GUI app and can confirm it works, both sending to a Channel (default(0) and my own (1)) and to a particular NodeId.

Not sure why it wouldn't work in this example.

My code is like this:

match channel_id {
      ChannelId::Channel(channel_number) => {
          let _ = api
              .send_text(
                  &mut my_router,
                  text,
                  PacketDestination::Broadcast,
                  true,
                  MeshChannel::from(channel_number as u32),
              )
              .await;
      }
      ChannelId::Node(node_id) => {
          match api
              .send_text(
                  &mut my_router,
                  text.clone(),
                  PacketDestination::Node(NodeId::from(node_id)),
                  true,
                  MeshChannel::default(),
              )
              .await
          {

Differences I can see:

• I use "want ack = true", just defaulted to that without thinking about it. Changing in the sample code doesn't seem to make any difference.

Your code uses the real my_node_num from MyInfo (via the PacketRouter), as does mine, so both should be correct (print it out to check?), while the other code above uses:

id: 0, // Will be assigned by the device

I'll keep fiddling to see if I can get this code to work.

[andrewdavidmackenzie]

Unrelated: Why is the payload_variant to send_to_radio_packet optional?

What would that call be used for if passed None?

[andrewdavidmackenzie]

We might need to review code or debug the differences in values passed to send_to_radio_packet() when passed directly (which is not working in there examples) with the values passed when calling send_text --> send_mesh_packet --> send_to_radio_packet

Here is the MeshPacket from the sample code above that doesn't work:

MeshPacket: Some(
    Packet(
        MeshPacket {
            from: 0,
            to: 4294967295,
            channel: 0,
            id: 0,
            rx_time: 0,
            rx_snr: 0.0,
            hop_limit: 0,
            want_ack: false,
            priority: Default,
            rx_rssi: 0,
            delayed: NoDelay,
            via_mqtt: false,
            hop_start: 0,
            public_key: [],
            pki_encrypted: false,
            next_hop: 0,
            relay_node: 0,
            tx_after: 0,
            transport_mechanism: TransportInternal,
            payload_variant: Some(
                Decoded(
                    Data {
                        portnum: TextMessageApp,
                        payload: [
                            72,
                            97,
                            108,
                            108,
                            111,
                            32,
                            119,
                            111,
                            114,
                            108,
                            100,
                            32,
                            102,
                            114,
                            111,
                            109,
                            32,
                            67,
                            76,
                            73,
                            32,
                            116,
                            101,
                            115,
                            116,
                        ],
                        want_response: true,
                        dest: 0,
                        source: 0,
                        request_id: 0,
                        reply_id: 0,
                        emoji: 0,
                        bitfield: None,
                    },
                ),
            ),
        },
    ),
)

Here is a debug output of the payload variant being passed to send_to_radio_packet() that works, when send via send_text:

[andrewdavidmackenzie]

Differences I can see in the two packets above, one that works and one that doesn't:

• Failing packet has "from:" field 0, and comments that radio will fill it out (forcing my from ID in the code doesn't seem to fix this)
• Failing packet has "id:" field 0 also. I've tried setting "id:" with utils::generate_rand_id(), no change.
• "want ack" is true in working packet and false in the failing one (setting to true in example code doesn't seem to fix that either)
• I assume TransportInternal is 0
• In payload want_response is true in failing one, false in working one (changing that and retesting doesn't seem to fix it)

Although now I notice this error printed:
Error: Channel unexpectedly close
This seems to come from the disconnect() call, and I assume by changes introduced in master recently.

For reference, here is the MeshPacket with those changes but that still fails:

MeshPacket: Some(
    Packet(
        MeshPacket {
            from: 3746187261,
            to: 4294967295,
            channel: 0,
            id: 3654085379,
            rx_time: 0,
            rx_snr: 0.0,
            hop_limit: 0,
            want_ack: true,
            priority: Default,
            rx_rssi: 0,
            delayed: NoDelay,
            via_mqtt: false,
            hop_start: 0,
            public_key: [],
            pki_encrypted: false,
            next_hop: 0,
            relay_node: 0,
            tx_after: 0,
            transport_mechanism: TransportInternal,
            payload_variant: Some(
                Decoded(
                    Data {
                        portnum: TextMessageApp,
                        payload: [
                            72,
                            97,
                            108,
                            108,
                            111,
                            32,
                            119,
                            111,
                            114,
                            108,
                            100,
                            32,
                            102,
                            114,
                            111,
                            109,
                            32,
                            67,
                            76,
                            73,
                            32,
                            116,
                            101,
                            115,
                            116,
                        ],
                        want_response: false,
                        dest: 0,
                        source: 0,
                        request_id: 0,
                        reply_id: 0,
                        emoji: 0,
                        bitfield: None,
                    },
                ),
            ),
        },
    ),
)

[adria0]

Ok, found it.

Happens that somehow the api needs, in order to process the message, to process all pending feeds. Or it seems something like this. If we add

    loop {
        tokio::select! {
            Some(packet) = packet_rx.recv() => {}
            _ = tokio::time::sleep(Duration::from_millis(200)) => {
                break;
            }
        }
    }

after sending the message, it is broadcasted.

Thanks for the help @andrewdavidmackenzie !

I will add an small example about sending a message, it will help others.

[andrewdavidmackenzie]

Excellent!

So, it needs to process the incoming packets from the radio before being able to send?
(waiting for MyNodeInfo makes sense to get my_node_num for use in sending).

I think some more doc comment examples would be great, or adding a sending example in /examples would be great (will need to get the device name and pass as an arg like this).

I want to contribute one for the PacketRouter trait that may overlap a little bit, but still fine I think.

[lukipuki]

Ok, found it.

Happens that somehow the api needs, in order to process the message, to process all pending feeds. Or it seems something like this. If we add

    loop {
        tokio::select! {
            Some(packet) = packet_rx.recv() => {}
            _ = tokio::time::sleep(Duration::from_millis(200)) => {
                break;
            }
        }
    }

after sending the message, it is broadcasted.

Thanks for the help @andrewdavidmackenzie !

I will add an small example about sending a message, it will help others.

This is expected although not well documented. The duplex stream allocated for BLE communication has 1024 bytes. It will quickly get filled with incoming data, so your outgoing message is buffered and not sent. We could bump the length here, but it would not solve the problem:

rust/src/utils_internal.rs

Line 293 in 0a3a9da

let (client, mut server) = tokio::io::duplex(1024);

Whatever you bump the size to, it will eventually get filled if you do not consume incoming packets.

[andrewdavidmackenzie]

Interesting.

I would have expected a duplex stream to have two buffers, one incoming and one outgoing.
That would solve the problem, no?
(or firmware running in the device might run into a similar issue?)

[sjm42]

Very interesting indeed. I have made a dead simple meshbot that is responding to "!ping" messages,
and used the first example code as the basis actually. The difference is that I also read all the received stuff,
simply because the bot is supposed to react on certain messages received from the mesh.
All this means that I did not encounter that closed channel problem because the code is running continuously. :)

My working example (using tcp!) can be found here:

https://github.com/sjm42/meshbot

Thanks & sorry :)