System-specific software pushes on web interface

[aforbis-stokes]

The variables that local operations would like to have access to alter for their systems are below:
pin_mapping (e.g. move HTR to A5 if A2 becomes damaged)
Temp high/low settings (ADPL-electon.ino INCINERATE_LOW_TEMP & INCINERATE_HIGH_TEMP, line 32 & 33)
Time between ignition (ADPL-election.ino IGNITE_DELAY, line 34)
Delay between valve open and ignite (ADPL-electron.ino delay (100), line 74)
Igniter on time (ignitor.h _ignitor_on_time, line 13)

One point of discussion is that most of these variables will only be altered during initial system setup, and once operation is consistent, they will remain unchanged.

[mlp6]

@aforbis-stokes for the delays, do you have bounds and increments that should be adhered to? Something to make sure that a nonsensical value doesn't get passed onto the device. Could be set by pulldown menu if in larger, discrete chunks, or be a number entry box with min/max limits.

[aforbis-stokes]

For delay between igniter ignition: If text entry, 1 min increments should be fine; bounds at 1 and 60. If options in a pull down, something like 10, 15, 20, 30, 45, 60
Delay valve open and ignite, 100ms increments up to 5s or if pull-down menu: 100ms, 500ms, 1s, 2s, 3s, 4s, 5s

[aforbis-stokes]

Additional variables to add to the list:
VOLUME - Tipping bucket volume changes per location
OPTIMAL_FLOW - Different expected flow rates per location
PUBLISH_DELAY - When performing field diagnostics, receiving publishes (e.g. temps) every 2.5 min can eat up time. Temporarily decreasing PUBLISH_DELAY will make this easier. Will have to be confirm that this will not create other problems.