meshtastic --device /dev/cu.SLAB_USBtoUART --sendtext hello

By using above command on macbook (10.15.6 Catalina), sending text message from Device A to be able to test onReceive event on iOS client connected to Device B. Unfortunately, Device A immediately restarts by running this command.
1- How can I resolve this if it's already known issue?
2- Could you please share how can I debug such situations on device?

Apparently rasberry pi distributions use a different server from pypi.

They use:
https://www.piwheels.org/

And for some reason that server has a 3.0.0 version of easy-table. The recently added code in meshtastic was written against the pypi 0.0.4 version.

Hi,
I did a simple python script to send a message.
Device is connected to linux computer.
When I send first message it goes through to all nodes in the mesh network. I see it on all OLED displays.
Then, when I start script again, only the device attached to the computer shows message on a display, but all other nodes don't get this message.
If I wait around 3 minutes, and then start script again, message is transferred to all nodes in mesh netwok (I see message appear on all node displays).

I think there is a problem with module not releasing resources (serialport) after it is finnished, allthough I use interface.close ...

I run my script like this:
/root/mesh_sendtext1.py SOMEARGUMENT
and display should show text like: Message: SOMEARGUMENT

my script:
#!/usr/bin/env python3 import meshtastic, sys, atexit, os n = len(sys.argv) interface = meshtastic.SerialInterface(devPath="/dev/ttyUSB0") interface.sendText("Message: " + sys.argv[1]) print("\nStevilo argumentov: ",sys.argv[1]) atexit.register(print,"Program exited successfully!") interface.close() del interface os._exit(1)
Best regards,
Jinx

Please - if you just have a question (i.e. not a bug report or a feature proposal), post in our forum instead.

Describe the bug
Send text from python causes device to reboot and not reliably send text.

To Reproduce
Steps to reproduce the behavior:

1. Run the meshtastic python script with the following command:
2. ./meshtastic --device /dev/cu.SLAB_USBtoUART --sendtext "asdf"

The text does get sent, but very infrequently.

Expected behavior
I expect the device not to reboot and the string I'm sending to be sent.

Screenshots
Video: http://www.casler.org/temp/IMG_0069.MOV

Device info:

• Device model: tbeam 0.9.5

Smartphone information (if relevant):

• Device: MacOS
• OS: 10.15
• python 0.9.2

Additional context

??????????????????????????????????????????????????Emitting reboot packet for serial shell
booted, wake cause 0 (boot count 1), reset_reason=reset
I2C device found at address 0x34
axp192 PMU found
I2C device found at address 0x3c
ssd1306 display found
done
Meshtastic swver=0.9.5, hwver=1.0-US
Setting random seed 1234553040
Total heap: 265492
Free heap: 238292
Total PSRAM: 4194252
Free PSRAM: 4194252
NVS: UsedEntries 91, FreeEntries 539, AllEntries 630
chip id detect 0x3
Detect CHIP :AXP192
OUTPUT Register 0x5f
AXP192 Begin PASS
DCDC1: ENABLE
DCDC2: ENABLE
LDO2: ENABLE
LDO3: ENABLE
DCDC3: ENABLE
Exten: ENABLE

DCDC1: ENABLE
DCDC2: ENABLE
LDO2: ENABLE
LDO3: ENABLE
DCDC3: ENABLE
Exten: ENABLE
SRC REG:0xcf
Charging enable is enable
Charging target-voltage : 0x2
end when the charge current is lower than 10% of the set value
Charge current : 1000.00 mA
enable [0x40]val:0xdc
enable [0x41]val:0xff
enable [0x42]val:0x3b
Turning on screen
Read RTC time as 0 (cur millis 137) valid=0
Connected to UBLOX GPS successfully
NOTE! Recording critical error 5, address=0
RadioConfig reset!
Installing AES128 key!
Initial packet id 1082405854, numPacketId 4294967295
Loading saved preferences
Loaded saved preferences version 11
Installing AES256 key!
NODENUM=0x336a8dc1, dbsize=1
Starting meshradio init...
Set radio: name=oontz-2, config=2, ch=4, power=17
RF95 init result 0
[D][esp32-hal-cpu.c:189] setCpuFrequencyMhz(): PLL: 320 / 4 = 80 Mhz, APB: 80000000 Hz
Battery 4138mV 100%
sending owner !c44f336a8dc1/Cat/C
Update DB node 0x336a8dc1, rx_time=0
old user !c44f336a8dc1/Cat/C
updating changed=0 user !c44f336a8dc1/Cat/C
Adding packet record (id=0x408433e1 Fr0xc1 To0xff, WantAck0, HopLim3 Payload:User)
enqueuing for send (id=0x408433e1 Fr0xc1 To0xff, WantAck0, HopLim3 encrypted)
txGood=0,rxGood=0,rxBad=0
Screen: Started...
GPS fix type 0
Ignoring invalid GPS month=1, year=21268, unixtime=-1
New GPS pos lat=0.000000, lon=0.000000, alt=0, pdop=131.510000, heading=16675.930550, sats=204
Sending position to mesh
Update DB node 0x336a8dc1, rx_time=0
Node status update: 1 online, 1 total
showing standard frames
Providing time to mesh 0
Adding packet record (id=0x408433e2 Fr0xc1 To0xff, WantAck0, HopLim3 Payload:Position)
enqueuing for send (id=0x408433e2 Fr0xc1 To0xff, WantAck0, HopLim3 encrypted)
txGood=0,rxGood=0,rxBad=0
Starting low level send (id=0x408433e1 Fr0xc1 To0xff, WantAck0, HopLim3 encrypted)
showing standard frames
Transition powerFSM transition=boot timeout, from=BOOT to=ON
Setting bluetooth enable=1
Pre BT: 222456 heap size
Starting bluetooth
Completed sending (id=0x408433e1 Fr0xc1 To0xff, WantAck0, HopLim3 encrypted)
BLE task running
registered service 0x1800 with handle=1
registered service 0x1801 with handle=6
registered service 6ba1b218-15a8-461f-9fa8-5dcae273eafd with handle=10
registered service cb0b9a0b-a84c-4c0d-bdbb-442e3144ee30 with handle=18
BLE advertisting type=0, Private=0, Device Address: 39:c4:4f:33:6a:8d

