There's a bit of a disconnect between inputs and holdings at the moment; holdings are far more "raw" and you read/write them unprocessed, specifying the exact register. In comparison inputs are processed into more "human friendly" values and batched out as part of inputs/1inputs/2 and inputs/3 messages, which is mostly an early design decision from when I only really cared about getting the power data into MQTT and had little knowledge of how the registers were laid out.
This PR adds more direct raw access to input registers, so now you can do lxp/cmd/all/read/input/10 to get the instant battery charge power and get the raw register result in MQTT.
This also means that sending lxp/cmd/all/read/input/0 with a payload of 40 is identical to sending lxp/cmd/all/read/inputs/1, so the new topic could eventually supercede the old one.
The processed JSON datadumps are still sent out when the appropriate packets are received (registers 0-39, 40-79, and 80-119 - or on newer inverters, 0-127).
Few considerations with this:
it gets quite spammy in MQTT because there's 120 publishes every 5 minutes when the usual automated power data gets sent out from the inverter. For this reason, I've added a new publish_individual_input configuration option, defaulting to off for now.
could be confusing that cmd/read/input returns unprocessed registers but cmd/read/inputs returns processed JSON. (and similarly that lxp/datalog/input/1 is raw integers, but lxp/datalog/inputs/1 is processed JSON.
Ultimately it's probably not that useful to read a single input register anyway when you can read 40 at a time, but I think having this in for completeness is a good idea.
There's a bit of a disconnect between inputs and holdings at the moment; holdings are far more "raw" and you read/write them unprocessed, specifying the exact register. In comparison inputs are processed into more "human friendly" values and batched out as part of
inputs/1inputs/2andinputs/3messages, which is mostly an early design decision from when I only really cared about getting the power data into MQTT and had little knowledge of how the registers were laid out.This PR adds more direct raw access to input registers, so now you can do
lxp/cmd/all/read/input/10to get the instant battery charge power and get the raw register result in MQTT.This also means that sending
lxp/cmd/all/read/input/0with a payload of40is identical to sendinglxp/cmd/all/read/inputs/1, so the new topic could eventually supercede the old one.The processed JSON datadumps are still sent out when the appropriate packets are received (registers 0-39, 40-79, and 80-119 - or on newer inverters, 0-127).
Few considerations with this:
publish_individual_inputconfiguration option, defaulting to off for now.cmd/read/inputreturns unprocessed registers butcmd/read/inputsreturns processed JSON. (and similarly thatlxp/datalog/input/1is raw integers, butlxp/datalog/inputs/1is processed JSON.Ultimately it's probably not that useful to read a single input register anyway when you can read 40 at a time, but I think having this in for completeness is a good idea.