self.currentPacketId = (self.currentPacketId + 1) & 0xffffffff TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'

Support Python API
1

Hi,

I try to send data, I’m on MacOS up to date
code:
import meshtastic
interface = meshtastic.StreamInterface("/dev/tty.SLAB_USBtoUART")
# By default will try to find a meshtastic
# device, otherwise provide a device path like /dev/ttyUSB0

    interface.sendText("hello mesh")
    # or sendData to send binary data, see documentations for other options.

Error:
Traceback (most recent call last):
File “test.py”, line 6, in
interface.sendText(“hello mesh”)
File “/Users/user/git/meshtas/lib/python3.7/site-packages/meshtastic/init.py”, line 110, in sendText
dataType=mesh_pb2.Data.CLEAR_TEXT, wantAck=wantAck, wantResponse=wantResponse)
File “/Users/user/git/meshtas/lib/python3.7/site-packages/meshtastic/init.py”, line 121, in sendData
return self.sendPacket(meshPacket, destinationId, wantAck=wantAck)
File “/Users/user/git/meshtas/lib/python3.7/site-packages/meshtastic/init.py”, line 173, in sendPacket
meshPacket.id = self._generatePacketId()
File “/Users/user/git/meshtas/lib/python3.7/site-packages/meshtastic/init.py”, line 190, in _generatePacketId
self.currentPacketId = (self.currentPacketId + 1) & 0xffffffff
TypeError: unsupported operand type(s) for +: ‘NoneType’ and ‘int’

2

oh yah - see my other comment. I accidentally broke API support for old firmwares (pre 0.9). I’ll fix. (Or you can update the firmware per the README - it is pretty painless and highly recommended)

3

Hi this is strange I update both modules with 0.9.5 (Handling FromRadio, possibly corrupted?)

4

actually - my theory was wrong. Your not allowed to call sendText until after you have received “meshtastic.connection.established” (see main.py in meshtastic for an example).

The reason for that exception was that we haven’t yet received the node db from the device at that point. I’ll make the error clearer.

5

Thank you sounds logical. one last question: I’m not sure about the main .py file you are refering to, is it this one:
https://github.com/meshtastic/Meshtastic-python/blob/master/meshtastic/__main__.py
?

6

yep - I think discourse converted the underscores to bold.

7

Thank you very much it works :slight_smile:

Just in case:
I think I burn a led (the blue one) on one of my t-beam V1.1… I did a mistake when I solder the oled, so I removed it … to do that I heated a lot… do you have an idea if their is a way to check if gps or bluetooth is not dead in command line or Python script?

1 Like
8

re: testing BLE hardware
If you have a phone you can check to see if the device is visible on the Bluetooth pairing device settings screen. Though I’ve heard iOS doesn’t show BLE devices. For iOS download the (free) NRF Connect app and that app will let you scan for BLE devices.

re: testing GPS hardware
easiest is probably to set the device outside for 15 mins or so and by then the red GPS lock led will start blinking (it is over near the GPS chip and directly controlled by that chip)

also: “meshtastic --info” will show a bunch of data, “has_gps” will be true if we’ve heard from the GPS.

9

ooh - btw that blue led is controlled directly by the axp192 power manager (and we talk to that chip via i2c to ask it to turn the led/on off). If that chip is warm and that led doesn’t work I bet the chip you fried is that chip. Which can happen if you insert the battery backwards (though newer versions of the tbeam now protect against this).

If you can capture the serial console (the meshtastic command will let you do this) and then press the reset button, one of the first few messages will be listing what i2c devices the cpu could find. I bet you’ll find that chip is missing.

I think the board could still work, but that chip also regulates battery charging, so if it is fried I wouldn’t recommend using a battery (because no overcharge protection). Also that chip provides power to the GPS, so if the GPS test fails - that’s why.

10

Thank you,
I confirm ios does not show BLE and the application NRF Connect works great to find it: very good application!
about the GPS so far I have “has_gps: true”, I’m going to test outdoor for GPS lock

11

I have a gps blinking so it looks good.

1 Like
12

But I don’t have the battery level, I guess the sensor is borken

13

if your axp192 is alive the boot will have messages like this.

I2C device found at address 0x34
axp192 PMU found
I2C device found at address 0x3c
ssd1306 display found
done
Meshtastic swver=0.9.7, hwver=1.0-US
Setting random seed 4102730859
Total heap: 265380
Free heap: 237600
Total PSRAM: 4194252
Free PSRAM: 4194252
NVS: UsedEntries 217, FreeEntries 413, 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

But if it is not able to talk on i2c, you won’t get battery level.

1 Like
14

Thank you for your support, additional question: how could I read the boot messages from an Unix plateform?

15

Hi,
You can install the python client as described here


The basic steps are 
$ pip3 install --upgrade meshtastic
$ meshtastic --help
$ meshtastic --seriallog stdout

This works on Linux. I would assume the same goes for unix.

3 Likes
16

Thank you for your help,
I tryed with minicom but some data are in a different format like binary.
This command works well on MacOS:

meshtastic --seriallog stdout --device "/dev/tty.SLAB_USBtoUART"

Then reboot the module by pressing the button on the right.

To conclude my axp192 is dead “AXP192 not found”

1 Like