Open aljaxus opened 7 months ago
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?
This issue has been mentioned on Meshtastic. There might be relevant details there:
https://meshtastic.discourse.group/t/typeerror-python-cli/10316/1
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).
The most straightforward way to try fixing this is to remove the old package, and install latest with pip.
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
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
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:
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!
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: protobuf@googlegroups.com Author-email: protobuf@googlegroups.com 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: protobuf@googlegroups.com Author-email: protobuf@googlegroups.com License: 3-Clause BSD License Location: /usr/local/lib/python3.9/site-packages Requires: Required-by: meshtastic
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.
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.
I have two devices in the same network. Both have the same
admin
channel setup. Running themeshtastic
CLI version2.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;