meshtastic
1.3 Testing Punchlist
Config Sections
- [x] Bluetooth Config - All options working in the CLI, WebUI and iOS, validation of fixed pin is in progress on iOS and currently only allows 123456
- [x] Device Config - All options are working in the cli, WebUI and iOS, factory reset handles the admin message correctly but is broken, there is an issue filed #1597.
- [x] Display Config - All options tested and working on iOS and in the cli.
- [x] LoRa Config - region, modem_preset & max_hops have been tested and are working on iOS, ~~lora.region does not seem to be saving properly to esp32 devices.~~ LoRa Config now causes a reboot after saving and is working much more consistently. Advanced settings still need testing.
- [x] Power Config - Saving values works, should not be necessary for most users. Sleep config values are now completely unused in the firmware so those settings do nothing and should probably be removed at some point.
- [x] Position Config - Config values including the flags have been tested and save properly.
- [x] Network Config - Client mode tested and working can be configured from CLI, apple and WebUI all 4 settings save. Enabled boolean value needs to be implemented in the firmware.
Module Config
- [ ] Canned Messages - Enabled updown1 for rak with pin a = 4 pin b = 10 pin press = 9 finds messages and knows the plugin is enabled but does not show a screen
- [x] External Notification - Updates from iOS and Python, Station G1 Successfully tested
- [x] Range Test - Sender and save working, currently no way to access the file.
- [ ] Serial - Untested
- [x] Telemetry - Device and Environment are Complete - Using Multiple sensors at the same time has not been tested.
- [x] MQTT - Commands work, Enabling MQTT works, custom server needs testing
Required Configuration Reboots
Test inconsistencies in reboots being required when changing settings and determine the appropriate action for each Config Section, Module Config and User
- [x] Bluetooth Config - Needs to reboot after changing settings so the user can use the updated settings.
- [ ] Display Config - Needs to reboot for screen timing settings to take affect
- [x] LoRa Config, automatic device reboot after saving LoRa Config, we may be able to remove this in the future but is a currently required workaround.
- [x] User - Needs to automatically reboot so that the end user will get updated MyInfo from the device verifying that the save worked
- [x] WiFi Config - Needs to automatically reboot so it can log into wifi
- [ ] All Modules need to reboot after saving
New Features / Bug Fixes / Broken Features
- [x] Admin Channel
- [ ] Remote Hardware - Untested
- [x] Get Device metadata (currently Firmware and Protobufs versions)
- [x] DM Routing over the mesh, ack only from recipient.
- [x] Ack failures when message received when using two devices.
- [x] Forwarding of packets with the same settings but different keys
- [x] Prioritize nodes further away via SNR for flood routing
- [ ] Ping / Reply App --sendping appears to work in the cli, reply module in the firmware does not appear to be working at all
- [x] Empty Position Packets
- [x] Config packets arriving before node info
- [ ] Channels are coming back from the device very slowly
- [x] Location Waypoints (can send from iOS and receive on the web ui, does not seem to be hooked up in the firmware at all, not getting packets.
Load Testing
With range test and telemetry working nicely in 1.3, if you want to create a lot of mesh activity with any device you can turn up the telemetry updates to 15 seconds and use the range test from an ESP32 to create messages. This is a much more reliable way to test and revert then messing with position features.
Testing on 1.3.29.7afc149, with tlora-v2-1-1.6
Configuring from command line with meshtastic: meshtastic --set position.fixed_position true Connected to radio Set position.fixed_position to true Writing modified preferences to device $ meshtastic --setlat 37.0 --setlon -121.0 Connected to radio Aborting due to: 'LocalConfig' object has no attribute 'fixed_position'
meshtastic --set wifi.ap_mode false Connected to radio Set wifi.ap_mode to false Writing modified preferences to device
$ meshtastic --set wifi.ssid "Localnet" Connected to radio Set wifi.ssid to Localnet Writing modified preferences to device
$ meshtastic --set wifi.password SecretPass47 Connected to radio Aborting due to: local variable 'localConfig' referenced before assignment
There are several more, very similar to this. Attempting to configure from the IOS app crashes the IOS app as well.
When you see the localconfig errors the command is wrong Aborting due to: 'LocalConfig' object has no attribute
Aborting due to: 'LocalConfig' object has no attribute 'fixed_position'
Only Config Sections and Module Config are working for setting in my testing, I would not expect any of the convenience methods that are setting things to work.
I think there is a case for adding an enabled Boolean property to the wifi config.
the right command for wifi password is set wifi.psk "password"
Ok, thanks - I was using https://meshtastic.org/docs/settings/config/wifi as my reference.
the right command for wifi password is set wifi.psk "password"
Ok, thanks - I was using https://meshtastic.org/docs/settings/config/wifi as my reference.
Thanks! Fixed https://github.com/meshtastic/Meshtastic/pull/386
Configuring via the web interface (via wifi) fails when attempting to save changes in the User configuration panel. Changes are rejected with a status message "hwModel must be a valid enum value" in red by the (unchangeable) Hardware field. In my case, the field shows TLORA_V2_1_1p6
Configuring via the web interface (via wifi) fails when attempting to save changes in the User configuration panel. Changes are rejected with a status message "hwModel must be a valid enum value" in red by the (unchangeable) Hardware field. In my case, the field shows TLORA_V2_1_1p6
This is now fixed
In my testing on 1.3.44 both --sendping and --reply are already working. When using 'meshtastic --reply' on one device, sending a message 'Hi there' from another gets a response "got msg 'Hi there' with rxSnr: 11.0 and hopLimit: 3" as seen here:
17:46:49 300 [RadioIf] AirTime - Packet received : 1214ms 17:46:49 300 [Router] Add packet record (id=0x88ec4132 Fr0xe4 To0xff, WantAck0, HopLim3 Ch0x8 encrypted rxSNR=10.25 rxRSSI=1.84093) 17:46:49 301 [Router] Using channel 0 (hash 0x8) 17:46:49 301 [Router] Expanding short PSK #1 17:46:49 301 [Router] Using AES128 key! 17:46:49 301 [Router] ESP32 crypt fr=bff18ce4, num=88ec4132, numBytes=55! 17:46:49 301 [Router] decoded message (id=0x88ec4132 Fr0xe4 To0xff, WantAck0, HopLim3 Ch0x0 Portnum=1 rxtime=1665683209 rxSNR=10.25 rxRSSI=1.84093) 17:46:49 301 [Router] handleReceived(REMOTE) (id=0x88ec4132 Fr0xe4 To0xff, WantAck0, HopLim3 Ch0x0 Portnum=1 rxtime=1665683209 rxSNR=10.25 rxRSSI=1.84093) 17:46:49 301 [Router] Module 'text' wantsPacket=1 17:46:49 301 [Router] Received text msg from=0xbff18ce4, id=0x88ec4132, msg=got msg 'Hi there' with rxSnr: 11.0 and hopLimit: 3
In my testing on 1.3.44 both --sendping and --reply are already working. When using 'meshtastic --reply' on one device, sending a message 'Hi there' from another gets a response "got msg 'Hi there' with rxSnr: 11.0 and hopLimit: 3" as seen here:
17:46:49 300 [RadioIf] AirTime - Packet received : 1214ms 17:46:49 300 [Router] Add packet record (id=0x88ec4132 Fr0xe4 To0xff, WantAck0, HopLim3 Ch0x8 encrypted rxSNR=10.25 rxRSSI=1.84093) 17:46:49 301 [Router] Using channel 0 (hash 0x8) 17:46:49 301 [Router] Expanding short PSK #1 17:46:49 301 [Router] Using AES128 key! 17:46:49 301 [Router] ESP32 crypt fr=bff18ce4, num=88ec4132, numBytes=55! 17:46:49 301 [Router] decoded message (id=0x88ec4132 Fr0xe4 To0xff, WantAck0, HopLim3 Ch0x0 Portnum=1 rxtime=1665683209 rxSNR=10.25 rxRSSI=1.84093) 17:46:49 301 [Router] handleReceived(REMOTE) (id=0x88ec4132 Fr0xe4 To0xff, WantAck0, HopLim3 Ch0x0 Portnum=1 rxtime=1665683209 rxSNR=10.25 rxRSSI=1.84093) 17:46:49 301 [Router] Module 'text' wantsPacket=1 17:46:49 301 [Router] Received text msg from=0xbff18ce4, id=0x88ec4132, msg=got msg 'Hi there' with rxSnr: 11.0 and hopLimit: 3
Checked off! :-)
This issue has been mentioned on Meshtastic. There might be relevant details there:
https://meshtastic.discourse.group/t/all-ttgo-boards-but-one-are-rebooting-after-each-cli-command/6600/2
