While in nutdrv_qx, I added a new USB subdriver that could (could) actually work, if your device is of the right type, and my assumptions are right.
Powermanagerii serial driver#
so (best scenario) the driver will still behave as before. I amended the richcomm_usb driver to also try the other -ahem- 'commands' (excluding 2 and 17, which should be the shutdowns in the two protocols), in order to gather some data to work with. So, here I am, a (no longer) young man, a crashing computer program. I'll try to implement the other two (starting from the Q1 one), and come back here when ready. Now, at first glance, the output you posted doesn't look like the dry-contact one. other devices with a protocol somewhat similar to the dry-contact one, with 'commands' at least from 1 to 17 (the meaning is not the same of the dry-contact protocol, though, so 1 != status flag and 2 != shutdown).Q1 devices ( Q1, I, F, S commands should be supported, possibly others), with commands simply sent to the device as they are (split in 4 byte packets, with the first byte used to store the length of the bytes to follow, i.e.USB devices supported by PowerManagerII:.(they should only support the 1 and 2 'commands', and probably the 30 in 01 00 00 30 should not be needed),
those are only contact closure devices - the protocol is the one currently implemented in richcomm_usb driver.USB devices supported by PowerManagerLite:.Network UPS Tools - Richcomm dry-contact to USB driver 0.04 (2.7.1) (Bus /lib/nut/richcomm_usb -a logicpower -DDD Preferred_State No_Null_Position Non_Volatile Bitfield Item(Global): Physical Maximum, data= 255 Bus 001 Device 002: ID 0925:1234 Lakeview ResearchīDeviceClass 0 (Defined at Interface level)
0 kommentar(er)