Can not send yet, busyRx
Can not send yet, busyRx
Lora RX (id=0x9f2b9135 Fr0xc1 To0xff, WantAck0, HopLim0 encrypted rxSNR=10)
Rx someone rebroadcasting for us (id=0x9f2b9135 Fr0xc1 To0xff, WantAck0, HopLim0 encrypted rxSNR=10)
Adding packet record (id=0x9f2b9135 Fr0xc1 To0xff, WantAck0, HopLim0 encrypted rxSNR=10)
FIXME not implementedFIXME-update-db Sniffing packet
Delivering rx packet (id=0x9f2b9135 Fr0xc1 To0xff, WantAck0, HopLim0 Payload:Data WANTRESP rxSNR=10)
Trigger powerFSM 3
Ignoring incoming time, because we have a GPS
Forwarding to phone (id=0x9f2b9135 Fr0xc1 To0xff, WantAck0, HopLim0 Payload:Data WANTRESP rxSNR=10)
Update DB node 0x336a8dc1, rx_time=0
Received text msg from=0x336a8dc1, id=-1624534731, msg=asdf
Trigger powerFSM 5
Transition powerFSM transition=Received text, from=ON to=ON
Node status update: 1 online, 1 total
showing standard frames
Sending network ping to 0x336a8dc1, with position=1, wantReplies=0
Update DB node 0x336a8dc1, rx_time=0
Node status update: 1 online, 1 total
Providing time to mesh 0
Enqueuing internal message for the receive queue
Adding packet record (id=0x408433e3 Fr0xc1 To0xc1, WantAck0, HopLim3 Payload:Position)
FIXME not implementedFIXME-update-db Sniffing packet
Delivering rx packet (id=0x408433e3 Fr0xc1 To0xc1, WantAck0, HopLim3 Payload:Position)
Trigger powerFSM 3
Ignoring incoming time, because we have a GPS
Forwarding to phone (id=0x408433e3 Fr0xc1 To0xc1, WantAck0, HopLim3 Payload:Position)
Update DB node 0x336a8dc1, rx_time=0
Node status update: 1 online, 1 total
Telling client we have new packets 2
Telling client we have new packets 2
No BLE notify
Starting low level send (id=0x408433e2 Fr0xc1 To0xff, WantAck0, HopLim3 encrypted)
Completed sending (id=0x408433e2 Fr0xc1 To0xff, WantAck0, HopLim3 encrypted)
Lora RX (id=0x9f2b9135 Fr0xc1 To0xff, WantAck0, HopLim0 encrypted rxSNR=10.75)
Rx someone rebroadcasting for us (id=0x9f2b9135 Fr0xc1 To0xff, WantAck0, HopLim0 encrypted rxSNR=10.75)
Found existing packet record for fr=0x336a8dc1,to=0xffffffff,id=-1624534731
Ignoring incoming msg, because we've already seen it: fr=0x336a8dc1,to=0xffffffff,id=-1624534731,hop_limit=0
GPS fix type 0
Ignoring invalid GPS month=1, year=21268, unixtime=-1
Update DB node 0x336a8dc1, rx_time=0
Node status update: 1 online, 1 total
Trigger powerFSM 9
Trigger powerFSM 11
Transition powerFSM transition=serial API, from=ON to=SERIAL
Shutdown BT: 236288 heap size
Connected to radio
Sending text message asdf to ^all
Received: {'from': 862621121, 'to': 4294967295, 'decoded': {'data': {'typ': 'CLEAR_TEXT', 'payload': 'YXNkZg==', 'text': 'asdf'}, 'wantResponse': True}, 'id': 2670432565, 'rxSnr': 10.0, 'fromId': '!c44f336a8dc1', 'toId': '^all'}
Received: {'from': 862621121, 'to': 862621121, 'decoded': {'position': {'batteryLevel': 100}}, 'id': 1082405859, 'hopLimit': 3, 'fromId': '!c44f336a8dc1', 'toId': '!c44f336a8dc1'}
jmcasler@Jms-Mac-mini bin % ./meshtastic --device /dev/cu.SLAB_USBtoUART --sendtext "asdf"
Trigger powerFSM 9
Trigger powerFSM 11
Transition powerFSM transition=serial API, from=ON to=SERIAL
Shutdown BT: 236840 heap size
Connected to radio
Sending text message asdf to ^all
Trigger powerFSM 9
Trigger powerFSM 5
Trigger powerFSM 3
Received: {'from': 862621121, 'to': 862621121, 'decoded': {'successId': 2511103153}, 'id': 363619506, 'rxTime': 315964866, 'fromId': '!c44f336a8dc1', 'toId': '!c44f336a8dc1'}

I am using meshtastic python 1.1.49 and firmware 1.1.50 tlora-v1, I want to get rid of web server support in my node but if I send meshtastic --set wifi_ssid "" an error message is returned saying missing parameter needed. It appears the firmware not accepting empty strings. The host PC runs on Windows10.

See https://meshtastic.discourse.group/t/how-to-remove-web-server-support/2735

The help menu says that the default operation of --seriallog is to print to stdout. However, when running "meshtastic --seriallog", it throws an error saying that an argument is needed:

meshtastic: error: argument --seriallog: expected one argument

I may be flashing my TTGO Tbeam with the wrong firmware but I've tried a few different .bin files and continue to receive this message when running the "Example Usage" script provided on the API page:

https://meshtastic.github.io/Meshtastic-python/meshtastic/index.html#example-usage

ERROR:root:Error while handling message from radio This device needs a newer python client, please "pip install --upgrade meshtastic"

This is the script I'm messing with:

import meshtastic
from pubsub import pub

def onReceive(packet, interface): # called when a packet arrives
    print(f"Received: {packet}")

