Re: Sensorsd not executing commands

[cheddar-cheeze]

I did try some test commands earlier but they were not working, but now
its working all of a sudden so im clueless to why it wasnt working in
the first place. Thanks for the help.

On Thu, Jul 25, 2019 at 09:18:57PM -, Stuart Henderson wrote:
> On 2019-07-25, cheddar-cheeze  wrote:
> > I am working on setting up sensorsd so that i can automatically turn on
> > my display when docking my laptop, but on doing so sensorsd does not
> > execute my shell script. In syslogd sensord shows the sensors being
> > tripped so i am confused on why the shell script will no execute.
> >
> > #/etc/sensorsd.conf
> > hw.sensors.acpidock0.indicator0:command=/etc/sensorsd/dock %2
> >
> >
> > #/etc/sensorsd/dock
> > #!/bin/sh
> >
> > if [ $1 = "On" ]
> > then
> > xrandr --output VGA-1 --auto --right-of LVDS-1
> > elif [ $1 = "Off" ]
> > then
> > xrandr --output VGA-1 --off
> > fi
> >
> >
> 
> Are you sure that sensorsd doesn't run your script? Have it do something
> that always happens ('touch /tmp/somefile' or something) to be sure.
> 
> If it is running but isn't working as you expect, that's not a surprise
> because a script started by sensorsd won't normally have access to your X
> session. You can try something like
> 
> su username -c "env DISPLAY=:0 xrandr --output [...]"
> 
> 

Re: Sensorsd not executing commands

[Stuart Henderson]

On 2019-07-25, cheddar-cheeze  wrote:
> I am working on setting up sensorsd so that i can automatically turn on
> my display when docking my laptop, but on doing so sensorsd does not
> execute my shell script. In syslogd sensord shows the sensors being
> tripped so i am confused on why the shell script will no execute.
>
> #/etc/sensorsd.conf
> hw.sensors.acpidock0.indicator0:command=/etc/sensorsd/dock %2
>
>
> #/etc/sensorsd/dock
> #!/bin/sh
>
> if [ $1 = "On" ]
> then
> xrandr --output VGA-1 --auto --right-of LVDS-1
> elif [ $1 = "Off" ]
> then
> xrandr --output VGA-1 --off
> fi
>
>

Are you sure that sensorsd doesn't run your script? Have it do something
that always happens ('touch /tmp/somefile' or something) to be sure.

If it is running but isn't working as you expect, that's not a surprise
because a script started by sensorsd won't normally have access to your X
session. You can try something like

su username -c "env DISPLAY=:0 xrandr --output [...]"

Re: sensorsd and acpiac0.indicator0?

[Job Snijders]

Dear Ingo,

On Tue, Nov 28, 2017 at 08:28:02PM +0100, Ingo Schwarze wrote:
> Job Snijders wrote on Mon, Nov 27, 2017 at 03:12:10PM +:
> > I'm tweaking how my laptop behaves depending on whether it is
> > pluggde into AC or not. Any hints or alternative suggestions are
> > welcome. This is my config: /etc/sensorsd.conf:
> > 
> > acpiac0.indicator0:command=/etc/sensorsd/ac_power %2
> 
> I am using:
> 
>   hw.sensors.acpiac0.indicator0:low=1:command=/etc/sensorsd/acpiac %2 %3 %4
> 
> The "%3 %4" is just useful for debugging, you don't need it.
> But are you sure you can omit "hw.sensors."?
> The sensorsd.conf(5) manual only says:
> 
>   Sensors may be specified by their full hw.sensors sysctl(8)
>   variable name or by type, with the full name taking precedence.
> 
> The string "acpiac0.indicator0" seems to be neither.

I tried both fully qualified and shortened, and based on your email also
with "low=1". Still the event doesn't fire reliably.

> > echo $1 >> /root/test
> 
> Using logger(1) might feel more professional ;-) For example, i'm
> using:
> 
>   logger -p daemon.info -t acpiac status=$1 low=$2 high=$3

Thank you, that is indeed a better approach :)

Kind regards,

Job

Re: sensorsd and acpiac0.indicator0?

[Ingo Schwarze]

Hi Job,

Job Snijders wrote on Mon, Nov 27, 2017 at 03:12:10PM +:

> I'm tweaking how my laptop behaves depending on whether it is pluggde
> into AC or not. Any hints or alternative suggestions are welcome.
> 
> This is my config:
> 
> /etc/sensorsd.conf:
> 
> acpiac0.indicator0:command=/etc/sensorsd/ac_power %2

I am using:

  hw.sensors.acpiac0.indicator0:low=1:command=/etc/sensorsd/acpiac %2 %3 %4

The "%3 %4" is just useful for debugging, you don't need it.
But are you sure you can omit "hw.sensors."?
The sensorsd.conf(5) manual only says:

  Sensors may be specified by their full hw.sensors sysctl(8)
  variable name or by type, with the full name taking precedence.

The string "acpiac0.indicator0" seems to be neither.

> and this is the script:
> 
> #!/bin/sh
> 
> echo $1 >> /root/test

Using logger(1) might feel more professional ;-).

For example, i'm using:

  logger -p daemon.info -t acpiac status=$1 low=$2 high=$3

Yours,
  Ingo

> case $1 in
> On)
> /sbin/sysctl -w machdep.lidaction=0
> ;;
> Off)
> /sbin/sysctl -w machdep.lidaction=1
> ;;
> *)
> echo "unknown state $1"
> exit 1
> ;;
> esac
> 
> I'd expect the lidaction to change when I plug my X270 into AC, or
> unplug it, but nothing seems to happen. Running 'sensorsd -d -c 1'
> didn't output anything. /root/test stays empty.

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

Re: sensorsd config tokens

[Stuart Henderson]

On 2012-06-08, Robert Connolly robertconnolly1...@gmail.com wrote:
 From /etc/sensorsd.conf (it's set to 51C for testing purposes):
 hw.sensors.km0.temp0:high=51C:command=/etc/sensorsd/cpu-temp.sh %l %x %t %2
 %3 %4

Looks like a shell problem not a sensorsd one; I guess you probably
want some  around the parameters.

 I have no idea what 9223372036581.62 is.

Default MIN value, i.e. the highest value that can be stored,
because you had no explicit value. LLONG_MAX in the storage format.

Re: Sensorsd

[Theo de Raadt]

 I decided to use sensorsd for the first time and am a little confused as
 to why it thinks I only have two (2) sensors when I have asked it to
 watch
 four (4) items. Any ideas would be great.
 
 The output from sysctl hw is the following
 hw.disknames=sd0,cd0
 hw.diskcount=2
 hw.sensors.cpu0.temp0=34.00 degC
 hw.sensors.mpi0.drive0=online (sd0), OK

The first two are not sensors.  Note the .sensors. part.

Re: Sensorsd

[Morris, Roy]

-Original Message-
From: Theo de Raadt [mailto:dera...@cvs.openbsd.org]
Sent: Wednesday, January 06, 2010 3:45 PM
To: Morris, Roy
Cc: misc@openbsd.org
Subject: Re: Sensorsd

 I decided to use sensorsd for the first time and am a little confused
as
 to why it thinks I only have two (2) sensors when I have asked it to
 watch
 four (4) items. Any ideas would be great.

 The output from sysctl hw is the following
 hw.disknames=sd0,cd0
 hw.diskcount=2
 hw.sensors.cpu0.temp0=34.00 degC
 hw.sensors.mpi0.drive0=online (sd0), OK

The first two are not sensors.  Note the .sensors. part.

Ok, figured that might be what it was! Thanks. Too bad it
would be nice to know if the disk count changed ie. someone
plugged in a USB key.

Cheers
Roy

Re: Sensorsd

[Alexander Polakov]

2010/1/6, Morris, Roy rmor...@internetsecure.com:
 Ok, figured that might be what it was! Thanks. Too bad it
 would be nice to know if the disk count changed ie. someone
 plugged in a USB key.

You can use hotplugd(8) for that.

Re: Sensorsd

[Morris, Roy]

-Original Message-

From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of 
Alexander Polakov

Sent: Wednesday, January 06, 2010 4:11 PM

To: misc@openbsd.org

Subject: Re: Sensorsd



2010/1/6, Morris, Roy rmor...@internetsecure.com:

 Ok, figured that might be what it was! Thanks. Too bad it

 would be nice to know if the disk count changed ie. someone

 plugged in a USB key.



You can use hotplugd(8) for that.

Yes sir you're absolutely correct! thanks.

Re: sensorsd strange tokens values

[Federico Giannici]

Constantine A. Murenin wrote:

On 27/07/2009, Federico Giannici giann...@neomedia.it wrote:

I'm using for the first time sensorsd to monitor RAID controller status and
motherboard temperature. A script of mine is called that sends me an email.
System is OpenBSD 4.4 amd64.

 The problem is the value of the %2 %3 and %4 tokens passed as arguments to
the command. I thought that they should be (in the same order): current
temperature, low limit and high limit as set in the sensorsd.conf file.

 Indeed here are the values I get:

 %2: 46.00
 %3: degC
 %4: 9223372036581.62

 The command I use is command=/path/scriptname %x %n %l %2 %3 %4.

 Is there some bug or I'm missing something?


%2 can never return 46.00 alone, what it must be returning is 46.00
degC.  Same goes for the rest of the tokens.

So perhaps the invocation of the script has to have some quotes around these.


You got it!!!

Thank you.


P.S.
Maybe the example in the man page could use the quotes so no other idiot 
like me spend time looking for whats wrong  :-)



