Just after I sent this, I happened to notice these lines in /var/log/messages. These came from the tests with the "low=1:high=2" attributes set in sensorsd.conf per the Undeadly example.
Nov 23 10:58:08 microserver sensorsd[6250]: upd0.indicator2: exceeds limits: On is below On Nov 23 10:59:54 microserver sensorsd[12047]: upd0.indicator2: exceeds limits: On is below On Nov 23 11:07:00 microserver sensorsd[27413]: upd0.indicator0: exceeds limits: On is below On On Sun, November 23, 2014 11:15 am, Joe Gidi wrote: > Hi Marcus, > > Thanks for the reply. Unfortunately, the "low=1:high=2" doesn't seem to > work for indicator2. When I start sensorsd I see an initial event logged > as the status goes from undefined to OK, but no further events as I > unplug/plug the UPS. I tried monitoring indicator0 as in the Undeadly > example, and I see exactly the same behavior. > > It appears to me that the driver should be changing the status (%s token) > of the indicators to something other than "OK" when the UPS loses mains > power, but it simply doesn't. > > BTW, I've tested with various check interval values for sensorsd, from the > default 20 seconds down to as low as 1 second, with no change in results. > > Is anyone successfully using sensorsd with upd? > > Thanks, > > Joe > > On Sun, November 23, 2014 4:13 am, Marcus MERIGHI wrote: >> j...@entropicblur.com (Joe Gidi), 2014.11.23 (Sun) 01:22 (CET): >>> I'm running OpenBSD 5.6/amd64 on my fileserver. It has an APC UPS that >>> was >>> previously managed with apcupsd. Since I upgraded to 5.6, the UPS now >>> attaches as a upd device: >>> >>> $ dmesg | grep uhidev3 >>> uhidev3 at uhub3 port 5 configuration 1 interface 0 "APC Back-UPS ES >>> 450 >>> FW:844.K2 .D USB FW:K2" rev 1.10/1.06 addr 2 >>> uhidev3: iclass 3/0, 123 report ids >>> upd0 at uhidev3 >>> >>> And it reports sensible values in hw.sensors: >>> $ sysctl hw.sensors.upd0 >>> hw.sensors.upd0.indicator0=On (Charging), OK >>> hw.sensors.upd0.indicator1=Off (Discharging), OK >>> hw.sensors.upd0.indicator2=On (ACPresent), OK >>> hw.sensors.upd0.indicator3=On (BatteryPresent), OK >>> hw.sensors.upd0.indicator4=Off (ShutdownImminent), OK >>> hw.sensors.upd0.percent0=79.00% (RemainingCapacity), OK >>> hw.sensors.upd0.percent1=100.00% (FullChargeCapacity), OK >>> >>> So far, so good. Now, I'd like to configure sensorsd to monitor the >>> device >>> and invoke a script when the power goes out. I have this line in >>> sensorsd.conf: >>> >>> hw.sensors.upd0.indicator2:command=/etc/sensorsd/ups.sh %s %2 >>> >>> The ups.sh script currently just echoes the token values that it's >>> passed >>> to a log file. >>> >>> The issue I'm running into is this: the status of the sensors seems to >>> always be "OK", even when their state changes. I can unplug the UPS >>> from >>> the wall and then I see this: >>> >>> hw.sensors.upd0.indicator0=Off (Charging), OK >>> hw.sensors.upd0.indicator1=On (Discharging), OK >>> hw.sensors.upd0.indicator2=Off (ACPresent), OK >>> hw.sensors.upd0.indicator3=On (BatteryPresent), OK >>> hw.sensors.upd0.indicator4=Off (ShutdownImminent), OK >>> hw.sensors.upd0.percent0=76.00% (RemainingCapacity), OK >>> hw.sensors.upd0.percent1=100.00% (FullChargeCapacity), OK >>> >>> We're not charging, we're discharging, AC power is not present, but >>> none >>> of the status indicators (the %s token) ever leaves the "OK" state. As >>> I >>> understand it, that lack of state change results in sensorsd doing >>> nothing, even though the sensor's value (the %2 token, On/Off) changes. >>> >>> Can anyone clue me in? I feel like I must be missing something silly >>> and >>> obvious here. >> >> see here: http://undeadly.org/cgi?action=article&sid=20140320093943 >> >> ``hw.sensors.upd0.indicator0:low=1:high=2:command=echo "who turned %2 \ >> the lights?" | mail -s "power sensors" root'' >> >> the trick seems to be to specify "low=1:high=2". I suppose that works >> for indicator2, too. >> >> Bye, Marcus >> >>> !DSPAM:54712928273131330177583! >> > > > -- > Joe Gidi > j...@entropicblur.com > > "You cannot buy skill." -- Ross Seyfried > -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried
