meshtastic
--configure does not work reliably
I'm not sure why but I cannot get --configure with a YAML file to work reliably.
Generally, seeing worse behaviour on ESP32-based devices than nRF52 devices. Various issues such as:
- Node not rebooting after output of
INFO file:node.py commitSettingsTransaction line:634 Telling node to commit open transaction for editing settings,Writing modified configuration to device - Node rebooting but none of the configurations took effect
I'm not really sure how to describe it further, but I can repeatably replicate it with my Heltec v4.
You may try some of the YAML files at https://github.com/Meshtastic-Malaysia/meshtastic-config-my-sg/tree/main/MY_919 to replicate.
I am preparing a PR for configure, so I can try to have a look into this. Can you please run the configure command with --debug option and post the output here? Then I might get clearer info where it blocks. Thank you.
I'm seeing the "Node rebooting but none of the configurations took effect" issue with my ESP32 devices. Attached are the outputs from a number of things:
meshtastic --infofrom before the attempt t3s3.beforeconfigureattempt.20251107.txtmeshtastic --infofrom after the attempt t3s3.afterconfigureattempt.20251107.txtmeshtastic --debug --configureoutput from the attempt itself t3s3.configureattemptdebug.20251107.logmeshtastic --export-configfrom before the attempt
# start of Meshtastic configure yaml
canned_messages: Hi|Bye|Yes|No|Ok
channel_url: https://meshtastic.org/e/#CgcSAQE6AggNEgwIATgBQANIAVAeaAE
config:
bluetooth:
enabled: true
fixedPin: 123456
device:
nodeInfoBroadcastSecs: 10800
display:
screenOnSecs: 600
lora:
hopLimit: 3
region: US
sx126xRxBoostedGain: true
txEnabled: true
txPower: 30
usePreset: true
mqtt:
encryptionEnabled: false
network:
ntpServer: meshtastic.pool.ntp.org
position:
broadcastSmartMinimumDistance: 100
broadcastSmartMinimumIntervalSecs: 30
gpsMode: NOT_PRESENT
gpsUpdateInterval: 120
positionBroadcastSecs: 900
positionBroadcastSmartEnabled: true
positionFlags: 811
power:
lsSecs: 300
minWakeSecs: 10
sdsSecs: 4294967295
waitBluetoothSecs: 60
security:
privateKey: base64:YI4/an2azhllmRzY9xersJS7oR9fM0q4MWrC3N8KrX0=
publicKey: base64:Y6jHVMlyOIQtxxT7Yc3Q/FVxkWa/jRxqawy2lIzSMEk=
serialEnabled: true
module_config:
ambientLighting:
blue: 220
current: 10
green: 248
red: 217
cannedMessage:
enabled: true
detectionSensor:
detectionTriggerType: LOGIC_HIGH
minimumBroadcastSecs: 45
mqtt:
address: mqtt.meshtastic.org
encryptionEnabled: true
password: large4cats
root: msh/US
username: meshdev
telemetry:
deviceUpdateInterval: 2147483647
owner: Meshtastic f8dc
owner_short: f8dc
meshtastic --export-configfrom after the attempt
# start of Meshtastic configure yaml
canned_messages: Hi|Bye|Yes|No|Ok
channel_url: https://meshtastic.org/e/#CgcSAQE6AggNEhUIARAGGPoBIAsoBTgBQANIAVAeaAE
config:
bluetooth:
enabled: true
fixedPin: 123456
device:
nodeInfoBroadcastSecs: 10800
display:
screenOnSecs: 600
lora:
bandwidth: 250
codingRate: 5
hopLimit: 3
modemPreset: SHORT_FAST
region: US
spreadFactor: 11
sx126xRxBoostedGain: true
txEnabled: true
txPower: 30
usePreset: true
mqtt:
encryptionEnabled: false
network:
enabledProtocols: 1
ntpServer: meshtastic.pool.ntp.org
position:
broadcastSmartMinimumDistance: 100
broadcastSmartMinimumIntervalSecs: 30
gpsMode: NOT_PRESENT
gpsUpdateInterval: 120
positionBroadcastSecs: 900
positionBroadcastSmartEnabled: true
positionFlags: 811
power:
lsSecs: 300
minWakeSecs: 10
sdsSecs: 4294967295
waitBluetoothSecs: 60
security:
privateKey: base64:YI4/an2azhllmRzY9xersJS7oR9fM0q4MWrC3N8KrX0=
publicKey: base64:Y6jHVMlyOIQtxxT7Yc3Q/FVxkWa/jRxqawy2lIzSMEk=
serialEnabled: true
module_config:
ambientLighting:
blue: 220
current: 10
green: 248
red: 217
cannedMessage:
enabled: true
detectionSensor:
detectionTriggerType: LOGIC_HIGH
minimumBroadcastSecs: 45
mqtt:
address: mqtt.meshtastic.org
encryptionEnabled: true
password: large4cats
root: msh/US
username: meshdev
telemetry:
deviceUpdateInterval: 2147483647
owner: Meshtastic f8dc
owner_short: f8dc
- And the config that is attempting to be applied
# start of Meshtastic configure yaml
channel_url: https://meshtastic.org/e/#ChQSBN6tvu8aBnNwcmF3bCgBOgIIIBIMCAE4AUADSAFQHmgB
config:
bluetooth:
enabled: true
fixedPin: 123456
device:
role: CLIENT_BASE
rebroadcastMode: LOCAL_ONLY
nodeInfoBroadcastSecs: 10800
buzzerMode: DISABLED
ledHeartbeatDisabled: false
display:
screenOnSecs: 600
use12hClock: false
lora:
hopLimit: 3
region: US
sx126xRxBoostedGain: true
txEnabled: true
txPower: 30
usePreset: true
modemPreset: SHORT_FAST
mqtt:
encryptionEnabled: false
network:
enabledProtocols: 1
ntpServer: meshtastic.pool.ntp.org
position:
broadcastSmartMinimumDistance: 100
broadcastSmartMinimumIntervalSecs: 30
gpsMode: NOT_PRESENT
gpsUpdateInterval: 120
positionBroadcastSecs: 900
positionBroadcastSmartEnabled: true
positionFlags: 811
power:
lsSecs: 300
minWakeSecs: 10
sdsSecs: 4294967295
waitBluetoothSecs: 60
isPowerSaving: false
security:
privateKey: base64:YI4/an2azhllmRzY9xersJS7oR9fM0q4MWrC3N8KrX0=
publicKey: base64:Y6jHVMlyOIQtxxT7Yc3Q/FVxkWa/jRxqawy2lIzSMEk=
serialEnabled: true
module_config:
ambientLighting:
blue: 220
current: 10
green: 248
red: 217
detectionSensor:
detectionTriggerType: LOGIC_HIGH
minimumBroadcastSecs: 45
mqtt:
address: mqtt.meshtastic.org
encryptionEnabled: true
password: large4cats
root: msh
username: meshdev
owner: Meshtastic f8dc
owner_short: f8dc
(GitHub wouldn't let me upload the yaml configs for some reason)
Just tried downgrading the t3s3 device from 2.7.13 firmware to 2.6.11 (stable) firmware. Now I'm seeing the not rebooting after the commit and not all the settings are being applied. Looks like the device and lora settings are being applied, but not the channel settings.
@dwilliams: Thanks for the details, I was working on other stuff in the meantime but will now continue on this one. I have a RAK and a HelTec V3 in the meantime, so I hope I can validate those things correctly.
During the other improvements, I found 2 issues concerning updating of channels. They might be related to your problems.
@dwilliams: I now did some investigations on this case. In short: the CLI executes the configure command completely and sends all data to the radio. But some messages are not taken into account by the radio, they somehow get lost. These lost messages are not noticed by the CLI.
I wrote a script to analyze the log to see what the CLI sends as messages and how often a certain message ID gets logged. Your log:
| Msg | Cnt | Cmd |
|---|---|---|
| 190929654 | 2 | get_config_request |
| 41520887 | 2 | begin_edit_settings |
| 644346616 | 8 | get_config_request |
| 3936147193 | 6 | set_owner |
| 2860579578 | 9 | get_config_request |
| 2200170235 | 7 | set_owner |
| 2599410428 | 2 | get_config_request |
| 2548099837 | 2 | set_channel |
| 1676646142 | 2 | get_config_request |
| 4214255359 | 2 | set_config |
| 1136164608 | 2 | set_config |
| 2621117185 | 2 | set_config |
| 3296717570 | 2 | set_config |
| 474209027 | 2 | set_config |
| 1228399364 | 2 | set_module_config |
| 3485225733 | 2 | set_config |
| 4091670278 | 2 | set_config |
| 1301996295 | 2 | set_config |
| 3427604232 | 2 | set_config |
| 4280169225 | 3 | set_module_config |
| 2680984330 | 3 | set_module_config |
| 1615213323 | 2 | set_module_config |
| 2157660940 | 2 | commit_edit_settings |
What I get:
| Msg | Cnt | Cmd |
|---|---|---|
| 3885043065 | 9 | get_config_request |
| 2919768442 | 7 | begin_edit_settings |
| 143423867 | 7 | set_owner |
| 2025950588 | 7 | set_owner |
| 1327811965 | 7 | set_channel |
| 4224312702 | 7 | set_channel |
| 1530988927 | 7 | set_config |
| 1068773760 | 7 | set_config |
| 4203177345 | 7 | set_config |
| 2447841666 | 7 | set_config |
| 3388718467 | 7 | set_config |
| 806551940 | 7 | set_config |
| 4248784261 | 7 | set_config |
| 4180660614 | 7 | set_config |
| 2210282887 | 7 | set_config |
| 2262607240 | 7 | set_module_config |
| 3380894089 | 7 | set_module_config |
| 2602626442 | 7 | set_module_config |
| 3325060491 | 7 | set_module_config |
| 670475660 | 3 | commit_edit_settings |
As you can see from the column count, the messages from your log are mostly not acknowledged from the radio (Cnt=2 versus Cnt=7). As well, there are many get_config_request messages, for the config command we normally would need only one. Your yaml-file also has a wrong entry for the mqtt, those are actually all in the module config part.
I compared your firmware: you use a very recent one, so this might not be the cause. I assume you use an older version of the CLI - is this right? I use 2.7.3 and the most recent one is 2.7.5.
Could you please recheck this? Thanks.
I believe we really shouldn't need any get_config_requests to be issued by the python client. All of the config sections come up on the want_config flow anyway.
The first one makes sense, here the CLI will ask for SESSIONKEY_CONFIG, I assume its for security reasons.