def onConnection(interface, topic=pub.AUTO_TOPIC): # called when we (re)connect to the radio
    # defaults to broadcast, specify a destination ID if you wish
    interface.sendText("hello mesh")

pub.subscribe(onReceive, "meshtastic.receive")
pub.subscribe(onConnection, "meshtastic.connection.established")
# By default will try to find a meshtastic device, otherwise provide a device path like /dev/ttyUSB0
interface = meshtastic.SerialInterface()

It would be nice if just running meshtastic without any arguments would simply display the help menu (rather than what appears to be the default action of "--seriallog stdout")

Version 1.2.10, --info reports "Channel URL https://mesh......" But --qr replies "serial interface has no attribute 'channelURL'"

Using FW V1.2.10:

If I direct the gpiowrb command to another node fc30 whilst I am connected to 1e28 via USB ie

meshtastic --port /dev/cu.SLAB_USBtoUART --dest '!d1c8fc30' --gpiowrb 13 1
Connected to radio
Writing GPIO mask 0x2000 with value 0x2000 to !d1c8fc30

The console then hangs and the connected node 1e28 just displays a repeating progress bar until I terminate it with ^C, but the destination node fc30 indeed does set/clear its bit on GPIO13.

Any ideas?
From: https://meshtastic.discourse.group/t/need-an-example-of-gpiowrb/1945/4?u=mike

If we start using tags in the releases then it makes pulling the latest release much easier using the API method recommended by GitHub. Currently, Meshtastic-Python doesn't have any tags. By doing this I can make the GUI pull whatever version of the firmware needed much easier for new users.

curl -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/meshtastic/Meshtastic-python/tags

This when configured will give the current tag which can then be used to grab the new release without having to filter for version numbers and such.

If anything other than an integer is passed to setpref, an error is returned.

"Connected to radio Setting preference wifi_ssid to myssid Can't set wifi_ssid due to invalid literal for int() with base 10: 'myssid'

Problem is here:

Add --setbluetoothpin for device that do not have screens. I would see this being used as more of a one off.

Above enhancement similar to meshtastic/firmware#357 This might be uses for bulk device provisioning for teams like AndroidTacticalAssaultKit-CIV

This should be set automatically (just like the androic client), so that the application client can optionally track sent messages.

Also .sendPacket should return the sent packet to the caller.

--SerialPlugin to output discovered Nodes in mesh to w/ GPS Coordinates to NMEA string

Created a PR for a new argument:

--reply

This automatically responds to messages with some stats of the received message, including the rxSnr -- very useful for range testing.

Based on the discourse at:

https://meshtastic.discourse.group/t/off-grid-field-test-meshtastic-python-heltec-custom-board-hop-connections/1188

When using the command line:
meshtastic --dest '!ac67b21bb0e8' --sendtext 'Hello e8'
Trigger powerFSM 9
Connected to radio
Sending text message Hello e8 to !ac67b21bb0e8
'dict' object has no attribute 'num'

See also description:
https://meshtastic.discourse.group/t/destination-node-id-format/1221?u=jl-eu

From one node, sending a byte string:
interface.sendData(byteData=b'123foobar')

results in base64-encoded value on the receiving end:
'decoded': {'data': {'payload': 'MTIzZm9vYmFy', 'typ': 'OPAQUE'}}

As in the issue title: this dependency is no longer on PyPI, and the Github user and all the associated repos have vanished.

If anyone wants to re-upload from a local copy they can probably acquire the PyPI project name if they do so quickly.

When using the library for the first time today, I ran into the error "AttributeError: 'str' object has no attribute 'device'. The stack trace does have the appropriate error message in it, but it looks like the format string used to return that message includes a .device that doesn't work on the mac I'm running on.

Traceback (most recent call last):
  File "./meshtastic-beacon.py", line 45, in <module>
    app.run(main)
  File "/Users/bensonk/Library/Python/3.7/lib/python/site-packages/absl/app.py", line 300, in run
    _run_main(main, args)
  File "/Users/bensonk/Library/Python/3.7/lib/python/site-packages/absl/app.py", line 251, in _run_main
    sys.exit(main(argv))
  File "./meshtastic-beacon.py", line 35, in main
    interface = meshtastic.StreamInterface(devPath=FLAGS.port)
  File "/Users/bensonk/Library/Python/3.7/lib/python/site-packages/meshtastic/__init__.py", line 439, in __init__
    f"Multiple ports detected, you must specify a device, such as {ports[0].device}")
AttributeError: 'str' object has no attribute 'device'

Hi
Maybe I'm getting it wrong, but to get text messages sent by app I have to subscribe to "meshtastic.receive.data" if I subscribe to "meshtastic.receive.text" I'm not getting any messages.

Device: tbeam
Firmware version: 1.0.0 and the version in my Branch.
Python API version: 1.0.8
Desktop OS version: Ubuntu 64bit 20.04.1 & MacOS 10.15.6

This happens in every combination between 1.0.0 and the WiFi / HTTP version in my branch and using Ubuntu and MacOS.

Conditions

1. meshtastic --device /dev/cu.SLAB_USBtoUART --info

2. meshtastic --device /dev/cu.SLAB_USBtoUART --setstr wifi_ssid "asdf" --debug

This will return a lot of stats, preference and channel settings. As soon as the script returns to the prompt, the device will "freeze". After freezing, none of the buttons will work. If on a screen that has dynamic elements, those elements will update.

Output from first run:

jmcasler@Mac-mini python scripts % /Users/jmcasler/Library/Python/3.7/bin/meshtastic --device /dev/cu.SLAB_USBtoUART --setstr wifi_ssid "" --debug
DEBUG:root:Connecting to /dev/cu.SLAB_USBtoUART
DEBUG:root:Sending: want_config_id: 42

Trigger powerFSM 9
Trigger powerFSM 11
Transition powerFSM transition=serial API, from=ON to=SERIAL
Shutdown BT: 236468 heap size
DEBUG:root:Received: {'myInfo': {'myNodeNum': 862626501, 'hasGps': True, 'numChannels': 13, 'region': '1.0-US', 'hwModel': 'tbeam', 'firmwareVersion': '1.0.0', 'packetIdBits': 32, 'currentPacketId': 1577150038, 'nodeNumBits': 32, 'messageTimeoutMsec': 300000, 'minAppVersion': 172}}
DEBUG:root:Received: {'radio': {'preferences': {'positionBroadcastSecs': 900, 'sendOwnerInterval': 4, 'waitBluetoothSecs': 120, 'screenOnSecs': 300, 'phoneTimeoutSecs': 900, 'phoneSdsTimeoutSec': 7200, 'meshSdsTimeoutSecs': 7200, 'sdsSecs': 31536000, 'lsSecs': 3600}, 'channelSettings': {'modemConfig': 'Bw125Cr48Sf4096', 'psk': '1PG7OiApB1nwvP+rz05pvw==', 'name': 'Default'}}}
DEBUG:root:Received: {'nodeInfo': {'num': 862626501, 'user': {'id': '!c44f336aa2c5', 'longName': 'Unknown a2c5', 'shortName': '?C5', 'macaddr': 'xE8zaqLF'}, 'position': {}}}
DEBUG:root:Received: {'configCompleteId': 42}
Connected to radio
Setting preference wifi_ssid to
Writing modified preferences to device
DEBUG:root:Sending: set_radio {
preferences {
position_broadcast_secs: 900
send_owner_interval: 4
wait_bluetooth_secs: 120
screen_on_secs: 300
phone_timeout_secs: 900
phone_sds_timeout_sec: 7200
mesh_sds_timeout_secs: 7200
sds_secs: 31536000
ls_secs: 3600
}
channel_settings {
modem_config: Bw125Cr48Sf4096
psk: "\324\361\273: )\007Y\360\274\377\253\317Ni\277"
name: "Default"
}
}

DEBUG:root:Closing serial stream
DEBUG:root:reader is exiting

On second run, the python script will not return any data except:

DEBUG:root:Connecting to /dev/cu.SLAB_USBtoUART
DEBUG:root:Sending: want_config_id: 42

Any string set by "--setstr" will not be saved into the device.

Note

About 1/10 of the time, the when device hangs, even the reset button doesn't work and the device needs to be power cycled.

Hi,

When sending data in the form `interface.sendData(b'some-bytes'), the following is thrown:

ERROR:root:Error handling FromRadio, possibly corrupted? 'typ'
Traceback (most recent call last):
  File "/home/tnwhitwell/workspace/scouts/meshtastic-scouts/.direnv/python-3.8.1/lib/python3.8/site-packages/meshtastic/__init__.py", line 460, in __reader
    self._handleFromRadio(self._rxBuf[HEADER_LEN:])
  File "/home/tnwhitwell/workspace/scouts/meshtastic-scouts/.direnv/python-3.8.1/lib/python3.8/site-packages/meshtastic/__init__.py", line 226, in _handleFromRadio
    self._handlePacketFromRadio(fromRadio.packet)
  File "/home/tnwhitwell/workspace/scouts/meshtastic-scouts/.direnv/python-3.8.1/lib/python3.8/site-packages/meshtastic/__init__.py", line 312, in _handlePacketFromRadio
    if asDict["decoded"]["data"]["typ"] == "CLEAR_TEXT":
KeyError: 'typ'

I've resolved this locally by changing
https://github.com/meshtastic/Meshtastic-python/blob/9da57e2d12ee440bd291d85f2ae64521529444ec/meshtastic/__init__.py#L310-L312

to:

            if "typ" in asDict["decoded"]["data"]:
                if asDict["decoded"]["data"]["typ"] == "CLEAR_TEXT":
                    asDict["decoded"]["data"]["text"] = meshPacket.decoded.data.payload.decode(
                        "utf-8")

I doubt this is actually the right solution, as the datatype is being set:
https://github.com/meshtastic/Meshtastic-python/blob/9da57e2d12ee440bd291d85f2ae64521529444ec/meshtastic/__init__.py#L114

Running it through the debugger, it appears mesh_pb2.Data.OPAQUE is resolving to False, and results in it not being transmitted? maybe?

https://github.com/meshtastic/Meshtastic-python/blob/0d7ef3a1096cd3bf462ec505affb631d15fe4ae6/meshtastic/__init__.py#L373-L374
This throws an exception if the message payload is raw binary (protobuf, layered encryption etc).
EDIT: ... which I understand that it shouldn't, but can still happen O:-)

/usr/local/opt/python-3.8.0/bin/meshtastic --setstr wifi_ssid asdf

Wil return:

Connected to radio
setPref() missing 1 required positional argument: 'val'

This change introduced the bug:

dd45429#diff-bf03b680564a46f99696f3adbd6c7a89

This was found while helping "devnull" from the forum with Raspberry Pi on python 3.7 and python 3.8.

Also reproduced on my Ubuntu on python 3.8.

I did some testing today and had a strange issue.
I used a program on my computer to captures the GPS positions, and send replies if it receives a message, so I can check if the LoRa is still in range.
This worked fine first, but after a short while, the replies sent from the computer didn't get through to the mobile node.
The computer got messages from my mobile node, generated replies and sent them to the attached node (they were showing on the display), but somehow they didn't transmit to my mobile node. Only after resetting the Node, I could get it working again.
My guess is that the attached node somehow gets stuck and doesn't send out messages it received over USB, but I don't know how to verify if that's acutely the case.

I used:
AppVersion 1.1.22
Firmware 1.1.23
Meshtastic-python 1.1.25

https://meshtastic.github.io/Meshtastic-python/meshtastic/index.html#meshtastic.MeshInterface

This page shows myNodeInfo as a SerialInterface property. The property name should be "myInfo".

When I run "meshtastic --sendtext some_message", onConnected() closes the interface before the message is sent. Since onConnected is called from a thread managed by pubsub, i'm not sure what the best way to resolve this is. Do we need a way to check if the message has been sent? Or to optionally block until it has been sent? Do we need to add an isBusy threading.Event to MeshInterface?

I'm using firmware 1.2.10, on helec and ttgo boards. Instructions for setting ssid and password from the python cli are wrong.

meshtastic --set wifi_ap_mode false --setstr wifi_ssid mywifissid --setstr wifi_password mywifipsw

should be

meshtastic --set wifi_ap_mode false --set wifi_ssid mywifissid --set wifi_password mywifipsw

Since upgrading to 1.2.6 I am no longer able to set the url via meshtastic --seturl <url>. I receive the following error

meshtastic --seturl <url>
Connected to radio
Incorrect padding

I am using the url from meshtastic --info from another node. Opening the QR code generated from the same node in the Android app works fine however.

Environment:
python 3.8.6
Windows 10
meshtastic-python 1.2.6
meshtastic-device 1.2.6

meshtastic 1.2.10 --help replies --set-router use --set router true instead of is_router true

Hi

I have been searching the site and some of the code to figure out, what settings can be made via the example application. No success. Sorry probably more a user question than a developer question who could for sure have found the answer looking at the meshtastic-device code.

What i am looking for is how to set the longName and shortName to get more usefull names when sending messages via the meshtastic-python.

-Benoît-

per this thread: https://meshtastic.discourse.group/t/preventing-confusion-on-channel-settings/637/6

meshtastic --setowner KR-Relay
doesn’t work for me using FW V1.2.10.

I get:

(base) MBP-5792:~ alport$ meshtastic --port /dev/cu.SLAB_USBtoUART --setowner KR-Relay
Connected to radio
Setting device owner to KR-Relay
Exception while handling connection: ‘SerialInterface’ object has no attribute ‘setOwner’

From:
https://meshtastic.discourse.group/t/howto-easy-create-a-relay-router-node/2105/9?u=mike

Portnums are being stored as strings instead of ints in packet['decoded']['data']['portnum'].

When I register a callback with "meshtastic.receive", and send the device a text message, I get the string 'TEXT_MESSAGE_APP' and not the enum value 1. The portnums_pb2.TEXT_MESSAGE_APP is an int == 1 so comparing the value from the packet to the portnums_pb2.TEXT_MESSAGE_APP returns False.

It would be swell to see some of the channel details that we see over the serial logs, such as actual frequency, with the --info argument.
For more context:
https://meshtastic.discourse.group/t/antenna-improved-range/227/102?u=thebentern

There seems to be a problem when starting the command line tool.

$ uname -a
Linux big-ubuntu 5.4.0-48-generic #52-Ubuntu SMP Thu Sep 10 10:58:49 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

$ pip3 install --upgrade meshtastic
Requirement already up-to-date: meshtastic in /home/claes/.local/lib/python3.8/site-packages (1.1.0)
Requirement already satisfied, skipping upgrade: pypubsub>=4.0.3 in /home/claes/.local/lib/python3.8/site-packages (from meshtastic) (4.0.3)
Requirement already satisfied, skipping upgrade: pygatt>=4.0.5 in /home/claes/.local/lib/python3.8/site-packages (from meshtastic) (4.0.5)
Requirement already satisfied, skipping upgrade: pyqrcode>=1.2.1 in /home/claes/.local/lib/python3.8/site-packages (from meshtastic) (1.2.1)
Requirement already satisfied, skipping upgrade: pexpect>=4.6.0 in /usr/lib/python3/dist-packages (from meshtastic) (4.6.0)
Requirement already satisfied, skipping upgrade: protobuf>=3.6.1 in /usr/lib/python3/dist-packages (from meshtastic) (3.6.1)
Requirement already satisfied, skipping upgrade: dotmap>=1.3.14 in /home/claes/.local/lib/python3.8/site-packages (from meshtastic) (1.3.14)
Requirement already satisfied, skipping upgrade: pyserial>=3.4 in /home/claes/.local/lib/python3.8/site-packages (from meshtastic) (3.4)
Requirement already satisfied, skipping upgrade: enum-compat in /home/claes/.local/lib/python3.8/site-packages (from pygatt>=4.0.5->meshtastic) (0.0.3)

$ meshtastic
Traceback (most recent call last):
  File "/home/claes/.local/bin/meshtastic", line 5, in <module>
    from meshtastic.__main__ import main
  File "/home/claes/.local/lib/python3.8/site-packages/meshtastic/__init__.py", line 69, in <module>
    from . import mesh_pb2
  File "/home/claes/.local/lib/python3.8/site-packages/meshtastic/mesh_pb2.py", line 22, in <module>
    create_key=_descriptor._internal_create_key,
AttributeError: module 'google.protobuf.descriptor' has no attribute '_internal_create_key'
$ 

I get the same fault when importing meshtastic in a python3 prompt.
Device has just been upgraded to 1.1.1

notes to self:

DEBUG:root:Publishing meshtastic.receive.routing: packet={'from': 681021528, 'to': 681021528, 'decoded': {'portnum': 'ROUTING_APP', 'requestId': 1806996963, 'payload': b'', 'routing': {'raw': }}, 'id': 1806996964, 'rxTime': 1614906133, 'priority': 'ACK', 'raw': from: 681021528 to: 681021528 decoded {   portnum: ROUTING_APP   request_id: 1806996963 } id: 1806996964 rx_time: 1614906133 priority: ACK , 'fromId': '!28979058', 'toId': '!28979058'} 
DEBUG:root:Publishing meshtastic.receive.admin: packet={'from': 681021528, 'to': 681021528, 'decoded': {'portnum': 'ADMIN_APP', 'payload': b'0\x04', 'wantResponse': True, 'admin': {'getChannelRequest': 4, 'raw': get_channel_request: 4 }}, 'id': 2137734321, 'rxTime': 1614906133, 'wantAck': True, 'raw': from: 681021528 to: 681021528 decoded {   portnum: ADMIN_APP   payload: "0\004"   want_response: true } id: 2137734321 rx_time: 1614906133 want_ack: true , 'fromId': '!28979058', 'toId': '!28979058'} 
DEBUG:root:Publishing meshtastic.receive.routing: packet={'from': 681021528, 'to': 681021528, 'decoded': {'portnum': 'ROUTING_APP', 'requestId': 2137734321, 'payload': b'', 'routing': {'raw': }}, 'id': 1806996965, 'rxTime': 1614906133, 'priority': 'ACK', 'raw': from: 681021528 to: 681021528 decoded {   portnum: ROUTING_APP   request_id: 2137734321 } id: 1806996965 rx_time: 1614906133 priority: ACK , 'fromId': '!28979058', 'toId': '!28979058'} 
DEBUG:root:Received channel index: 3 settings { } 
DEBUG:root:Requesting channel 4
DEBUG:root:Serializing protobuf as data: get_channel_request: 5 
DEBUG:root:Sending packet: to: 681021528 decoded {   portnum: ADMIN_APP   payload: "0\005"   want_response: true } id: 2137734322 want_ack: true 
DEBUG:root:Sending: packet {   to: 681021528   decoded {     portnum: ADMIN_APP     payload: "0\005"     want_response: true   }   id: 2137734322   want_ack: true } 
DEBUG:root:Publishing meshtastic.receive.admin: packet={'from': 681021528, 'to': 681021528, 'decoded': {'portnum': 'ADMIN_APP', 'payload': b':\x04\x08\x03\x12\x00', 'requestId': 2137734321, 'admin': {'getChannelResponse': {'index': 3, 'settings': {}}, 'raw': get_channel_response {   index: 3   settings {   } } }}, 'id': 1806996966, 'rxTime': 1614906133, 'hopLimit': 3, 'wantAck': True, 'raw': from: 681021528 to: 681021528 decoded {   portnum: ADMIN_APP   payload: ":\004\010\003\022\000"   request_id: 2137734321 } id: 1806996966 rx_time: 1614906133 hop_limit: 3 want_ack: true , 'fromId': '!28979058', 'toId': '!28979058'} 
DEBUG:root:Publishing meshtastic.receive.routing: packet={'from': 681021528, 'to': 681021528, 'decoded': {'portnum': 'ROUTING_APP', 'requestId': 1806996966, 'payload': b'', 'routing': {'raw': }}, 'id': 1806996967, 'rxTime': 1614906133, 'priority': 'ACK', 'raw': from: 681021528 to: 681021528 decoded {   portnum: ROUTING_APP   request_id: 1806996966 } id: 1806996967 rx_time: 1614906133 priority: ACK , 'fromId': '!28979058', 'toId': '!28979058'} 
DEBUG:root:Publishing meshtastic.receive.admin: packet={'from': 681021528, 'to': 681021528, 'decoded': {'portnum': 'ADMIN_APP', 'payload': b'0\x05', 'wantResponse': True, 'admin': {'getChannelRequest': 5, 'raw': get_channel_request: 5 }}, 'id': 2137734322, 'rxTime': 1614906133, 'wantAck': True, 'raw': from: 681021528 to: 681021528 decoded {   portnum: ADMIN_APP   payload: "0\005"   want_response: true } id: 2137734322 rx_time: 1614906133 want_ack: true , 'fromId': '!28979058', 'toId': '!28979058'} 
DEBUG:root:Publishing meshtastic.receive.routing: packet={'from': 681021528, 'to': 681021528, 'decoded': {'portnum': 'ROUTING_APP', 'requestId': 2137734322, 'payload': b'', 'routing': {'raw': }}, 'id': 1806996968, 'rxTime': 1614906133, 'priority': 'ACK', 'raw': from: 681021528 to: 681021528 decoded {   portnum: ROUTING_APP   request_id: 2137734322 } id: 1806996968 rx_time: 1614906133 priority: ACK , 'fromId': '!28979058', 'toId': '!28979058'} 
DEBUG:root:Publishing meshtastic.receive.routing: packet={'from': 681021528, 'to': 681021528, 'decoded': {'portnum': 'ROUTING_APP', 'requestId': 1806996969, 'payload': b'', 'routing': {'raw': }}, 'id': 1806996970, 'rxTime': 1614906133, 'priority': 'ACK', 'raw': from: 681021528 to: 681021528 decoded {   portnum: ROUTING_APP   request_id: 1806996969 } id: 1806996970 rx_time: 1614906133 priority: ACK , 'fromId': '!28979058', 'toId': '!28979058'} 
^[[ADEBUG:root:Publishing meshtastic.receive.admin: packet={'from': 681021528, 'to': 681021528, 'decoded': {'portnum': 'ADMIN_APP', 'payload': b'0\x06', 'wantResponse': True, 'admin': {'getChannelRequest': 6, 'raw': get_channel_request: 6 }}, 'id': 4291410402, 'rxTime': 1614906133, 'wantAck': True, 'priority': 'RELIABLE', 'raw': from: 681021528 to: 681021528 decoded {   portnum: ADMIN_APP   payload: "0\006"   want_response: true } id: 4291410402 rx_time: 1614906133 want_ack: true priority: RELIABLE , 'fromId': '!28979058', 'toId': '!28979058'} 
DEBUG:root:Publishing meshtastic.receive.routing: packet={'from': 681021528, 'to': 681021528, 'decoded': {'portnum': 'ROUTING_APP', 'requestId': 4291410402, 'payload': b'', 'routing': {'raw': }}, 'id': 1806996971, 'rxTime': 1614906133, 'priority': 'ACK', 'raw': from: 681021528 to: 681021528 decoded {   portnum: ROUTING_APP   request_id: 4291410402 } id: 1806996971 rx_time: 1614906133 priority: ACK , 'fromId': '!28979058', 'toId': '!28979058'} 
DEBUG:root:Publishing meshtastic.receive.admin: packet={'from': 681021528, 'to': 681021528, 'decoded': {'portnum': 'ADMIN_APP', 'payload': b':\x04\x08\x05\x12\x00', 'requestId': 4291410402, 'admin': {'getChannelResponse': {'index': 5, 'settings': {}}, 'raw': get_channel_response {   index: 5   settings {   } } }}, 'id': 1806996972, 'rxTime': 1614906133, 'hopLimit': 3, 'wantAck': True, 'raw': from: 681021528 to: 681021528 decoded {   portnum: ADMIN_APP   payload: ":\004\010\005\022\000"   request_id: 4291410402 } id: 1806996972 rx_time: 1614906133 hop_limit: 3 want_ack: true , 'fromId': '!28979058', 'toId': '!28979058'} 
DEBUG:root:Publishing meshtastic.receive.routing: packet={'from': 681021528, 'to': 681021528, 'decoded': {'portnum': 'ROUTING_APP', 'requestId': 1806996972, 'payload': b'', 'routing': {'raw': }}, 'id': 1806996973, 'rxTime': 1614906133, 'priority': 'ACK', 'raw': from: 681021528 to: 681021528 decoded {   portnum: ROUTING_APP   request_id: 1806996972 } id: 1806996973 rx_time: 1614906133 priority: ACK , 'fromId': '!28979058', 'toId': '!28979058'} 
Traceback (most recent call last):

See forum post for initial detail about this issue: https://meshtastic.discourse.group/t/python-tcp-interface-close-blocking-for-arbitrary-amount-of-time/2035/1.

Description: calling interface.close() doesn't close the connection until an event arrives on the meshtastic.receive topic regardless of whether we are subscribed to that topic or not. I have worked around this issue by adding an explicit data sent command just before interface.close(). Using sendText is undesirable because I don't want messages to show up for every API open/close so I do:
interface.sendData(b'api closing')
just before I call interface.close() and this reliably allows the interface to close every time.
I have also tried explicitly unsubscribing from all topics, but that doesn't have any effect.

The example script is in the forum post, but it's literally just creating a new TCPInterface and then calling close on it with nothing in between.

To Reproduce
Run the python script. The first run of the script will work successfully. Subsequent runs will fail to close in a timely manner. Unblock by sending/receiving a message.

Expectation
Every time I call interface.close(), I shouldn't have to wait any significant amount of time for it to close and it should close regardless of whether there's messages on the message topic.

Device info:

• Device model: tbeam
• Software Version: 1.1.30

Additional Context
Here's a doc that contains the serial output from multiple runs.
https://docs.google.com/document/d/1QnsyCvWVey8a6hTCSooTRB6YhtqSoZEckWCGA0QG9U4/edit?usp=sharing

Setup.py is crashing for me

PS C:\Users\Charles\Documents\GitHub\Meshtastic\Meshtastic-python> ./setup.py install
Traceback (most recent call last):
  File "C:\Users\Charles\Documents\GitHub\Meshtastic\Meshtastic-python\setup.py", line 10, in <module>
    long_description = fh.read()
  File "C:\Python38\lib\encodings\cp1252.py", line 23, in decode
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 957: character maps to <undefined>

It seems like it's failing to parse the special-quotes in README.md, since changing those to standard-quotes allows setup to proceed:

Missing a comma in setup.py

Error:

Fix is to add a comma in setup.py

Plan

• Map node nums to IP address 10.x.y.z. Where x can be selected by the user but defaults to 115 ('M' for meshtastic). Y and Z are the last two bytes of the meshtastic Node ID. Given the small sizes of current meshes, the chance of duplicate Y/Z pairs is very low. If this proof of concept works well, a more robust mapping can be constructed.
• Expose A TUN network 'device' named 'mesh0'.
• Any packets received on that device will be either delivered into the mesh (if the address is valid) or dropped (with a log error) if not. They will be marked as an IP packet by using a special reserved app number for that purpose. Messages will be sent as non-reliable, with a max hop of 1 (to allow one level of forwarding within the mesh)
• Any IP packets (based on the app number) that are received FROM the mesh will be written to the TUN device (and then presumably delivered to linux apps)
• The MTU will be quite low - to fit inside one lora packet.
• Packets sent to the broadcast mask for the 10.115.y.z network will be sent using the meshtastic broadcast address.

Misc notes on this idea

python libs

• A good gist on tap/tun from python (see comments re python3): https://gist.github.com/glacjay/585369
• Even better a lib (uses ioctl python calls): https://pypi.org/project/python-pytuntap/
• Or this lib is more popular (but uses custom c code) https://pypi.org/project/python-pytun/

tutorials

• https://backreference.org/2010/03/26/tuntap-interface-tutorial/#:~:text=Tun%2Ftap%20interfaces%20are%20a,whatever%20they%20like%20with%20it.
• probably want TUN not TAP. Map nodenums to IP nums in the TBD IP range. https://en.wikipedia.org/wiki/TUN/TAP

Hi,

I'm trying to make a dashboard for use on scout camps, using meshtastic as the transport method.

I've gotten it up and running and have two nodes communicating, and can happily send messages between them using python. However, as soon as I start flask up within the same python app, I start seeing weird errors:

WARNING:werkzeug:WebSocket transport not available. Install eventlet or gevent and gevent-websocket for improved performance.
 * Serving Flask app "app" (lazy loading)
 * Environment: development
 * Debug mode: on
INFO:werkzeug: * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)
INFO:werkzeug: * Restarting with stat
Traceback (most recent call last):
  File "/home/tnwhitwell/workspace/scouts/meshtastic-scouts/.direnv/python-3.8.1/lib/python3.8/site-packages/serial/serialposix.py", line 310, in _reconfigure_port
    fcntl.flock(self.fd, fcntl.LOCK_EX | fcntl.LOCK_NB)
BlockingIOError: [Errno 11] Resource temporarily unavailable

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/tnwhitwell/workspace/scouts/meshtastic-scouts/app.py", line 141, in <module>
    meshDevice = ScoutMesh()
  File "/home/tnwhitwell/workspace/scouts/meshtastic-scouts/my_meshtastic.py", line 11, in __init__
    self.interface = meshtastic.StreamInterface()
  File "/home/tnwhitwell/workspace/scouts/meshtastic-scouts/.direnv/python-3.8.1/lib/python3.8/site-packages/meshtastic/__init__.py", line 391, in __init__
    self.stream = serial.Serial(
  File "/home/tnwhitwell/workspace/scouts/meshtastic-scouts/.direnv/python-3.8.1/lib/python3.8/site-packages/serial/serialutil.py", line 240, in __init__
    self.open()
  File "/home/tnwhitwell/workspace/scouts/meshtastic-scouts/.direnv/python-3.8.1/lib/python3.8/site-packages/serial/serialposix.py", line 272, in open
    self._reconfigure_port(force_update=True)
  File "/home/tnwhitwell/workspace/scouts/meshtastic-scouts/.direnv/python-3.8.1/lib/python3.8/site-packages/serial/serialposix.py", line 312, in _reconfigure_port
    raise SerialException(msg.errno, "Could not exclusively lock port {}: {}".format(self._port, msg))
serial.serialutil.SerialException: [Errno 11] Could not exclusively lock port /dev/ttyUSB0: [Errno 11] Resource temporarily unavailable

code:

    meshDevice = ScoutMesh()
    meshDevice.subscribe(extract_mesh_message, "meshtastic.receive")
    # meshDevice.interface.close()
    time.sleep(5)
    socketio.run(app)

(ScoutMesh is a simple wrapper class that provides a subscribe method, without importing pubsub all over the place)

If I close the interface, the server starts up, if I don't run the flask server, I don't see any issues.

I don't suppose you'd know off-hand where this issue may come from?

Need a --version flag of the meshtastic CLI tool so users can easily discover the currently running version of the tool

It appears that the manifest is missing at least one file necessary to build
from the sdist for version 0.5.1. You're in good company, about 5% of other
projects updated in the last year are also missing files.

+ /tmp/venv/bin/pip3 wheel --no-binary meshtastic -w /tmp/ext meshtastic==0.5.1
Looking in indexes: http://10.10.0.139:9191/root/pypi/+simple/
Collecting meshtastic==0.5.1
  Downloading http://10.10.0.139:9191/root/pypi/%2Bf/8ed/52fe4d06cb0e4/meshtastic-0.5.1.tar.gz (11 kB)
    ERROR: Command errored out with exit status 1:
     command: /tmp/venv/bin/python3 -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-wheel-jd7i0a45/meshtastic/setup.py'"'"'; __file__='"'"'/tmp/pip-wheel-jd7i0a45/meshtastic/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info --egg-base /tmp/pip-wheel-jd7i0a45/meshtastic/pip-egg-info
         cwd: /tmp/pip-wheel-jd7i0a45/meshtastic/
    Complete output (5 lines):
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-wheel-jd7i0a45/meshtastic/setup.py", line 7, in <module>
        with open("README.md", "r") as fh:
    FileNotFoundError: [Errno 2] No such file or directory: 'README.md'
    ----------------------------------------
ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.

reported by @dinthenorth in the alpha tester thread. alas, I haven't yet been able to reproduce this. My run seems successful:

~/development/meshtastic/Meshtastic-python$ meshtastic --set position_broadcast_secs 60 --set wait_bluetooth_secs 28800
rm: cannot remove 'log_*': No such file or directory
Node changed: {'num': 2885173400, 'user': {'id': '!2462abf84098', 'longName': 'Unknown 4098', 'shortName': '?98', 'macaddr': 'JGKr+ECY'}, 'position': {'batteryLevel': 100, 'time': 1605398970}}
Connected to radio
Setting position_broadcast_secs to 60
Setting wait_bluetooth_secs to 28800
Writing modified preferences to device
~/development/meshtastic/Meshtastic-python$ meshtastic --info
Node changed: {'num': 2885173400, 'user': {'id': '!2462abf84098', 'longName': 'Unknown 4098', 'shortName': '?98', 'macaddr': 'JGKr+ECY'}, 'position': {'batteryLevel': 100, 'time': 1605398970}}
Connected to radio
my_node_num: 2885173400
has_gps: true
num_channels: 10
region: "1.0"
hw_model: "tbeam"
firmware_version: "1.1.8"
packet_id_bits: 32
current_packet_id: 1401156767
node_num_bits: 32
message_timeout_msec: 300000
min_app_version: 172

preferences {
  position_broadcast_secs: 60
  wait_bluetooth_secs: 28800
  ls_secs: 300
  region: TW
}
channel_settings {
  modem_config: Bw125Cr48Sf4096
  psk: "\324\361\273: )\007Y\360\274\377\253\317Ni\277"
  name: "Default"
}

Channel URL https://www.meshtastic.org/c/#GAMiENTxuzogKQdZ8Lz_q89Oab8qB0RlZmF1bHQ=
Nodes in mesh:
{'num': 2885173400, 'user': {'id': '!2462abf84098', 'longName': 'Unknown 4098', 'shortName': '?98', 'macaddr': 'JGKr+ECY'}, 'position': {'batteryLevel': 100, 'time': 1605398970}}

To folks who see this problem a couple of questions:

1. can you try "pip3 install --upgrade meshtastic" to make sure you have the latest python tool?
2. What OS is your desktop computer?

I got this error when trying to set psk to empty meshtastic --setchan psk ""

Can’t set psk due to Cannot set ChannelSettings.psk to ‘’: ‘’ has type <class ‘str’>, but expected one of: (<class ‘bytes’>,)

It appear to be a data type issue on the python app.

I was wondering whether it might be a good idea to add a switch to format the output of

meshtastic --info

in tabular form and reduce data to a minimum when just a quick glance at the mesh status is required.

Output examples:

It could be invoked with

meshtastic --nodes

Reference: https://meshtastic.discourse.group/t/simplified-tabular-output-of-meshtastic-info/2468