Thank you for explaining that. That makes me feel better about my
approach - maybe I misunderstood the programming of get_type, or the
requirements of creating a variable in the driver - but this helps keep
things simple on my end.
On 9/3/2021 12:54 AM, Roger Price wrote:
On Thu, 2 Sep 2021, Glen Bakeman via Nut-upsdev wrote:
To give a little more background, I'm working on a program that,
among other things, will parse the variable type(s) that are passed
to it from a NUT server. I'd like to understand just how
exotic/complicated a variable type can get. If that means ENUMs are
just enum and nothing else, great - although from my understanding in
the master branch of the nut-ups code, it seems possible that
variables can mix and match when the server responds to such a query.
I'm hoping someone can maybe provide a few examples of what the most
complex variables look like, since I don't seem to have those on my end.
There is no overall grammar for the "language" of the responses sent
by a NUT server to the client. Each command received by the server
invites a response with a very limited grammar available for that
response.
The command GET TYPE <upsname> <varname> returns the type, i.e. the
grammar of the response. There is only one type per variable, and
there is only one grammar. Choosing the grammar of the response
requires the server code to be able to handle all the possible types,
but the client will receive only one at a time.
This is why the examples given are always simple, as in 4.2.4.6.
command GET VAR su700 ups.status and response VAR su700 ups.status "OB
LB"
However some testing showed:
rprice@maria ~ nc localhost 3493
GET TYPE Eaton ups.status
TYPE Eaton ups.status NUMBER
GET VAR Eaton ups.status
VAR Eaton ups.status "OL"
"OL" is not a NUMBER. I cannot explain this. Perhaps others can.
Roger
_______________________________________________
Nut-upsdev mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
_______________________________________________
Nut-upsdev mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
