CLI set owner and owner-short not reliable BUG
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
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.
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
- Case Conversion: Meshtastic automatically converts
owner_shortto lowercase in ham mode - Unexpected Owner Format: Ham mode enforces
Meshtastic <callsign>format - 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:
-
Ham Mode Constraints:
ownermust be your exact FCC callsign (no spaces)owner_shortauto-converted to lowercase- Cannot customize owner prefix ("Meshtastic" is enforced)
-
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 -
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 -
Firmware Note: The case preservation issue (B4F8 → b4f8) is documented in GitHub issue #1076. If you need uppercase display, use the
long_namefield 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.
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:
- Volatile Storage Handling: Owner/owner_short are stored differently than other settings (likely in RAM-backed storage)
- Power Loss Sequence: When battery voltage drops critically low, ESP32 brownout protection triggers before settings can be committed to flash
- 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
3V3andGND - 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:
- Simulate power failure:
meshtastic --host 192.168.1.201 --set reboot # Immediately disconnect power during reboot - Check settings after 24 hours:
meshtastic --host 192.168.1.201 --export-config | grep -e owner -e long_name - Monitor retention rate:
# Run weekly diff last_config.txt new_config.txt
Additional Recommendations:
-
Update Firmware: Newer versions (2.2.x+) improved flash handling:
meshtastic --host 192.168.1.201 --update -
Enable Debug Logs:
meshtastic --host 192.168.1.201 --set logging_level DEBUGCheck for
Preferencerelated errors after power cycles -
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
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.
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:
- 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 falseoption, this it will not work. To Do: set also the short name according rules (if they apply) - I can't see any forcing of ham mode when selecting US region. The preference will just be set as any other configuration value.
- Setting Owner long/short names are handled independent from ham mode.
- Verifying settings must be done with
--info,--get owner, --get owner-short, --get long_namedo not exist (anymore). - 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.
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 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".