That would not allow you to send multiple configuration values in one downlink?
As configurations won’t happen too often, I’d simply use some key-value format, even though that increases the payload size a bit. Say 0x00 denotes the interval and requires a 2 bytes value, 0x01 sets some number of measurements and uses a 1 byte value, 0x02 sets some single byte bitmap, and 0x03 would restart the device (and make it do a new OTAA join, perhaps after a short timeout to allow for removing a device from one network and registering it on another). Then all of the following would work in a single downlink:
00....to change interval00....01..to change interval and number of measurements01..00....same result00....02..to change interval and some bitmap, but not number of measurements03to reset the device- and any combination and order
You’ll also need to decide if the settings should survive a restart. (If they should be persisted in non-volatile memory.)
After each downlink, I’d send an uplink with the current settings, to confirm the settings. That could probably include all settings, so no “key” needed there, just an ordered list of values. I’d also do this after an empty downlink. (I’m not sure if empty application downlinks are supported, given that Paxcounter supports some 0x08 “do nothing” NOOP-command.)
Be careful when using confirmed downlinks, especially when implementing some restart command.
I don’t understand what you’re saying here. 