GUI and Gateway Software Next Steps

This page lists suggested improvements to make on the GUI that are known at this time.


High-Level Goals

High-level understanding of this code:

  1. Scan for devices that have a very specific address with some kind of encryption.
    1. These devices shouldn't show up anywhere else, and this scan shouldn't single out devices that are not sensor nodes.
  2. Instantly pair with sensor nodes and store the node.
  3. Allow user configuration of the nodes.
    1. User can see a list of nodes that are connected.
    2. User can press a button so that the specific node to edit flashes the LED.
    3. User can name the node (default is assigned).
    4. User can give info like device type, device placement, and notes.
    5. User can configure info like collection frequency (ex: once a day) and collection duration (ex: 30s)
    6. User can remove a node from the fleet. (Database of fleet?)
    7. User can choose gateway settings, like upload frequency.
    8. User can change connection settings (ex: Wi-Fi vs cell)
    9. User can decide what to do with the data saved on Pi (ex: replace data, stop collecting)
    10. User can also see data saved on the device by device type (user-entered name) and by day.
      1. Folder also contains a file with current config settings, which can be changed.
    11. User can manually upload information to the cloud.

Software Next Steps

Improvements to the GUI

Suggested Improvement Current Priority (1-5, 1=highest)
There is a language drop-down for French and Chinese (simplified). All text fields have translating enabled. Currently the only available language is English. 5
There is no data scrubbing for modified fields that will be updated in the database, except for ensuring that ' and " are not present in the fields. Scrubbing is needed to ensure that there are no instances of DROP TABLE/ other SQL commands, as well as allow ' and " and other special characters to be entered as characters. 3
Some functions rely on a cursor to be passed as a parameter, while other functions open the database connection from scratch. This should be changed so that all functions follow the same protocol. 4
Some database functions open a connection and do not close it after. This will need to be updated so that they open and close the connection (at the very least the cursor), or some alternative (good database hygiene). 2
Some functions are named using camelCase and other use lower_with_under. Python Naming Conventions say that all functions, packages, variables and libraries should use lower_with_under, classes should use CapWords, global/class constants should use CAPS_WITH_UNDER. 3
This code is run from a .py function. This should be changed so that an .exe can be ran directly from either terminal or a shortcut on the Pi (for ease of use). 5
All library files for this project contain a variable SHOW_PRINT that allows some print statements to go to the terminal for debugging purposes. These have not been chosen for integrated testing; these were usually print statements that were used while writing the individual function, and then commented out with this variable later. Care should be taken to decide which of these statements are worth keeping in, and the others should be removed. 5
Many database functions use the "try… except" method as an alternative to proper query validation. This works for now, however it might be more useful to expand these sections to give back specific errors and have the GUI react accordingly - ex. sending error pop-ups that describe what is wrong, without breaking the GUI. 3
There are several points in the code where it would be useful to have some kind of loading icon to show that something is happening in the backend. I tried implementing this, but the processor couldn't keep up with the problem of generating the animation and running it's background functions at the same time. (First method I tried) (Second method I tried) (Good source for finding animations) (Also tried a text-based method by adapting this source) 4
Will need to implement firmware update over the air (OTA) in the Bluetooth protocol using the method recommended by Silabs 1
So far communication has been OK without explicitly pairing (ie connecting only), however there is a way to force pairing that has not yet been implemented. Explained here in some depth. 2

Items to Research Further

See Also

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License