Feat WiFi creds over serial

[nitin710]

Description

• Adds provision to write WiFi credentials to config file over serial input
• Fixes issue where any serial input key could activate Debug mode

Requirements

• https://github.com/EmotiBit/EmotiBit_XPlat_Utils/pull/25

Issues Referenced

• 274

Documentation update

• https://github.com/EmotiBit/EmotiBit_Docs/pull/115

Notes for Reviewer

• For details about handshaking, see SD Card Serial Add Wifi Credentials API Diagram drawing in drive.
• sample output

Successfully entered config file edit mode.
@FV,1.9.0~
Options available in this mode:
1. Add a wifi credential. Usage: @WA,{"ssid":"SSSS","password" : "PPPP"}~
  - Replace SSSS with network name and PPPP with network password
2. List wifi credentials. Usage: @LS,~
3. Delete Wifi Credential. Usage: @WD,<credential number>~
  - use List option to get a wifi list. Then use the number in the list to delete a credential

>>>>>>>>>>>[serial input] @WA,{"ssid":"emoti-net","password" : "emotibit-rocks"}~
typetag: WA
payload: {"ssid":"emoti-net","password" : "emotibit-rocks"}
Parsed output: 
ssid: emoti-net
password: emotibit-rocks

config file exists. Appending to file.
@AK,WA~
Updated file contents:
{
  "WifiCredentials": [
    {
      "ssid": "emoti-net",
      "password": "emotibit-rocks"
    }
  ]
}

>>>>>>>>>>>[serial input] @LS,~
typetag: LS
payload: 
##################################
config file credetials:
0. emoti-net : emotibit-rocks
1. SSSS : PPPP
##################################
@AK,LS~

>>>>>>>>>>>[serial input] @WD,1~
typetag: WD
payload: 1
Deleting entry: 1. SSSS
@AK,WD~

Testing

Results

• Synopsis of results

Test	Feather ESP32	Feather M0
Add credentials when config.txt does not exist	✔️	✔️
Add credentials when config.txt fails parsing	✔️
Add cred, config exists, can be parsed	✔️	✔️
delete valid option	✔️	✔️
delete invalid option	✔️	✔️
add enterprise cred	✔️	✔️

Feature Tests

• [✔️ ] WiFi creds serial interface: Add cred, config not exist
• [✔️ ] WiFi creds serial interface: Add cred, config exists, cannot be parsed
• [✔️ ] WiFi creds serial interface: Add cred, config exists, can be parsed
• [✔️ ] WiFi creds serial interface: Add cred, config exists, can be parsed, more than 12 creds
• [✔️ ] WiFi creds serial interface: delete valid option, config exists, can be parsed
• [✔️ ] WiFi creds serial interface: delete invalid option, config exists, can be parsed
• [✔️ ] WiFi creds serial interface: delete option, config does not exists
• [✔️ ] WiFi creds serial interface: Add enterprise cred, config exists, can be parsed

Steps to test

• Use the serial monitor to edit credentials in the config file
• Handy test inputs
  • Add a credential: @WA,{"ssid":"ssid_name","password" : "network_password"}~
  • Delete a credential: @WD,<number>~
  • List creds: @LS,~

Shared files

• ~1.9.0.feat-sdCardWiFiCredentials.16.zip~
• 1.9.0.feat-sdCardWiFiCredentials.18.zip

Checklist to allow merge

• [ ] All dependent repositories used were on branch master
• Firmware
  • [ ] Set testingMode to TestingMode::NONE
  • [ ] Set const bool DIGITAL_WRITE_DEBUG = false (if set true while testing)
  • [ ] Update version in EmotiBit.h
  • [ ] Update library.properties to the correct version (should match EmotiBit.h)
• [ ] doxygen style comments included for new code snippets
• [ ] Required documentation updated

[nitin710]

WIP

