sjstein / tpmonitor Goto Github PK

Check into handling user-interrupt (ctrl-c) during server poll. The following trace was noted when the server was not responsive and the user tried to exit:

20200330 16:41:51 [WARN] Timeout waiting for server response. {tpMonitor.py}
20200330 16:41:56 [WARN] Timeout waiting for server response. {tpMonitor.py}
20200330 16:42:01 [WARN] Timeout waiting for server response. {tpMonitor.py}
Traceback (most recent call last):
File "tpMonitor.py", line 133, in
s.connect((server_addr, PORT))
socket.timeout: timed out

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "tpMonitor.py", line 133, in
s.connect((server_addr, PORT))
KeyboardInterrupt

To clean up calls to console message, consider creating class logger with:
verbosity as a class variable
methods for printing the different severity messages
a parameter for messages which specifies either a file or stdout
a parameter for decimal precision of timestamp logging
logger.{info,warn,erro}(destination,prec,message)

Make the server log and console messages consistent with severity codes used in tpMonitor client software

Create a directory structure and add files to support installing tpServer as a *nix startup process

Work on a true message passing client-server request model. As it stands now, the server just spits back data when connected to. Generate different query types allowing the client to request certain data, or possibly set system time or other parameters (for example, density of water).

Per comment from @c-to-the-fazzy :

There's a kwarg on the parser.add_argument called choices that sets the allowable values for a CL argument. It's usage would be something like choices = [0, 1, 2] up on line 61, and it would do this type of error checking automagically.

This will allow cleaning up range validation for certain CL arguments

To be consistent with other ASP tools, the datasets should be stored in a directory as follows:
./Data/<YYYYMMDD>/<fname>

If the exists, an underscore and sequential number should be added:

./Data/<YYYYMMDD>/<fname>_1
./Data/<YYYYMMDD>/<fname>_2
etc.

To make this a bit easier to implement, default to always using a .txt extension therefore making the -l argument the filename without extension. The will aid in appending the sequence number if needed. #

This should be run forever condition, but gives error
20200425 06:43:58 [ERRO] Invalid run duration (--time) (-1). Exiting. {tpMonitor.py}

Consider adopting console message styles as seen at APS or elsewhere

Clean up the naming conventions of variables and function names to correspond to modern python standards

Be able to handle out-of-bounds conditions for the input arguments (like negative time or invalid characters in filename). Also check for proper tcp/ip address formatting.

For [info] level messages, add temperature to the status output (deg C / deg F)

The following error is generated when a run completes normally in tpMonitor:

20200409 18:31:55 [INFO] Acquisition complete. {tpMonitor.py} Traceback (most recent call last): File "tpMonitor.py", line 161, in <module> f.close() AttributeError: 'str' object has no attribute 'close'

Should a general library be created for things like console message functions to be used by multiple project programs?

Get this code up to python 3 syntax

We need to consider the in-field use case for the tpMonitor:

• Will it be run multiple times in sequence?
  -- If so, should the program break up the saving of the logged data into discrete files? What granularity?
• Revisit the default values for frequency and duration (depending on decision above)

Problem

For the purposes of debugging, it is desirable to be able to test changes to tpServer.py and tpMonitor.py without direct access to the MS5837 sensor hardware.

Solution

Develop a 'mock' sensor that exposes an identical set of class methods, which return random or static synthetic data.

Enable graceful exit on ctrl-c for tpServer

Consider creating a separate server application to present a RESTful API for use as a web service

Learn and use git submodules to properly link to the blue robotics fork. Also consider renaming tpUtilities.py to something more generic for use with other repos

No reason to have these two in separate places

Look into periodically closing (and re-opening) the log file to allow asynchronous reading from the cmd line during server operation

There are times where a user may want to monitor either the temperature or pressure rapidly on the console. Consider adjusting the output format for that case so they do not have to parse through the [INFO] type stuff. Perhaps another CLarg which polls at a rate and outputs in a more concise format like:

depth = 123m (366ft)

carry even further for displaying just one unit given the CLarg?

During a router reboot, the following error was noted:

20200525 00:19:06 [WARN] Timeout waiting for server response. {tpMonitor.py}
Traceback (most recent call last):
File "tpMonitor.py", line 101, in
data = s.recv(1024)
ConnectionResetError: [WinError 10054] An existing connection was forcibly closed by the remote host

Add except clause to catch, delay, and retry connection until either success or user interrupt.

This code snippet within tpMonitor appears to have a socket close which is not needed. Possibly vestiges of older style of client/server comms wherein the socket would be opened and closed for each message handshake.

 if logging:
            f.close()
            s.close()

Would it be valuable to add alarms for monitoring temp and/or depth as a parameter for the client?

-thi : temp too high
-tlo : temp too low
-dhi : depth too high
-dlo : depth too low

How often to alarm?

Usage example:

python tpMonitor 192.168.1.1 -t 100 -thi 28c

Connect to server and alarm if the temperature is over 28 degrees c

Figure out how to narrow down broad use of except: clause in try statement(s)

Get rid of camelCase, Follow pep-8 guidelines.

Add support for connections from more than one client by multi-threading

Add option for different verbosity levels re: console messages