Imported Upstream version 2.7.3
This commit is contained in:
Arnaud Quette
parent
a356b56d11
commit
fd413a3168
283 changed files with 14978 additions and 6511 deletions
|
|
@ -85,7 +85,37 @@ String to match if the driver is expecting a reply from the UPS in case of error
|
|||
Note that this comparison is done on the answer we got back from the UPS before it has been processed, so include also the trailing carriage return (+\r+) and whatever character is expected.
|
||||
|
||||
*+testing+*::
|
||||
Testing table that will hold the commands and the replies used for testing the subdriver.
|
||||
Testing table (an array of +testing_t+) that will hold the commands and the replies used for testing the subdriver.
|
||||
+
|
||||
--
|
||||
+testing_t+:
|
||||
|
||||
----
|
||||
typedef struct {
|
||||
const char *cmd;
|
||||
const char answer[SMALLBUF];
|
||||
const int answer_len;
|
||||
} testing_t;
|
||||
----
|
||||
|
||||
Where:
|
||||
|
||||
*+cmd+*::
|
||||
Command to match.
|
||||
|
||||
*+answer+*::
|
||||
Answer for that command.
|
||||
+
|
||||
NOTE: If +answer+ contains inner ++\0++s, in order to preserve them, +answer_len+ as well as an +item_t+'s +preprocess_answer()+ function must be set.
|
||||
|
||||
*+answer_len+*::
|
||||
Answer length:
|
||||
+
|
||||
- if set to +-1+ -> auto calculate answer length (treat +answer+ as a null-terminated string),
|
||||
- otherwise -> use the provided length (if reasonable) and preserve inner ++\0++s (treat +answer+ as a sequence of bytes till the +item_t+'s +preprocess_answer()+ function gets called).
|
||||
|
||||
For more informations, see <<_mapping_an_idiom_to_nut,Mapping an idiom to NUT>>.
|
||||
--
|
||||
|
||||
|
||||
Mapping an idiom to NUT
|
||||
|
|
@ -107,6 +137,7 @@ typedef struct item_t {
|
|||
const int to;
|
||||
const char *dfl;
|
||||
unsigned long qxflags;
|
||||
int (*preprocess_answer)(struct item_t *item, const int len);
|
||||
int (*preprocess)(struct item_t *item, char *value, size_t valuelen);
|
||||
} item_t;
|
||||
----
|
||||
|
|
@ -155,6 +186,8 @@ Command sent to the UPS to get answer/to execute a instant command/to set a vari
|
|||
|
||||
*+answer+*::
|
||||
Answer from the UPS, filled at runtime.
|
||||
+
|
||||
NOTE: If you expect a nonvalid C string (e.g.: inner ++\0++s) or need to perform actions before the answer is used (and treated as a null-terminated string), you should set a +preprocess_answer()+ function.
|
||||
|
||||
*+answer_len+*::
|
||||
Expected minimum length of the answer.
|
||||
|
|
@ -164,7 +197,7 @@ Set it to +0+ if there's no minimum length to look after.
|
|||
Expected leading character of the answer (optional), e.g. +#+, +(+ ...
|
||||
|
||||
*+value+*::
|
||||
Value from the answer, filled at runtime (i.e. +answer+ between +from+ and +to+).
|
||||
Value from the answer, filled at runtime (i.e. +answer+ in the interval [+from+ to +to+]).
|
||||
|
||||
*+from+*::
|
||||
Position of the starting character of the info we're after in the answer.
|
||||
|
|
@ -212,6 +245,11 @@ If there's a problem with a var in +QX_WALKMODE_INIT+, the driver will automagic
|
|||
====
|
||||
--
|
||||
|
||||
*+preprocess_answer(item, len)+*::
|
||||
Function to preprocess the answer we got from the UPS before we do anything else (e.g. for CRC, decoding, ...).
|
||||
This function is given the currently processed item (+item+) with the answer we got from the UPS unmolested and already stored in +item+'s +answer+ and the length of that answer (+len+).
|
||||
Return +-1+ in case of errors, else the length of the newly allocated +item+'s +answer+ (from now on, treated as a null-terminated string).
|
||||
|
||||
*+preprocess(item, value, valuelen)+*::
|
||||
Function to preprocess the data from/to the UPS: you are given the currently processed item (+item+), a char array (+value+) and its +size_t+ (+valuelen+).
|
||||
Return +-1+ in case of errors, else +0+.
|
||||
|
|
@ -252,7 +290,7 @@ We know that when the UPS is queried for status with +QGS\r+, it replies with so
|
|||
Here's the +item_t+:
|
||||
|
||||
----
|
||||
{ "output.voltage", 0, NULL, "QGS\r", "", 76, '(', "", 12, 16, "%.1f", 0, NULL },
|
||||
{ "output.voltage", 0, NULL, "QGS\r", "", 76, '(', "", 12, 16, "%.1f", 0, NULL, NULL },
|
||||
----
|
||||
|
||||
[horizontal]
|
||||
|
|
@ -295,6 +333,9 @@ Because of that we need to provide a floating point specifier.
|
|||
+qxflags+::
|
||||
+0+
|
||||
|
||||
+preprocess_answer+::
|
||||
+NULL+
|
||||
|
||||
+preprocess+::
|
||||
+NULL+
|
||||
|
||||
|
|
@ -314,7 +355,7 @@ Also from +QGS\r+, we want to process the 9th status bit +10000000+*`0`*+001+ th
|
|||
Here's the +item_t+:
|
||||
|
||||
----
|
||||
{ "ups.status", 0, NULL, "QGS\r", "", 76, '(', "", 71, 71, "%s", QX_FLAG_QUICK_POLL, voltronic_status },
|
||||
{ "ups.status", 0, NULL, "QGS\r", "", 76, '(', "", 71, 71, "%s", QX_FLAG_QUICK_POLL, NULL, voltronic_status },
|
||||
----
|
||||
|
||||
[horizontal]
|
||||
|
|
@ -357,6 +398,9 @@ Since a +preprocess+ function is defined for this item, this could have been +NU
|
|||
+QX_FLAG_QUICK_POLL+ -> this item will be polled every time the driver will check for updates.
|
||||
Since this item is mandatory to run the driver, if a problem arises in +QX_WALKMODE_INIT+ the driver won't skip it an it'll set +datastale+.
|
||||
|
||||
+preprocess_answer+::
|
||||
+NULL+
|
||||
|
||||
+preprocess+::
|
||||
+voltronic_status+
|
||||
+
|
||||
|
|
@ -378,7 +422,8 @@ So your UPS reports its battery type when queried for +QBT\r+; we are expecting
|
|||
Here's the +item_t+:
|
||||
|
||||
----
|
||||
{ "battery.type", ST_FLAG_RW, voltronic_e_batt_type, "QBT\r", "", 4, '(', "", 1, 2, "%s", QX_FLAG_SEMI_STATIC | QX_FLAG_ENUM, voltronic_p31b },
|
||||
{ "battery.type", ST_FLAG_RW, voltronic_e_batt_type, "QBT\r", "", 4, '(', "", 1, 2, "%s",
|
||||
QX_FLAG_SEMI_STATIC | QX_FLAG_ENUM, NULL, voltronic_p31b },
|
||||
----
|
||||
|
||||
[horizontal]
|
||||
|
|
@ -424,6 +469,9 @@ Since a +preprocess+ function is defined for this item, this could have been +NU
|
|||
+
|
||||
+QX_FLAG_ENUM+ -> this r/w variable is of the enumerated type and the enumerated values are listed in the +info_rw+ structure (i.e. +voltronic_e_batt_type+)
|
||||
|
||||
+preprocess_answer+::
|
||||
+NULL+
|
||||
|
||||
+preprocess+::
|
||||
+voltronic_p31b+
|
||||
+
|
||||
|
|
@ -441,7 +489,8 @@ We also know that we can change battery type with the +PBTnn\r+ command; we are
|
|||
Here's the +item_t+:
|
||||
|
||||
----
|
||||
{ "battery.type", 0, voltronic_e_batt_type, "PBT%02.0f\r", "", 5, '(', "", 1, 4, NULL, QX_FLAG_SETVAR | QX_FLAG_ENUM, voltronic_p31b_set },
|
||||
{ "battery.type", 0, voltronic_e_batt_type, "PBT%02.0f\r", "", 5, '(', "", 1, 4, NULL,
|
||||
QX_FLAG_SETVAR | QX_FLAG_ENUM, NULL, voltronic_p31b_set },
|
||||
----
|
||||
|
||||
[horizontal]
|
||||
|
|
@ -485,6 +534,9 @@ Not used for +QX_FLAG_SETVAR+
|
|||
+
|
||||
+QX_FLAG_ENUM+ -> this r/w variable is of the enumerated type and the enumerated values are listed in the +info_rw+ structure (i.e. +voltronic_e_batt_type+)
|
||||
|
||||
+preprocess_answer+::
|
||||
+NULL+
|
||||
|
||||
+preprocess+::
|
||||
+voltronic_p31b_set+
|
||||
+
|
||||
|
|
@ -506,7 +558,7 @@ We know that we have to send to the UPS +Tnn\r+ or +T.n\r+ in order to start a b
|
|||
Here's the +item_t+:
|
||||
|
||||
----
|
||||
{ "test.battery.start", 0, NULL, "T%s\r", "", 5, '(', "", 1, 4, NULL, QX_FLAG_CMD, voltronic_process_command },
|
||||
{ "test.battery.start", 0, NULL, "T%s\r", "", 5, '(', "", 1, 4, NULL, QX_FLAG_CMD, NULL, voltronic_process_command },
|
||||
----
|
||||
|
||||
[horizontal]
|
||||
|
|
@ -546,6 +598,9 @@ Not used for +QX_FLAG_CMD+
|
|||
+qxflags+::
|
||||
+QX_FLAG_CMD+ -> this item is an instant command that will be fired when +info_type+ (i.e. +test.battery.start+) is called
|
||||
|
||||
+preprocess_answer+::
|
||||
+NULL+
|
||||
|
||||
+preprocess+::
|
||||
+voltronic_process_command+
|
||||
+
|
||||
|
|
@ -558,7 +613,8 @@ Informations absent in the device
|
|||
In order to set the server-side var +ups.delay.start+, that will be then used by the driver, we have to provide the following +item_t+:
|
||||
|
||||
----
|
||||
{ "ups.delay.start", ST_FLAG_RW, voltronic_r_ondelay, NULL, "", 0, 0, "", 0, 0, "180", QX_FLAG_ABSENT | QX_FLAG_SETVAR | QX_FLAG_RANGE, voltronic_process_setvar },
|
||||
{ "ups.delay.start", ST_FLAG_RW, voltronic_r_ondelay, NULL, "", 0, 0, "", 0, 0, "180",
|
||||
QX_FLAG_ABSENT | QX_FLAG_SETVAR | QX_FLAG_RANGE, NULL, voltronic_process_setvar },
|
||||
----
|
||||
|
||||
[horizontal]
|
||||
|
|
@ -605,6 +661,9 @@ Not used for +QX_FLAG_ABSENT+
|
|||
+
|
||||
+QX_FLAG_RANGE+ -> this r/w variable has a settable range and its boundaries are listed in the +info_rw+ structure (i.e. +voltronic_r_ondelay+)
|
||||
|
||||
+preprocess_answer+::
|
||||
+NULL+
|
||||
|
||||
+preprocess+::
|
||||
+voltronic_process_setvar+
|
||||
+
|
||||
|
|
@ -628,7 +687,8 @@ So we know that the UPS reports actual input/output phase angles when queried fo
|
|||
Here's the +item_t+ for input phase angle:
|
||||
|
||||
----
|
||||
{ "input_phase_angle", 0, NULL, "QPD\r", "", 9, '(', "", 1, 3, "%03.0f", QX_FLAG_STATIC | QX_FLAG_NONUT, voltronic_phase },
|
||||
{ "input_phase_angle", 0, NULL, "QPD\r", "", 9, '(', "", 1, 3, "%03.0f",
|
||||
QX_FLAG_STATIC | QX_FLAG_NONUT, NULL, voltronic_phase },
|
||||
----
|
||||
|
||||
[horizontal]
|
||||
|
|
@ -675,6 +735,9 @@ Here instead it's used by the +preprocess+ function.
|
|||
+
|
||||
+QX_FLAG_NONUT+ -> this item doesn't have yet a NUT variable
|
||||
|
||||
+preprocess_answer+::
|
||||
+NULL+
|
||||
|
||||
+preprocess+::
|
||||
+voltronic_phase+
|
||||
+
|
||||
|
|
@ -683,7 +746,8 @@ This function will be called *after* the +command+ has been sent to the UPS so t
|
|||
Here's the +item_t+ for output phase angle:
|
||||
|
||||
----
|
||||
{ "output_phase_angle", ST_FLAG_RW, voltronic_e_phase, "QPD\r", "", 9, '(', "", 5, 7, "%03.0f", QX_FLAG_SEMI_STATIC | QX_FLAG_ENUM | QX_FLAG_NONUT, voltronic_phase },
|
||||
{ "output_phase_angle", ST_FLAG_RW, voltronic_e_phase, "QPD\r", "", 9, '(', "", 5, 7, "%03.0f",
|
||||
QX_FLAG_SEMI_STATIC | QX_FLAG_ENUM | QX_FLAG_NONUT, NULL, voltronic_phase },
|
||||
----
|
||||
|
||||
[horizontal]
|
||||
|
|
@ -737,6 +801,9 @@ Here instead it's used by the +preprocess+ function.
|
|||
+
|
||||
+QX_FLAG_NONUT+ -> this item doesn't have yet a NUT variable
|
||||
|
||||
+preprocess_answer+::
|
||||
+NULL+
|
||||
|
||||
+preprocess+::
|
||||
+voltronic_phase+
|
||||
+
|
||||
|
|
@ -759,7 +826,8 @@ We know we can set output phase angle sending +PPDnnn\r+ to the UPS:
|
|||
Here's the +item_t+
|
||||
|
||||
----
|
||||
{ "output_phase_angle", 0, voltronic_e_phase, "PPD%03.0f\r", "", 5, '(', "", 1, 4, NULL, QX_FLAG_SETVAR | QX_FLAG_ENUM | QX_FLAG_NONUT, voltronic_phase_set },
|
||||
{ "output_phase_angle", 0, voltronic_e_phase, "PPD%03.0f\r", "", 5, '(', "", 1, 4, NULL,
|
||||
QX_FLAG_SETVAR | QX_FLAG_ENUM | QX_FLAG_NONUT, NULL, voltronic_phase_set },
|
||||
----
|
||||
|
||||
[horizontal]
|
||||
|
|
@ -809,6 +877,9 @@ Not used for +QX_FLAG_SETVAR+
|
|||
+
|
||||
+QX_FLAG_NONUT+ -> this item doesn't have yet a NUT variable
|
||||
|
||||
+preprocess_answer+::
|
||||
+NULL+
|
||||
|
||||
+preprocess+::
|
||||
+voltronic_phase_set+
|
||||
+
|
||||
|
|
@ -838,7 +909,7 @@ Send +command+ or, if it is +NULL+, send the command stored in the +item+ to the
|
|||
Return +-1+ on errors, +0+ on success.
|
||||
|
||||
*+int ups_infoval_set(item_t *item)+*::
|
||||
Process the value we got back from the UPS (set status bits and set the value of other parameters), calling its +preprocess+ function, if any.
|
||||
Process the value we got back from the UPS (set status bits and set the value of other parameters), calling its +preprocess+ function, if any, otherwise executing the standard preprocessing (including trimming if +QX_FLAG_TRIM+ is set).
|
||||
Return +-1+ on failure, +0+ for a status update and +1+ in all other cases.
|
||||
|
||||
*+int qx_status(void)+*::
|
||||
|
|
@ -860,6 +931,7 @@ You can then recompile +nutdrv_qx+, and start experimenting with the new subdriv
|
|||
|
||||
For more informations, have a look at the currently available subdrivers:
|
||||
|
||||
- +nutdrv_qx_bestups.+{+c+,+h+}
|
||||
- +nutdrv_qx_mecer.+{+c+,+h+}
|
||||
- +nutdrv_qx_megatec.+{+c+,+h+}
|
||||
- +nutdrv_qx_megatec-old.+{+c+,+h+}
|
||||
|
|
@ -867,5 +939,6 @@ For more informations, have a look at the currently available subdrivers:
|
|||
- +nutdrv_qx_q1.+{+c+,+h+}
|
||||
- +nutdrv_qx_voltronic.+{+c+,+h+}
|
||||
- +nutdrv_qx_voltronic-qs.+{+c+,+h+}
|
||||
- +nutdrv_qx_voltronic-qs-hex.+{+c+,+h+}
|
||||
- +nutdrv_qx_zinto.+{+c+,+h+}
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue