nutdrv_qx_masterguard: Adds a clear.fault.record instant command

[atanas-vladimirov]

Also adds two experimental variables:

• battery.ageing.factor ("Battery ageing factor in promille) and
• battery.calibration.factor (Battery calibration factor in percent).

Tested on A1000 and A2000 units

Signed-off-by: Atanas Vladimirov [email protected]

[jimklimov]

I see you've caught on to the idea of spinning numerous feature branches simultaneously ;)
This was a very bright week so far :)

[atanas-vladimirov]

Hey Jim,

Yes, but I still make mistakes and try to learn :)))
By the way I have some doubts about this experimental.* variables thing and meaning. For example, I wonder if those two battery variables should be experimental or not?
What I saw during my tests is that they are not shown together with all other variables, but are logged by the driver in the logs. Any thoughts on that will be appreciated :)

Edit:

Here is how it looks:

Nov 13 09:43:12 hodor nutdrv_qx[87544]: experimental.input_fault_voltage: 225.5
Nov 13 09:43:12 hodor nutdrv_qx[87544]: experimental.battery.ageing.factor: 999
Nov 13 09:43:12 hodor nutdrv_qx[87544]: experimental.battery.calibration.factor: 100
Nov 13 09:43:12 hodor nutdrv_qx[87544]: experimental.fault_1: 0: none
Nov 13 09:43:12 hodor nutdrv_qx[87544]: experimental.fault_2: 0: none
Nov 13 09:43:12 hodor nutdrv_qx[87544]: experimental.fault_3: 0: none
Nov 13 09:43:12 hodor nutdrv_qx[87544]: experimental.fault_4: 0: none
Nov 13 09:43:12 hodor nutdrv_qx[87544]: experimental.fault_5: 0: none
Nov 13 09:43:42 hodor nutdrv_qx[87544]: experimental.input_fault_voltage: 224.5
Nov 13 09:43:42 hodor nutdrv_qx[87544]: experimental.battery.ageing.factor: 999
Nov 13 09:43:42 hodor nutdrv_qx[87544]: experimental.battery.calibration.factor: 100
Nov 13 09:43:43 hodor nutdrv_qx[87544]: experimental.fault_1: 0: none
Nov 13 09:43:43 hodor nutdrv_qx[87544]: experimental.fault_2: 0: none
Nov 13 09:43:43 hodor nutdrv_qx[87544]: experimental.fault_3: 0: none
Nov 13 09:43:43 hodor nutdrv_qx[87544]: experimental.fault_4: 0: none
Nov 13 09:43:43 hodor nutdrv_qx[87544]: experimental.fault_5: 0: none

Another question (not related to this PR) is about experimental.input_fault_voltage - I still can't find its meaning and what the UPS is reporting as value is the same as input.voltage. So, I wonder if any changes are needed there.
The same questions applies for the fault_X records .....

Because now the drives is filling the logs with unuseful records ....

[jimklimov]

Primarily, the experimental.* namespace allows to move forward quickly. Changes to nut-names.txt should happen via some community discussion and concensus, to make sure the concepts we reflect there make sense for different vendors and devices. For example, much of last/this year revolved around the concept of "ECO" which means absolutely different things to different makers and users, ultimately a greenwashing buzzword with no real single meaning - not a "term" that can be useful in technical or scientific sense.

[jimklimov]

I did not quickly find where those logs are coming from, there does not seem to be any special logging handling for experimental in nutdrv_qx_masterguard.c, nutdrv_qx.c, main.c or even dstate.c I think.

The use of addvar() also looked fishy in this subdriver, but apparently happens in many others so could have been a copy-paste with initial submission(s) - this is a way to add command-line options to a driver program. Maybe something in nutdrv-qx unified processing of those somehow, but I do not quickly see any C variables related to those strings, nor value-getters in code loops (which would also be incorrect if they were/are there - tree walks and string-number parsers too expensive to do regularly, especially over same inputs for same outputs).

[jimklimov]

I'll be fairly busy today, so probably this is something you would have to track down yourself. Maybe a debugger would help to step through the code (I had good experience with NetBeans IDE for that, some with VSCode - see notes in NUT docs).

[AppVeyorBot]

❌ Build nut 2.8.4.3781-master failed (commit b02a94cfc3 by @jimklimov)