• ✔️ Needs a clearer Serial interface
• Add
  • ✔️ details on options available when the mode is entered
  • [stretch goal] move Sd functions to a new file?
  • ✔️ "pretty" the output when using list command
  • ~output the new config file contents when a delete is performed, (same as add)~

[nitin710]

Moving this provision to a different class.

• Class name options
  • EmotiBitSdController
  • failure cases
    • If storatge is not an Sd-Card
    • NAND flash or
    • EEPROM
    • FRAM
  • EmotiBitStorageController // As per discussion, storage might be a superset of NVM. a better word needed

Current functions getting affected

{
  bool setupSdCard(int chipSelPin, bool loadConfig);
  bool loadConfigFile(String filename); // need to pass wifi object handle
  bool writeSdCardMessages(File &dataFile, String &stringToWrite);
  void printConfigInfo(File &file, String &stringToWrite)
  void processWiFiConfigInputs(String &configFileName);
}

New class

class UserAccessibleStorage
{
  bool setup(enum hwVersion, string sku); 
  bool loadConfigFile(String filename, EmotiBitWiFi &emotibitWifi); 
  bool writeToStorage(File &dataFile, String &stringToWrite);
  void writeConfigInfo(File &file, String &stringToWrite);
  void processWiFiConfigInput(String &configFileName);
  bool createDataFile(String filename);
}

[nitin710]

Discussion points

• storage is a superset of NVM
• Removing the word "EmotiBit"
• Removing the word "controller"

[nitin710]

possible stored data types

• exposed to user
  • config file
  • data csv file
  • data info file
  • setup log
  • ?Derivative metric typetags (defined by users)
  • Derivative metric pipelines
  • sampling rates
  • base filename modifier
  • device name
  • disabe/enable sensors sets
  • disable/enable typetags
  • crash event logging
  • debug log
• emotibit private
  • hardware serial number/identification
  • Sensor calib data
  • EDA
  • hardware specific sensor-constellation profile
  • maybe this is hardcoded in the EEPROM not if/else in code?
  • crash core dump

Organizing into categories

• DataWriter (class)
  • writeCsv
  • write Info
• Data Reader (class) // future implementation. Probably plays with implementing reading data files from SD-Card using WiFi
  • readCsv
  • readInfo
• ConfigurationManager (decoupled from other classes like DataWriter)(class)
  • config File (currently)
  • in the future, we may split this into
    • loadWifiCreds (exclusively used by EmotiBitWiFi)
    • processConfigWiFiInputs (called buy EmotiBit)
    • emotibit.configurationManager.processWiFiCredsInputs()
  • Derivative metric typetags (defined by users)
  • Derivative metric pipelines
  • sampling rates
  • base filename modifier
  • device name
  • disabe/enable sensors sets
  • disable/enable typetags
  • hardware serial number (emotibit private)
  • sensor calib (emotibit private)
  • crash core dump (emotibit private)
  • hardware sensor-contellation profile (emotibit private)
• Logging (class)
  • setup log
  • Debug log
  • Crash log

Summary

• There is a bit more to be thought through to identify how these classes (defined above) will interact with other classes in EmotiBit and the information exchange.
  • The information exchange will dictate the structure of files
• A high level discussion on this topic may also bring out other types not thought of yet.

• Conclusions

• We should shelf this PR till we define the above listed classes better.
  • The pros for doing so
  • higher likelihood of not moving code again after we complete the PR
  • relatively low tax on task switching as this is a very defined code add.
  • It is very consolidated and well documented, so picking it up later should be relatively easy.
  • It is not an "essential" feature add.
  • The cons for doing so
  • we will leave an open PR
  • This is a good feature add to have, and keep testing to gauge if it needs to change/evolve. (needs more time in master)

Next steps

• discuss and define the structure mentioned above.
• Define the above classes in more detail + information flow

[nitin710]

@produceconsumerobot made the requested changes. Ready for review. (long list of changes.)