Some older tech debt found during work on solution for #2708 and planned follow-up to #2850 in particular:

• drivers/dstate.c: sock_arg(): if INSTCMD returns STAT_INSTCMD_UNKNOWN, let it be known to the TRACKING clients
  • Follow-up to RFC: INSTCMD and SET VAR status tracking #656, INSTCMD and SET VAR status tracking implementation  #659, INSTCMD and SET VAR status tracking implementation - bis #660, Implement tracking commands in libnutclient #673 et al
  • The situation seemed unlikely (unsupported commands would be filtered out earlier), but still untidy. The code structure with "try shared instcmd, try driver instcmd, return" was there from 2005 or before; the (pedantically incomplete) ability to actually report the status was added in v2.8.0, in 2019 or so (when TRACKING mode is enabled for the query).
• server/upsd.{c,h}: handle TRACKING value for STAT_CONVERSION_FAILED
  • Follow-up from apc_modbus: Updates, command, writable variables and outlet group support #2184 (v2.8.2)
  • We could report a numeric status (on socket protocol between driver and data server) not understood by the latter, so it would be an ERR UNKNOWN rather than ERR INVALID-ARGUMENT which applies more closely (at least from variants already defined in the NUT networking protocol)
• drivers/usbhid-ups.c: anticipate NULL hidups_item->dfl for commands; return STAT_INSTCMD_CONVERSION_FAILED if neither caller nor default parameter was available
  • for older code - avoid NPE in subsequent use of val with drivers that might put a NULL value in that dfl field for HU_TYPE_CMD entries (none seen in-tree so far)
  • for future code - prepare for use-cases that require a caller-provided argument (intentionally setting no defaults) for an INSTCMD, this is a direction where PR Revise the stance on ECO/... modes in NUT standard, amend implementations #2850 (or its follow-ups) may be going