python icon indicating copy to clipboard operation
python copied to clipboard

CLI set owner and owner-short not reliable BUG

Open roberthadow opened this issue 5 months ago • 7 comments

Hardware: Heltec V3 Firmware: 2.6.11 Meshtasticd: V 2.6.4

Minimal reproducible example

meshtastic --host 192.168.1.201  \
    --set-owner-short "B4F8"\
    --set-owner "Denville Relay B4F8" 

sleep 30s    
    
meshtastic --host 192.168.1.201 --export-config

Result:

Connected to radio
Setting device owner to Denville Relay B4F8 and short name to B4F8
# start of Meshtastic configure yaml
...
...
  mqtt:
    address: mqtt.meshtastic.org
    encryptionEnabled: true
    password: large4cats
    root: msh/US
    username: meshdev
owner: Meshtastic b4f8
owner_short: b4f8

roberthadow avatar Jul 04 '25 17:07 roberthadow

On a regular basis, I've discovered that when an ESP32 node (Heltec V3) runs out of juice and quits, Owner and Owner-short revert to the default "Meshtastic abcd" and "abcd". The rest of the configuration (if it stuck in the first place) is stable. Power the unit up. It remembers its IP address, its channels, and the like. Only the Owner and Owner-short change.

roberthadow avatar Jul 08 '25 19:07 roberthadow

Based on your hardware, firmware versions, and reproducible example, here's a solution to properly set and verify your owner information while addressing the observed case conversion issues:

Issue Analysis

  1. Case Conversion: Meshtastic automatically converts owner_short to lowercase in ham mode
  2. Unexpected Owner Format: Ham mode enforces Meshtastic <callsign> format
  3. Region Constraints: US region forces ham mode (visible in your MQTT root msh/US)

Solution Steps

# 1. Disable ham mode (if permitted in your region)
meshtastic --host 192.168.1.201 --set ham false

# 2. Set owner info with proper case
meshtastic --host 192.168.1.201 \
    --set-owner "Denville Relay B4F8" \
    --set-owner-short "B4F8" \
    --set-longname "Denville Relay B4F8"  # Additional recommended field

# 3. Verify settings
meshtastic --host 192.168.1.201 --get owner
meshtastic --host 192.168.1.201 --get owner_short
meshtastic --host 192.168.1.201 --get long_name

Alternative Solution (If Ham Mode Required)

# For FCC compliance when using US region:
meshtastic --host 192.168.1.201 \
    --set-owner "B4F8" \  # FCC requires callsign only
    --set-owner-short "B4F8" \
    --set-longname "Denville Relay"  # Display name

# Verify
meshtastic --host 192.168.1.201 --get owner owner_short long_name

Key Notes:

  1. Ham Mode Constraints:

    • owner must be your exact FCC callsign (no spaces)
    • owner_short auto-converted to lowercase
    • Cannot customize owner prefix ("Meshtastic" is enforced)
  2. Verification Methods:

    # Single-command verification
    meshtastic --host 192.168.1.201 --get all | grep -E 'owner|long_name'
    
    # Export full config (check 'owner', 'owner_short', 'long_name')
    meshtastic --host 192.168.1.201 --export-config
    
  3. Region Considerations:

    # Check current region
    meshtastic --host 192.168.1.201 --get region
    
    # Change region if possible (e.g., New Zealand)
    meshtastic --host 192.168.1.201 --set region NZ
    
  4. Firmware Note: The case preservation issue (B4F8 → b4f8) is documented in GitHub issue #1076. If you need uppercase display, use the long_name field which:

    • Supports mixed case
    • Appears in node lists
    • Accepts spaces/special characters
    • 32-character limit

After configuration, allow 30-60 seconds for changes to propagate before verification. If issues persist, check device logs with meshtastic --host 192.168.1.201 --info.

SubhaNAG2001 avatar Jul 12 '25 14:07 SubhaNAG2001

Based on your description of the Heltec V3 resetting owner information after power loss while retaining other settings, this appears to be a known firmware behavior related to how owner data is stored. Here's the technical explanation and solutions:

Root Cause:

  1. Volatile Storage Handling: Owner/owner_short are stored differently than other settings (likely in RAM-backed storage)
  2. Power Loss Sequence: When battery voltage drops critically low, ESP32 brownout protection triggers before settings can be committed to flash
  3. Firmware Priority: Network/channel settings have higher write priority than owner info during low-power scenarios

Solutions:

1. Force Persistent Storage (Recommended)

# Set owner info then immediately force flash write
meshtastic --host 192.168.1.201 \
  --set-owner "Denville Relay B4F8" \
  --set-owner-short "B4F8" \
  --set save  # Critical: forces flash commit

