driver/powerdriver: ykushpower: board_name support

[PaulVittorino]

Description
When 6425df9 switched from pykush to ykushcmd, support for the YKUSH 3 and YKUSH XS was lost. Restore support for those boards by passing the board_name argument to ykushcmd. The board_name is determined by listing the attached YKUSH boards by model.

Checklist

• Documentation for the feature
• Tests for the feature
• The arguments and description in doc/configuration.rst have been updated
• PR has been tested

[codecov]

Codecov Report

❌ Patch coverage is 88.88889% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 45.2%. Comparing base (dbd4b11) to head (6952f14).
⚠️ Report is 2 commits behind head on master.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
labgrid/driver/powerdriver.py	88.8%	1 Missing ⚠️

Additional details and impacted files

@@          Coverage Diff           @@
##           master   #1280   +/-   ##
======================================
  Coverage    45.1%   45.2%           
======================================
  Files         173     173           
  Lines       13712   13721    +9     
======================================
+ Hits         6188    6203   +15     
+ Misses       7524    7518    -6     

Flag	Coverage Δ
3.10	45.2% <88.8%> (+<0.1%)	⬆️
3.11	45.2% <88.8%> (+<0.1%)	⬆️
3.12	45.2% <88.8%> (+<0.1%)	⬆️
3.13	45.1% <88.8%> (+<0.1%)	⬆️
3.14	45.1% <88.8%> (+<0.1%)	⬆️
3.9	45.2% <88.8%> (+<0.1%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jluebbe]

Isn't it possible to detect the model automatically (i.e. using the USB VID/PID) instead of requiring manual configuration by the user? How did this work previously? @edersondisouza?

[PaulVittorino]

Isn't it possible to detect the model automatically (i.e. using the USB VID/PID) instead of requiring manual configuration by the user?

The user manuals for the YKUSH XS, YKUSH, and YKUSH3 state the products have the same VID but different PIDs. Therefore, I believe it is possible to detect the model automatically. Would you advise changing YKUSHPowerPort to inherit from USBResource?

How did this work previously?

pykush does not have a board_type argument.

$ python3.8 pykush.py -l
listing YKUSH family devices
  found a YKUSH XS release 2 device with serial number YKU2768
    system device path 1-8.2:1.0, vendor id 0x04d8, product id 0xf0cd
    the device has 1 downstream port
    Checking running power state, port 1 : UP
  found a YKUSH3 release 1 device with serial number Y3N10673
    system device path 1-4.4:1.0, vendor id 0x04d8, product id 0xf11b
    the device is running a v1.0 firmware and has 3 downstream ports
    downstream running power states, port 1 to 3: UP, UP, UP

ykushcmd requires the board_name argument for the YKUSH XS and YKUSH3 boards.

$ ./bin/ykushcmd -l
Attached YKUSH Boards:
No YKUSH boards found.

$ ./bin/ykushcmd ykush3 -l
Attached YKUSH3 Boards:
1. Board found with serial number: Y3N10673

$ ./bin/ykushcmd ykushxs -l
Attached YKUSH XS Boards:
1. Board found with serial number: YKU2768

[edersondisouza]

Ouch, this is really inconvenient =/

Wonder if trying to get USB PID will work nice with the remote instance. Maybe require pykush and use the command line tool (not the module, so it's easy to support remote instance)?

An ugly hack would be to try to chain three calls to ykushcmd and use it, like ykushcmd ... | ykushcmd ykush3 ... | ykushcmd ykushxs... (/me hides in the corner).

Or fix ykushcmd itself... =/

[jluebbe]

Fixing ykushkmd would be nice and should be easy based on the VID/PID info.

Otherwise, you could make YKUSHPowerPort inherit from USBResource, which will give it additional USB properties (busnum, devnum, path, vendor_id and model_id). NetworkYKUSHPowerPort would then inherit from RemoteUSBResource to store these new properties.

YKUSHPowerPort would match USB HID devices by the given serial. In the Driver, you could then use the USB vendor/model IDs to generate the correct board name for ykushcmd.

The additional resource properties would break backwards compatibility, but the current state is broken anyway. :/

[PaulVittorino]

The additional resource properties would break backwards compatibility, but the current state is broken anyway. :/

I found a way to not break backward compatibility. Use ykushcmd to list out the attached boards by model. Then determine the model of a given board by looking for the serial number in the output for each model. It will require adding each new board to the YKUSHPowerDriver but the PID/VID solution had the same issue.

[edersondisouza]

Nice workaround! Minor nit: on commit message the phrase "Added tests for YKUSHPowerPort and YKUSHPowerPort.' seems wrong - maybe you meant YKUSHPowerDriver for the second YKUSHPowerPort?

[PaulVittorino]

Nice workaround! Minor nit: on commit message the phrase "Added tests for YKUSHPowerPort and YKUSHPowerPort.' seems wrong - maybe you meant YKUSHPowerDriver for the second YKUSHPowerPort?

Yes, thanks for catching that.

[edersondisouza]

Any more comments on this, @jluebbe and @Bastian-Krause?

[Bastian-Krause]

Force-pushed: rebased, fixed remote support for the model detection

[Bastian-Krause]

Force-pushed: dropped unrelated copy-pasted test_import_backend_poe_mib.