Request for generic Q2/Q6 protocol variants

[dvdesolve]

In a light of recent findings:

• 1
• 2
• 3
• 4, especially, this comment

it looks like we're close to formulate generic handler for Q2/Q6 protocols. As for now innovart31 protocol was already merged in the main code tree and it uses only a small subset of known Qx protocol details for very specific 3/1 topology of some UPSes (such as Ippon Innova RT 3/1, models 10K compact, 10K and 20K). However now it becomes clear that more advanced UPSes (e. g. not from Ippon's Back Basic series, especially three phase models) uses primarily Q2/Q6 protocol variant and not Q1. In addition to the plain Q2 and Q6 requests such UPSes actively uses info from WA, WH, BPS, F and some other. As for now innovart31 uses good old Blazer claiming and init routines which rely on input.voltage variables and some more. Also it hardcodes input.phases and output.phases to 3 and 1, accordingly.

May be it would be a good idea to make separate claimer/initializer for such advanced UPS models to test for their capabilities (e. g. via FW?, SASV07?, F, WA, Q2, Q6 etc) and suggest which topology we're dealing with (according to the Santak's datasheet we can decide whether we have single or three phase input or output by looking for explicit zeroes for S and T phase measurements). In any case it may be useful to just dump all-phase measurements to the list of NUT variables to support broader range of devices and user requests.

Also from now we can even know a bit of input and output transformer topologies - star and delta. However, I haven't found corresponding variables for the description of I/O power topologies in RFC. Is it possible to add experimental.* one?

@jimklimov what do you think about separate protocol variant for advanced Megatec-like devices?

[jimklimov]

I think it makes sense, at least being a separate protocol allows it to be an option that does not "infringe" on other code (in case something works not as well as older protocol implementations for someone).

[jimklimov]

And yes, experimental.* data points are a good start for a community discussion to find similar concepts in other vendirs' products, and a common name (maybe not one that any vendor uses) that satisfies the majority of audience.

[dvdesolve]

I think it makes sense, at least being a separate protocol allows it to be an option that does not "infringe" on other code (in case something works not as well as older protocol implementations for someone).

Some points to think about:

1. Is there a rule that Q2 support also implies Q6 and vice versa?
2. Does WA support work only in pair with Q2/Q6 or also may exist without them?

If 1st point is false we can provide two separate protocol variants - q2 and q6, so the end user will be able to choose between them.
If WA may be accessible without Q2/Q6 we can just provide any available info without checking for WA support explicitly during claim/init. If I understand it in a right way, even if we make explicit requests for some info and it's not available (e. g., command is not supported), NUT will not crash the whole pipeline, just will omit non-existent variables?

[dvdesolve]

Moreover, in case of Q6, there is no status bits as with Q1/Q2. So, for Q6 protocol driver we still need to ask for Q1 (it seems like all of Megatec-compatible devices still speak Q1 dialect) to get status bits