A belated thank you for all the information! Pandemic reduced coding time, oddly, until a few weeks ago.
Sending 0x00 01 from the TTN Console (Device->Overview->downlink) is much easier than constructing a json there as you suggested, and I’ve created an excel spreadsheet to enter information and create the HEX to send to various ports. Because of the amount of data to potentially send to the node (much more than the 51 bytes allowed), I have split my downlinks into meaningful groupings (site-specific information used in calculations such as elevation, lat-lon, etc.; node behavior such as timing, how often to send battery information, etc.).
Now that I have a very long switch-case representing almost 50% of my sketch (with debug Serial.print lines) I’ll have to explore and figure out how to implement the suggested handler function based on the paxcounter example–static cmd_t table [].
Also on the node I have set the variables to be stored in EEPROM. When the node starts it first checks to see if the EEPROM.get(start byte address, data) is not equal to 0, then uses that value, or if 0, then it sets a default value for initial startup. On downlink, I can also reset the node to all defaults by using EEPROM.put for all non-zero values. At this time, there is a specific EEPROM range for each variable, but I understand that should be cycled through the whole of the EEPROM registers to preserve the life of the chip. However, if I run over 100k write limits on eeprom, I have grossly messed up.
As an example of what the node receives from downlinks, I have set my downlink to Port 1 to five standard operational conditions. Sending 0x0005 (0005 in the Overview Panel) to Port 1 is the same as sending 0x0000B501030200640300020400480501060207F0 to Port 2, both of which have the following settings as seen from this Excel Spreadsheet grab:
If the user chooses to set any variable individually or as a group outside normal operations, Port 2 can be used for that (edit: in our particular setup).