--
___
__
   |-  giann...@neomedia.it
   |ederico Giannici  http://www.neomedia.it
___

Re: sensorsd strange tokens values

[Constantine A. Murenin]

On 27/07/2009, Federico Giannici giann...@neomedia.it wrote:
 I'm using for the first time sensorsd to monitor RAID controller status and
 motherboard temperature. A script of mine is called that sends me an email.
 System is OpenBSD 4.4 amd64.

  The problem is the value of the %2 %3 and %4 tokens passed as arguments to
 the command. I thought that they should be (in the same order): current
 temperature, low limit and high limit as set in the sensorsd.conf file.

  Indeed here are the values I get:

  %2: 46.00
  %3: degC
  %4: 9223372036581.62

  The command I use is command=/path/scriptname %x %n %l %2 %3 %4.

  Is there some bug or I'm missing something?

%2 can never return 46.00 alone, what it must be returning is 46.00
degC.  Same goes for the rest of the tokens.

So perhaps the invocation of the script has to have some quotes around these.

C.

Re: sensorsd says the sensor is within limit, but it's not...

[Per-Olov Sjöholm]

On Wednesdayen den 4 July 2007 04.17.30 you wrote:
 On 03/07/07, Per-Olov Sjvholm [EMAIL PROTECTED] wrote:
  Hi Misc
 
 
  I am probably missing something, but what..
 
 
  sensorsd says in the syslog that the sensor is within limits even
  though a sysctl -a|grep sensor shows that it is not.
 
 
  Are there any known bugs? I have checked the list and cannot find
  anything related to this... I run a Dell PE830 on OpenBSD 4.0 stable
  (latest update in May 25:th). I have these sensors which appears to
  always show the correct values running a sysctl -a|grep sensor.
  hw.sensors.0=ipmi0, Temp, 43.00 degC, OK
  hw.sensors.1=ipmi0, Planar Temp, 38.00 degC, OK
  hw.sensors.2=ipmi0, CMOS Battery, 3.13 V DC, OK
  hw.sensors.3=ipmi0, Back Fan, 2204 RPM, OK
  hw.sensors.4=ipmi0, Intrusion, Off, OK
  hw.sensors.5=ami0, sd0, drive online, OK
 
 
 
  From sensords.conf
  hw.sensors.0:high=42C:command=/bin/echo test test|/usr/bin/mailx -s
  Sensor warning: CPU temp over %2 bla bla bla MYEMAIL
  hw.sensors.1:high=39C:command=/bin/echo test test|/usr/bin/mailx -s
  Sensor warning: Chassie temp over %2 bla bla bla MYEMAIL
 
 
  Starting sensorsd and look at /var/log/daemon
  Jul  3 16:12:22 xanadu sensorsd[14634]: hw.sensors.0: within limits,
  value: 43.00 degC
  Jul  3 16:12:22 xanadu sensorsd[14634]: hw.sensors.1: within limits,
  value: 38.00 degC
 
 
  I assume I receive no reports as the daemon say the sensor wrongly is
  within the limits

 Please, check the manual page for your system [0], specifically, the
 following:

  Sensors that provide status (such as from bio(4), esm(4), or ipmi(4))
 do not require boundary values specified (that otherwise will be ignored)
 and simply trigger on status transitions.

 In other words, for those sensors that provide the status themselves,
 the keywords high and low in sensorsd.conf have no effect. This
 limitation was removed at c2k7 [1], and the newest sensorsd in OpenBSD
 4.1-current allows you to set your own limits for any sensor, and
 ignore the status that the sensor device itself provides.

 So if you need this functionality, you may wish to upgrade to OpenBSD
 4.1-current.

 Alternatively, you may upgrade to OpenBSD 4.1-stable that has the new
 two-level sensor framework, and then manually update sensorsd to
 4.1-current (files /usr/src/{etc/sensorsd.conf,usr.sbin/sensorsd/*}),
 compiling and installing it afterwards  -- sensorsd in 4.1-current as
 of today is source-code-compatible with 4.1-stable (note that it is
 not binary compatible). However, please be warned that mixing
 4.1-stable and 4.1-current is not officially supported, so use it at
 your own risk! (Even though it works for me in this specific case with
 sensorsd.)

 Cheers,
 Constantine. :)

 [0]
 http://www.openbsd.org/cgi-bin/man.cgi?query=sensorsd.confsektion=5manpat
h=OpenBSD+4.0

 [1]
 http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/sensorsd/sensorsd.c#rev1
.32


Thanks for the answer

So I only need the command with %1-%4 and no low/high specs in
sensorsd.conf? The trigger will come when Dell think the temp i to low or
high? If so... Is there a way of knowing at what temperature this happends. I
mean, could you ask the hardware itself with any software, or do I have to
dig into some of Dell:s docs? That is not super important, but it would be
nice to know at what value it happends, and if possible test it.

Also, isn't it possible then to have different commands for low and high if
low and high has no meanings? I mean, do I have to take care of if it's a low
or a high warning in the command script. If low and high have meanings (as in
OBSD 4.1-current) I could have one sensor row in sensorsd.conf for high and
one for low with different commands. Right?


You said that:
Alternatively, you may upgrade to OpenBSD 4.1-stable that has the new
two-level sensor framework Why do I need to go to -CURRENT if it's included
in 4.1-STABLE? Isn't 4.1-STABLE ok? I want to avoid -current on production
servers. But after looking at
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/sensorsd/sensorsd.c it
seems I am *not* OK with just 4.1 STABLE, and that I need -CURRENT if I want
this functionality...



Per-Olov
--
GPG keyID: 4DB283CE
GPG fingerprint: 45E8 3D0E DE05 B714 D549 45BC CFB4 BBE9 4DB2 83CE
GPG key:
http://keyserv.nic-se.se:11371/pks/lookup?op=getsearch=0xCFB4BBE94DB283CE

Re: sensorsd says the sensor is within limit, but it's not...

[Constantine A. Murenin]

On 04/07/07, Per-Olov Sjvholm [EMAIL PROTECTED] wrote:

On Wednesdayen den 4 July 2007 04.17.30 you wrote:
 Please, check the manual page for your system [0], specifically, the
 following:

  Sensors that provide status (such as from bio(4), esm(4), or

ipmi(4))

 do not require boundary values specified (that otherwise will be ignored)
 and simply trigger on status transitions.

 In other words, for those sensors that provide the status themselves,
 the keywords high and low in sensorsd.conf have no effect. This
 limitation was removed at c2k7 [1], and the newest sensorsd in OpenBSD
 4.1-current allows you to set your own limits for any sensor, and
 ignore the status that the sensor device itself provides.

 So if you need this functionality, you may wish to upgrade to OpenBSD
 4.1-current.

 Alternatively, you may upgrade to OpenBSD 4.1-stable that has the new
 two-level sensor framework, and then manually update sensorsd to
 4.1-current (files /usr/src/{etc/sensorsd.conf,usr.sbin/sensorsd/*}),
 compiling and installing it afterwards  -- sensorsd in 4.1-current as
 of today is source-code-compatible with 4.1-stable (note that it is
 not binary compatible). However, please be warned that mixing
 4.1-stable and 4.1-current is not officially supported, so use it at
 your own risk! (Even though it works for me in this specific case with
 sensorsd.)

 Cheers,
 Constantine. :)

 [0]


http://www.openbsd.org/cgi-bin/man.cgi?query=sensorsd.confsektion=5manpat

h=OpenBSD+4.0

 [1]


http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/sensorsd/sensorsd.c#rev1

.32


Thanks for the answer

So I only need the command with %1-%4 and no low/high specs in
sensorsd.conf?


yes


The trigger will come when Dell think the temp i to low or
high?


yes, it will trigger whenever there is any transition in state. I.e.
when you start sensorsd, sensors state in sensorsd goes from undefined
to whatever it is for every sensor, and this also triggers the
command.


If so... Is there a way of knowing at what temperature this happends. I
mean, could you ask the hardware itself with any software, or do I have to
dig into some of Dell:s docs? That is not super important, but it would be
nice to know at what value it happends, and if possible test it.


not that I'm aware of, however, I've never used ipmi


Also, isn't it possible then to have different commands for low and high if
low and high has no meanings? I mean, do I have to take care of if it's a

low

or a high warning in the command script. If low and high have meanings (as

in

OBSD 4.1-current) I could have one sensor row in sensorsd.conf for high and
one for low with different commands. Right?


No, if you read the man-pages, you'll see that every sensor is matched
by at most one entry in the config file. You can have a shell script
as the command, which can compare sensor values to the limits and take
appropriate decision on which command to execute.


You said that:
Alternatively, you may upgrade to OpenBSD 4.1-stable that has the new
two-level sensor framework Why do I need to go to -CURRENT if it's

included

in 4.1-STABLE? Isn't 4.1-STABLE ok? I want to avoid -current on production
servers. But after looking at
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/sensorsd/sensorsd.c it
seems I am *not* OK with just 4.1 STABLE, and that I need -CURRENT if I

want

this functionality...


In 4.1-stable we have the new two-level sensors framework, but no
changes in sensorsd other then the way sensors are addressed --
however, this change in sensor addressing is a huge improvement for
sensorsd in itself. ;)

In -current, we have the new sensorsd functionality, which is based on
the new framework. Hence my suggestion to use -current sensorsd with a
4.1-stable system -- it's not officially supported, but it works as of
today without any problems.

If you don't want to copy and compile sensorsd sources from -current
to 4.1-stable, then I'd suggest you wait until 4.2 is released. :)

Cheers,
Constantine.

Re: sensorsd says the sensor is within limit, but it's not...

[Constantine A. Murenin]

On 03/07/07, Per-Olov Sjvholm [EMAIL PROTECTED] wrote:

Hi Misc


I am probably missing something, but what..


sensorsd says in the syslog that the sensor is within limits even though
a sysctl -a|grep sensor shows that it is not.


Are there any known bugs? I have checked the list and cannot find anything
related to this... I run a Dell PE830 on OpenBSD 4.0 stable (latest update

in

May 25:th). I have these sensors which appears to always show the correct
values running a sysctl -a|grep sensor.
hw.sensors.0=ipmi0, Temp, 43.00 degC, OK
hw.sensors.1=ipmi0, Planar Temp, 38.00 degC, OK
hw.sensors.2=ipmi0, CMOS Battery, 3.13 V DC, OK
hw.sensors.3=ipmi0, Back Fan, 2204 RPM, OK
hw.sensors.4=ipmi0, Intrusion, Off, OK
hw.sensors.5=ami0, sd0, drive online, OK



From sensords.conf
hw.sensors.0:high=42C:command=/bin/echo test test|/usr/bin/mailx -s

Sensor

warning: CPU temp over %2 bla bla bla MYEMAIL
hw.sensors.1:high=39C:command=/bin/echo test test|/usr/bin/mailx -s

Sensor

warning: Chassie temp over %2 bla bla bla MYEMAIL


Starting sensorsd and look at /var/log/daemon
Jul  3 16:12:22 xanadu sensorsd[14634]: hw.sensors.0: within limits, value:
43.00 degC
Jul  3 16:12:22 xanadu sensorsd[14634]: hw.sensors.1: within limits, value:
38.00 degC


I assume I receive no reports as the daemon say the sensor wrongly is

within

the limits



Please, check the manual page for your system [0], specifically, the
following:

Sensors that provide status (such as from bio(4), esm(4), or ipmi(4)) do
not require boundary values specified (that otherwise will be ignored)
and simply trigger on status transitions.

In other words, for those sensors that provide the status themselves,
the keywords high and low in sensorsd.conf have no effect. This
limitation was removed at c2k7 [1], and the newest sensorsd in OpenBSD
4.1-current allows you to set your own limits for any sensor, and
ignore the status that the sensor device itself provides.

So if you need this functionality, you may wish to upgrade to OpenBSD
4.1-current.

Alternatively, you may upgrade to OpenBSD 4.1-stable that has the new
two-level sensor framework, and then manually update sensorsd to
4.1-current (files /usr/src/{etc/sensorsd.conf,usr.sbin/sensorsd/*}),
compiling and installing it afterwards  -- sensorsd in 4.1-current as
of today is source-code-compatible with 4.1-stable (note that it is
not binary compatible). However, please be warned that mixing
4.1-stable and 4.1-current is not officially supported, so use it at
your own risk! (Even though it works for me in this specific case with
sensorsd.)

Cheers,
Constantine. :)

[0]
http://www.openbsd.org/cgi-bin/man.cgi?query=sensorsd.confsektion=5manpath=
OpenBSD+4.0

[1]
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/sensorsd/sensorsd.c#rev1.3
2

Re: sensorsd shutting computer down

[Constantine A. Murenin]

On 27/05/07, Steven [EMAIL PROTECTED] wrote:

Hello,

Last update (~2 weeks ago) and the one from last night result in
sensorsd shutting down my PC within 2 to 4 minutes after booting up.
Now /etc/sensorsd.conf has an entry in it that I added to safely
shut the computer down if the CPU gets too hot.  The only problem is
that sensorsd keeps shutting the computer down even though the
temperature displayed using systat -w 1 sensors shows the cpu to be
a good 8 to 10 degrees cooler than the conditional temperature!
Perhaps the temperature is spiking at some point between systat
updating itself?

Anyhow, here are the relevant /etc/sensorsd.conf and dmesg.  Thanks
and let me know if there's anymore information that I can (should)
include.


# $OpenBSD: sensorsd.conf,v 1.1 2003/10/08 20:30:04 grange Exp $

#
# Sample sensorsd.conf file. See sensorsd.conf(5) for details.
#

# +5 voltage (volts)
#hw.sensors.3:low=4.8V:high=5.2V

# +12 voltage (volts)
#hw.sensors.4:low=11.5V:high=12.5V

# Chipset temperature (degrees Celsius)
#hw.sensors.7:high=50C

# CPU temperature (degrees Celsius)
hw.sensors.viaenv0.temp0:high=70C:command=/sbin/shutdown -hp now System 
overheating!  Emergency Shutdown!

# CPU fan (RPM)
#hw.sensors.3:low=5000


Have you updated the userland? There was some change in
sys/sensors.h 2 months ago (22nd March) that required recompilation
of all userland and port utilities that interact with the sensors
framework.

If updating the userland doesn't fix your problem, then please include
`grep sensorsd /var/log/daemon` and `sysctl hw`.

Cheers,
Constantine.

Re: sensorsd

[Constantine A. Murenin]

On 24/03/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

In /etc/sensorsd.conf

hw.sensors.3:low=4.8V:high=5.2V:command=/bin/sh /etc/sensorsd/notify

In /etc/sensorsd/notify

#!/bin/sh

/usr/bin/tail -n 25 /var/log/daemon | /usr/bin/grep sensorsd | /usr/
bin/grep exceed  /etc/sensorsd/`date +%m%d%y_%H%M`.log
/usr/bin/mail -s Hardware Sensors Monitor - Threshold Exceeded  /
etc/sensorsd/`date +%m%d%y_%H%M`.log [EMAIL PROTECTED]

 From /var/log/daemon

# grep sensorsd /var/log/daemon | grep exceed
Mar 24 02:31:31 vegeta sensorsd[23054]: hw.sensors.4: exceed limits,
value: 12.61 V DC
Mar 24 03:30:44 vegeta sensorsd[23054]: hw.sensors.4: exceed limits,
value: 12.61 V DC
Mar 24 03:30:52 vegeta sensorsd[13951]: hw.sensors.4: exceed limits,
value: 12.61 V DC
Mar 24 08:28:51 vegeta sensorsd[13951]: hw.sensors.4: exceed limits,
value: 12.61 V DC
Mar 24 08:30:51 vegeta sensorsd[13951]: hw.sensors.4: exceed limits,
value: 12.61 V DC

 From /var/log/mail

Mar 24 03:30:54 vegeta sendmail[23902]: l2O8UrwM023902:
[EMAIL PROTECTED], ctladdr=dj_goku (1000/1000), delay=00:00:01,
xdelay=00:00:00, mailer=relay, pri=30599, relay=[127.0.0.1]
[127.0.0.1], dsn=2.0.0, stat=Sent (l2O8Us5n000215 Message accepted
for delivery)
Mar 24 03:30:55 vegeta sm-mta[18718]: l2O8Us5n000215:
to=[EMAIL PROTECTED], ctladdr=[EMAIL PROTECTED] (1000/1000),
delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=30901,
relay=mail.mail.com. [12.34.56.78], dsn=2.0.0, stat=Sent (OK
1174725055 15si26531894nzn)

I have only gotten 1 email from all those exceeds from sensorsd.

Any ideas?


I'm surprised you've got any emails from those exceeds at all, because
the sensors that you have warnings for do not match the one's you
claim you are monitoring in sensorsd.conf (hw.sensors.3 in conf,
hw.sensors.4 on log).

Cheers,
Constantine.

Re: sensorsd

[djgoku]

On Mar 24, 2007, at 1:38 PM, Constantine A. Murenin wrote:

I'm surprised you've got any emails from those exceeds at all, because
the sensors that you have warnings for do not match the one's you
claim you are monitoring in sensorsd.conf (hw.sensors.3 in conf,
hw.sensors.4 on log).


Sorry I didn't post the whole sensorsd.conf

hw.sensors.3:low=4.8V:high=5.2V:command=/bin/sh /etc/sensorsd/notify

# +12 voltage (volts)
hw.sensors.4:low=11.5V:high=12.55V

# Chipset temperature (degrees Celsius)
hw.sensors.7:high=35C

hw.sensors.9:low=3000
hw.sensors.10:low=3000

Re: sensorsd

[Constantine A. Murenin]

On 24/03/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

On Mar 24, 2007, at 1:38 PM, Constantine A. Murenin wrote:
 I'm surprised you've got any emails from those exceeds at all, because
 the sensors that you have warnings for do not match the one's you
 claim you are monitoring in sensorsd.conf (hw.sensors.3 in conf,
 hw.sensors.4 on log).

Sorry I didn't post the whole sensorsd.conf

hw.sensors.3:low=4.8V:high=5.2V:command=/bin/sh /etc/sensorsd/notify

# +12 voltage (volts)
hw.sensors.4:low=11.5V:high=12.55V


You do not have a command specified on hw.sensors.4, so you should not
be expecting any emails to be sent when this sensor undergoes
transitions from one state to another.

I think the syntax of sensorsd.conf is rather obvious here -- your
command gets executed only when hw.sensors.3 undergoes state
transitions, hw.sensors.4 transitions will only be reported into
syslog.

C.

Re: sensorsd

[djgoku]

On Mar 24, 2007, at 5:27 PM, Constantine A. Murenin wrote:


You do not have a command specified on hw.sensors.4, so you should not
be expecting any emails to be sent when this sensor undergoes
transitions from one state to another.

I think the syntax of sensorsd.conf is rather obvious here -- your
command gets executed only when hw.sensors.3 undergoes state
transitions, hw.sensors.4 transitions will only be reported into
syslog.


Ahh, I must of interpreted (man sensorsd.conf) that incorrectly. So  
just add the command part to the rest of the sensors will fix it.


thanks

Re: sensorsd bug on macppc

[Antoine Jacoutot]

On Tue, 26 Sep 2006, mickey wrote:

in some cases sensor values cannot be provided by the hw
(most drivers fail a few times a day on my machines).
in this case the sensor state is marked as unknown
or invalid. that's why you are getting your mail.


Allright, I see.
The weird thing though is that:
- it used to work
- it _only_ happens once on sensorsd startup, after that it works fine


as we can see 28c is not really even a valid temperature.


Indeed.

Thanks for the explanation.

--
Antoine

Re: sensorsd

[Mark Zimmerman]

On Mon, Jul 17, 2006 at 11:42:01PM -0300, Gustavo Rios wrote:
 Hey folks,
 
 I am running a Dell Precision Workstation, is it possible to have
 sensors working with such hardware? Any special consideration?
 
First, try 'sysctl hw.sensors'. If you get nothing (like on the Dell I
am using right now) then you are probably out of luck.

-- Mark

Re: sensorsd configuration

[Antoine Jacoutot]

On Thu, 13 Jul 2006, Daniel A. Ramaley wrote:

The lines in sensorsd.conf start with hw.sensors.N (where N is a small
natural number). How do i determine N for each sensor? Is there a list


You can retrieve sensors information using the sysctl command:

$ sysctl hw.sensors
hw.sensors.0=viaenv0, TSENS1, temp, 50.50 degC / 122.90 degF
hw.sensors.1=viaenv0, TSENS2, temp, 52.00 degC / 125.60 degF
hw.sensors.2=viaenv0, TSENS3, temp, 26.82 degC / 80.28 degF
hw.sensors.3=viaenv0, FAN1, fanrpm, 0 RPM
hw.sensors.4=viaenv0, FAN2, fanrpm, 0 RPM
hw.sensors.5=viaenv0, VSENS1, volts_dc, 1.20 V
hw.sensors.6=viaenv0, VSENS2, volts_dc, 2.51 V
hw.sensors.7=viaenv0, Vcore, volts_dc, 3.26 V
hw.sensors.8=viaenv0, VSENS3, volts_dc, 4.95 V
hw.sensors.9=viaenv0, VSENS4, volts_dc, 11.83 V

Now, to know what hw.sensors.0 is, you have a loot at the man page 
corresponding to your sensor (here viaenv):


$ man viaenv
(...)
 The device has 10 sensors:

   SensorUnitsTypical Use
   TSENS1uK   CPU temperature
   TSENS2uK   System temperature
   TSENS3uK   Unknown
   FAN1  RPM  CPU fan
   FAN2  RPM  System fan
   VSENS1uV DCCPU core voltage (2.0V)
   VSENS2uV DCNorth Bridge core voltage (2.5V)
   Vcore uV DCInternal core voltage (3.3V)
   VSENS3uV DC+5V
   VSENS4uV DC+12V
(...)

Let's say you want to monitor your CPU temperature, in your 
/etc/sensorsd.conf file, you could put something like:


hw.sensors.0:high=60C:\
 :command=echo %2 \(high=%4\) | mail -s [`hostname`] sensorsd WARNING \(CPU 
Temp.\) root

Regards,

--
Antoine

Re: sensorsd configuration

[Weldon Goree]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Daniel A. Ramaley wrote:
 The lines in sensorsd.conf start with hw.sensors.N (where N is a small 
 natural number). How do i determine N for each sensor? Is there a list 
 somewhere that tells what is what? Or is there a command i can run to 
 generate a list?

`sysctl hw.sensors` will show you the list of all the sensors and their
appropriate number (and current value). As I found out a couple of days
ago, sysctl(8) does this by just trying all possible N's for 1 to 256
and then checks what each sensor is. AFAICT, that's the only facility
the kernel offers to find them.

 Secondly, is it possible to read the current values of sensors? For 
 example, say i have configured a sensor to monitor the CPU temperature. 
 Is there a way to find out what the current temperature is?

sysctl(8), again. If CPU temp is hw.sensors.4, then sysctl hw.sensors.4
will tell you. Sensorsd is more for watching for threshholds and
boundary readings, rather than a real-time display of the current reading.

If you're programming, you can also use sysctl(3); it would be something
like sysctl({CTL_HW, HW_SENSORS, 4}, 3, some_allocated_buffer,
length_of_that_buffer, NULL, 0);
some_allocated_buffer will then hold the struct sensor containing its
current state.

Weldon Goree
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEtnuvixcispFzVm8RAttkAJ95eFTvJaaqn4R1Tkf1Kpo9c1KtuwCfS5aG
0ET6NQe4/KoC6iUw2w6qipk=
=PTNG
-END PGP SIGNATURE-

Re: sensorsd configuration

[Daniel A. Ramaley]

Thank you to those who responded! I can figure out sensorsd.conf now. 
Also thank you to the developers who created such a simple way to 
monitor the sensors. I've configured sensors on other operating systems 
that have been a much greater hassle.


Dan RamaleyDial Center 118, Drake University
Network Programmer/Analyst 2407 Carpenter Ave
+1 515 271-4540Des Moines IA 50311 USA

Re: sensorsd and mail alert

[Antoine Jacoutot]

Antoine Jacoutot wrote:
How can I make sensorsd or syslog to mail me this, without running a 
parser every minute on /var/log/messages which looks overkill.


Answering to myself...
Allright, I had a check on sensorsd under current and it looks like in 
3.8 I will be able to give a command to execute when the sensor is too 
high. Great, I just have to wait for 3.8...


Sorry for the noise, in the meanwhile, I'll use syslogc.
Regards,

Antoine

Re: sensorsd and mail alert

[kami petersen]

Antoine Jacoutot skrev:
How can I make sensorsd or syslog to mail me this, without running a 
parser every minute on /var/log/messages which looks overkill.


man 5 sensorsd.conf

/kami