If contactdoes not having access to write to the parent directory, it cannot run. And there is no current way for this path to be set by the user:
$ /nix/store/sj46lpiaqb4v9ysvvcidkfkai0bqk4pm-contact-1.3.14/bin/contact -h
Traceback (most recent call last):
File "/nix/store/sj46lpiaqb4v9ysvvcidkfkai0bqk4pm-contact-1.3.14/bin/.contact-wrapped", line 6, in <module>
from contact.__main__ import start
File "/nix/store/sj46lpiaqb4v9ysvvcidkfkai0bqk4pm-contact-1.3.14/lib/python3.13/site-packages/contact/__main__.py", line 27, in <module>
import contact.ui.default_config as config
File "/nix/store/sj46lpiaqb4v9ysvvcidkfkai0bqk4pm-contact-1.3.14/lib/python3.13/site-packages/contact/ui/default_config.py", line 203, in <module>
loaded_config = initialize_config()
File "/nix/store/sj46lpiaqb4v9ysvvcidkfkai0bqk4pm-contact-1.3.14/lib/python3.13/site-packages/contact/ui/default_config.py", line 150, in initialize_config
with open(json_file_path, "w", encoding="utf-8") as json_file:
~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OSError: [Errno 30] Read-only file system: '/nix/store/sj46lpiaqb4v9ysvvcidkfkai0bqk4pm-contact-1.3.14/lib/python3.13/site-packages/contact/config.json'
## Description
Currently `contact` writes out its config, state, and log to the scripts' parent directory: https://github.com/pdxlocations/contact/blob/6ed0cc8c9f66f8e92cb30bcab79cc700079f81c4/contact/ui/default_config.py#L11-L13
If `contact`does not having access to write to the parent directory, it cannot run. And there is no current way for this path to be set by the user:
```
$ /nix/store/sj46lpiaqb4v9ysvvcidkfkai0bqk4pm-contact-1.3.14/bin/contact -h
Traceback (most recent call last):
File "/nix/store/sj46lpiaqb4v9ysvvcidkfkai0bqk4pm-contact-1.3.14/bin/.contact-wrapped", line 6, in <module>
from contact.__main__ import start
File "/nix/store/sj46lpiaqb4v9ysvvcidkfkai0bqk4pm-contact-1.3.14/lib/python3.13/site-packages/contact/__main__.py", line 27, in <module>
import contact.ui.default_config as config
File "/nix/store/sj46lpiaqb4v9ysvvcidkfkai0bqk4pm-contact-1.3.14/lib/python3.13/site-packages/contact/ui/default_config.py", line 203, in <module>
loaded_config = initialize_config()
File "/nix/store/sj46lpiaqb4v9ysvvcidkfkai0bqk4pm-contact-1.3.14/lib/python3.13/site-packages/contact/ui/default_config.py", line 150, in initialize_config
with open(json_file_path, "w", encoding="utf-8") as json_file:
~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OSError: [Errno 30] Read-only file system: '/nix/store/sj46lpiaqb4v9ysvvcidkfkai0bqk4pm-contact-1.3.14/lib/python3.13/site-packages/contact/config.json'
```
> Anything under `/nix/store` is readonly
## Ideas
Ideas to help resolve this:
- Consider making this parent directory configurable. This would need to change how initialization happens for the config since right now it happens on import: https://github.com/pdxlocations/contact/blob/6ed0cc8c9f66f8e92cb30bcab79cc700079f81c4/contact/ui/default_config.py#L203-L204
- Defaulting to a parent directory in $HOME or utilizing the XDG directory specs might be more appropriate: https://specifications.freedesktop.org/basedir-spec/latest/
<!-- github-sync-id:3223987456 -->
Thanks for this issue and your idea to default to a home directory sounds good.
Notes to self:
Making the parent directory configurable might be harder since the config file itself is stored in this directory. Hmm. Almost feels like a prompt at first boot is in order.
Besides the config file itself, this directory also holds client.db and client.log so those will have to follow the change.
We need to be careful that we remain backwards-compatible and test on mac/pc/linux.
Thanks for this issue and your idea to default to a home directory sounds good.
Notes to self:
Making the parent directory configurable might be harder since the config file itself is stored in this directory. Hmm. Almost feels like a prompt at first boot is in order.
Besides the config file itself, this directory also holds client.db and client.log so those will have to follow the change.
We need to be careful that we remain backwards-compatible and test on mac/pc/linux.
<!-- github-comment-id:3084556573 -->
#208 should at least let you run the app. If we can't write to the install directory, we fall back to ~/.contact_client/config.json
Thinking out loud: I'm still not sure how to best handle changing the config file location while editing the config file. Maybe we check for the existence of a config in the new location, then if none, copy the current file to the new location, then set a new config location variable?
#208 should at least let you run the app. If we can't write to the install directory, we fall back to ~/.contact_client/config.json
Thinking out loud: I'm still not sure how to best handle changing the config file location while editing the config file. Maybe we check for the existence of a config in the new location, then if none, copy the current file to the new location, then set a new config location variable?
<!-- github-comment-id:3087110081 -->
I have a TBeam Supreme for the meshtastic hardware Im using
Upon trying serial Im getting the following error after it hangs on the initial connecting... screen:
$ /nix/store/6i38kfk1ckaiqn7cw951n3phgsn0kxfi-contact-1.3.14/bin/contact
CRITICAL:root:Fatal error
Traceback (most recent call last):
File "/nix/store/6i38kfk1ckaiqn7cw951n3phgsn0kxfi-contact-1.3.14/lib/python3.13/site-packages/contact/__main__.py", line 127, in start
curses.wrapper(main)
~~~~~~~~~~~~~~^^^^^^
File "/nix/store/sd81bvmch7njdpwx3lkjslixcbj5mivz-python3-3.13.4/lib/python3.13/curses/__init__.py", line 94, in wrapper
return func(stdscr, *args, **kwds)
File "/nix/store/6i38kfk1ckaiqn7cw951n3phgsn0kxfi-contact-1.3.14/lib/python3.13/site-packages/contact/__main__.py", line 99, in main
if interface_state.interface.localNode.localConfig.lora.region == 0:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'localNode'
Fatal error: 'NoneType' object has no attribute 'localNode'
Traceback (most recent call last):
File "/nix/store/6i38kfk1ckaiqn7cw951n3phgsn0kxfi-contact-1.3.14/lib/python3.13/site-packages/contact/__main__.py", line 127, in start
curses.wrapper(main)
~~~~~~~~~~~~~~^^^^^^
File "/nix/store/sd81bvmch7njdpwx3lkjslixcbj5mivz-python3-3.13.4/lib/python3.13/curses/__init__.py", line 94, in wrapper
return func(stdscr, *args, **kwds)
File "/nix/store/6i38kfk1ckaiqn7cw951n3phgsn0kxfi-contact-1.3.14/lib/python3.13/site-packages/contact/__main__.py", line 99, in main
if interface_state.interface.localNode.localConfig.lora.region == 0:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'localNode'
Same result explicitly setting the serial port:
$ /nix/store/6i38kfk1ckaiqn7cw951n3phgsn0kxfi-contact-1.3.14/bin/contact --port /dev/ttyACM0
CRITICAL:root:Fatal error
Traceback (most recent call last):
File "/nix/store/6i38kfk1ckaiqn7cw951n3phgsn0kxfi-contact-1.3.14/lib/python3.13/site-packages/contact/__main__.py", line 127, in start
curses.wrapper(main)
~~~~~~~~~~~~~~^^^^^^
File "/nix/store/sd81bvmch7njdpwx3lkjslixcbj5mivz-python3-3.13.4/lib/python3.13/curses/__init__.py", line 94, in wrapper
return func(stdscr, *args, **kwds)
File "/nix/store/6i38kfk1ckaiqn7cw951n3phgsn0kxfi-contact-1.3.14/lib/python3.13/site-packages/contact/__main__.py", line 99, in main
if interface_state.interface.localNode.localConfig.lora.region == 0:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'localNode'
Fatal error: 'NoneType' object has no attribute 'localNode'
Traceback (most recent call last):
File "/nix/store/6i38kfk1ckaiqn7cw951n3phgsn0kxfi-contact-1.3.14/lib/python3.13/site-packages/contact/__main__.py", line 127, in start
curses.wrapper(main)
~~~~~~~~~~~~~~^^^^^^
File "/nix/store/sd81bvmch7njdpwx3lkjslixcbj5mivz-python3-3.13.4/lib/python3.13/curses/__init__.py", line 94, in wrapper
return func(stdscr, *args, **kwds)
File "/nix/store/6i38kfk1ckaiqn7cw951n3phgsn0kxfi-contact-1.3.14/lib/python3.13/site-packages/contact/__main__.py", line 99, in main
if interface_state.interface.localNode.localConfig.lora.region == 0:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'localNode'
Im using a tbeam supreme and I tried putting in flash mode (hold down boot button on powerup) and well as regular mode but nothing seemed to help. This is probably my device though since I was unable to connect it via serial to https://client.meshtastic.org/
Another interesting observation: Im not seeing a log or db but I do see the config.json:
Looks like you aren't getting a successful connection to the node. Can you try a simple command like meshtastic --noproto to see if you can connect with the CLI?
I don't have a tbeam supreme, but you shouldn't have to hold down any buttons when plugging it in. Make sure you have all other connections (wifi/ble/serial) closed before trying to connect.
Seems to be working with wifi except the log is missing. I made some changes to logging which are working as I'd hoped so that could be an unrelated issue.
Looks like you aren't getting a successful connection to the node. Can you try a simple command like `meshtastic --noproto` to see if you can connect with the CLI?
I don't have a tbeam supreme, but you shouldn't have to hold down any buttons when plugging it in. Make sure you have all other connections (wifi/ble/serial) closed before trying to connect.
Seems to be working with wifi except the log is missing. I made some changes to logging which are working as I'd hoped so that could be an unrelated issue.
<!-- github-comment-id:3091965184 -->
So this is definitely just something up with the TBeam Supreme.
Seems to be working with wifi except the log is missing. I made some changes to logging which are working as I'd hoped so that could be an unrelated issue.
@pdxlocations Ok good to know, is there a particular way to get that log to appear (debug, etc.)?
Thank you again for the help!
And below I've include details from attempting to debug the TBeam Supreme but I plan to raise this issue elsewhere (more appropriate forum) within meshtastic project.
Looks like you aren't getting a successful connection to the node. Can you try a simple command like meshtastic --noproto to see if you can connect with the CLI?
I don't have a tbeam supreme, but you shouldn't have to hold down any buttons when plugging it in. Make sure you have all other connections (wifi/ble/serial) closed before trying to connect.
With the TBeam Supreme (2.6.11.60ec05e and 2.7.3.cf574c7). Upgrading didnt seem to make a difference. Plugging in normally and closing all other connections:
$ sudo dmesg -w
...
[1114143.460388] usb 3-1: new full-speed USB device number 16 using xhci_hcd
[1114143.620228] usb 3-1: New USB device found, idVendor=303a, idProduct=1001, bcdDevice= 1.00
[1114143.620241] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1114143.620247] usb 3-1: Product: LilyGo TBeam-S3-Core
[1114143.620252] usb 3-1: Manufacturer: Espressif Systems
[1114143.620257] usb 3-1: SerialNumber: 48CA435756EC
The TBream Supreme can get the following on initial connection bug :
$ meshtastic --port /dev/ttyACM0 --noproto --debug
DEBUG file:serial_interface.py __init__ line:47 Connecting to /dev/ttyACM0
DEBUG file:stream_interface.py __reader line:151 in __reader()
WARNING file:mesh_interface.py _sendToRadio line:1171 Not sending packet because protocol use is disabled by noProto
Connected to radio
^CINFO file:__main__.py common line:1323 Exiting due to keyboard interrupt
But subsequent connections (after Ctrl-Cing out of the first meshtastic --noproto) results in:
$ meshtastic --port /dev/ttyACM0 --debug
DEBUG file:__main__.py common line:1221 Not logging serial output
DEBUG file:serial_interface.py __init__ line:47 Connecting to /dev/ttyACM0
^CTraceback (most recent call last):
File "/nix/store/vwa8f8f6lv2ml0pmbv8k8jxp8wny54ch-python3.12-meshtastic-2.6.3/bin/.meshtastic-wrapped", line 9, in <module>
sys.exit(main())
^^^^^^
File "/nix/store/vwa8f8f6lv2ml0pmbv8k8jxp8wny54ch-python3.12-meshtastic-2.6.3/lib/python3.12/site-packages/meshtastic/__main__.py", line 2062, in main
common()
File "/nix/store/vwa8f8f6lv2ml0pmbv8k8jxp8wny54ch-python3.12-meshtastic-2.6.3/lib/python3.12/site-packages/meshtastic/__main__.py", line 1261, in common
client = meshtastic.serial_interface.SerialInterface(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/nix/store/vwa8f8f6lv2ml0pmbv8k8jxp8wny54ch-python3.12-meshtastic-2.6.3/lib/python3.12/site-packages/meshtastic/serial_interface.py", line 65, in __init__
StreamInterface.__init__(
File "/nix/store/vwa8f8f6lv2ml0pmbv8k8jxp8wny54ch-python3.12-meshtastic-2.6.3/lib/python3.12/site-packages/meshtastic/stream_interface.py", line 55, in __init__
self.connect()
File "/nix/store/vwa8f8f6lv2ml0pmbv8k8jxp8wny54ch-python3.12-meshtastic-2.6.3/lib/python3.12/site-packages/meshtastic/stream_interface.py", line 71, in connect
self._writeBytes(p)
File "/nix/store/vwa8f8f6lv2ml0pmbv8k8jxp8wny54ch-python3.12-meshtastic-2.6.3/lib/python3.12/site-packages/meshtastic/stream_interface.py", line 97, in _writeBytes
self.stream.flush()
File "/nix/store/1h5kwfri8k6jym4akzggv882n6lcpvic-python3.12-pyserial-3.5/lib/python3.12/site-packages/serial/serialposix.py", line 673, in flush
termios.tcdrain(self.fd)
KeyboardInterrupt
^C
And if I reconnect the device and try --info it just hangs with a little more detail:
$ meshtastic --port /dev/ttyACM0 --info --debug
DEBUG file:__main__.py common line:1221 Not logging serial output
DEBUG file:serial_interface.py __init__ line:47 Connecting to /dev/ttyACM0
DEBUG file:stream_interface.py __reader line:151 in __reader()
DEBUG file:stream_interface.py _sendToRadioImpl line:114 Sending: want_config_id: 3999028387
DEBUG file:stream_interface.py _sendToRadioImpl line:119 sending header:b'\x94\xc3\x00\x06' b:b'\x18\xa3\xa9\xf1\xf2\x0e'
WARNING file:stream_interface.py __reader line:207 Meshtastic serial port disconnected, disconnecting... device reports readiness to read but returned no data (device disconnected or multiple access on port?)
DEBUG file:stream_interface.py __reader line:222 reader is exiting
DEBUG file:stream_interface.py _disconnected line:85 Closing our port5'
I tried another device: `SenseCAP Indicator (2.7.0.705515a)` which connects no problem with `metastatic` cli and `contact` 🚀 :
```
$ /nix/store/6i38kfk1ckaiqn7cw951n3phgsn0kxfi-contact-1.3.14/bin/contact --port /dev/ttyUSB0
```
So this is definitely just something up with the `TBeam Supreme`.
> Seems to be working with wifi except the log is missing. I made some changes to logging which are working as I'd hoped so that could be an unrelated issue.
@pdxlocations Ok good to know, is there a particular way to get that log to appear (debug, etc.)?
Thank you again for the help!
---
And below I've include details from attempting to debug the `TBeam Supreme` but I plan to raise this issue elsewhere (more appropriate forum) within meshtastic project.
> Looks like you aren't getting a successful connection to the node. Can you try a simple command like meshtastic --noproto to see if you can connect with the CLI?
>
> I don't have a tbeam supreme, but you shouldn't have to hold down any buttons when plugging it in. Make sure you have all other connections (wifi/ble/serial) closed before trying to connect.
With the `TBeam Supreme (2.6.11.60ec05e and 2.7.3.cf574c7)`. Upgrading didnt seem to make a difference. Plugging in normally and closing all other connections:
```
$ sudo dmesg -w
...
[1114143.460388] usb 3-1: new full-speed USB device number 16 using xhci_hcd
[1114143.620228] usb 3-1: New USB device found, idVendor=303a, idProduct=1001, bcdDevice= 1.00
[1114143.620241] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1114143.620247] usb 3-1: Product: LilyGo TBeam-S3-Core
[1114143.620252] usb 3-1: Manufacturer: Espressif Systems
[1114143.620257] usb 3-1: SerialNumber: 48CA435756EC
```
The `TBream Supreme` can get the following on initial connection bug :
```
$ meshtastic --port /dev/ttyACM0 --noproto --debug
DEBUG file:serial_interface.py __init__ line:47 Connecting to /dev/ttyACM0
DEBUG file:stream_interface.py __reader line:151 in __reader()
WARNING file:mesh_interface.py _sendToRadio line:1171 Not sending packet because protocol use is disabled by noProto
Connected to radio
^CINFO file:__main__.py common line:1323 Exiting due to keyboard interrupt
```
But subsequent connections (after `Ctrl-C`ing out of the first `meshtastic --noproto`) results in:
```
$ meshtastic --port /dev/ttyACM0 --debug
DEBUG file:__main__.py common line:1221 Not logging serial output
DEBUG file:serial_interface.py __init__ line:47 Connecting to /dev/ttyACM0
^CTraceback (most recent call last):
File "/nix/store/vwa8f8f6lv2ml0pmbv8k8jxp8wny54ch-python3.12-meshtastic-2.6.3/bin/.meshtastic-wrapped", line 9, in <module>
sys.exit(main())
^^^^^^
File "/nix/store/vwa8f8f6lv2ml0pmbv8k8jxp8wny54ch-python3.12-meshtastic-2.6.3/lib/python3.12/site-packages/meshtastic/__main__.py", line 2062, in main
common()
File "/nix/store/vwa8f8f6lv2ml0pmbv8k8jxp8wny54ch-python3.12-meshtastic-2.6.3/lib/python3.12/site-packages/meshtastic/__main__.py", line 1261, in common
client = meshtastic.serial_interface.SerialInterface(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/nix/store/vwa8f8f6lv2ml0pmbv8k8jxp8wny54ch-python3.12-meshtastic-2.6.3/lib/python3.12/site-packages/meshtastic/serial_interface.py", line 65, in __init__
StreamInterface.__init__(
File "/nix/store/vwa8f8f6lv2ml0pmbv8k8jxp8wny54ch-python3.12-meshtastic-2.6.3/lib/python3.12/site-packages/meshtastic/stream_interface.py", line 55, in __init__
self.connect()
File "/nix/store/vwa8f8f6lv2ml0pmbv8k8jxp8wny54ch-python3.12-meshtastic-2.6.3/lib/python3.12/site-packages/meshtastic/stream_interface.py", line 71, in connect
self._writeBytes(p)
File "/nix/store/vwa8f8f6lv2ml0pmbv8k8jxp8wny54ch-python3.12-meshtastic-2.6.3/lib/python3.12/site-packages/meshtastic/stream_interface.py", line 97, in _writeBytes
self.stream.flush()
File "/nix/store/1h5kwfri8k6jym4akzggv882n6lcpvic-python3.12-pyserial-3.5/lib/python3.12/site-packages/serial/serialposix.py", line 673, in flush
termios.tcdrain(self.fd)
KeyboardInterrupt
^C
```
And if I reconnect the device and try `--info` it just hangs with a little more detail:
```
$ meshtastic --port /dev/ttyACM0 --info --debug
DEBUG file:__main__.py common line:1221 Not logging serial output
DEBUG file:serial_interface.py __init__ line:47 Connecting to /dev/ttyACM0
DEBUG file:stream_interface.py __reader line:151 in __reader()
DEBUG file:stream_interface.py _sendToRadioImpl line:114 Sending: want_config_id: 3999028387
DEBUG file:stream_interface.py _sendToRadioImpl line:119 sending header:b'\x94\xc3\x00\x06' b:b'\x18\xa3\xa9\xf1\xf2\x0e'
WARNING file:stream_interface.py __reader line:207 Meshtastic serial port disconnected, disconnecting... device reports readiness to read but returned no data (device disconnected or multiple access on port?)
DEBUG file:stream_interface.py __reader line:222 reader is exiting
DEBUG file:stream_interface.py _disconnected line:85 Closing our port5'
```
<!-- github-comment-id:3092445464 -->
> Ok good to know, is there a particular way to get that log to appear
should show up now with 8716ea6fe1eb661895c3bd7ee466b266de2f0762
<!-- github-comment-id:3095464516 -->
Trying to reproduce by force attempting to save logs to a directory without write permissions. The home directory fallback is working for me. If config.json has old data it may be using that.
Did you delete your config file before running 1.3.16?
And/or what does the filepath say in config.json?
Trying to reproduce by force attempting to save logs to a directory without write permissions. The home directory fallback is working for me. If config.json has old data it may be using that.
Did you delete your config file before running 1.3.16?
And/or what does the filepath say in config.json?
```
"db_file_path": "/Users/benlipsey/.contact_client/client.db",
"log_file_path": "/Users/benlipsey/.contact_client/client.log",
```
<!-- github-comment-id:3099913048 -->
Fortunately, you're not missing much - logging isn't fully implemented and only really helpful for development.
Strange, thanks for bearing with me, I can't seem to reproduce this behavior. The log is created https://github.com/pdxlocations/contact/blob/4378f3045c7b28243b42912b2833b6f399b33d35/contact/__main__.py#L51
with that config filepath so it probably should work. I'm not sure what to try next but I'll keep poking at it when I have a chance.
Fortunately, you're not missing much - logging isn't fully implemented and only really helpful for development.
<!-- github-comment-id:3115510139 -->
Could you give me the TLDR as it relates to your request?
> Quick interjection here: Please follow the [XDG Base Directory Specification](https://specifications.freedesktop.org/basedir/latest/)
Could you give me the TLDR as it relates to your request?
<!-- github-comment-id:3483401120 -->
Could you give me the TLDR as it relates to your request?
Check if set and use when possible:
$XDG_DATA_HOME for user-specific data files
$XDG_CONFIG_HOME for user specific config files
If those are not set, the default data path is $HOME/.local/share and config path is $HOME/.config. These should be used for fallbacks if the environment variables are not set.
In other words, the defaults that contact is currently using do not follow convention. Specifically, using $XDG_CONFIG_HOME would address the original concern here of allowing user defined behavior as well as make contact compliant with standard, expected behavior.
> > Quick interjection here: Please follow the [XDG Base Directory Specification](https://specifications.freedesktop.org/basedir/latest/)
>
> Could you give me the TLDR as it relates to your request?
Check if set and use when possible:
- $XDG_DATA_HOME for user-specific data files
- $XDG_CONFIG_HOME for user specific config files
If those are not set, the default data path is $HOME/.local/share and config path is $HOME/.config. These should be used for fallbacks if the environment variables are not set.
In other words, the defaults that contact is currently using do not follow convention. Specifically, using $XDG_CONFIG_HOME would address the original concern here of allowing user defined behavior as well as make contact compliant with standard, expected behavior.
<!-- github-comment-id:3483430200 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Description
Currently
contactwrites out its config, state, and log to the scripts' parent directory: https://github.com/pdxlocations/contact/blob/6ed0cc8c9f66f8e92cb30bcab79cc700079f81c4/contact/ui/default_config.py#L11-L13If
contactdoes not having access to write to the parent directory, it cannot run. And there is no current way for this path to be set by the user:Ideas
Ideas to help resolve this:
Thanks for this issue and your idea to default to a home directory sounds good.
Notes to self:
Making the parent directory configurable might be harder since the config file itself is stored in this directory. Hmm. Almost feels like a prompt at first boot is in order.
Besides the config file itself, this directory also holds client.db and client.log so those will have to follow the change.
We need to be careful that we remain backwards-compatible and test on mac/pc/linux.
#208 should at least let you run the app. If we can't write to the install directory, we fall back to ~/.contact_client/config.json
Thinking out loud: I'm still not sure how to best handle changing the config file location while editing the config file. Maybe we check for the existence of a config in the new location, then if none, copy the current file to the new location, then set a new config location variable?
Thanks @pdxlocations for the update! Trying out against latest main: https://github.com/pdxlocations/contact/commit/a8bdcbb7e645eb04244a825098bcf4bf2428aa53
I have a TBeam Supreme for the meshtastic hardware Im using
Upon trying
serialIm getting the following error after it hangs on the initialconnecting...screen:Same result explicitly setting the serial port:
Im using a tbeam supreme and I tried putting in flash mode (hold down boot button on powerup) and well as regular mode but nothing seemed to help. This is probably my device though since I was unable to connect it via serial to https://client.meshtastic.org/
Another interesting observation: Im not seeing a log or db but I do see the
config.json:config.jsoncontents:If I switch to WiFi then Im able to connect to the TBeam and then the db gets populated but still no log:
Looks like you aren't getting a successful connection to the node. Can you try a simple command like
meshtastic --noprototo see if you can connect with the CLI?I don't have a tbeam supreme, but you shouldn't have to hold down any buttons when plugging it in. Make sure you have all other connections (wifi/ble/serial) closed before trying to connect.
Seems to be working with wifi except the log is missing. I made some changes to logging which are working as I'd hoped so that could be an unrelated issue.
I tried another device:
SenseCAP Indicator (2.7.0.705515a)which connects no problem withmetastaticcli andcontact🚀 :So this is definitely just something up with the
TBeam Supreme.@pdxlocations Ok good to know, is there a particular way to get that log to appear (debug, etc.)?
Thank you again for the help!
And below I've include details from attempting to debug the
TBeam Supremebut I plan to raise this issue elsewhere (more appropriate forum) within meshtastic project.With the
TBeam Supreme (2.6.11.60ec05e and 2.7.3.cf574c7). Upgrading didnt seem to make a difference. Plugging in normally and closing all other connections:The
TBream Supremecan get the following on initial connection bug :But subsequent connections (after
Ctrl-Cing out of the firstmeshtastic --noproto) results in:And if I reconnect the device and try
--infoit just hangs with a little more detail:should show up now with
8716ea6fe1still no luck getting the log to appear after bumping to
1.3.16:Trying to reproduce by force attempting to save logs to a directory without write permissions. The home directory fallback is working for me. If config.json has old data it may be using that.
Did you delete your config file before running 1.3.16?
And/or what does the filepath say in config.json?
Ya it doesnt seem to appear on 1.3.16, even though
log_file_pathseems correct. I did the following:Strange, thanks for bearing with me, I can't seem to reproduce this behavior. The log is created https://github.com/pdxlocations/contact/blob/4378f3045c7b28243b42912b2833b6f399b33d35/contact/__main__.py#L51
with that config filepath so it probably should work. I'm not sure what to try next but I'll keep poking at it when I have a chance.
Fortunately, you're not missing much - logging isn't fully implemented and only really helpful for development.
definitely odd
I'll try and do some debugging on this and see what could be happening.
Quick interjection here: Please follow the XDG Base Directory Specification
Could you give me the TLDR as it relates to your request?
Check if set and use when possible:
If those are not set, the default data path is $HOME/.local/share and config path is $HOME/.config. These should be used for fallbacks if the environment variables are not set.
In other words, the defaults that contact is currently using do not follow convention. Specifically, using $XDG_CONFIG_HOME would address the original concern here of allowing user defined behavior as well as make contact compliant with standard, expected behavior.
@tedwardd sorry for the late reply and thank you for the suggestion! It's on my list.