Meshtastic-Python current_packet_id help

Support Python API
1

I was interested in identifying any packets (sendText messages) that get lost so I would be able to resend them but I noticed that when querying meshtastic.StreamInterface().myInfo the current_packet_id never changes (even after sending a new packet). Is there another way to get the current id of the most recent packet sent or should I increment the packet id myself? This can be valided with the script below which will query myInfo then send a new packet in a loop.

import meshtastic
import time
from pubsub import pub

class test:

def __init__(self):
    pub.subscribe(self.onReceive, "meshtastic.receive")
    self.interface = meshtastic.StreamInterface()

def onReceive(self, packet, interface):
    print(f"From {interface.devPath}: {packet}")

def main(self):

    for i in range(100):

        self.my_info = str(self.interface.myInfo)
        print(self.interface.myInfo)

        t_str = time.strftime("%a, %H:%M:%S", time.gmtime())
        self.interface.sendText(t_str, wantAck=True)

        time.sleep(10)

    self.interface.close()

cl = test()
cl.main()

1 Like
2

hmm - the right approach is really not possible because of something I forgot to do in the python API.

Every packet has a unique packet ID, the python API should generate that ID (currently it isn’t and the device is picking one). I’ve made a bug for this and should fix it by tuesday:

3

Awesome. Its most appreciated. I am very impressed with this project! I tested the range with (2) TTGO V1.1 433mhz today and was able to get transfers at 0.92 mile and reliable transfers at a little less than 0.5 mile. Incredible.

1 Like
4

Nice work, you can post your results here if you desire. Practical Range Test Results

5

Thanks! Fixed in this commit: https://github.com/meshtastic/Meshtastic-python/commit/331b83a95dbe4853b0c8db6b4ee3ef1859c00029

Released on pypi as:

6

Thanks for your help and the quick turn around! I’m now able to get the message ID from the sendText function.

1 Like
7

Btw In theory you should always receive back an ack or nak response with that id specified. (If you specified you want the packet sent reliably)