Fleshed out both documents

CONFIGURE.md

@@ -25,6 +25,7 @@ Environment=EMAIL_TO="email@domain.tld"
 Environment=SMS_DST="phone_number@sms.domain.tld"
 Environment=NOTIFICATION_CMD="dunstify"
 Environment=NOTIFICATION_OPTS="--timeout=0 --printid --urgency=critical --icon=/usr/share/icons/breeze-dark/emblems/16/emblem-warning.svg"
+Environment=NOTIFICATION_HIST_CMD="dunstctl history"
 Environment=NOTIFICATION_IDX=15
 Environment=SSH_USER="username"
 Environment=SSH_HOST="localhost"
@@ -49,3 +50,40 @@ Environment=CLEAR_THRESHOLD="5.0"
 # WantedBy=multi-user.target
 ```
 
+All of these are required except where noted, there are no default options
+(defaults may be added in the future).  A brief description of each:
+* **EMAIL_TO**:  the email address the notification should be sent to.  The
+  output of `pidstat` will be included in the body of this email, for each
+  triggered resource type (CPU, I/O, Memory), at the time the monitor alerted.
+* **SMS_DST**:  the email-to-SMS address, as defined by your mobile carrier.
+  Please review your mobile carrier's documentation.  For Google Fi, based in
+  the US, the format is
+  `<mobile_number_without_country_code>@msg.fi.google.com`.  This email address
+  does **not** get the output of `pidstat` in the body of the message.
+* **NOTIFICATION_CMD**:   The command on the remote host to run to display
+  notifications, e.g. `notify-send` or `dunstify`.
+* **NOTIFICATION_OPTS**:   Options for the `${NOTIFICATION_CMD}`.  Should
+  include `--print-id` if supported by the command.
+* **NOTIFICATION_HIST_CMD**:  The command to display the notification history
+  (e.g. `dunst history`).
+* **NOTIFICATION_IDX**:  The index if the JSON structure that contains the
+  notification ID.  `dunst`, as of version 1.9.2-1, displays its history as a
+  JSON structure.  For other notification daemons, some other history mechanism
+  will likely be required;  patches needed and welcome!
+* **SSH_USER**:  The SSH username to connect to the remote host that will
+  display the notifications to the system administrator.
+* **SSH_HOST**:  The SSH host to connect to.  This is where
+  `${NOTIFICATION_CMD} ${NOTIFICATION_OPTS}` and `${NOTIFICATION_HIST_CMD}`
+  will run.
+* **SSH_PORT**:  The SSH port to connect to.
+* **SSH_ID_PATH**:  The path to the SSH id (private key file) to use for
+  authenticating to the remote host.  This can be exluded if the local user
+  already has an ssh-agent running, with the necessary key and passphrase
+  entered.  If ssh-agent is not desired, then this SSH id (private key file)
+  should have an empty passphrase (i.e., no passphrase).  Not having this
+  environment variable, and no ssh-agent will disable the desktop notifications
+  (SMS and email will still work, as they don't use SSH)
+* **CLEAR_THRESHOLD**:  The percentage threshold the some avg300 threshold
+  should be below before considering the alert cleared.  This will depend
+  highly on the workload running on 
+

README.md

@@ -17,6 +17,18 @@ near real time.
 * psi-by-example (a modified version of this is included in this project as a
   submodule)
 * a libnotify-compatible desktop notification system
+    * any notification program should use the `--print-id` parameter if
+      possible
+        * both `notify-send` and `dunstify` (part of
+          [dunst](https://dunst-project.org/)) support this
+    * note, this has only been tested with `dunst`, since it has the capability
+      of showing notification history
+        * `notify-send` specifically does not appear to retain a history, so the
+          `check_dunst_id_is_visible` function won't work with it (and the logic to
+          skip sending a new notification if one is already sent will be broken).  
+            * since I don't use `notify-send`, I'm not sure how to solve this
+            * patches welcome!
+* jq (for the aformentioned `dunst` integration)
 
 ## History
 
@@ -98,6 +110,7 @@ below the configurable threshold for at least five minutes).
     * consider reworking this for a user service, not a system service
         * this could make desktop notifications simpler, and not having to use
           SSH keys without passphrases
+          * possibly learn how to connect to an existing ssh-agent
         * need to become much more familiar with user services
 * consider reworking all code in a compiled language (other than C)
     * time to learn Go