BUG: TypeError: 'EU_868' has type str, but expected one of: int

[aljaxus]

I have two devices in the same network. Both have the same admin channel setup. Running the meshtastic CLI version 2.2.17, on Arch, installed via AUR. When running the --get lora (specifically, some other categories work, have not tested all of them) I get the following error;

[aljaxus@aljaxus-laptop2 ~]$ meshtastic --dest '!nodeid' --get lora
Connected to radio
Requesting current config from remote node (this can take a while).

ERROR file:stream_interface.py __reader line:175 Error while handling message from radio 'EU_868' has type str, but expected one of: int
Traceback (most recent call last):
  File "/usr/lib/python3.11/site-packages/meshtastic/stream_interface.py", line 173, in __reader
    self._handleFromRadio(self._rxBuf[HEADER_LEN:])
  File "/usr/lib/python3.11/site-packages/meshtastic/mesh_interface.py", line 811, in _handleFromRadio
    self._handlePacketFromRadio(fromRadio.packet)
  File "/usr/lib/python3.11/site-packages/meshtastic/mesh_interface.py", line 1032, in _handlePacketFromRadio
    handler.callback(asDict)
  File "/usr/lib/python3.11/site-packages/meshtastic/node.py", line 114, in onResponseRequestSettings
    setattr(config_values, camel_to_snake(key), value)
TypeError: 'EU_868' has type str, but expected one of: int
Completed getting preferences

[majodi]

Same here. Also with --get position (now there is a TypeError on gps_mode). Did you find a solution? Are firmware and CLI versions out of sync?

[geeksville]

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/typeerror-python-cli/10316/1

[majodi]

Yes, this mention on Meshtastic was by me. I was hoping someone there could help me (there were no further comments here). It looks as if there is a type mismatch between the firmware and the Python CLI (or the definitions of the protobufs). I don't know if anyone is aware of this or working on it (or maybe I did something wrong).

[jp-bennett]

The most straightforward way to try fixing this is to remove the old package, and install latest with pip.

[majodi]

I pip uninstalled meshtastic:

Successfully uninstalled meshtastic-2.2.22

I then pip installed meshtastic:

Installing collected packages: meshtastic Successfully installed meshtastic-2.2.22

I try to get lora settings of remote:

meshtastic --dest '!fa75f684' --get lora

I get:

Connected to radio Requesting current config from remote node (this can take a while).

ERROR file:stream_interface.py __reader line:175 Error while handling message from radio Cannot set Config.LoRaConfig.region to 'EU_868': 'EU_868' has type <class 'str'>, but expected one of: (<class 'int'>,) Traceback (most recent call last): File "/Users/majodi/.pyenv/versions/3.8.5/lib/python3.8/site-packages/google/protobuf/internal/python_message.py", line 696, in field_setter new_value = type_checker.CheckValue(new_value) File "/Users/majodi/.pyenv/versions/3.8.5/lib/python3.8/site-packages/google/protobuf/internal/type_checkers.py", line 140, in CheckValue raise TypeError(message) TypeError: 'EU_868' has type <class 'str'>, but expected one of: (<class 'int'>,)

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/Users/majodi/.pyenv/versions/3.8.5/lib/python3.8/site-packages/meshtastic/stream_interface.py", line 173, in __reader self._handleFromRadio(self._rxBuf[HEADER_LEN:]) File "/Users/majodi/.pyenv/versions/3.8.5/lib/python3.8/site-packages/meshtastic/mesh_interface.py", line 811, in _handleFromRadio self._handlePacketFromRadio(fromRadio.packet) File "/Users/majodi/.pyenv/versions/3.8.5/lib/python3.8/site-packages/meshtastic/mesh_interface.py", line 1036, in _handlePacketFromRadio handler.callback(asDict) File "/Users/majodi/.pyenv/versions/3.8.5/lib/python3.8/site-packages/meshtastic/node.py", line 114, in onResponseRequestSettings setattr(config_values, camel_to_snake(key), value) File "/Users/majodi/.pyenv/versions/3.8.5/lib/python3.8/site-packages/google/protobuf/internal/python_message.py", line 698, in field_setter raise TypeError( TypeError: Cannot set Config.LoRaConfig.region to 'EU_868': 'EU_868' has type <class 'str'>, but expected one of: (<class 'int'>,) Completed getting preferences

[PonyOny]

Same issue here, can't get remote data same

Error while handling message from radio 'EU_868' has type str, but expected one of: int

[majodi]

I did some further testing. Same connected device, same mesh network environment. When I run "meshtastic --dest '!fa75f818' --get lora" on my Macbook it works. But when I run the same on my iMac (where I did get the TypeError earlier), I get a timeout and after a while I get the TypeError again. Did try several times with exactly the same steps, same outcome.

Macbook: Monterey 12.7.3 iMac: Sonoma 14.2.1 Meshtastic: both 2.2.22

Debug output:

meshtastic_debug.txt

[ianmcorvidae]

Looking into this as I go through the backlog -- there's some indications on the internet that that error may have to do with an older version of the protobuf library. If you've still got the older machine erroring, could you run pip show protobuf on it, without touching anything else? Newer versions of the CLI do also depend on an updated version of the protobuf library, so it's possible that merely updating meshtastic itself would make the error go away, but if possible I'd love to confirm that's the fix!

[majodi]

pip show protobuf on iMac (where I do get the error):

Name: protobuf Version: 4.25.3 Summary: None Home-page: https://developers.google.com/protocol-buffers/ Author: [email protected] Author-email: [email protected] License: 3-Clause BSD License Location: /Users/majodi/.pyenv/versions/3.8.5/lib/python3.8/site-packages Requires: Required-by: -eshtastic, meshtastic

on the macbook (where it does work):

Name: protobuf Version: 4.25.3 Summary: None Home-page: https://developers.google.com/protocol-buffers/ Author: [email protected] Author-email: [email protected] License: 3-Clause BSD License Location: /usr/local/lib/python3.9/site-packages Requires: Required-by: meshtastic

[ianmcorvidae]

This is very odd, then. It looks like you're using a virtualenv on the erroring machine, so perhaps it's another dependency in there (though I admit I'm grasping at straws a bit there). I could at least take a look at those if you can provide them via pip freeze, though I don't know why it'd be anything other than the protobuf library to be honest.

[aljaxus]

This is very odd, then. It looks like you're using a virtualenv on the erroring machine, so perhaps it's another dependency in there (though I admit I'm grasping at straws a bit there). I could at least take a look at those if you can provide them via pip freeze, though I don't know why it'd be anything other than the protobuf library to be honest.

• https://pastebin.com/raw/LTU8viUV (for easier viewing, no need to download the file)
• freeze.txt (for archival, no external platform dependency)

[juergenRe]

I stumbled over this issue because it is marked as "good first issue" and I want to get a bit used to the Python CLI. This point now is nearly 2 years old and the SW has evolved in the meantime - so I tried to reproduce the mentioned error with current releases first. Result: I was not able to reproduce the mentioned problem with actual SW releases.

(.venv) PS c:\[...]Meshtastic\Python-CLI> meshtastic --dest !1a6aeb85 --get lora
Connected to radio
Requesting current config from remote node (this can take a while).

lora:
use_preset: true
region: EU_868
hop_limit: 3
tx_enabled: true
tx_power: 27
sx126x_rx_boosted_gain: true
ignore_mqtt: true
config_ok_to_mqtt: true

Completed getting preferences

Of course, this does not mean the problem is solved - so here a description of what I tried. Could someone check if this is the correct setup? How to proceed with this bug?

1. Used HW and SW releases:

• HW: 2 x RAK 4631, both with firmware 2.6.11.60ec05e
• Python CLI V 2.7.3

3. Dev environment

• PyCharm, Python 3.12 in venv, set-up according installation instructions using poetry.

4. Setup of devices This is where I am not sure if I understood it correctly. From the description I assume, that the lora settings will be requested via remote admin from device B using device A: meshtastic --dest !B --get lora My current setup uses default channel 0 with "LongFast" setting on both devices. A is setup as "Client", B as "Router_Late", A can administer B. Is this the correct setup? Any remarks?

[aljaxus]

Indeed the issue was at some point fixed. Thank you for taking your time going though old issues and following up on them.

ps: Such actions should be rewarded when possible. If you ever need a small VM for research/personal projects, feel free to reach out (and remind me of this issue).

[juergenRe]

Thanks for closing/following up. Also thanks for offering a reward - for the moment I am happy with what I have, but its very kind.