Re: sensorsd, upd, and state changes

[Constantine Aleksandrovich Murenin]

On 26 February 2016 at 08:40, lilit-aibolit  wrote:
> I've tried to change low=1:high=2 to low=0:high=0
> but I haven't got *Off* current state for this sensor from sensord:
>
> - hw.sensors.upd0.indicator2=On (ACPresent), OK
>
> Even for AC disconnected sensord repors that ACPresent is *On*,
> however when I look for
>
> - sysctl hw.sensors.upd0.indicator2
>
> it repororts that ACPresent is *Off*, so I decided don't rely
> on sensord logic and place own script to cron and execute it
> every minute.

The `indicator` changes between On/Off with a user limit of
`low=0:high=0`  should definitely be triggered as reported by the
prior users (http://marc.info/?l=openbsd-misc=144526769005460=2).

http://BXR.SU/OpenBSD/usr.sbin/sensorsd/sensorsd.c#check_sdlim

370if (sensor.flags & SENSOR_FINVALID)
371newustatus = SENSORSD_S_INVALID;
372else if (sensor.value > limit->upper)
373newustatus = SENSORSD_S_ABOVE;
374else if (sensor.value < limit->lower)
375newustatus = SENSORSD_S_BELOW;
376else
377newustatus = SENSORSD_S_WITHIN;

However, notice that all status changes are subject to dampening --
the default check period is 20 seconds
(http://BXR.SU/OpenBSD/usr.sbin/sensorsd/sensorsd.c#check_period,
e.g., `sensorsd` is equivalent to `sensorsd -c20`), and it takes 3
cycles for the value to stuck in.  E.g., if the status does not
consistently stay the same for about a minute by default, then it is
simply discarded and not taken seriously.

Most Hardware Monitor drivers in OpenBSD update their sensors every 5
seconds (regardless of whether anyone's reading them or not), so, you
might as well check them more often as well, yet still have the
dampening:

% fgrep sensorsd /etc/rc.conf.local
sensorsd_flags=-c5

As for upd(4), the updates are done every 6 seconds, for whichever reason:

http://BXR.SU/OpenBSD/sys/dev/usb/upd.c#upd_attach,

210sc->sc_sensortask = sensor_task_register(sc, upd_refresh, 6);

So, if you want a faster notice, but without giving up the dampening,
you might want to run your sensorsd with `-c6`, for example.

Cheers,
Constantine.

Re: sensorsd, upd, and state changes

[lilit-aibolit]

I've tried to change low=1:high=2 to low=0:high=0
but I haven't got *Off* current state for this sensor from sensord:

- hw.sensors.upd0.indicator2=On (ACPresent), OK

Even for AC disconnected sensord repors that ACPresent is *On*,
however when I look for

- sysctl hw.sensors.upd0.indicator2

it repororts that ACPresent is *Off*, so I decided don't rely
on sensord logic and place own script to cron and execute it
every minute.

#!/bin/sh
if [ -f /tmp/powerout.lock ]; then
exit 0
fi

ACstatus () {
sysctl hw.sensors.upd0.indicator2 | cut -c28-29 | grep -q "On" > /dev/null
}

i=0

if ACstatus ; then
  exit 0
else
  logger -t UPS "AC has been disconnected"
  touch /tmp/powerout.lock
  /usr/local/bin/mutt -s "Power outage in office" -- ad...@example.com 
< /root/powerout

while [ $i -lt "360" ]
  do
i=$((i+60))
sleep 60
  if ACstatus ; then
logger -t UPS "AC has been connected again after ${i} seconds."
/usr/local/bin/mutt -s "Power returned in office" -- 
ad...@example.com

rm -rf /tmp/powerout.lock
exit 0
  else
if [ "$i" -eq "300" ]; then
  /usr/local/bin/mutt -s "No power for 5 min. System is 
shutting down now." -- ad...@example.com

  logger -t UPS "System is shutting down now."
  shutdown -hp +0
fi
  fi
  done
fi

Re: sensorsd, upd, and state changes

[lilit-aibolit]

Hi list, why I don't have extra line in output with sensor 
upd0.percent1(RemainingCapacity)?

Is it related to model of my UPS?

# usbdevs | grep UPS
  addr 4: Back-UPS ES 525 FW:851.t3.I USB FW:t3, American Power Conversion

# sysctl hw.sensors
hw.sensors.upd0.indicator0=Off (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=100.00% (FullChargeCapacity), OK

# tail /var/log/messages | grep upd
Feb 25 12:59:27 gw sensorsd[2261]: upd0.percent1: 0.00%, UNKNOWN
Feb 25 13:45:43 gw sensorsd[13167]: upd0.percent1: 0.00%, UNKNOWN

Re: sensorsd, upd, and state changes

[Maxim Khitrov]

On Mon, Dec 8, 2014 at 3:45 PM, David Higgs  wrote:
> On Mon, Dec 8, 2014 at 3:37 PM, trondd  wrote:
>> On Mon, Dec 8, 2014 at 3:23 PM, trondd  wrote:
>>> On Mon, Dec 8, 2014 at 11:47 AM, David Higgs  wrote:


 sysctl(8) will display Off if the value is zero, and On for nonzero.
 So, using the "closed interval" rule above, you should use "high=0"
 for indicators that you consider in "good" state when Off (i.e.
 ShutdownImminent), and "low=1" for indicators that you consider in
 "good" state when On (i.e. ACPresent).

>>>
>>> Isn't saying high=0 kind of the same thing as saying low=1?
>>
>>
>> Oh, I think I get this.  Since the sensor doesn't trigger if it is on the
>> limit, only outside the limit, you have to set up which is the OK state.
>>
>> Still a little confusing but I guess there is no way to automatically know
>> if an indicator is supposed to be Off or On when it's in it's good state?
>>
>
> Kind of.  The high/low difference is what values you consider "within"
> normal operating parameters (and the output of %l).  The upd(4) code
> hasn't yet been taught how to map specific indicator values to OK /
> WARN / CRITICAL status.  Currently any value successfully read is
> marked OK.
>
> I'm working with tech@ and slowly writing diffs to improve these things.
>
> --david

Resurrecting an old thread since I just ran into the same problem in
5.8. To summarize, upd(4) exposes some SENSOR_INDICATOR-type sensors
for attached UPSes, such as ACPresent = On/Off, and it's not clear how
to configure sensorsd(8) to execute a command when this value changes.
Also, upd always sets sensor status to "OK," so sensorsd never
triggers commands for status changes; we have to use low/high limits
until this is fixed. One proposed hack was to use "low=1:high=2" in
sensorsd.conf, but this doesn't seem to work for everybody.

Has anyone tried using "low=0:high=0"? I'm pretty sure that should
solve the problem in all cases.

The low/high range is inclusive at both ends. Off is 0, but On can be
any other int64 value, including negative. For my UPS, ACPresent = On
is actually a value of -1. I know this because when I set
"low=-1:high=-1" sensorsd reports "upd0.indicator2: within limits:
On". That being the case, "low=1:high=2" would not work because the
value changes from -1 (On) to 0 (Off), and is always below the lower
limit.

Using "low=0:high=0" should always work for On -> Off -> On
transitions, but it will show On as outside (below or above) the
limits. If you want On to be within limits, then just play with the
values until you figure out whether On is 1, -1, or something else
entirely. That may not be as reliable. I'm not actually sure whether
this value is UPS-specific or something that upd determines.

-Max

Re: sensorsd, upd, and state changes

[David Higgs]

On Mon, Oct 19, 2015 at 11:11 AM, Maxim Khitrov  wrote:

> On Mon, Dec 8, 2014 at 3:45 PM, David Higgs  wrote:
> > On Mon, Dec 8, 2014 at 3:37 PM, trondd  wrote:
> >> On Mon, Dec 8, 2014 at 3:23 PM, trondd  wrote:
> >>> On Mon, Dec 8, 2014 at 11:47 AM, David Higgs  wrote:
> 
> 
>  sysctl(8) will display Off if the value is zero, and On for nonzero.
>  So, using the "closed interval" rule above, you should use "high=0"
>  for indicators that you consider in "good" state when Off (i.e.
>  ShutdownImminent), and "low=1" for indicators that you consider in
>  "good" state when On (i.e. ACPresent).
> 
> >>>
> >>> Isn't saying high=0 kind of the same thing as saying low=1?
> >>
> >>
> >> Oh, I think I get this.  Since the sensor doesn't trigger if it is on
> the
> >> limit, only outside the limit, you have to set up which is the OK state.
> >>
> >> Still a little confusing but I guess there is no way to automatically
> know
> >> if an indicator is supposed to be Off or On when it's in it's good
> state?
> >>
> >
> > Kind of.  The high/low difference is what values you consider "within"
> > normal operating parameters (and the output of %l).  The upd(4) code
> > hasn't yet been taught how to map specific indicator values to OK /
> > WARN / CRITICAL status.  Currently any value successfully read is
> > marked OK.
> >
> > I'm working with tech@ and slowly writing diffs to improve these things.
> >
> > --david
>
> Resurrecting an old thread since I just ran into the same problem in
> 5.8. To summarize, upd(4) exposes some SENSOR_INDICATOR-type sensors
> for attached UPSes, such as ACPresent = On/Off, and it's not clear how
> to configure sensorsd(8) to execute a command when this value changes.
> Also, upd always sets sensor status to "OK," so sensorsd never
> triggers commands for status changes; we have to use low/high limits
> until this is fixed. One proposed hack was to use "low=1:high=2" in
> sensorsd.conf, but this doesn't seem to work for everybody.
>
> Has anyone tried using "low=0:high=0"? I'm pretty sure that should
> solve the problem in all cases.
>
> The low/high range is inclusive at both ends. Off is 0, but On can be
> any other int64 value, including negative. For my UPS, ACPresent = On
> is actually a value of -1. I know this because when I set
> "low=-1:high=-1" sensorsd reports "upd0.indicator2: within limits:
> On". That being the case, "low=1:high=2" would not work because the
> value changes from -1 (On) to 0 (Off), and is always below the lower
> limit.
>
> Using "low=0:high=0" should always work for On -> Off -> On
> transitions, but it will show On as outside (below or above) the
> limits. If you want On to be within limits, then just play with the
> values until you figure out whether On is 1, -1, or something else
> entirely. That may not be as reliable. I'm not actually sure whether
> this value is UPS-specific or something that upd determines.
>

Yes, the values reported are UPS-specific.  You may need to adjust the
ranges, but (as previously discussed) you can just use either high or low
(not both) to detect transition between good and bad indicator states.

This is still all just a hack; I ran out of free time to keep working on
upd(4).  I made the driver less terrible and added a few sensors, but
didn't get as far as changing sensor statuses which could make reporting
much easier.

--david

Re: sensorsd, upd, and state changes

[Maxim Khitrov]

On Mon, Oct 19, 2015 at 2:31 PM, David Higgs  wrote:
> On Mon, Oct 19, 2015 at 11:11 AM, Maxim Khitrov  wrote:
>>
>> On Mon, Dec 8, 2014 at 3:45 PM, David Higgs  wrote:
>> > On Mon, Dec 8, 2014 at 3:37 PM, trondd  wrote:
>> >> On Mon, Dec 8, 2014 at 3:23 PM, trondd  wrote:
>> >>> On Mon, Dec 8, 2014 at 11:47 AM, David Higgs  wrote:
>> 
>> 
>>  sysctl(8) will display Off if the value is zero, and On for nonzero.
>>  So, using the "closed interval" rule above, you should use "high=0"
>>  for indicators that you consider in "good" state when Off (i.e.
>>  ShutdownImminent), and "low=1" for indicators that you consider in
>>  "good" state when On (i.e. ACPresent).
>> 
>> >>>
>> >>> Isn't saying high=0 kind of the same thing as saying low=1?
>> >>
>> >>
>> >> Oh, I think I get this.  Since the sensor doesn't trigger if it is on
>> >> the
>> >> limit, only outside the limit, you have to set up which is the OK
>> >> state.
>> >>
>> >> Still a little confusing but I guess there is no way to automatically
>> >> know
>> >> if an indicator is supposed to be Off or On when it's in it's good
>> >> state?
>> >>
>> >
>> > Kind of.  The high/low difference is what values you consider "within"
>> > normal operating parameters (and the output of %l).  The upd(4) code
>> > hasn't yet been taught how to map specific indicator values to OK /
>> > WARN / CRITICAL status.  Currently any value successfully read is
>> > marked OK.
>> >
>> > I'm working with tech@ and slowly writing diffs to improve these things.
>> >
>> > --david
>>
>> Resurrecting an old thread since I just ran into the same problem in
>> 5.8. To summarize, upd(4) exposes some SENSOR_INDICATOR-type sensors
>> for attached UPSes, such as ACPresent = On/Off, and it's not clear how
>> to configure sensorsd(8) to execute a command when this value changes.
>> Also, upd always sets sensor status to "OK," so sensorsd never
>> triggers commands for status changes; we have to use low/high limits
>> until this is fixed. One proposed hack was to use "low=1:high=2" in
>> sensorsd.conf, but this doesn't seem to work for everybody.
>>
>> Has anyone tried using "low=0:high=0"? I'm pretty sure that should
>> solve the problem in all cases.
>>
>> The low/high range is inclusive at both ends. Off is 0, but On can be
>> any other int64 value, including negative. For my UPS, ACPresent = On
>> is actually a value of -1. I know this because when I set
>> "low=-1:high=-1" sensorsd reports "upd0.indicator2: within limits:
>> On". That being the case, "low=1:high=2" would not work because the
>> value changes from -1 (On) to 0 (Off), and is always below the lower
>> limit.
>>
>> Using "low=0:high=0" should always work for On -> Off -> On
>> transitions, but it will show On as outside (below or above) the
>> limits. If you want On to be within limits, then just play with the
>> values until you figure out whether On is 1, -1, or something else
>> entirely. That may not be as reliable. I'm not actually sure whether
>> this value is UPS-specific or something that upd determines.
>
>
> Yes, the values reported are UPS-specific.  You may need to adjust the
> ranges, but (as previously discussed) you can just use either high or low
> (not both) to detect transition between good and bad indicator states.

Why not both? The low limit is initialized to LLONG_MIN and high to
LLONG_MAX. For "indicator" sensors, the logic we are trying to express
is either value == 0 or value != 0. For the former (i.e. a sensor that
should be "Off" normally), "low=0:high=0" is exactly what you want.
For the latter, sensorsd.conf doesn't give you a way of negating the
range (possible feature request?), but if you know that ACPresent = On
is really -1 for your UPS, then "high=-1" is sufficient. This is, of
course, assuming that the On value will never be positive in the
future.

I just tested all of this, and it works perfectly. For UPSes that use
1 to indicate On, instead of "low=1:high=2" you can simplify that to
"low=1". Alternatively, use "low=0:high=0" everywhere, which will be
the most reliable method, and provide an extra parameter to your
script to indicate which value to consider "normal." The downside is
that sensorsd will complain when the value is On and stay silent when
it's Off.

-Max

Re: sensorsd, upd, and state changes

[Constantine Aleksandrovich Murenin]

On 19 October 2015 at 11:31, David Higgs  wrote:
> On Mon, Oct 19, 2015 at 11:11 AM, Maxim Khitrov  wrote:
>> Also, upd always sets sensor status to "OK," so sensorsd never
>> triggers commands for status changes; we have to use low/high limits
>> until this is fixed. One proposed hack was to use "low=1:high=2" in
>> sensorsd.conf, but this doesn't seem to work for everybody.
[...]
> This is still all just a hack; I ran out of free time to keep working on
> upd(4).  I made the driver less terrible and added a few sensors, but
> didn't get as far as changing sensor statuses which could make reporting
> much easier.

Yes, it looks like http://bxr.su/o/sys/dev/usb/upd.c follows the
NetBSD paradigm where ksensor.status is simply tied to SENSOR_FINVALID
from ksensor.flags, which is a redundant approach in the OpenBSD
ksensor API, and ksensor.status should instead not be set to anything
at all in such scenarios where it wouldn't alert one of a WARN or CRIT
condition as per http://bxr.su/o/sys/sys/sensors.h#sensor_status.

Cns:OpenBSD {8224} fgrep -n -e .status -e .flags sys/dev/usb/upd.c
254:sensor->ksensor.flags |= SENSOR_FINVALID;
255:sensor->ksensor.status = SENSOR_S_UNKNOWN;
398:sensor->ksensor.status = SENSOR_S_UNKNOWN;
399:sensor->ksensor.flags |= SENSOR_FINVALID;
432:sensor->ksensor.status = SENSOR_S_OK;
433:sensor->ksensor.flags &= ~SENSOR_FINVALID;
Cns:OpenBSD {8225}

All the three lines with `.status` should probably be removed to avoid
the extra confusion and not give the impression that ksensor.status is
actually supported by the driver.

Cheers,
Constantine.SU.

Re: sensorsd, upd, and state changes

[David Higgs]

On Sun, Nov 30, 2014 at 10:54 AM, Marcus MERIGHI mcmer-open...@tor.at wrote:
 for the impatient, here are my questions:

 - Although I use the same (undocumented, undeadly.org) trick of
   low=1:high=2 for indicators everywhere, this can result in
   On is below On, and Off is below On
 - Although I use low=1:high=2, I get On for %3 (low limit) as well
   as for %4 (high limit)
 - Reading sensorsd.conf(5):
   If the limits are crossed or if the status provided by the driver
   changes, sensorsd(8)'s alert functionality is triggered and a command,
   if specified, is executed
   If limits are crossed, yes; if status changes, no, unless you use the
   low=1:high=2 trick.
 - Reading sensorsd.conf(5):
   Values for all other types of sensors can be specified in the same
   units as they appear under the sysctl(8) hw.sensors tree.
   No: low=Off:high=On results in (sensorsd -c 1 -d):
   sensorsd: incorrect value: Off: file or directory not found


Now that I have a reporting upd(4) device, I've had a chance to poke
at this.  There is currently no code in upd(4) that sets WARN or
CRITICAL.

Yes, it appears that SENSOR_INDICATOR items require numeric high/low
values.  This is not documented in sensorsd.conf(5).  It is either an
oversight in documentation or parsing.

I've found that it helps to think of the high/low values in
sensorsd.conf(5) as the closed interval for normal operation. The
example hw.sensors.lm0.volt3:low=4.8V:high=5.2V will trigger when
the voltage goes below (but not at) 4.8V and above (but not at) 5.2V.

sysctl(8) will display Off if the value is zero, and On for nonzero.
So, using the closed interval rule above, you should use high=0
for indicators that you consider in good state when Off (i.e.
ShutdownImminent), and low=1 for indicators that you consider in
good state when On (i.e. ACPresent).

# sensorsd.conf(5)
hw.sensors.upd0.indicator0:high=0:command=/etc/sensorsd_log.sh %x Charging %2 %s
hw.sensors.upd0.indicator1:high=0:command=/etc/sensorsd_log.sh %x
Discharging %2 %s
hw.sensors.upd0.indicator2:low=1:command=/etc/sensorsd_log.sh %x ACPresent %2 %s
hw.sensors.upd0.indicator3:high=0:command=/etc/sensorsd_log.sh %x
ShutdownImminent %2 %s
hw.sensors.upd0.indicator4:low=1:command=/etc/sensorsd_log.sh %x
BatteryPresent %2 %s
hw.sensors.upd0.percent0:low=25:command=/etc/sensorsd_log.sh %x
RemainingCapacity %2 %s
hw.sensors.upd0.percent1:low=25:command=/etc/sensorsd_log.sh %x
FullChargeCapacity %2 %s

--david

Re: sensorsd, upd, and state changes

[trondd]

On Mon, Dec 8, 2014 at 11:47 AM, David Higgs hig...@gmail.com wrote:


 sysctl(8) will display Off if the value is zero, and On for nonzero.
 So, using the closed interval rule above, you should use high=0
 for indicators that you consider in good state when Off (i.e.
 ShutdownImminent), and low=1 for indicators that you consider in
 good state when On (i.e. ACPresent).


Isn't saying high=0 kind of the same thing as saying low=1?
Why is there a high/low for binary indicators at all?  If the state
changes, execute the command.  Let the command read the state and
determine, based on which indicator it is, if that state is a good thing or
a bad thing.

Tim.

Re: sensorsd, upd, and state changes

[trondd]

On Mon, Dec 8, 2014 at 3:23 PM, trondd tro...@gmail.com wrote:

 On Mon, Dec 8, 2014 at 11:47 AM, David Higgs hig...@gmail.com wrote:


 sysctl(8) will display Off if the value is zero, and On for nonzero.
 So, using the closed interval rule above, you should use high=0
 for indicators that you consider in good state when Off (i.e.
 ShutdownImminent), and low=1 for indicators that you consider in
 good state when On (i.e. ACPresent).


 Isn't saying high=0 kind of the same thing as saying low=1?


Oh, I think I get this.  Since the sensor doesn't trigger if it is on the
limit, only outside the limit, you have to set up which is the OK state.

Still a little confusing but I guess there is no way to automatically know
if an indicator is supposed to be Off or On when it's in it's good state?

Tim.

Re: sensorsd, upd, and state changes

[David Higgs]

On Mon, Dec 8, 2014 at 3:37 PM, trondd tro...@gmail.com wrote:
 On Mon, Dec 8, 2014 at 3:23 PM, trondd tro...@gmail.com wrote:
 On Mon, Dec 8, 2014 at 11:47 AM, David Higgs hig...@gmail.com wrote:


 sysctl(8) will display Off if the value is zero, and On for nonzero.
 So, using the closed interval rule above, you should use high=0
 for indicators that you consider in good state when Off (i.e.
 ShutdownImminent), and low=1 for indicators that you consider in
 good state when On (i.e. ACPresent).


 Isn't saying high=0 kind of the same thing as saying low=1?


 Oh, I think I get this.  Since the sensor doesn't trigger if it is on the
 limit, only outside the limit, you have to set up which is the OK state.

 Still a little confusing but I guess there is no way to automatically know
 if an indicator is supposed to be Off or On when it's in it's good state?


Kind of.  The high/low difference is what values you consider within
normal operating parameters (and the output of %l).  The upd(4) code
hasn't yet been taught how to map specific indicator values to OK /
WARN / CRITICAL status.  Currently any value successfully read is
marked OK.

I'm working with tech@ and slowly writing diffs to improve these things.

--david

Re: sensorsd, upd, and state changes

[trondd]

On Mon, Dec 8, 2014 at 3:45 PM, David Higgs hig...@gmail.com wrote:

 I'm working with tech@ and slowly writing diffs to improve these things.

 --david


I saw that.  Thanks!

Tim.

Re: sensorsd, upd, and state changes

[Marcus MERIGHI]

hig...@gmail.com (David Higgs), 2014.11.28 (Fri) 15:43 (CET):
 On Fri, Nov 28, 2014 at 2:45 AM, Marcus MERIGHI mcmer-open...@tor.at wrote:
  What I have now:
 
  $ getcap -a -f /etc/sensorsd.conf
  hw.sensors.upd0.indicator0:low=1:high=2:command=/etc/sensorsd/upd.sh \
  %l %n %s %x %t %2 %3 %4
  hw.sensors.upd0.indicator1:low=1:high=2:command=/etc/sensorsd/upd.sh \
  %l %n %s %x %t %2 %3 %4
  hw.sensors.upd0.indicator2:low=1:high=2:command=/etc/sensorsd/upd.sh \
  %l %n %s %x %t %2 %3 %4
  hw.sensors.upd0.indicator3:low=1:high=2:command=/etc/sensorsd/upd.sh \
  %l %n %s %x %t %2 %3 %4
  hw.sensors.upd0.indicator4:low=1:high=2:command=/etc/sensorsd/upd.sh \
  %l %n %s %x %t %2 %3 %4
  hw.sensors.upd0.percent0:low=10:high=100:command=\
  /etc/sensorsd/upd-capacityremaining.sh %l %n %s %x %t %2 %3 %4
  hw.sensors.upd0.percent1:low=95:high=100:command=/etc/sensorsd/upd.sh \
  %l %n %s %x %t %2 %3 %4
 
 Do you mind saying what type of USB you have, and what these sensors
 map are for your hardware?
 
 I have:
 uhidev0 at uhub1 port 2 configuration 1 interface 0 American Power
 Conversion Back-UPS ES 750 FW:841.I3 .D USB FW:I3 rev 1.10/1.01 addr
 2
 uhidev0: iclass 3/0, 146 report ids
 upd0 at uhidev0
 
 Which only appears to provide:
 hw.sensors.upd0.indicator3=Off (ShutdownImminent), OK

uhidev0 at uhub2 port 1 configuration 1 interface 0 APC Back-UPS ES \
  550G FW:870.O2 .I USB FW:O2 rev 1.10/1.06 addr 2
uhidev0: iclass 3/0, 146 report ids
upd0 at uhidev0

I think this should be it:
http://www.apc.com/resource/include/techspec_index.cfm?base_sku=BE550-GRISOCountryCode=en

And I get:
$ sysctl hw.sensors.upd0
hw.sensors.upd0.indicator0=Off (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=100.00% (RemainingCapacity), OK
hw.sensors.upd0.percent1=100.00% (FullChargeCapacity), OK

Bye, Marcus

Re: sensorsd, upd, and state changes

[Marcus MERIGHI]

for the impatient, here are my questions:

- Although I use the same (undocumented, undeadly.org) trick of
  low=1:high=2 for indicators everywhere, this can result in
  On is below On, and Off is below On
- Although I use low=1:high=2, I get On for %3 (low limit) as well
  as for %4 (high limit)
- Reading sensorsd.conf(5):
  If the limits are crossed or if the status provided by the driver
  changes, sensorsd(8)'s alert functionality is triggered and a command,
  if specified, is executed
  If limits are crossed, yes; if status changes, no, unless you use the
  low=1:high=2 trick.
- Reading sensorsd.conf(5):
  Values for all other types of sensors can be specified in the same
  units as they appear under the sysctl(8) hw.sensors tree.
  No: low=Off:high=On results in (sensorsd -c 1 -d):
  sensorsd: incorrect value: Off: file or directory not found

(for the more patient these will come up later...)

j...@entropicblur.com (Joe Gidi), 2014.11.28 (Fri) 17:40 (CET):
 On Fri, November 28, 2014 2:45 am, Marcus MERIGHI wrote:
  j...@entropicblur.com (Joe Gidi), 2014.11.27 (Thu) 16:41 (CET):
  I just spent some more time poking at this and I'm still unable to get
 
  So did I...
 
  sensorsd to recognize upd state changes. This is a bit of a frustrating
  regression from my point of view, since I can no longer use apcupsd
  unless
  I disable uhidev in the kernel.
 
  Does anyone have a working example configuration for sensorsd/upd?
 
  What I have now:
 
  $ getcap -a -f /etc/sensorsd.conf
  hw.sensors.upd0.indicator0:low=1:high=2:command=/etc/sensorsd/upd.sh \
  %l %n %s %x %t %2 %3 %4
  hw.sensors.upd0.indicator1:low=1:high=2:command=/etc/sensorsd/upd.sh \
  %l %n %s %x %t %2 %3 %4
  hw.sensors.upd0.indicator2:low=1:high=2:command=/etc/sensorsd/upd.sh \
  %l %n %s %x %t %2 %3 %4
  hw.sensors.upd0.indicator3:low=1:high=2:command=/etc/sensorsd/upd.sh \
  %l %n %s %x %t %2 %3 %4
  hw.sensors.upd0.indicator4:low=1:high=2:command=/etc/sensorsd/upd.sh \
  %l %n %s %x %t %2 %3 %4
  hw.sensors.upd0.percent0:low=10:high=100:command=\
  /etc/sensorsd/upd-capacityremaining.sh %l %n %s %x %t %2 %3 %4
  hw.sensors.upd0.percent1:low=95:high=100:command=/etc/sensorsd/upd.sh \
  %l %n %s %x %t %2 %3 %4
 
  The ``command=/etc/sensorsd/upd.sh'' lines are just informational.
 
  The workhorse is command=/etc/sensorsd/upd-capacityremaining.sh:
  
  #!/bin/sh -e
  if [[ X${1} == Xbelow ]]; then
  logger -t UPD-capacityremaining SHUTDOWN (${@})
  shutdown -hp +1
  else
  logger -t UPD-capacityremaining NON-SHUTDOWN (${@})
  fi
  
 
  I did some testing (plug/unplug, wait for hw.sensors.upd0.percent0 to go
  below low=) and left it as working.
 
 Thanks for this! The percent0 example will be useful. Were you able to get
 any useful results with the other indicator sensors? The 'low=1:high=2'
 attributes don't seem to do anything for me.

What I never mentioned: for now I'm running sensorsd(8) with '-c 1'. 

What happens in syslog when running unplugged with the above config,
the UPD:-lines are from the script 
'command=/etc/sensorsd/upd.sh %l %n %s %x %t %2 %3 %4'
which just does 
'echo ${@} | logger -t UPD'

I've trimmed and shuffled the lines a bit to have a better reading
experience. Commented lines after syslog lines are my comments and the
config (without parameters to command=).


sensorsd[14579]: startup, system has 9 sensors
# just restarted sensorsd

sensorsd[658]: upd0.indicator0: Off, OK
sensorsd[658]: upd0.indicator0: exceeds limits: Off is below On
UPD: below 0 OK upd0 indicator Off On On 
# Charging is Off, command= is run.
# hw.sensors.upd0.indicator0:low=1:high=2:command=/etc/sensorsd/upd.sh

sensorsd[658]: upd0.indicator1: On, OK
sensorsd[658]: upd0.indicator1: exceeds limits: On is below On
UPD: below 1 OK upd0 indicator On On On 
# Discharging is On, command= is run
# hw.sensors.upd0.indicator1:low=1:high=2:command=/etc/sensorsd/upd.sh

sensorsd[658]: upd0.indicator2: Off, OK
sensorsd[658]: upd0.indicator2: exceeds limits: Off is below On
UPD: below 2 OK upd0 indicator Off On On 
# ACPresent is Off, command= is run
# hw.sensors.upd0.indicator2:low=1:high=2:command=/etc/sensorsd/upd.sh

sensorsd[658]: upd0.indicator3: On, OK
sensorsd[658]: upd0.indicator3: exceeds limits: On is below On
UPD: below 3 OK upd0 indicator On On On 
# BatteryPresent is On, command= is run
# hw.sensors.upd0.indicator3:low=1:high=2:command=/etc/sensorsd/upd.sh

sensorsd[658]: upd0.indicator4: Off, OK
sensorsd[658]: upd0.indicator4: exceeds limits: Off is below On
UPD: below 4 OK upd0 indicator Off On On 
# ShutdownImminent is Off, command= is run
# hw.sensors.upd0.indicator4:low=1:high=2:command=/etc/sensorsd/upd.sh
# todo: test low=2:high=1:; 
# todo: check whether it flips when upd0.percent0 goes below low=.

sensorsd[658]: upd0.percent0: 71.00%, OK
sensorsd[658]: upd0.percent0: within limits: 71.00%
# RemainingCapacity is 71%, command= is run but does no syslog output
# 

Re: sensorsd, upd, and state changes

[David Higgs]

On Fri, Nov 28, 2014 at 2:45 AM, Marcus MERIGHI mcmer-open...@tor.at wrote:
 What I have now:

 $ getcap -a -f /etc/sensorsd.conf
 hw.sensors.upd0.indicator0:low=1:high=2:command=/etc/sensorsd/upd.sh \
 %l %n %s %x %t %2 %3 %4
 hw.sensors.upd0.indicator1:low=1:high=2:command=/etc/sensorsd/upd.sh \
 %l %n %s %x %t %2 %3 %4
 hw.sensors.upd0.indicator2:low=1:high=2:command=/etc/sensorsd/upd.sh \
 %l %n %s %x %t %2 %3 %4
 hw.sensors.upd0.indicator3:low=1:high=2:command=/etc/sensorsd/upd.sh \
 %l %n %s %x %t %2 %3 %4
 hw.sensors.upd0.indicator4:low=1:high=2:command=/etc/sensorsd/upd.sh \
 %l %n %s %x %t %2 %3 %4
 hw.sensors.upd0.percent0:low=10:high=100:command=\
 /etc/sensorsd/upd-capacityremaining.sh %l %n %s %x %t %2 %3 %4
 hw.sensors.upd0.percent1:low=95:high=100:command=/etc/sensorsd/upd.sh \
 %l %n %s %x %t %2 %3 %4

Do you mind saying what type of USB you have, and what these sensors
map are for your hardware?

I have:
uhidev0 at uhub1 port 2 configuration 1 interface 0 American Power
Conversion Back-UPS ES 750 FW:841.I3 .D USB FW:I3 rev 1.10/1.01 addr
2
uhidev0: iclass 3/0, 146 report ids
upd0 at uhidev0

Which only appears to provide:
hw.sensors.upd0.indicator3=Off (ShutdownImminent), OK

Thanks.

--david

Re: sensorsd, upd, and state changes

[Steven Surdock]

I have two different APC units...

uhidev0 at uhub1 port 1 configuration 1 interface 0 American Power Conversion 
Smart-UPS 1500 FW:601.3.D USB FW:1.3 rev 1.10/0.06 addr 2
uhidev0: iclass 3/0, 54 report ids
upd0 at uhidev0
$ sysctl | grep upd
hw.sensors.upd0.indicator0=Off (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=100.00% (FullChargeCapacity), OK
hw.sensors.upd0.percent1=100.00% (RemainingCapacity), OK

uhidev0 at uhub7 port 2 configuration 1 interface 0 APC Back-UPS ES 550G 
FW:904.W1 .D USB FW:W1 rev 1.10/1.06 addr 2
uhidev0: iclass 3/0, 123 report ids
upd0 at uhidev0
$ sysctl | grep upd
hw.sensors.upd0.indicator0=Off (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=100.00% (RemainingCapacity), OK
hw.sensors.upd0.percent1=100.00% (FullChargeCapacity), OK


 -Original Message-
 From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
 David Higgs
 Sent: Friday, November 28, 2014 9:43 AM
 To: misc@openbsd.org
 Subject: Re: sensorsd, upd, and state changes
 
 Do you mind saying what type of USB you have, and what these sensors map
 are for your hardware?
 
 I have:
 uhidev0 at uhub1 port 2 configuration 1 interface 0 American Power
 Conversion Back-UPS ES 750 FW:841.I3 .D USB FW:I3 rev 1.10/1.01 addr
 2
 uhidev0: iclass 3/0, 146 report ids
 upd0 at uhidev0
 
 Which only appears to provide:
 hw.sensors.upd0.indicator3=Off (ShutdownImminent), OK

Re: sensorsd, upd, and state changes

[Joe Gidi]

On Fri, November 28, 2014 2:45 am, Marcus MERIGHI wrote:
 j...@entropicblur.com (Joe Gidi), 2014.11.27 (Thu) 16:41 (CET):
 I just spent some more time poking at this and I'm still unable to get

 So did I...

 sensorsd to recognize upd state changes. This is a bit of a frustrating
 regression from my point of view, since I can no longer use apcupsd
 unless
 I disable uhidev in the kernel.

 Does anyone have a working example configuration for sensorsd/upd?

 What I have now:

 $ getcap -a -f /etc/sensorsd.conf
 hw.sensors.upd0.indicator0:low=1:high=2:command=/etc/sensorsd/upd.sh \
 %l %n %s %x %t %2 %3 %4
 hw.sensors.upd0.indicator1:low=1:high=2:command=/etc/sensorsd/upd.sh \
 %l %n %s %x %t %2 %3 %4
 hw.sensors.upd0.indicator2:low=1:high=2:command=/etc/sensorsd/upd.sh \
 %l %n %s %x %t %2 %3 %4
 hw.sensors.upd0.indicator3:low=1:high=2:command=/etc/sensorsd/upd.sh \
 %l %n %s %x %t %2 %3 %4
 hw.sensors.upd0.indicator4:low=1:high=2:command=/etc/sensorsd/upd.sh \
 %l %n %s %x %t %2 %3 %4
 hw.sensors.upd0.percent0:low=10:high=100:command=\
 /etc/sensorsd/upd-capacityremaining.sh %l %n %s %x %t %2 %3 %4
 hw.sensors.upd0.percent1:low=95:high=100:command=/etc/sensorsd/upd.sh \
 %l %n %s %x %t %2 %3 %4

 The ``command=/etc/sensorsd/upd.sh'' lines are just informational.

 The workhorse is command=/etc/sensorsd/upd-capacityremaining.sh:
 
 #!/bin/sh -e
 if [[ X${1} == Xbelow ]]; then
 logger -t UPD-capacityremaining SHUTDOWN (${@})
 shutdown -hp +1
 else
 logger -t UPD-capacityremaining NON-SHUTDOWN (${@})
 fi
 

 I did some testing (plug/unplug, wait for hw.sensors.upd0.percent0 to go
 below low=) and left it as working.

 Bye, Marcus

Hi Marcus,

Thanks for this! The percent0 example will be useful. Were you able to get
any useful results with the other indicator sensors? The 'low=1:high=2'
attributes don't seem to do anything for me.

Thanks again,

-- 
Joe Gidi
j...@entropicblur.com

You cannot buy skill. -- Ross Seyfried

Re: sensorsd, upd, and state changes

[Joe Gidi]

On Fri, November 28, 2014 9:43 am, David Higgs wrote:
 On Fri, Nov 28, 2014 at 2:45 AM, Marcus MERIGHI mcmer-open...@tor.at
 wrote:
 What I have now:

 $ getcap -a -f /etc/sensorsd.conf
 hw.sensors.upd0.indicator0:low=1:high=2:command=/etc/sensorsd/upd.sh \
 %l %n %s %x %t %2 %3 %4
 hw.sensors.upd0.indicator1:low=1:high=2:command=/etc/sensorsd/upd.sh \
 %l %n %s %x %t %2 %3 %4
 hw.sensors.upd0.indicator2:low=1:high=2:command=/etc/sensorsd/upd.sh \
 %l %n %s %x %t %2 %3 %4
 hw.sensors.upd0.indicator3:low=1:high=2:command=/etc/sensorsd/upd.sh \
 %l %n %s %x %t %2 %3 %4
 hw.sensors.upd0.indicator4:low=1:high=2:command=/etc/sensorsd/upd.sh \
 %l %n %s %x %t %2 %3 %4
 hw.sensors.upd0.percent0:low=10:high=100:command=\
 /etc/sensorsd/upd-capacityremaining.sh %l %n %s %x %t %2 %3 %4
 hw.sensors.upd0.percent1:low=95:high=100:command=/etc/sensorsd/upd.sh \
 %l %n %s %x %t %2 %3 %4

 Do you mind saying what type of USB you have, and what these sensors
 map are for your hardware?

 I have:
 uhidev0 at uhub1 port 2 configuration 1 interface 0 American Power
 Conversion Back-UPS ES 750 FW:841.I3 .D USB FW:I3 rev 1.10/1.01 addr
 2
 uhidev0: iclass 3/0, 146 report ids
 upd0 at uhidev0

 Which only appears to provide:
 hw.sensors.upd0.indicator3=Off (ShutdownImminent), OK

 Thanks.

 --david

Hi David,

I have the same UPS as you on one of my machines, with the same result:
only indicator3 shows up. On the server that started this thread, I have:

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

Which does report all the expected sensors.

-- 
Joe Gidi
j...@entropicblur.com

You cannot buy skill. -- Ross Seyfried

Re: sensorsd, upd, and state changes

[Joe Gidi]

I just spent some more time poking at this and I'm still unable to get
sensorsd to recognize upd state changes. This is a bit of a frustrating
regression from my point of view, since I can no longer use apcupsd unless
I disable uhidev in the kernel.

Does anyone have a working example configuration for sensorsd/upd?

Thanks,

On Sun, November 23, 2014 11:51 am, Marcus MERIGHI wrote:
 j...@entropicblur.com (Joe Gidi), 2014.11.23 (Sun) 17:19 (CET):
 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

 As I had just copied the undeadly example as-is to my sensorsd.conf I
 did receive the e-mail (i.e. command= worked). It was a false positive,
 though, as no one had pulled the plug. Did you really pull the plug or
 was yours a false positive, too?

 Bye, Marcus

 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=articlesid=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
 


-- 
Joe Gidi
j...@entropicblur.com

You cannot buy skill. -- Ross Seyfried

Re: sensorsd, upd, and state changes

[Marcus MERIGHI]

j...@entropicblur.com (Joe Gidi), 2014.11.27 (Thu) 16:41 (CET):
 I just spent some more time poking at this and I'm still unable to get

So did I...

 sensorsd to recognize upd state changes. This is a bit of a frustrating
 regression from my point of view, since I can no longer use apcupsd unless
 I disable uhidev in the kernel.
 
 Does anyone have a working example configuration for sensorsd/upd?

What I have now:

$ getcap -a -f /etc/sensorsd.conf
hw.sensors.upd0.indicator0:low=1:high=2:command=/etc/sensorsd/upd.sh \
%l %n %s %x %t %2 %3 %4
hw.sensors.upd0.indicator1:low=1:high=2:command=/etc/sensorsd/upd.sh \
%l %n %s %x %t %2 %3 %4
hw.sensors.upd0.indicator2:low=1:high=2:command=/etc/sensorsd/upd.sh \
%l %n %s %x %t %2 %3 %4
hw.sensors.upd0.indicator3:low=1:high=2:command=/etc/sensorsd/upd.sh \
%l %n %s %x %t %2 %3 %4
hw.sensors.upd0.indicator4:low=1:high=2:command=/etc/sensorsd/upd.sh \
%l %n %s %x %t %2 %3 %4
hw.sensors.upd0.percent0:low=10:high=100:command=\
/etc/sensorsd/upd-capacityremaining.sh %l %n %s %x %t %2 %3 %4
hw.sensors.upd0.percent1:low=95:high=100:command=/etc/sensorsd/upd.sh \
%l %n %s %x %t %2 %3 %4

The ``command=/etc/sensorsd/upd.sh'' lines are just informational.

The workhorse is command=/etc/sensorsd/upd-capacityremaining.sh:

#!/bin/sh -e
if [[ X${1} == Xbelow ]]; then
logger -t UPD-capacityremaining SHUTDOWN (${@})
shutdown -hp +1
else
logger -t UPD-capacityremaining NON-SHUTDOWN (${@})
fi


I did some testing (plug/unplug, wait for hw.sensors.upd0.percent0 to go
below low=) and left it as working.

Bye, Marcus

 On Sun, November 23, 2014 11:51 am, Marcus MERIGHI wrote:
  j...@entropicblur.com (Joe Gidi), 2014.11.23 (Sun) 17:19 (CET):
  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
 
  As I had just copied the undeadly example as-is to my sensorsd.conf I
  did receive the e-mail (i.e. command= worked). It was a false positive,
  though, as no one had pulled the plug. Did you really pull the plug or
  was yours a false positive, too?
 
  Bye, Marcus
 
  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
   

Re: sensorsd, upd, and state changes

[Marcus MERIGHI]

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=articlesid=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!

Re: sensorsd, upd, and state changes

[Joe Gidi]

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=articlesid=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

Re: sensorsd, upd, and state changes

[Joe Gidi]

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=articlesid=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

Re: sensorsd, upd, and state changes

[Marcus MERIGHI]

j...@entropicblur.com (Joe Gidi), 2014.11.23 (Sun) 17:19 (CET):
 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

As I had just copied the undeadly example as-is to my sensorsd.conf I
did receive the e-mail (i.e. command= worked). It was a false positive,
though, as no one had pulled the plug. Did you really pull the plug or
was yours a false positive, too?

Bye, Marcus

 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=articlesid=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
 
  
 
 
 
  --
  Joe Gidi
  j...@entropicblur.com
 
  You cannot buy skill. -- Ross Seyfried
 
 
 
 -- 
 Joe Gidi
 j...@entropicblur.com
 
 You cannot buy skill. -- Ross Seyfried
 
 
 !DSPAM:547209ba317089995017961!

Re: sensorsd, upd, and state changes

[Joe Gidi]

On Sun, November 23, 2014 11:51 am, Marcus MERIGHI wrote:
 j...@entropicblur.com (Joe Gidi), 2014.11.23 (Sun) 17:19 (CET):
 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

 As I had just copied the undeadly example as-is to my sensorsd.conf I
 did receive the e-mail (i.e. command= worked). It was a false positive,
 though, as no one had pulled the plug. Did you really pull the plug or
 was yours a false positive, too?

 Bye, Marcus

I actually tested by pulling the plug. In my testing, sensorsd detects a
change and invokes my script when the daemon is first started; I believe
this is because the status of the sensor goes from undefined to OK.
However, after that, unplugging/plugging the UPS doesn't have any effect
on sensorsd.

Thanks,
Joe