Some devices may not need to have a port when creating an alias for them in pdedaemon config, i.e. devices with BMC that can be directly controlled through the ipmitool.

So, I end up with something like this (notice I had to include %s in the commands themselves because the following block, but also specify a port that I don't need):

{
    "daemon": {
            . . . 
      },
      "pdus": {
          "device-name": {
              "driver": "localcmdline",
              "cmd_on": "ipmitool -I lanplus -H <IP address> -p %s -U lava -P <password> power on",
              "cmd_off": "ipmitool -I lanplus -H <IP address> -p %s -U lava -P <password> power off"
          }
      },
      "aliases": {
          "device-alias": {
              "hostname": "device-name",
              "port": "xxx"
        }
    }
}

Hi there!

Just was wondering if there are plans to release this package onto the pypi?

Currently attempts to use an APC UPS with SNMP fail since the SNMP driver attempts to get MIBs from http://mibs.snmplabs.com/asn1/ but snmplabs.com is no longer operational, and there is no option in the configuration file to allow the location for MIBs to be overridden at present.

All current pdudaemon operations are asynchronous and delayed (#72). It's possible that for client sequence of off(); sleep(1); on(); pdudaemon delays will cause "off" to take effect after the on() call. This can be worked around (for example with longer sleep times) but it's nasty.

I think it would be reasonable to support a "block=true" parameter that makes "on/off" requests to only return after the driver does. This could also propagate driver errors back to the client.

https://github.com/pdudaemon/pdudaemon/blob/main/pdudaemon/listener.py#L105 seems to always return true, even if a request fails. This can mean downstream consumers may think that a port has changed state, even though it hasn't.

requests.exceptions.ConnectionError: HTTPConnectionPool(host='1', port=80): Max retries exceeded with url: /switch/1/turn_off (Caused by NameResolutionError("<urllib3.connection.HTTPConnection object at 0x7fca9a3a2010>: Failed to resolve 'pdu' ([Errno -2] Name or service not known)"))
2024-04-04 13:47:28,238 - pdud.pdu.1       - WARNING Failed to execute job: 1 off (attempts left 0)

Should also report failures in pduclient

Hi,

we have 2 APC7921 devices that we bought 1-2 years ago. The APC7921 driver that is currently available here does not work as the telnet interface has changed its behavior. We had to rewrite the driver so it works with our devices. I assume that we have a newer FW in use on our devices.

How do you handle such cases, should the APC7921 driver do some sort of automagical detection and behave differently? Or would it be better to add another "flavor" of the APC7921 (something APC7921_v2) to keep the complexity and the test effort low?

The fork https://github.com/lextudio/pysnmp continues the development of pysnmp, but the API has changed.

To use the new version pdudaemon/drivers/snmp.py should be updated to the new API. As there is now an async API, pdudaemon should probably use that.

A PR would be highly appreciated.

Running a database for protection between threads is too heavy, so move to asyncio and remove threading.

Older versions of pdudaemon (the version in Debian oldstable at least) accepted string values as ports. This was useful for my system where I have devices controlled via a command line program which don't meaningfully have numbered ports, they have scripts that get run to power them on and off, so I assigned meaningful names to them to make the system more understandable. This really feels like a regression in functionality.

Well... it's about time

We dont need a massive database backend to keep a list of queued jobs, find something lighter.

Hi, I want to monitor multiple PDUs in my network. Let's say I have 5 different PDUs from 3 different make with multiple protocol:

1. 2 PDUs supports SNMP
2. 2 PDUs support HTTP
3. 1 PDU support TCP
   Now where should I do the configuration or add the lists of PDUs to get the data from the PDUs?

There is some confusion about the intended semantics of the default value for the delay parameter. While it makes a lot of sense to put a delay in between the reboot command by default (i.e. to allow capacitors to discharge), it is not very intuitive why a on/off command is delayed before execution by default as well:

Right now, the Labgrid driver implementation is broken because it only explicitly sets the delay parameter for the shutdown command:

https://github.com/labgrid-project/labgrid/blob/27126daa04a382d228b0013efcb34e299689be46/labgrid/driver/powerdriver.py#L298-L299

Hence, it would like to ask if the behaviour in PDUDaemon is intended as it is or if the default delay should rather be zero for on/off commands?

It would be nice to have a package to run on an arm processor

The configuration file is confusing for new users, so explain each option in documentation.

This will probably be easier if the config file was in the format that supports comments :/

The last tag was from "0.0.8" in 2019 but there have been many changes since that time. Could we get updated tags created so we can use this reliably?

Looks like just one queue in daemon?

Means if just set one PDU daemon for two pdu: pdu1 & pdu2.
Then, the request sent to PDU1 and the request sent to PDU2 will wait in the same queue?
So, suggest to have separate PDU deamon for different PDU? Not just use one PDU deamon for different PDUs?

Recently support for the Cleware devices USB-Switch 4 and USB-Switch 8 was added to PDUDaemon, which I appreciate very much.

Unfortunately, it is not possible to distinguish between multiple Cleware USB-Switch 4 devices:

• PDUDaemon uses the serial number provided by hid to identify Cleware devices
• Each Cleware USB-Switch 4 appears to have the same serial number
• This might also occur for Cleware USB-Switch 8 devices (although I am not able test this, since I only possess 1 device of this kind)

Thus, we need another way to identify Cleware USB-Switch 4 (and possibly 8) devices.

Hints to do this might be hidden in the vendor's software, since this does support multiple device of the same kind afaik.

It would be interesting to support PDUDriver implementations in separate packages. This would reduce dependencies in pdudaemon core and make it easier to experiment with drivers.

The pkgresources iter_entry_points API would be a straight-forward fit.

If we return an ID to clients requesting a pdu command, the client should then be able to cancel that job.

I've been running a busy pdudaemon (several requests per minute constantly), and lavapdu-listener eventually stops working. The symptom is errors from pduclient reporting:

Error sending command, wrong daemon hostname?

But checking in the lavapdu-listener.log, the last line shows:

*** Error in `/usr/bin/python': double free or corruption (out): 0x00007fbabc0013d0 ***

Using HEAD from this repo
Server platform: x86, Debian jessie

Is there a way to pass arguments to the commands that use the localcmdline tool?

For example, I'd like to set a variable like "serial_number" in the config file, but then pass it as a variable. Right now, I have a section like this:

        "phidget4-E6-1": {
            "driver": "localcmdline",
            "serial_number": "262305",
            "cmd_on": "/usr/local/bin/phidget-ctrl --serial 262305 --port %d --command on",
            "cmd_off": "/usr/local/bin/phidget-ctrl --serial 262305 --port %d --command off"
        },

but is there a way to replace the option passed to --serial with the variable?

I used to think that having separate listening and dispatching processes was a good idea, but it meant a database had to sit in between them. If possible, make a single daemon that handles accepting tasks and also forks runners to execute them.

There's no need for all the logfile and daemonising support scripts.

Instead, have a single python file that can be started manually or with systemd, log to stdout or the journal and do not fork into the background. Let systemd handle the restarting and pid status

Add an SNMP driver generic enough to cover most PDU cases, and as an alternative way to drive newer APC PDU

JSON is tedious to update and impossible to comment, so consider supporting other config file formats and eventually deprecate JSON slowly.

YAML?

I did not discover that the Tasmota HTTP response handling fixed in #95 did not work with all our devices until I had a look at the log; this is due to the fact that one cannot query if a job was succesfully executed or not.

The asynchronous nature of the API makes this a bit difficult, however, I think the easiest approach would be to respond with a job ID when a command is queued in; this ID can then later be used to query the job status via a separate API endpoint (queued/successful/failure with error message). What do you think about that?

I am mostly interested in using this together with Labgrid in blocking mode (for which #78 is a prerequisite); in that case, the command response can of course directly contain the job status.

In #135 non-int port names were fixed. It was also identified that we can simplify the esphome driver by ignoring the switch_ids configuration mapping and just allowing port names to be passed.

In the configuration there is a a hack for switch_ids which maps passed port number -> port name e.g:

        "pdu-0001": {
            "driver": "esphome-http",
            "username": "admin",
            "password": "supersecretpasswordhere",
            "switch_ids": [
                "pdu-0001_relay_1",
                "pdu-0001_relay_2",
                "pdu-0001_relay_3",
                "pdu-0001_relay_4",
                "pdu-0001_relay_5",
                "pdu-0001_relay_6",
                "pdu-0001_usb"
            ]
        },

I would like to remove switch_ids from the config and just be able to pass the port ID to pdudaemon (and make sure pdudaemon errors out if the ID doesn't exist).

This would be a breaking change, but my local setup is probably the only significant user of this driver...

When trying to setup on a fresh machine directly from source, it fails to start because there is no initial database (startup log below.)
Setup should include helper script to setup initial empty database.

2018-02-05 12:37:49,189:INFO:root:Running PDUDaemon Listener /var/log/pdudaemon.log 0.0.0.0 16421. 2018-02-05 12:37:49,191:INFO:pdudaemon.socketserver:listening on 0.0.0.0:16421 Traceback (most recent call last): File "./pdudaemon-start", line 51, in <module> ListenerServer(settings).start() File "/home/khilman/work/platforms/lava/pdudaemon/pdudaemon/socketserver.py", line 48, in __init__ self.server.dbh = DBHandler(settings) File "/home/khilman/work/platforms/lava/pdudaemon/pdudaemon/dbhandler.py", line 34, in __init__ host=config["dbhost"]) File "/usr/local/lib/python2.7/dist-packages/psycopg2/__init__.py", line 130, in connect conn = _connect(dsn, connection_factory=connection_factory, **kwasync) psycopg2.OperationalError: FATAL: database "pdudaemon" does not exist

Convince a friendly debian-ist, or become one myself, to package pdudaemon and get it uploaded.

It is currently not possible to query the status of a PDU, i.e. if it is turned on or off. This would be useful for the Labgrid PDUDaemonDriver, which currently cannot implement its get method.

I have a synchronous API endpoint in mind that queries the status via a driver method (could be optional, maybe not all PDUs support status query), no caching by pdudaemon involved. What are your thoughts on this?

I've got a whole pile of PDUs that I'd like to connect to home automation systems, Google Nest, Alexa, etc

Maybe add a plugin to HomeAssistant, or add MQTT support.