NUT Dummy driver Gen3

[aquette]

dummycons (1rst generation) and dummy-ups (2nd generation) have well served various purposes, such as:

• debug of the NUT framework,
• client development
• simulation for QA regression testing purpose (with static definitions and power sequences)

The work on dummy-ups also permitted the creation of the NUT Devices Dumps Library (http://www.networkupstools.org/devdumps/).

However, time has come for a 3rd generation to address the following, either in definition files (.dev / . seq) and / or the driver:

• 1. Add versioning to current definition files (.dev / . seq)
• 2. Specify v2 of definition files (.nut?), including the below
• 2.1. Handle read/write flags for variables
• 2.2. Handle instant commands
• 2.3. Handle complementary information and user comments (need specific comment annotation)
• 3. Create a new nutdrv-repeater driver from the "repetition" mode code
• 4. Create a new driver nutdrv-simulation from the "dummy" mode code
• 5. Create a tool to assist users in dumping all needed data in a smart and easy way

1. and 2.* will also permit to improve the NUT Devices Dumps Library, by providing more information.

[clepple]

Actually, the nutdrv-repeater driver might also be useful for modifying values from an UPS that is reporting predictably incorrect values. I think this was the original motivation behind the thread that inspired #97 (min/max reporting).

Obviously, if we can unambiguously detect that a driver should scale or offset a value, then we should do that in the driver, but if it is a calibration issue, or if the UPS hardware cannot be uniquely identified, then I think this should be handled by a repeater. That way, upsmon can still connect directly to the real driver, but graphing software can talk to the repeater.

The repeater might be best implemented in a high-level language like Python, where the scale/offset operations can be done with an 'eval' statement.

[zykh]

.dev/.seq files

what about something like this?
https://github.com/zykh/nut-ddl-raw/blob/master/Manufacturer1/ModelFamily1/Manufacturer1__ModelFamily1__ActualModel1__driver-name__NUTVersion2.dev

• RW variables
  RW:var.name:<type>:<option>\n
• Commands
  CMD:command.name\n

If we want new dumps to be backward compatible we could:

• comment out everything new
• then evaluate every commented line to search one of the supported things (i.e. RW:<var.name>:<type>:<option>\n, CMD:<cmd.name>\n)

However doing this would mean we won't be able to use parseconf (at least as it is now, since # lines are treated as comments and ignored)
https://github.com/zykh/nut-ddl-raw/blob/master/Manufacturer1/ModelFamily1/Manufacturer1__ModelFamily1__ActualModel1__driver-name__NUTVersion2.backward_compatible.dev

ddl repo

We may want to split things down to Manufacturer/Model_Families/Models:
https://github.com/zykh/nut-ddl-raw

nut-recorder

Since we want to record (both in dev and sec files) also rw vars and commands instead of relying on the output from upsc/upsrw/upscmd and then parse it we may want use directly NUT's net-protocol.

We could use PyNUT or maybe upsclient, just like ups{c,cmd,rw}.. and since we are there.. what about merging ups{c,cmd,rw}/nut-recorder in something like a 'nut-controller'?

Does this whole thing sound that bad?

[zykh]

.dev/.seq files - ..follow-up:
If we don't care about it being backward compatible we could get rid of colons altogether:
var.name var value
RW var.name <type> <options>
CMD command.name
This would be easier to handle with parseconf.

[aquette]

@zykh: this doesn't sound bad at all, and we're definitely on the same page!

2) .dev/.seq files v2

• backward compat will not be kept
• v2 can functionally be either .dev (static definition) or .seq (definition + events)
  As such, the .dev/.seq extension becomes meaningless.
  The file extension is still questionable. Ideas welcome...
• the format you're proposing suits me fine. The comment idea is very nice.
• a specific Version comment is missing (https://github.com/zykh/nut-ddl-raw/pull/1/files)
• however, as you pointed, parseconf is on the way.
  It has been the major limitation since day 1 of dummy-ups
• @balooloo has started to work on that (I let you detail @balooloo )
• @balooloo also proposed the idea of embedded script, under a specific comment block.
  This would be a(nother) way to create power sequences.

nutdrv-simulation

• naming idea are still welcome
• we've also discussed a lot about it with @balooloo (over coffees...), since it's the opportunity:
  • to start the new C++ driver core (will also serve nutdrv-snmp)
  • to elaborate and implement a few methods that would be also needed for nutdrv-snmp

ddl repo

• suits me fine
• we'll need someway to index / something to create a manifest

nut-recorder

• @zykh: nut-controller is already (TM) @balooloo ;)
  we'll discuss that point in a separate thread / issue. Also see NUT Controller (nutctld) #13.
• nutclient (what you called nut-controller) is indeed what I had in mind. You added the recorder part, which makes a lot of sense.
  Another C++ opportunity, using libnutclient
• nut-client would be a more coherent name with nut-scanner, nut-config

[EmilienKia]

Many considerations:

Dummy driver

The need to have a dummy driver is clearly to have a simulation driver. This needs to address three points, in order of importance:

1. To reproduce a previously recorded sequence. This is for what current dummy driver is design for. I agree to say we need also a (or many - see after) way to record sequences.
2. To reproduce a full device behavior. This imply to simulate a state-machine. Each state (OL, OB ...) will be associated to a specific sequence. Transition between sequences can be affected by SET commands. The used file format can be derivate from current format by adding subsequence sections with section header (like config files).
3. To programmatically reproduce a device. This is an enhanced case of previous one. The new dummy driver can offer an API for a light language like LUA.

Recording data

We need to record data ... to replay them.

• To understand and debug user cases.
• To develop and debug new drivers.
• (Put here here any user specific need).

But we probably need to record different level of data.

• Primary data: what (and when) is directly picked-up from device.
• Filtered data: what (and when) is taken in account by device. This is the filtered version of primary data.
• Shared data: what (and when) is shared to all the nut system. This is data pass to upsd and shared above it.

I think we will have a complete correct vision of what is done in nut data flow when we will ready to have these 3 levels.
So recording is not the job of a dedicated agent in the nut system. Such job must be addressed by different actors in nut system. (to be completed).

I think this needs some big rework and cannot be achieve soon. But it make sense to be considered.

nutclient

A strange thing is remaining in nut distribution is the presence of many executables to do similar requests: upsc/upsrw/upscmd. Why not ! But why ?
Perhaps having a nutclient command that will process all commands can be a good idea. It can process commands from:

• command line parameters (scripting capability)
• an input script file
• an interactive stdin
  Results can be flush to file or directly to stdout.

A such client can process commands like network commands:

GET UPS
GET VAR UPS1...
SET VAR ...

This can be nammed "nutclient". It is more in line with actual commands and library (like libnutclient). Moreover the "nut controller" will be used to the internal orchestrator for future nut system.

[aquette]

@clepple : on the repeater part and your above answer...
a cleaner / simpler approach would be allowed through some scaling mechanism / directive and common code in main (as for the "override" for example).

[clepple]

@aquette,

a cleaner / simpler approach would be allowed through some scaling mechanism / directive and common code in main (as for the "override" for example).

I guess, although the common code should not have more than a multiplier and an offset.

If people need more powerful scripting capabilities to adjust reported values, it should not be in the driver core.