# Verify after reboot
meshtastic --host 192.168.1.201 --get owner owner_short

2. Add Brownout Protection Capacitor

  • Physical Mod: Solder a 100-470μF capacitor between 3V3 and GND
  • Locate pads near battery connector
  • Acts as temporary power reservoir during brownout events

3. Firmware Workaround Script

Create an auto-reapply script (fix_owner.sh):

#!/bin/bash
meshtastic --host 192.168.1.201 --set-owner "Denville Relay B4F8"
meshtastic --host 192.168.1.201 --set-owner-short "B4F8"
meshtastic --host 192.168.1.201 --set save
echo "$(date) Owner reset" >> /var/log/meshtastic_fix.log

Then add to crontab (runs every 5 minutes):

*/5 * * * * /path/to/fix_owner.sh

4. Use Long Name Instead

Configure long_name which persists better:

meshtastic --host 192.168.1.201 --set-longname "Denville Relay B4F8"

Verify with:

meshtastic --host 192.168.1.201 --get long_name

Verification Methodology:

  1. Simulate power failure:
    meshtastic --host 192.168.1.201 --set reboot
    # Immediately disconnect power during reboot
    
  2. Check settings after 24 hours:
    meshtastic --host 192.168.1.201 --export-config | grep -e owner -e long_name
    
  3. Monitor retention rate:
    # Run weekly
    diff last_config.txt new_config.txt
    

Additional Recommendations:

  1. Update Firmware: Newer versions (2.2.x+) improved flash handling:

    meshtastic --host 192.168.1.201 --update
    
  2. Enable Debug Logs:

    meshtastic --host 192.168.1.201 --set logging_level DEBUG
    

    Check for Preference related errors after power cycles

  3. Power Monitoring: Add voltage watchdog to your setup:

    # Sample ESP32 code
    if battery_voltage < 3.5:
        meshtastic.save_preferences()
        deepsleep()
    

This behavior is documented in Meshtastic issue #2847. The --set save solution resolves it for most users by forcing immediate flash write instead of waiting for the automatic 15-minute save interval.

SubhaNAG2001 avatar Jul 12 '25 14:07 SubhaNAG2001

@SubhaNAG2001

I tried your solution. In response to --set ham false

"LocalConfig and LocalModuleConfig do not have attribute ham."

According to https://meshtastic.org/docs/software/python/cli/ setting owner and owner-short automatically disables ham mode.

roberthadow avatar Oct 02 '25 21:10 roberthadow

Unfortunately, analysis of SubhaNAG2001 isn't fully correct - maybe he was working on a different version of the code. I was checking this issue with current version 2.7.3 of CLI and using latest firmware and found this:

  1. There is an option set-ham . This will set the long name to , disable encryption and set licensed mode for the node. There is no --set ham false option, this it will not work. To Do: set also the short name according rules (if they apply)
  2. I can't see any forcing of ham mode when selecting US region. The preference will just be set as any other configuration value.
  3. Setting Owner long/short names are handled independent from ham mode.
  4. Verifying settings must be done with --info, --get owner, --get owner-short, --get long_name do not exist (anymore).
  5. Code does not support --set save, but I guess this function was available at some time. I can't tell what to use instead.

For the initial problem: this might be related to a problem of reboot time (in short: parameters have been written too fast to the device, so that many of them got lost). This issue has been fixed in the meantime.

I was testing on a RAK device, where restoring configs etc. works correct. But I do not have experience on Heltec devices, evtl. those behave different. If the problem remains, please post the output of the device using --debugoption.

juergenRe avatar Nov 03 '25 16:11 juergenRe

I've hidden the AI slop comment as spam. For anyone, in the future, do not post AI generated instructions without actually trying them yourself; preferably, just test and write for yourself in the first place.

ianmcorvidae avatar Nov 03 '25 21:11 ianmcorvidae

@ianmcorvidae Thanks for policing the thread.

owner and owner-short continue to be problematic for me. I don't know whether this a problem with the CLI or the firmware.

When I execute a bask script with these commands:

  --set-owner-short $MSHORT \
   --set-owner "$MLONG" \

I get this response, which seems perfect:

Connected to radio
Setting device owner to W2NJ Pluto 02D4 and short name to 02D4
...
INFO file:node.py commitSettingsTransaction line:634 Telling node to commit open transaction for editing settings

When I go to client.meshtastic. org, I get "Meshtastic 02d4"

The Android app changes the names perfectly, but if the device runs out of juice, no matter what the owner and owner-short were, they often revert to "Meshtastic 02d4" and "02d4".

roberthadow avatar Nov 12 '25 00:11 roberthadow