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 [...]"

Sensorsd not executing commands

[cheddar-cheeze]

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

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.

sensorsd and acpiac0.indicator0?

[Job Snijders]

Hi all,

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

and this is the script:

#!/bin/sh

echo $1 >> /root/test

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.



Kind regards,

Job

Re: sensorsd, upd, and state changes

[Constantine Aleksandrovich Murenin]

On 26 February 2016 at 08:40, lilit-aibolit <lilit-aibo...@mail.ru> 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: APC UPS & sensorsd - how?

[Maxim Khitrov]

On Wed, Feb 24, 2016 at 3:38 AM, lilit-aibolit <lilit-aibo...@mail.ru> wrote:
> On 03/22/2015 05:44 PM, T. Ribbrock wrote:
>>
>> Then, I re-applied power, but that, too, was never flagged by sensorsd.
>> For some reason, it looks like sensorsd only ever detects a status change
>> (for these rules) when it gets started - but not afterwards. Regards, Thomas
>
> Have you succeed with getting status change while sensord is running?

low=0:high=0 has been working well for me:

https://marc.info/?l=openbsd-misc=144529176814155=2

Re: APC UPS & sensorsd - how?

[lilit-aibolit]

On 03/22/2015 05:44 PM, T. Ribbrock wrote:
Then, I re-applied power, but that, too, was never flagged by 
sensorsd. For some reason, it looks like sensorsd only ever detects a 
status change (for these rules) when it gets started - but not 
afterwards. Regards, Thomas 

Have you succeed with getting status change while sensord is running?

Re: sensorsd, upd, and state changes

[Maxim Khitrov]

On Mon, Dec 8, 2014 at 3:45 PM, David Higgs <hig...@gmail.com> wrote:
> 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

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 <m...@mxcrypt.com> wrote:

> On Mon, Dec 8, 2014 at 3:45 PM, David Higgs <hig...@gmail.com> wrote:
> > 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
>
> 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 <hig...@gmail.com> wrote:
> On Mon, Oct 19, 2015 at 11:11 AM, Maxim Khitrov <m...@mxcrypt.com> wrote:
>>
>> On Mon, Dec 8, 2014 at 3:45 PM, David Higgs <hig...@gmail.com> wrote:
>> > 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
>>
>> 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 <hig...@gmail.com> wrote:
> On Mon, Oct 19, 2015 at 11:11 AM, Maxim Khitrov <m...@mxcrypt.com> 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.

APC UPS sensorsd - how?

[T. Ribbrock]

Hi all,

one of the remaining kinks in the cable that still need working out
after me updating to OpenBSD 5.6 is the fact that I can no longer use
apcupsd to monitor the APC Back-UPS CS 500 that is connected to the
server via USB. From what I have gathered so far, one has to use
sensorsd instead, so I've been through the man pages (sensorsd(8) and
sensorsd.conf(5)) as well as through the archives of this list. The one
relevant thread I found was this one:

http://marc.info/?t=14167023941r=1w=2

Despite this, I cannot seem to get sensorsd to monitor the state of the
ups. Here's what I have so far:

The ups is detected properly as can be seen from dmesg:

[...]
uhidev0 at uhub4 port 2 configuration 1 interface 0 American Power Conversion 
Back-UPS CS 500 FW:808.q8.I USB FW:q8 rev 1.10/0.06 addr 2
uhidev0: iclass 3/0, 98 report ids
upd0 at uhidev0
[...]

It is also seen properly by sysctl:
# sysctl | grep upd 
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=100.00% (FullChargeCapacity), OK
hw.sensors.upd0.percent1=55.00% (RemainingCapacity), OK

When removing AC power, I can see that the ups reports this as expected:

# sysctl | grep upd 
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=100.00% (FullChargeCapacity), OK
hw.sensors.upd0.percent1=55.00% (RemainingCapacity), OK

(see changes in Charging, Discharging and ACPresent)

What I cannot seem to get to work is that sensorsd *reacts* to these
changes. Based on the examples in the thread mentioned above, I've
created a small script /etc/sensorsd/upd.sh that looks as follows:

# cat /etc/sensorsd/upd.sh 
echo ${@} | logger -t UPD

I have then created the following sensorsd.conf:
hw.sensors.upd0.indicator0:high=0:command=/etc/sensorsd/upd.sh %x.%t%n Charging 
%2 %s
hw.sensors.upd0.indicator1:high=0:command=/etc/sensorsd/upd.sh %x.%t%n 
Discharging %2 %s
hw.sensors.upd0.indicator2:low=1:command=/etc/sensorsd/upd.sh %x.%t%n ACPresent 
%2 %s
hw.sensors.upd0.indicator3:low=1:command=/etc/sensorsd/upd.sh %x.%t%n 
BatteryPresent %2 %s
hw.sensors.upd0.indicator4:high=0:command=/etc/sensorsd/upd.sh %x.%t%n 
ShutdownImminent %2 %s
hw.sensors.upd0.percent0:low=25:command=/etc/sensorsd/upd.sh %x.%t%n 
FullChargeCapacity %2 %s
hw.sensors.upd0.percent1:low=25:command=/etc/sensorsd/upd.sh %x.%t%n 
RemainingCapacity %2 %s

When I start sensorsd, I get this output:
sensorsd[31995]: upd0.indicator2: exceeds limits: On is below On
sensorsd[31995]: upd0.indicator3: exceeds limits: On is below On
UPD: upd0.indicator2 ACPresent On OK 
UPD: upd0.indicator3 BatteryPresent On OK 
UPD: upd0.percent0 FullChargeCapacity 100.00% OK 
UPD: upd0.indicator4 ShutdownImminent Off OK 
UPD: upd0.indicator1 Discharging Off OK 
UPD: upd0.percent1 RemainingCapacity 61.00% OK 
UPD: upd0.indicator0 Charging On OK 

However, when I subsequently remove AC power, nothing happens - no more
messages from sensorsd are forthcoming. I've also tried running sensorsd
with '-c 1' and left the system for more than a minute after the change,
but no avail. Also, some variations on the limits (e.g. low=1:high=2
for indicator3) did not change anything. I get the sneaking feeling that
I might miss something obvious, but so far have no idea. Hence, if
someone out there *does* have an idea, I'd be very interested to hear
and learn.

Thanks in advance,

Thomas


-- 
-
 Thomas Ribbrockhttp://www.ribbrock.org/ 
   You have to live on the edge of reality - to make your dreams come true!

Re: APC UPS sensorsd - how?

[T. Ribbrock]

On Sun, Mar 22, 2015 at 03:26:30PM +, Stuart Henderson wrote:
 On 2015-03-22, T. Ribbrock emga...@gmx.net wrote:
  What I cannot seem to get to work is that sensorsd *reacts* to these
  changes. Based on the examples in the thread mentioned above, I've
  created a small script /etc/sensorsd/upd.sh that looks as follows:

  # cat /etc/sensorsd/upd.sh 
  echo ${@} | logger -t UPD

  I have then created the following sensorsd.conf:
  hw.sensors.upd0.indicator0:high=0:command=/etc/sensorsd/upd.sh %x.%t%n 
  Charging %2 %s
  hw.sensors.upd0.indicator1:high=0:command=/etc/sensorsd/upd.sh %x.%t%n 
  Discharging %2 %s
  hw.sensors.upd0.indicator2:low=1:command=/etc/sensorsd/upd.sh %x.%t%n 
  ACPresent %2 %s
  hw.sensors.upd0.indicator3:low=1:command=/etc/sensorsd/upd.sh %x.%t%n 
  BatteryPresent %2 %s
  hw.sensors.upd0.indicator4:high=0:command=/etc/sensorsd/upd.sh %x.%t%n 
  ShutdownImminent %2 %s
  hw.sensors.upd0.percent0:low=25:command=/etc/sensorsd/upd.sh %x.%t%n 
  FullChargeCapacity %2 %s
  hw.sensors.upd0.percent1:low=25:command=/etc/sensorsd/upd.sh %x.%t%n 
  RemainingCapacity %2 %s

 It's a bit of a hack, but for the normally on sensors like ACPresent you 
 can use :low=1:high=2

 http://www.undeadly.org/cgi?action=articlesid=20140320093943pid=1

Thanks for the suggestion! I tried that just now for the ACPresent
sensor and changed the corresponding rule to

hw.sensors.upd0.indicator2:low=1:high=2:command=/etc/sensorsd/upd.sh %x.%t%n 
ACPresent %2 %s

Upon starting sensorsd (with '-c 1'), I got the following messages:

sensorsd[23468]: upd0.indicator2: exceeds limits: On is below On
sensorsd[23468]: upd0.indicator3: exceeds limits: On is below On
UPD: upd0.indicator3 BatteryPresent On OK 
UPD: upd0.indicator2 ACPresent On OK 
UPD: upd0.percent0 FullChargeCapacity 100.00% OK 
UPD: upd0.indicator0 Charging On OK 
UPD: upd0.indicator4 ShutdownImminent Off OK 
UPD: upd0.indicator1 Discharging Off OK 
UPD: upd0.percent1 RemainingCapacity 88.00% OK

Then, I removed the power and waited for almost two minutes, but no
further messages appeared and no apparent reaction from sensorsd was
visible.

To be certain, I also tried the other way round, i.e. I restarted
sensorsd while the power was still removed:

sensorsd[24532]: upd0.indicator2: exceeds limits: Off is below On 
sensorsd[24532]: upd0.indicator3: exceeds limits: On is below On
UPD: upd0.indicator0 Charging Off OK 
UPD: upd0.indicator4 ShutdownImminent Off OK 
UPD: upd0.indicator3 BatteryPresent On OK 
UPD: upd0.indicator2 ACPresent Off OK 
UPD: upd0.indicator1 Discharging On OK 
UPD: upd0.percent1 RemainingCapacity 79.00% OK 
UPD: upd0.percent0 FullChargeCapacity 100.00% OK

Then, I re-applied power, but that, too, was never flagged by sensorsd.
For some reason, it looks like sensorsd only ever detects a status
change (for these rules) when it gets started - but not afterwards.

Regards,

Thomas
-- 
-
 Thomas Ribbrockhttp://www.ribbrock.org/ 
   You have to live on the edge of reality - to make your dreams come true!

Re: APC UPS sensorsd - how?

[Stuart Henderson]

On 2015-03-22, T. Ribbrock emga...@gmx.net wrote:
 What I cannot seem to get to work is that sensorsd *reacts* to these
 changes. Based on the examples in the thread mentioned above, I've
 created a small script /etc/sensorsd/upd.sh that looks as follows:

 # cat /etc/sensorsd/upd.sh 
 echo ${@} | logger -t UPD

 I have then created the following sensorsd.conf:
 hw.sensors.upd0.indicator0:high=0:command=/etc/sensorsd/upd.sh %x.%t%n 
 Charging %2 %s
 hw.sensors.upd0.indicator1:high=0:command=/etc/sensorsd/upd.sh %x.%t%n 
 Discharging %2 %s
 hw.sensors.upd0.indicator2:low=1:command=/etc/sensorsd/upd.sh %x.%t%n 
 ACPresent %2 %s
 hw.sensors.upd0.indicator3:low=1:command=/etc/sensorsd/upd.sh %x.%t%n 
 BatteryPresent %2 %s
 hw.sensors.upd0.indicator4:high=0:command=/etc/sensorsd/upd.sh %x.%t%n 
 ShutdownImminent %2 %s
 hw.sensors.upd0.percent0:low=25:command=/etc/sensorsd/upd.sh %x.%t%n 
 FullChargeCapacity %2 %s
 hw.sensors.upd0.percent1:low=25:command=/etc/sensorsd/upd.sh %x.%t%n 
 RemainingCapacity %2 %s

It's a bit of a hack, but for the normally on sensors like ACPresent you can 
use :low=1:high=2

http://www.undeadly.org/cgi?action=articlesid=20140320093943pid=1

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
# hw.sensors.upd0.percent0:low=10:high=100:command

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
   hw.sensors.upd0

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

sensorsd, upd, and state changes

[Joe Gidi]

Hi all,

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.

Thanks,

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

You cannot buy skill. -- Ross Seyfried

Shutdown on low battery with sensorsd

[Laurence Rochfort]

Hello,

I'm trying to use sensorsd to shutdown my Thinkpad T410 laptop when
the battery reaches the low capacity level. However, when I add the
line shown below to sensorsd.conf the laptop always shutdown within a
couple of minutes of booting regardless of the current battery level
or if running on AC power.

The line I added to sensorsd.conf is:

hw.sensors.acpibat0.amphour3:low=0.02Ah:command=/sbin/shutdown -hp now

The sysctl output for my battery is:

hw.sensors.acpibat0.volt0=10.80 VDC (voltage)
hw.sensors.acpibat0.volt1=11.17 VDC (current voltage)
hw.sensors.acpibat0.current0=0.99 A (rate)
hw.sensors.acpibat0.amphour0=4.93 Ah (last full capacity)
hw.sensors.acpibat0.amphour1=0.25 Ah (warning capacity)
hw.sensors.acpibat0.amphour2=0.02 Ah (low capacity)
hw.sensors.acpibat0.amphour3=0.27 Ah (remaining capacity), OK
hw.sensors.acpibat0.raw0=2 (battery charging), OK
hw.sensors.acpiac0.indicator0=On (power supply)

Any suggestions as to what I'm doing wrong?

Regards,
Laurence.

Re: Shutdown on low battery with sensorsd

[Laurence Rochfort]

A fellow subscriber noticed that I didn't have a space between 0.02 and Ah.

Changing the sensorsd.conf line to the following makes everything work:

hw.sensors.acpibat0.amphour3:low=0.02 Ah:command=/sbin/shutdown -hp now

Regards,
Laurence.

On 19 January 2014 18:34, Laurence Rochfort laurence.rochf...@gmail.com wrote:
 Hello,

 I'm trying to use sensorsd to shutdown my Thinkpad T410 laptop when
 the battery reaches the low capacity level. However, when I add the
 line shown below to sensorsd.conf the laptop always shutdown within a
 couple of minutes of booting regardless of the current battery level
 or if running on AC power.

 The line I added to sensorsd.conf is:

 hw.sensors.acpibat0.amphour3:low=0.02Ah:command=/sbin/shutdown -hp now

 The sysctl output for my battery is:

 hw.sensors.acpibat0.volt0=10.80 VDC (voltage)
 hw.sensors.acpibat0.volt1=11.17 VDC (current voltage)
 hw.sensors.acpibat0.current0=0.99 A (rate)
 hw.sensors.acpibat0.amphour0=4.93 Ah (last full capacity)
 hw.sensors.acpibat0.amphour1=0.25 Ah (warning capacity)
 hw.sensors.acpibat0.amphour2=0.02 Ah (low capacity)
 hw.sensors.acpibat0.amphour3=0.27 Ah (remaining capacity), OK
 hw.sensors.acpibat0.raw0=2 (battery charging), OK
 hw.sensors.acpiac0.indicator0=On (power supply)

 Any suggestions as to what I'm doing wrong?

 Regards,
 Laurence.

Re: Shutdown on low battery with sensorsd

[Sergey Bronnikov]

Delay can be due to a limitations of sensorsd(8):

CAVEATS
 Certain sensors may flip status from time to time.  To guard against
 false reports, sensorsd implements a state dumping mechanism.  However,
 this inevitably introduces an additional delay in status reporting and
 command execution, e.g. one may notice that sensorsd makes its initial
 report about the state of monitored sensors not immediately, but about 60
 seconds after it is started.
Sergey Bronnikov


On Sun, Jan 19, 2014 at 10:34 PM, Laurence Rochfort
laurence.rochf...@gmail.com wrote:
 Hello,

 I'm trying to use sensorsd to shutdown my Thinkpad T410 laptop when
 the battery reaches the low capacity level. However, when I add the
 line shown below to sensorsd.conf the laptop always shutdown within a
 couple of minutes of booting regardless of the current battery level
 or if running on AC power.

 The line I added to sensorsd.conf is:

 hw.sensors.acpibat0.amphour3:low=0.02Ah:command=/sbin/shutdown -hp now

 The sysctl output for my battery is:

 hw.sensors.acpibat0.volt0=10.80 VDC (voltage)
 hw.sensors.acpibat0.volt1=11.17 VDC (current voltage)
 hw.sensors.acpibat0.current0=0.99 A (rate)
 hw.sensors.acpibat0.amphour0=4.93 Ah (last full capacity)
 hw.sensors.acpibat0.amphour1=0.25 Ah (warning capacity)
 hw.sensors.acpibat0.amphour2=0.02 Ah (low capacity)
 hw.sensors.acpibat0.amphour3=0.27 Ah (remaining capacity), OK
 hw.sensors.acpibat0.raw0=2 (battery charging), OK
 hw.sensors.acpiac0.indicator0=On (power supply)

 Any suggestions as to what I'm doing wrong?

 Regards,
 Laurence.

Temperature script for sensorsd(8)

[Robert Connolly]

Hello.

I'm not a proficient shell script writer, so I would like advice
and criticism for my sensorsd(8) temperature script.

In particular, I would like the above email to root to include helpful
information that would help explain why the temperature went to critical.
Anything else that I may be missing would be nice to know too, including
scripting style.

 $ cat /etc/sensorsd/temp.sh
#!/bin/sh

case $1 in
below)
# Normal operation.
apm -A
;;
within)
# We hit the warning threshold. Step down the CPU.
apm -L
# Write the warning to syslog, so we know why the CPU was stepped
down.
logger -t $0 Reached warning temperature. Stepping down CPU.
# Tell root.
echo Stepping down CPU due to high temperature | mail -s $0
root@`hostname`
# Tell users:
echo Stepping down CPU due to high temperature | wall
;;
above)
# Mail message for root, with hopefully helpful information.
message=
The system was shut down due to excessive temperature.
The system hardware may need maintenance.

System information:
`date`
`uptime`
`who -u`

`sysctl hw.sensors`
`sysctl hw.cpuspeed`
`sysctl hw.setperf`

`ps auxw`

# Mail root.
echo $message | mail -s $0 root@`hostname`
# Halt and power down.
shutdown -h -p now Reached critical temperature. Halting system
from $0
;;
esac

Re: acpiac(4) manual page and sensorsd(8)

[Jason McIntyre]

On Sat, Jun 16, 2012 at 10:24:02PM -0700, Robert Connolly wrote:
 Hello.
 
 The acpiac(4) man page mentions that the AC power source status can be
 monitored by sensorsd(8), but sensorsd(8) does not monitor this sensor as
 far as I know. apmd(8) does however.
 
 Could the acpiac(4) man page be reworded to reflect this?
 
 Thanks
 

hi. i asked mark kettenis about this. his reply:

This is incorrect.  The acpiac(4) driver provides a sensor
that can be monitored by sensorsd(8).

Now apmd(8) monitors the power status as well, but this is
not done through the sensors framework.

so it appears acpiac(4) is correct.

jmc

acpiac(4) manual page and sensorsd(8)

[Robert Connolly]

Hello.

The acpiac(4) man page mentions that the AC power source status can be
monitored by sensorsd(8), but sensorsd(8) does not monitor this sensor as
far as I know. apmd(8) does however.

Could the acpiac(4) man page be reworded to reflect this?

Thanks

sensorsd config tokens

[Robert Connolly]

Hello.

I have some problems with the tokens used in sensorsd.conf.

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
hw.sensors.acpitz0.temp0:high=75C:command=/etc/sensorsd/cpu-temp.sh %l %x
%t %2 %3 %4

And /etc/sensorsd/cpu-temp.sh:
#!/bin/sh
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin

# Adapted from
http://blas.phemo.us/2006/11/12/setting-up-system-vitals-monitoring-on-openbsd
# Posted by Tres 12/11/2006 at 01h41

notify=root@`hostname`

sensor_limits=$1
sensor_xname=$2
sensor_type=$3
sensor_value=$4
sensor_low_limit=$5
sensor_high_limit=$6

mailNotification() {

message=

This is an automatic message sent because sensorsd found the system
temperature is
high. The system will be shut down immedietly.

Sensor xname: $sensor_xname
Sensor type: $sensor_type
Sensor value: $sensor_value
Sensor low limit: $sensor_low_limit
Sensor high limit: $sensor_high_limit


echo $message | mail -s System shut down due to critical CPU
temperature $notify

}

if [ $sensor_limits = above ]
then
mailNotification
fi

And the output from mail:
Sensor xname: km0
Sensor type: temp
Sensor value: 56.50
Sensor low limit: degC
Sensor high limit: 9223372036581.62

And so the problem is the sensor low and high limits are wrong. Everything
else works fine.

Just to complicate things, if I use:
hw.sensors.km0.temp0:high=51C:command=/etc/sensorsd/cpu-temp.sh %l %x %t %2
%4 %3
... reversing the positions of the %3 and %4, then $sensor_low_limit (%3)
reports 51.00, which is the expected value of %4, and $sensor_high_limit
(%4) remains degC. I have no idea what 9223372036581.62 is.

Thanks

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: 4.8 sensorsd blind spot, failure to trigger command on any state changes after initialisation

[mark hellewell]

On 14 November 2010 20:06, Constantine A. Murenin muren...@gmail.comwrote:

 indicator is not a smart sensor  doesn't have a state like OK  so
 it's never monitored automatically; i think you'd have to specify low
 and high values for it or something like that.

 You can also use a shell script for watthour3 thing, where you can
 manually run sysctl and see what the value of the indicator is, then
 decide whether to shutdown or not.  Also, specifying an extra low
 value will get you the extra command execution if you need one.


Ah; thanks for your reply!  I think I was expecting the wrong thing from
sensorsd -- thanks for shedding light on what's going on.  I'll use a shell
script command on watthour3 to check the other vals through sysctl directly,
as you suggest.

I wish that hw.sensors.acpibat0.raw0 changed state from OK to something else
when it was discharging. I wonder why this isn't the case: CHARGING,
DISCHARGING, IDLE would be great additions I think.  Maybe it's done the way
it is for good reason.

Mark

C.

4.8 sensorsd blind spot, failure to trigger command on any state changes after initialisation

[mark hellewell]

Hi,

I'm configuring sensorsd to conditionally shutdown -- based on Wh of charge
left in laptop battery and whether or not the computer is plugged in -- and
it seems that sensorsd might have a bit of a blind spot when it comes my
available sensors.  After reporting the initial states, no more state change
events seem to be picked up by sensorsd (I'm definitely waiting long enough
for them).

A call to `sysctl` clearly reflects some changes, yet they are not picked up
by sensorsd.  Odd?!  Am I alone?  For one sensor in particular
(acpiac0.indicator0) I don't even get the initial state notification.

Is it that sensorsd is looking for something other than an OK from these
sensors, in order to trigger a change event?


Initial values are reported as expected in /var/log/daemon:

Nov 14 12:41:45 ace sensorsd[26828]: startup, system has 10 sensors
Nov 14 12:42:45 ace sensorsd[27276]: acpibat0.watthour3: 2.71 Wh, OK
Nov 14 12:42:45 ace sensorsd[27276]: acpibat0.raw0: 2, OK
Nov 14 12:42:45 ace sensorsd[27276]: cpu0.temp0: within limits: 36.00 degC


Output of `sysctl hw.sensors` when plugged:

hw.sensors.acpibat0.volt0=11.10 VDC (voltage)
hw.sensors.acpibat0.volt1=12.38 VDC (current voltage)
hw.sensors.acpibat0.watthour0=3.34 Wh (last full capacity)
hw.sensors.acpibat0.watthour1=0.30 Wh (warning capacity)
hw.sensors.acpibat0.watthour2=0.13 Wh (low capacity)
hw.sensors.acpibat0.watthour3=2.37 Wh (remaining capacity), OK
hw.sensors.acpibat0.raw0=2 (battery charging), OK
hw.sensors.acpibat0.raw1=64433 (rate)
hw.sensors.acpiac0.indicator0=On (power supply)
hw.sensors.cpu0.temp0=36.00 degC


Output of `sysctl hw.sensors` when unplugged, running on battery:

hw.sensors.acpibat0.volt0=11.10 VDC (voltage)
hw.sensors.acpibat0.volt1=12.38 VDC (current voltage)
hw.sensors.acpibat0.watthour0=3.34 Wh (last full capacity)
hw.sensors.acpibat0.watthour1=0.30 Wh (warning capacity)
hw.sensors.acpibat0.watthour2=0.13 Wh (low capacity)
hw.sensors.acpibat0.watthour3=2.37 Wh (remaining capacity), OK
hw.sensors.acpibat0.raw0=1 (battery discharging), OK
hw.sensors.acpibat0.raw1=824 (rate)
hw.sensors.acpiac0.indicator0=Off (power supply)
hw.sensors.cpu0.temp0=36.00 degC


My sensorsd.conf:

# $OpenBSD: sensorsd.conf,v 1.8 2007/08/14 19:02:02 cnst Exp $

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

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

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

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

# CPU temperature (degrees Celsius)
#hw.sensors.lm0.temp1:high=60C

# CPU fan (RPM)
#hw.sensors.lm0.fan1:low=3000

# ignore certain indicators on ipmi(4)
#hw.sensors.ipmi0.indicator1:istatus

# Warn if any temperature sensor is over 70 degC.
# This entry will match only those temperature sensors
# that don't have their own entry.
temp:high=70C

# no emails after the first
hw.sensors.acpibat0.watthour3:command=echo l %l n %n s %s x %x t %t 2 %2 3
%3 4 %4 | mail mch
hw.sensors.acpibat0.raw0:command=echo l %l n %n s %s x %x t %t 2 %2 3 %3 4
%4 | mail mch
# don't even get initial state on this one
hw.sensors.acpiac0.indicator0:command=echo l %l n %n s %s x %x t %t 2 %2 3
%3 4 %4 | mail mch

# By default, sensorsd(8) reports status changes of all sensors that
# keep their state. Uncomment the following lines if you want to
# suppress reports about status changes of specific sensor types.

#temp:istatus
#fan:istatus
#volt:istatus
#acvolt:istatus
#resistance:istatus
#power:istatus
#current:istatus
#watthour:istatus
#amphour:istatus
#indicator:istatus
#raw:istatus
#percentage:istatus
#illuminance:istatus
#drive:istatus
#timedelta:istatus


dmesg:

OpenBSD 4.8 (GENERIC.MP) #359: Mon Aug 16 09:16:26 MDT 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
RTC BIOS diagnostic error 80clock_battery
cpu0: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (GenuineIntel 686-class) 1.60
GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE
real mem  = 523292672 (499MB)
avail mem = 504750080 (481MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 10/06/08, SMBIOS rev. 2.4 @ 0xe8eb0
(31 entries)
bios0: vendor Acer version v0.3310 date 10/06/2008
bios0: Acer AOA110
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT HPET APIC MCFG ASF! SLIC BOOT
acpi0: wakeup devices P32_(S4) UHC1(S3) UHC2(S3) UHC3(S3) UHC4(S3) ECHI(S3)
EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) AZAL(S0) MODM(S0)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 133MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (GenuineIntel 686-class) 1.60
GHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX

Re: 4.8 sensorsd blind spot, failure to trigger command on any state changes after initialisation

[mark hellewell]

On 14 November 2010 13:03, mark hellewell mark.hellew...@gmail.com wrote:

 Hi,

 I'm configuring sensorsd to conditionally shutdown -- based on Wh of charge
 left in laptop battery and whether or not the computer is plugged in -- and
 it seems that sensorsd might have a bit of a blind spot when it comes my
 available sensors.  After reporting the initial states, no more state change
 events seem to be picked up by sensorsd (I'm definitely waiting long enough
 for them).


An update to this:  I drained my battery and eventually the state of
hw.sensors.acpibat0.watthour3 flips to 0.09 Wh, CRITICAL -- and triggers a
sensorsd command -- which I can work with in a pinch to shutdown the
machine.  Without the state of the power supply (acpiac0.indicator0) or
battery state (acpibat0.raw0), however, I can't tell sensorsd not to
shutdown again when I plug it in and boot up.

Cheers,
Mark

Bad behavior of sensorsd on laptop

[Tomas Bodzar]

Hi all,

I set sensorsd and sensorsd.conf this way :

# $OpenBSD: sensorsd.conf,v 1.8 2007/08/14 19:02:02 cnst Exp $

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

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

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

# Monitor laptop battery for remaining capacity
hw.sensors.acpibat0.watthour3:low=1.40Wh:command=/etc/sensorsd/switchoff

# Chipset temperature (degrees Celsius)
#hw.sensors.lm0.temp0:high=50C
hw.sensors.acpitz0.temp0:high=60C:command=/etc/sensorsd/switchoff
hw.sensors.acpitz1.temp0:high=60C:command=/etc/sensorsd/switchoff

# CPU temperature (degrees Celsius)
#hw.sensors.lm0.temp1:high=60C
hw.sensors.cpu0.temp0:high=65C:command=/etc/sensorsd/switchoff

# CPU fan (RPM)
#hw.sensors.lm0.fan1:low=3000
hw.sensors.acpithinkpad0.fan0:low=2500:command=/etc/sensorsd/switchoff

# ignore certain indicators on ipmi(4)
#hw.sensors.ipmi0.indicator1:istatus

# Warn if any temperature sensor is over 70 degC.
# This entry will match only those temperature sensors
# that don't have their own entry.
#temp:high=70C


# By default, sensorsd(8) reports status changes of all sensors that
# keep their state. Uncomment the following lines if you want to
# suppress reports about status changes of specific sensor types.

#temp:istatus
#fan:istatus
#volt:istatus
#acvolt:istatus
#resistance:istatus
#power:istatus
#current:istatus
#watthour:istatus
#amphour:istatus
#indicator:istatus
#raw:istatus
#percentage:istatus
#illuminance:istatus
#drive:istatus
#timedelta:istatus

Command is simple :

#!/bin/sh
shutdown -h now Shutdown caused by sensor

It's running from point of view that computer is turned off in case of
low battery or high battery on some of sensor which has command
assigned. Problem starts if your battery is empy and computer turned
off. So you plug AC and start laptop. If you are below limit for
hw.sensors.acpibat0.watthour3 then your laptop is turned off after
login again. It's quite understandable, but if you're above limit
behavior is still same. Is it problem this part from man page for
sensorsd.conf?

 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.

Battery status trough this sensor is changing because battery was
empty and now laptop is in AC and charging. Does it really mean that
it will turn off my computer after every change of battery status
untill my battery is fully recharged?

OpenBSD 4.7-beta (GENERIC.MP) #423: Tue Feb 23 12:24:22 MST 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM)2 Duo CPU L7300 @ 1.40GHz (GenuineIntel
686-class) 1.40 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,xTPR
real mem  = 2657374208 (2534MB)
avail mem = 2574045184 (2454MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 07/02/07, BIOS32 rev. 0 @
0xfdc80, SMBIOS rev. 2.4 @ 0xe0010 (63 entries)
bios0: vendor LENOVO version 7NET25WW (1.06 ) date 07/02/2007
bios0: LENOVO 766927G
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT ASF!
SSDT SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) DURT(S3) IGBE(S4) EXP0(S4)
EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB1(S3)
USB2(S3) USB3(S3) USB4(S3) EHC0(S3) EHC1(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 199MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU L7300 @ 1.40GHz (GenuineIntel
686-class) 1.40 GHz
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,xTPR
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus -1 (EXP2)
acpiprt5 at acpi0: bus -1 (EXP3)
acpiprt6 at acpi0: bus -1 (EXP4)
acpiprt7 at acpi0: bus 5 (PCI1)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpipwrres0 at acpi0: PUBS
acpitz0 at acpi0: critical temperature 127 degC
acpitz1 at acpi0: critical temperature 99 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model 42T5247 serial   505 type LION oem SANYO
acpibat1 at acpi0: BAT1 not present
acpibat2 at acpi0: BAT2 not present
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK not docked (0)
bios0: ROM list: 0xc/0x1! 0xd/0x1000 0xd1000/0x1000 0xe/0x1!
cpu0: Enhanced SpeedStep 1397 MHz

Re: Bad behavior of sensorsd on laptop

[Joachim Schipper]

On Sat, Mar 06, 2010 at 02:26:28PM +0100, Tomas Bodzar wrote:
 Hi all,
 
 I set sensorsd and sensorsd.conf this way :
 
 # $OpenBSD: sensorsd.conf,v 1.8 2007/08/14 19:02:02 cnst Exp $

 # Monitor laptop battery for remaining capacity
 hw.sensors.acpibat0.watthour3:low=1.40Wh:command=/etc/sensorsd/switchoff

 Command is simple :
 
 #!/bin/sh
 shutdown -h now Shutdown caused by sensor
 
 It's running from point of view that computer is turned off in case of
 low battery or high battery on some of sensor which has command
 assigned. Problem starts if your battery is empy and computer turned
 off. So you plug AC and start laptop. If you are below limit for
 hw.sensors.acpibat0.watthour3 then your laptop is turned off after
 login again. It's quite understandable, but if you're above limit
 behavior is still same. Is it problem this part from man page for
 sensorsd.conf?
 
  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.
 
 Battery status trough this sensor is changing because battery was
 empty and now laptop is in AC and charging. Does it really mean that
 it will turn off my computer after every change of battery status
 untill my battery is fully recharged?

Yes. Write a better script to fix this. Some ideas: if the CPU gets hot,
switch to low speed (apm -L) instead of turning the machine off; if the
battery is low, check if you're connected to wall power before turning
off; etc.

Joachim

Re: Bad behavior of sensorsd on laptop

[Tomas Bodzar]

Thx. I will prepare some more complicated creatures :-)

On Sat, Mar 6, 2010 at 5:09 PM, Joachim Schipper
joac...@joachimschipper.nl wrote:
 On Sat, Mar 06, 2010 at 02:26:28PM +0100, Tomas Bodzar wrote:
 Hi all,

 I set sensorsd and sensorsd.conf this way :

 # $OpenBSD: sensorsd.conf,v 1.8 2007/08/14 19:02:02 cnst Exp $

 # Monitor laptop battery for remaining capacity
 hw.sensors.acpibat0.watthour3:low=1.40Wh:command=/etc/sensorsd/switchoff

 Command is simple :

 #!/bin/sh
 shutdown -h now Shutdown caused by sensor

 It's running from point of view that computer is turned off in case of
 low battery or high battery on some of sensor which has command
 assigned. Problem starts if your battery is empy and computer turned
 off. So you plug AC and start laptop. If you are below limit for
 hw.sensors.acpibat0.watthour3 then your laptop is turned off after
 login again. It's quite understandable, but if you're above limit
 behavior is still same. Is it problem this part from man page for
 sensorsd.conf?

 B If the limits are crossed or if the status provided by the driver
 B  B  B changes, sensorsd(8)'s alert functionality is triggered and a
command, if
 B  B  B specified, is executed.

 Battery status trough this sensor is changing because battery was
 empty and now laptop is in AC and charging. Does it really mean that
 it will turn off my computer after every change of battery status
 untill my battery is fully recharged?

 Yes. Write a better script to fix this. Some ideas: if the CPU gets hot,
 switch to low speed (apm -L) instead of turning the machine off; if the
 battery is low, check if you're connected to wall power before turning
 off; etc.

 B  B  B  B  B  B  B  B Joachim

Re: Bad behavior of sensorsd on laptop

[Constantine A. Murenin]

On 6 March 2010 08:26, Tomas Bodzar tomas.bod...@gmail.com wrote:
 Hi all,

 I set sensorsd and sensorsd.conf this way :

 # $OpenBSD: sensorsd.conf,v 1.8 2007/08/14 19:02:02 cnst Exp $

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

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

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

 # Monitor laptop battery for remaining capacity
 hw.sensors.acpibat0.watthour3:low=1.40Wh:command=/etc/sensorsd/switchoff

 # Chipset temperature (degrees Celsius)
 #hw.sensors.lm0.temp0:high=50C
 hw.sensors.acpitz0.temp0:high=60C:command=/etc/sensorsd/switchoff
 hw.sensors.acpitz1.temp0:high=60C:command=/etc/sensorsd/switchoff

 # CPU temperature (degrees Celsius)
 #hw.sensors.lm0.temp1:high=60C
 hw.sensors.cpu0.temp0:high=65C:command=/etc/sensorsd/switchoff

 # CPU fan (RPM)
 #hw.sensors.lm0.fan1:low=3000
 hw.sensors.acpithinkpad0.fan0:low=2500:command=/etc/sensorsd/switchoff

 # ignore certain indicators on ipmi(4)
 #hw.sensors.ipmi0.indicator1:istatus

 # Warn if any temperature sensor is over 70 degC.
 # This entry will match only those temperature sensors
 # that don't have their own entry.
 #temp:high=70C


 # By default, sensorsd(8) reports status changes of all sensors that
 # keep their state. Uncomment the following lines if you want to
 # suppress reports about status changes of specific sensor types.

 #temp:istatus
 #fan:istatus
 #volt:istatus
 #acvolt:istatus
 #resistance:istatus
 #power:istatus
 #current:istatus
 #watthour:istatus
 #amphour:istatus
 #indicator:istatus
 #raw:istatus
 #percentage:istatus
 #illuminance:istatus
 #drive:istatus
 #timedelta:istatus

 Command is simple :

 #!/bin/sh
 shutdown -h now Shutdown caused by sensor

 It's running from point of view that computer is turned off in case of
 low battery or high battery on some of sensor which has command
 assigned. Problem starts if your battery is empy and computer turned
 off. So you plug AC and start laptop. If you are below limit for
 hw.sensors.acpibat0.watthour3 then your laptop is turned off after
 login again. It's quite understandable, but if you're above limit
 behavior is still same. Is it problem this part from man page for
 sensorsd.conf?

  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.

 Battery status trough this sensor is changing because battery was
 empty and now laptop is in AC and charging. Does it really mean that
 it will turn off my computer after every change of battery status
 untill my battery is fully recharged?


core:constant {6432} man sensorsd.conf | fgrep -C5 shutdown
CAVEATS
 Alert functionality is triggered every time there is a change in sensor
 state; for example, when sensorsd(8) is started, the status of each
moni-
 tored sensor changes from undefined to whatever it is.  One must keep
 this in mind when using commands that may unconditionally perform
adverse
 actions (e.g. shutdown(8)), as they will be executed even when all sen-
 sors perform to specification.  If this is undesirable, then a wrapper
 shell script should be used instead.

OpenBSD 4.6 March 15, 2008
2
core:constant {6433}


Try using the %l token in your scripts for conditional shutdown.

C.

Sensorsd

[Morris, Roy]

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

I put this in my /etc/sensorsd.conf
hw.disknames:command=/etc/sendalert %t %n %2
hw.diskcount:command=/etc/sendalert %t %n %2
hw.sensors.cpu0.temp0:high=60C:command=/etc/sendalert %t %n %2
hw.sensors.mpi0.drive0:command=/etc/sendalert %t %n %2

After firing up sensorsd I check the log file and see it says it only
sees two ? Will it only work if the word 'sensors' exists?

Jan  6 09:17:22 dc-fw1 sensorsd[12648]: startup, system has 2 sensors
Jan  6 09:18:22 dc-fw1 sensorsd[23326]: cpu0.temp0: within limits: 34.00
degC
Jan  6 09:18:22 dc-fw1 sensorsd[23326]: mpi0.drive0: online, OK

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
___

sensorsd strange tokens values

[Federico Giannici]

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?


Thanks.

--
___
__
   |-  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.

Sensorsd behavior

[João Salvatti]

Hi Misc,

I put the following line in my sensorsd.conf file:

hw.sensors.acpibat0.raw0:command=/etc/sensorsd/bat_status %2

When the battery's laptop status change, bat_status program is
executed using param %2 (sensor's value can be: 0 when battery is
idle, 1 when battery is discharging and 2 when battery is charging),
but the problem is: sensorsd only runs program bat_status when it is
started!

EG: If my power cord is plugged on my laptop sensorsd execute
bat_status, but when I remove my power cord the sensorsd doesn't run
bat_status again. Is this a normal behavior?

bat_status.c:

#include stdio.h
#include syslog.h
#include stdarg.h

int
main(int argc, char *argv[])
{
int bat_status = atoi(argv[1]);

if (bat_status == 0)
syslog(LOG_WARNING, Battery is now idle.\n);
else if (bat_status == 1)
syslog(LOG_WARNING, Battery is now
discharging...\n);
else
syslog(LOG_WARNING, Battery is now charging...\n);

return 0;
}

Thanks in advance.

--
Joco Salvatti
Graduated in Computer Science
Federal University of Para - UFPA - Brazil
E-Mail: salva...@gmail.com

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

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

[Per-Olov Sjöholm]

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


A dmesg follows below my autosignature

Thanks in advance
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


OpenBSD 4.0-stable (GENERIC) #0: Fri May 25 21:07:24 CEST 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) 4 CPU 2.80GHz (GenuineIntel 686-class) 2.81 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16
real mem  = 536182784 (523616K)
avail mem = 481148928 (469872K)
using 4256 buffers containing 26910720 bytes (26280K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 08/22/06, BIOS32 rev. 0 @ 0xffe90,
SMBIOS rev. 2.3 @ 0xfa3d0 (48 entries)
bios0: Dell Computer Corporation PowerEdge 830
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfb900/208 (11 entries)
pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82801GB LPC rev 0x00)
pcibios0: PCI bus #8 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0x1000 0xc9000/0x1600 0xca800/0x2600
0xec000/0x4000!
ipmi0 at mainbus0: version 1.5 interface KCS iobase 0xca8/8 spacing 4
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 Intel E7230 MCH rev 0x00
ppb0 at pci0 dev 1 function 0 Intel E7230 PCIE rev 0x00
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 Intel 41210 PCIE-PCIX rev 0x09
pci2 at ppb1 bus 2
em0 at pci2 dev 4 function 0 Intel PRO/1000MT (82546GB) rev 0x03: irq 3,
address 00:0e:0c:72:4b:a2
em1 at pci2 dev 4 function 1 Intel PRO/1000MT (82546GB) rev 0x03: irq 11,
address 00:0e:0c:72:4b:a3
ppb2 at pci1 dev 0 function 2 Intel 41210 PCIE-PCIX rev 0x09
pci3 at ppb2 bus 3
ppb3 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x01
pci4 at ppb3 bus 4
ppb4 at pci4 dev 0 function 0 Intel PCIE-PCIE rev 0x09
pci5 at ppb4 bus 5
ami0 at pci5 dev 2 function 0 Symbios Logic MegaRAID rev 0x01: irq 10
ami0: LSI 523, 32b, FW 713R, BIOS vG121, 64MB RAM
ami0: 1 channels, 0 FC loops, 1 logical drives
scsibus0 at ami0: 40 targets
sd0 at scsibus0 targ 0 lun 0: AMI, Host drive #00,  SCSI2 0/direct fixed
sd0: 476935MB, 476935 cyl, 64 head, 32 sec, 512 bytes/sec, 976762880 sec
total
scsibus1 at ami0: 16 targets
ppb5 at pci0 dev 28 function 4 Intel 82801G PCIE rev 0x01
pci6 at ppb5 bus 6
bge0 at pci6 dev 0 function 0 Broadcom BCM5721 rev 0x11, BCM5750 B1
(0x4101): irq 3, address 00:12:3f:2a:3e:b8
brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
ppb6 at pci0 dev 28 function 5 Intel 82801G PCIE rev 0x01
pci7 at ppb6 bus 7
uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x01: irq 11
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x01: irq 10
usb1 at uhci1: USB revision 1.0
uhub1 at usb1
uhub1: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x01: irq 5
usb2 at uhci2: USB revision 1.0
uhub2 at usb2
uhub2: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x01: irq 11
usb3 at ehci0: USB revision 2.0
uhub3 at usb3
uhub3: Intel EHCI root hub, rev 2.00/1.00, addr 1
uhub3: 6 ports with 6 removable, self powered
ppb7 at pci0 dev 30 function 0 Intel 82801BA AGP rev 0xe1
pci8 at ppb7 bus 8
vga1 at pci8 dev 5 function 0 XGI Technology Volari Z7 rev 0x00
wsdisplay0 at vga1 mux 1

sensorsd shutting computer down

[Steven]

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


OpenBSD 4.1-current (GENERIC) #178: Fri May 25 03:22:20 MDT 2007
   [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: AMD Athlon(tm) processor (AuthenticAMD 686-class, 256KB L2 cache) 1.20 
GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
real mem  = 804810752 (767MB)
avail mem = 726335488 (692MB)
using 4278 buffers containing 40366080 bytes (39420K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+ BIOS, date 07/13/01, BIOS32 rev. 0 @ 0xfb5d0, SMBIOS 
rev. 2.2 @ 0xf0800 (38 entries)
bios0: Gigabyte Technology Co., LTD 7DXR
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 70102 dobusy 1 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xf/0xde74
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfddb0/192 (10 entries)
pcibios0: PCI Exclusive IRQs: 5 7 10 11
pcibios0: PCI Interrupt Router at 000:07:0 (VIA VT82C596A ISA rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0x8000 0xcc000/0x4000! 0xd/0x4000
acpi0 at mainbus0: rev 0
acpi0: tables DSDT FACP 
acpitimer at acpi0 not configured

acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu at acpi0 not configured
acpibtn at acpi0 not configured
acpibtn at acpi0 not configured
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 AMD 761 PCI rev 0x13
ppb0 at pci0 dev 1 function 0 AMD 761 PCI-PCI rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 5 function 0 ATI Mach64 GM rev 0x27
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 7 function 0 VIA VT82C686 ISA rev 0x40
pciide0 at pci0 dev 7 function 1 VIA VT82C571 IDE rev 0x06: ATA100, channel 0 
configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0: Maxtor 6Y080L0
wd0: 16-sector PIO, LBA, 78167MB, 160086528 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: ASUS, CD-S500/A, 1.2C SCSI0 5/cdrom removable
atapiscsi1 at pciide0 channel 1 drive 1
scsibus1 at atapiscsi1: 2 targets
cd1 at scsibus1 targ 0 lun 0: BENQ, CDRW 5232X, KPBY SCSI0 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
cd1(pciide0:1:1): using PIO mode 4, Ultra-DMA mode 2
uhci0 at pci0 dev 7 function 2 VIA VT83C572 USB rev 0x1a: irq 11
uhci1 at pci0 dev 7 function 3 VIA VT83C572 USB rev 0x1a: irq 11
viaenv0 at pci0 dev 7 function 4 VIA VT82C686 SMBus rev 0x40: failed to map 
PM I/O space
dc0 at pci0 dev 10 function 0 ADMtek AN983 rev 0x11: irq 5, address 
00:10:a7:26:1d:3c
ukphy0 at dc0 phy 1: Generic IEEE 802.3u media interface, rev. 1: OUI 0x000749, 
model 0x0001
rl0 at pci0 dev 12 function 0 D-Link Systems 530TX+ rev 0x10: irq 10, address 
00:50:ba:59:24:c3
rlphy0 at rl0 phy 0: RTL internal PHY
eap0 at pci0 dev 14 function 0 Ensoniq CT5880 rev 0x03: irq 5
ac97: codec id 0x83847608 (SigmaTel STAC9708/11)
ac97: codec features 18 bit DAC, 18 bit ADC, SigmaTel 3D
audio0 at eap0
midi0 at eap0: AudioPCI MIDI UART
uhci2 at pci0 dev 15 function 0 VIA VT83C572 USB rev 0x50: irq 11
uhci3 at pci0 dev 15 function 1 VIA VT83C572 USB rev 0x50: irq 10
ehci0 at pci0 dev 15 function 2 VIA VT6202 USB rev 0x51: irq 7
usb0 at ehci0: USB revision 2.0
uhub0 at usb0
uhub0: VIA EHCI root hub, rev 2.00/1.00, addr 1
uhub0: 4 ports with 4 removable, self powered
pciide1 at pci0 dev 16 function 0 Promise PDC20265 rev 0x02: DMA, channel 0 
configured to native-PCI, channel 1 configured to native-PCI
pciide1: using irq 11 for native-PCI interrupt
pciide1: channel 0 disabled (no drives)
pciide1: channel 1 disabled (no drives)
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot

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.

sensorsd

[djgoku]

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?

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: -current sensorsd doesn't work for me

[Constantine A. Murenin]

On 12/01/07, andrew fresh [EMAIL PROTECTED] wrote:

I am trying to shut down my laptop using the voltage sensors.
Unfortunatly I can't test this with a generic kernel because all my
sensors on my only -current box come from the ACPI subsystem.

The problem is, the limits don't seems to work:

$ sysctl hw.sensors.acpibat0.volt1
hw.sensors.acpibat0.volt1=7.96 VDC (current voltage), OK
$ tail -3 /etc/sensorsd.conf
hw.sensors.acpibat0.volt1:low=8V:high=9V


sensorsd.conf(5) says 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.


However, volt0 and volt1 on acpibat never change status from an OK,
so they will never be triggered in sensorsd, which may or may not be
desirable behaviour.

The following patch will allow you to set high and low values for
volt0 and volt1 on acpibat in sensorsd:

Index: dev/acpi/acpibat.c
===
RCS file: /cvs/src/sys/dev/acpi/acpibat.c,v
retrieving revision 1.37
diff -u -d -p -8 -r1.37 acpibat.c
--- dev/acpi/acpibat.c  2006/12/26 23:58:08 1.37
+++ dev/acpi/acpibat.c  2006/12/31 18:53:01
@@ -128,17 +128,16 @@ acpibat_monitor(struct acpibat_softc *sc
sizeof(sc-sc_sens[2].desc));
sc-sc_sens[2].type = type;
sensor_attach(sc-sc_sensdev, sc-sc_sens[2]);
sc-sc_sens[2].value = sc-sc_bif.bif_low * 1000;

strlcpy(sc-sc_sens[3].desc, voltage, sizeof(sc-sc_sens[3].desc));
sc-sc_sens[3].type = SENSOR_VOLTS_DC;
sensor_attach(sc-sc_sensdev, sc-sc_sens[3]);
-   sc-sc_sens[3].status = SENSOR_S_OK;
sc-sc_sens[3].value = sc-sc_bif.bif_voltage * 1000;

strlcpy(sc-sc_sens[4].desc, battery unknown,
sizeof(sc-sc_sens[4].desc));
sc-sc_sens[4].type = SENSOR_INTEGER;
sensor_attach(sc-sc_sensdev, sc-sc_sens[4]);
sc-sc_sens[4].status = SENSOR_S_UNKNOWN;
sc-sc_sens[4].value = sc-sc_bst.bst_state;
@@ -153,17 +152,16 @@ acpibat_monitor(struct acpibat_softc *sc
sc-sc_sens[6].type = type;
sensor_attach(sc-sc_sensdev, sc-sc_sens[6]);
sc-sc_sens[6].value = sc-sc_bst.bst_capacity * 1000;

strlcpy(sc-sc_sens[7].desc, current voltage,
sizeof(sc-sc_sens[7].desc));
sc-sc_sens[7].type = SENSOR_VOLTS_DC;
sensor_attach(sc-sc_sensdev, sc-sc_sens[7]);
-   sc-sc_sens[7].status = SENSOR_S_OK;
sc-sc_sens[7].value = sc-sc_bst.bst_voltage * 1000;

sensordev_install(sc-sc_sensdev);
}

void
acpibat_refresh(void *arg)
{

Re: -current sensorsd doesn't work for me

[andrew fresh]

I am CC'ing tech@ not because I like to crosspost, but because I believe
this to be the end of a conversation on misc@ and the start of a
discussion on tech@ about hopefully getting this changed.

On Sat, Jan 13, 2007 at 10:11:24AM -0500, Constantine A. Murenin wrote:
 On 12/01/07, andrew fresh [EMAIL PROTECTED] wrote:
 I am trying to shut down my laptop using the voltage sensors.
 Unfortunatly I can't test this with a generic kernel because all my
 sensors on my only -current box come from the ACPI subsystem.
 
 The problem is, the limits don't seems to work:
 
 $ sysctl hw.sensors.acpibat0.volt1
 hw.sensors.acpibat0.volt1=7.96 VDC (current voltage), OK
 $ tail -3 /etc/sensorsd.conf
 hw.sensors.acpibat0.volt1:low=8V:high=9V

no matter what I set, sensorsd always says within limits.

 sensorsd.conf(5) says [that's how it is supposed to work]
 
 The following patch will allow you to set high and low values for
 volt0 and volt1 on acpibat in sensorsd:

I think would prefer this patch, or something like it, just in case I
want to override the choices someone made for other sensors.

I believe this diff adds useful functionality without losing anything.
However, I am NOT a C programmer, so I may have screwed something up.

Index: sensorsd.c
===
RCS file: /cvs/src/usr.sbin/sensorsd/sensorsd.c,v
retrieving revision 1.27
diff -u -r1.27 sensorsd.c
--- sensorsd.c  6 Jan 2007 18:17:06 -   1.27
+++ sensorsd.c  13 Jan 2007 18:15:12 -
@@ -218,7 +218,9 @@
 * status had failed so warn about it */
if (newstatus == SENSOR_S_UNKNOWN)
newstatus = SENSOR_S_WARN;
-   else if (newstatus == SENSOR_S_UNSPEC) {
+   else if (newstatus == SENSOR_S_UNSPEC ||
+   limit-upper != LLONG_MAX  ||
+   limit-lower != LLONG_MIN) {
if (sensor.value  limit-upper ||
sensor.value  limit-lower)
newstatus = SENSOR_S_CRIT;
Index: sensorsd.conf.5
===
RCS file: /cvs/src/usr.sbin/sensorsd/sensorsd.conf.5,v
retrieving revision 1.10
diff -u -r1.10 sensorsd.conf.5
--- sensorsd.conf.5 28 Dec 2006 10:04:27 -  1.10
+++ sensorsd.conf.5 13 Jan 2007 18:15:12 -
@@ -58,8 +58,8 @@
 .Xr esm 4 ,
 or
 .Xr ipmi 4 )
-do not require boundary values specified (that otherwise will be
-ignored) and simply trigger on status transitions.
+do not require boundary values specified and simply trigger on status
+transitions unless you specify either boundry.
 .Pp
 The command is executed on transitions out of, and back into, given limits.
 Tokens in the command are substituted as follows:
===

l8rZ,
-- 
andrew - ICQ# 253198 - JID: [EMAIL PROTECTED]

BOFH excuse of the day: (l)user error

-current sensorsd doesn't work for me

[andrew fresh]

I am trying to shut down my laptop using the voltage sensors.
Unfortunatly I can't test this with a generic kernel because all my
sensors on my only -current box come from the ACPI subsystem.

The problem is, the limits don't seems to work:

$ sysctl hw.sensors.acpibat0.volt1
hw.sensors.acpibat0.volt1=7.96 VDC (current voltage), OK
$ tail -3 /etc/sensorsd.conf
hw.sensors.acpibat0.volt1:low=8V:high=9V
#:command=/etc/sensorsd/shutdown %2 %3

$ sudo sensorsd -d
^C
$ tail -1 /var/log/messages
Jan 12 18:25:24 trin sensorsd[15369]: hw.sensors.acpibat0.volt1: within limits, 
value: 7.96 V DC
$

I think that should trip the low limit.

I changed it to low=5V:high=9V and it works as expected.  The log says
it is within limits.

But, if I change the entry in sensorsd.conf to low=5V:high=6V (should
trip the high limit) it still claims the sensors are within limits.

Am I doing something stupid?


The diff for the acpi kernel

--- GENERIC Fri Jan  5 18:54:24 2007
+++ ACPIThu Jan 11 21:20:37 2007
@@ -57,19 +57,19 @@
 eisa0  at mainbus0
 pci*   at mainbus0
 
-#optionACPIVERBOSE
-#optionACPI_ENABLE
+option ACPIVERBOSE
+option ACPI_ENABLE
 
-acpi0  at mainbus? disable
-#acpitimer*at acpi?
-#acpihpet* at acpi?
-#acpiac*   at acpi?
-#acpibat*  at acpi?
-#acpibtn*  at acpi?
-#acpicpu*  at acpi?
-acpiec*at acpi?disable
+acpi0  at mainbus?
+acpitimer* at acpi?
+acpihpet*  at acpi?
+acpiac*at acpi?
+acpibat*   at acpi?
+acpibtn*   at acpi?
+acpicpu*   at acpi?
+acpiec*at acpi?
 acpiprt*   at acpi?
-#acpitz*   at acpi?
+acpitz*at acpi?
 
 option PCIVERBOSE
 option EISAVERBOSE

and my DMESG

OpenBSD 4.0-current (ACPI) #1: Thu Jan 11 21:42:30 MST 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/ACPI
cpu0: Intel(R) Pentium(R) M processor 1.30GHz (GenuineIntel 686-class) 1.30 
GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,SBF,EST,TM2
real mem  = 1063415808 (1038492K)
avail mem = 961875968 (939332K)
using 4256 buffers containing 53293056 bytes (52044K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(d8) BIOS, date 12/01/05, BIOS32 rev. 0 @ 0xfd6a0, 
SMBIOS rev. 2.3 @ 0xd8010 (17 entries)
bios0: Sony Corporation VGN-TX770P
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 30102 dobusy 0 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xfd6a0/0x960
pcibios0: PCI BIOS has 17 Interrupt Routing table entries
pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82801FBM LPC rev 0x00)
pcibios0: PCI bus #7 is the last bus
bios0: ROM list: 0xc/0x1! 0xd8000/0x4000! 0xdc000/0x4000!
acpi0 at mainbus0: rev 0
acpi0: tables DSDT FACP APIC BOOT MCFG SSDT SSDT SSDT SSDT 
acpitimer0 at acpi0: can't identify bus
acpi device at acpi0 from table DSDT not configured
acpi device at acpi0 from table FACP not configured
acpi device at acpi0 from table APIC not configured
acpi device at acpi0 from table BOOT not configured
acpi device at acpi0 from table MCFG not configured
acpi device at acpi0 from table SSDT not configured
acpi device at acpi0 from table SSDT not configured
acpi device at acpi0 from table SSDT not configured
acpi device at acpi0 from table SSDT not configured
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 0 (PEGP)
acpiprt2 at acpi0: bus 6 (PCIB)
acpiec0 at acpi0: EC0_
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: PWRB
acpibat0 at acpi0: BAT1: model:  serial:  type: LION oem: Sony Corp.
acpiac0 at acpi0: AC unit online
acpicpu0 at acpi0: CPU0: 1300, 1000, 800, 600 MHz
acpitz0 at acpi0, critical temperature: 99 degC
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 Intel 82915GM/PM/GMS Host rev 0x03
vga1 at pci0 dev 2 function 0 Intel 82915GM/GMS Video rev 0x03: aperture at 
0xb008, size 0x1000
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
Intel 82915GM/GMS Video rev 0x03 at pci0 dev 2 function 1 not configured
azalia0 at pci0 dev 27 function 0 Intel 82801FB HD Audio rev 0x03: irq 10
azalia0: host: High Definition Audio rev. 1.0
azalia0: codec: Realtek ALC260 (rev. 3.0), HDA version 1.0
azalia0: codec: 0x04x/0x14f1 (rev. 0.0), HDA version 0.9
azalia0: codec[1]: No support for modem function groups
azalia0: codec[1]: No audio function groups
audio0 at azalia0
uhci0 at pci0 dev 29 function 0 Intel 82801FB USB rev 0x03: irq 10
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1 at pci0 dev 29 function 1 Intel 82801FB USB rev 0x03: irq 10
usb1 at uhci1: USB revision 1.0
uhub1 at usb1
uhub1: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2

sensorsd bug on macppc

[Antoine Jacoutot]

Hi.

I have sensorsd running on a 4.0-current macppc.
It always worked fine and when min/max values of a sensor are 
reached, a mail is sent to me.
Recently, a problem happened: each time I start the sensorsd daemon 
(either on boot up or manually), I get the following warning mail:

28.00 degC (high=60.01 degC)

Strange since I only set up high value for this one, and not low.

# extract from /etc/sensorsd.conf
hw.sensors.7:high=60C:\
 :command=echo %2 \(high=%4\) \
 | mail -s [`hostname`] sensorsd WARNING \(CPU Temp.\) root

For info:
$ sysctl hw
hw.machine=macppc
hw.model=7447A (Revision 0x101)
hw.ncpu=1
hw.byteorder=4321
hw.physmem=536870912
hw.usermem=535818240
hw.pagesize=4096
hw.disknames=cd0,wd0
hw.diskcount=2
hw.sensors.0=adt0, +2.5Vin, 1.45 V DC
hw.sensors.1=adt0, Vccp, 0.00 V DC
hw.sensors.2=adt0, Vcc, 3.32 V DC
hw.sensors.3=adt0, +5V, 0.00 V DC
hw.sensors.4=adt0, +12V, 0.00 V DC
hw.sensors.5=adt0, Remote1 Temp, 43.00 degC
hw.sensors.6=adt0, Internal Temp, 43.00 degC
hw.sensors.7=adt0, Remote2 Temp, 44.00 degC
hw.cpuspeed=1499
hw.product=PowerBook5,5

OpenBSD 4.0 (GENERIC) #1056: Sat Sep 16 21:21:14 MDT 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/macppc/compile/GENERIC
real mem = 536870912 (524288K)
avail mem = 482914304 (471596K)
using 1254 buffers containing 26841088 bytes (26212K) of memory
mainbus0 (root): model PowerBook5,5
cpu0 at mainbus0: 7447A (Revision 0x101): 1499 MHz: 512KB L2 cache
memc0 at mainbus0: uni-n
hw-clock at memc0 not configured
ki2c0 at memc0 offset 0xf8001000
iic0 at ki2c0
adt0 at iic0 addr 0xae: adt7460 rev 0x6a
lmu-controller at iic0 addr 0x42 not configured
mpcpcibr0 at mainbus0 pci: uni-north, Revision 0xff
pci0 at mpcpcibr0 bus 0
pchb0 at pci0 dev 11 function 0 Apple UniNorth AGP rev 0x00
vgafb0 at pci0 dev 16 function 0 ATI Radeon Mobility M10 NP rev 0x00, 
mmio

wsdisplay0 at vgafb0 mux 1: console (std, vt100 emulation)
mpcpcibr1 at mainbus0 pci: uni-north, Revision 0x5
pci1 at mpcpcibr1 bus 0
pchb1 at pci1 dev 11 function 0 Apple UniNorth PCI rev 0x00
Broadcom BCM4306 rev 0x03 at pci1 dev 18 function 0 not configured
cbb0 at pci1 dev 19 function 0 TI PCI1510 CardBus rev 0x00: irq 53
macobio0 at pci1 dev 23 function 0 Apple Intrepid rev 0x00
openpic0 at macobio0 offset 0x4: version 0x4614
macgpio0 at macobio0 offset 0x50
macgpio1 at macgpio0 offset 0x9 irq 47
programmer-switch at macgpio0 offset 0x11 not configured
cpu-vcore-select at macgpio0 offset 0x6b not configured
gpio4 at macgpio0 offset 0x1e not configured
gpio5 at macgpio0 offset 0x6f not configured
gpio6 at macgpio0 offset 0x70 not configured
extint-gpio4 at macgpio0 offset 0x5c not configured
gpio11 at macgpio0 offset 0x75 not configured
extint-gpio15 at macgpio0 offset 0x67 not configured
escc-legacy at macobio0 offset 0x12000 not configured
zsc0 at macobio0 offset 0x13000: irq 22,23
zstty0 at zsc0 channel 0
zstty1 at zsc0 channel 1
snapper0 at macobio0 offset 0x1: irq 30,1,2
timer at macobio0 offset 0x15000 not configured
adb0 at macobio0 offset 0x16000 irq 25: via-pmu, 3 targets
akbd0 at adb0 addr 2: iBook keyboard with inverted T (ISO layout)
wskbd0 at akbd0: console keyboard, using wsdisplay0
ams0 at adb0 addr 3: EMP trackpad tpad 4-button, 400 dpi
wsmouse0 at ams0 mux 0
abtn0 at adb0 addr 7: brightness/volume/eject buttons
apm0 at adb0: battery flags 0x5, 61% charged
pi2c0 at adb0
iic1 at pi2c0
battery at macobio0 offset 0x0 not configured
backlight at macobio0 offset 0xf300 not configured
ki2c1 at macobio0 offset 0x18000
iic2 at ki2c1
wdc0 at macobio0 offset 0x2 irq 24: DMA
atapiscsi0 at wdc0 channel 0 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: MATSHITA, DVD-R UJ-825, DAND SCSI0 5/cdrom 
removable

cd0(wdc0:0:0): using BIOS timings, DMA mode 2
audio0 at snapper0
ohci0 at pci1 dev 24 function 0 Apple Intrepid USB rev 0x00: irq 0, 
version 1.0, legacy support

usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: Apple OHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ohci1 at pci1 dev 25 function 0 Apple Intrepid USB rev 0x00: irq 0, 
version 1.0, legacy support

usb1 at ohci1: USB revision 1.0
uhub1 at usb1
uhub1: Apple OHCI root hub, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
ohci2 at pci1 dev 26 function 0 Apple Intrepid USB rev 0x00: irq 29, 
version 1.0, legacy support

usb2 at ohci2: USB revision 1.0
uhub2 at usb2
uhub2: Apple OHCI root hub, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
ohci3 at pci1 dev 27 function 0 NEC USB rev 0x43: irq 63, version 1.0
usb3 at ohci3: USB revision 1.0
uhub3 at usb3
uhub3: NEC OHCI root hub, rev 1.00/1.00, addr 1
uhub3: 3 ports with 3 removable, self powered
ohci4 at pci1 dev 27 function 1 NEC USB rev 0x43: irq 63, version 1.0
usb4 at ohci4: USB revision 1.0
uhub4 at usb4
uhub4: NEC OHCI root hub, rev 1.00/1.00, addr 1
uhub4: 2 ports with 2 removable, self powered
ehci0 at pci1 dev 27 function 2 NEC USB rev 0x04: irq 63
usb5 at ehci0

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

sensorsd

[Gustavo Rios]

Hey folks,

I am running a Dell Precision Workstation, is it possible to have
sensors working with such hardware? Any special consideration?

Thanks in advance.

sensorsd configuration

[Daniel A. Ramaley]

Hello. I have not used sensorsd on OpenBSD before, but am trying to 
learn. I have read sensorsd(8) and sensorsd.conf(5) from OpenBSD 3.9 
and the configuration looks very simple. However, i have a couple quick 
questions:

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?

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?


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

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: (3.9beta/i386) sensorsd can not start?

[Moritz Jodeit]

On Mon, Jan 30, 2006 at 12:57:24PM +0800, John Wong wrote:
 after upgrade to 3.9beta/i386, sensorsd can not start
 when i start the sensorsd, it show the error message
 
 shell$: /usr/sbin/sensorsd
 sensorsd: sysctl: No such file or directory

Just fixed that in -current. Thanks for the report.

Moritz

Re: (3.9beta/i386) sensorsd can not start?

[viq]

On Monday 30 January 2006 05:57, John Wong wrote:
 after upgrade to 3.9beta/i386, sensorsd can not start
 when i start the sensorsd, it show the error message

 shell$: /usr/sbin/sensorsd
 sensorsd: sysctl: No such file or directory

I see the same behaviour on snapshot from Jan 24, i386.

-- 
viq

--
Katowice 'ground zero' - najnowsze informacje
 http://link.interia.pl/f18f8

(3.9beta/i386) sensorsd can not start?

[John Wong]

after upgrade to 3.9beta/i386, sensorsd can not start
when i start the sensorsd, it show the error message

shell$: /usr/sbin/sensorsd
sensorsd: sysctl: No such file or directory

what file or directory should i need?

shell$: cat /etc/sensorsd.conf

hw.sensors.0:low=4000
hw.sensors.12:high=55C
hw.sensors.13:high=55C
hw.sensors.14:high=80C


shell$: sysctl hw.sensors
---
hw.sensors.0=it0, Fan1, fanrpm, 4821 RPM
hw.sensors.3=it0, VCORE_A, volts_dc, 1.57 V
hw.sensors.4=it0, VCORE_B, volts_dc, 2.50 V
hw.sensors.5=it0, +3.3V, volts_dc, 3.31 V
hw.sensors.6=it0, +5V, volts_dc, 5.13 V
hw.sensors.7=it0, +12V, volts_dc, 12.10 V
hw.sensors.8=it0, Unused, volts_dc, -1.06 V
hw.sensors.9=it0, -12V, volts_dc, -9.99 V
hw.sensors.10=it0, +5VSB, volts_dc, 2.71 V
hw.sensors.11=it0, VBAT, volts_dc, 0.00 V
hw.sensors.12=it0, Temp1, temp, 33.00 degC / 91.40 degF
hw.sensors.13=it0, Temp2, temp, 33.00 degC / 91.40 degF
hw.sensors.14=it0, Temp3, temp, 58.00 degC / 136.40 degF
OpenBSD 3.9-beta (GENERIC) #0: Sun Jan 29 18:06:40 HKT 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: AMD Sempron(tm) 2200+ (AuthenticAMD 686-class, 256KB L2 cache)
1.50 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
cpu0: AMD Powernow: TS
real mem  = 234401792 (228908K)
avail mem = 206909440 (202060K)
using 2886 buffers containing 11821056 bytes (11544K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(be) BIOS, date 08/04/04, BIOS32 rev. 0 @
0xfa300
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 70102 dobusy 1 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xf/0xc6c4
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfc620/160 (8 entries)
pcibios0: PCI Exclusive IRQs: 5 10 11 12
pcibios0: PCI Interrupt Router at 000:17:0 (VIA VT82C596A ISA rev
0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0x7e00
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 VIA VT8378 PCI rev 0x00
ppb0 at pci0 dev 1 function 0 VIA VT8377 PCI-PCI rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 VIA VT8378 VGA rev 0x01: aperture at
0xd800, size 0x1000
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
rl0 at pci0 dev 10 function 0 Realtek 8139 rev 0x10: irq 10, address
00:50:fc:99:64:6c
rlphy0 at rl0 phy 0: RTL internal phy
uhci0 at pci0 dev 16 function 0 VIA VT83C572 USB rev 0x80: irq 11
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: VIA UHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1 at pci0 dev 16 function 1 VIA VT83C572 USB rev 0x80: irq 5
usb1 at uhci1: USB revision 1.0
uhub1 at usb1
uhub1: VIA UHCI root hub, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2 at pci0 dev 16 function 2 VIA VT83C572 USB rev 0x80: irq 10
usb2 at uhci2: USB revision 1.0
uhub2 at usb2
uhub2: VIA UHCI root hub, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
ehci0 at pci0 dev 16 function 3 VIA VT6202 USB rev 0x82: irq 12
usb3 at ehci0: USB revision 2.0
uhub3 at usb3
uhub3: VIA EHCI root hub, rev 2.00/1.00, addr 1
uhub3: 6 ports with 6 removable, self powered
viapm0 at pci0 dev 17 function 0 VIA VT8235 ISA rev 0x00
iic0 at viapm0
pciide0 at pci0 dev 17 function 1 VIA VT82C571 IDE rev 0x06: ATA133,
channel 0 configured to compatibility, channel 1 configured to
compatibility
wd0 at pciide0 channel 0 drive 0: FUJITSU MPE3102AT
wd0: 16-sector PIO, LBA, 9772MB, 20014235 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4
wd1 at pciide0 channel 1 drive 0: Maxtor 6Y080L0
wd1: 16-sector PIO, LBA, 78167MB, 160086528 sectors
wd1(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 6
auvia0 at pci0 dev 17 function 5 VIA VT8233 AC97 rev 0x50: irq 10
ac97: codec id 0x56494170 (VIA Technologies 70)
ac97: codec features headphone, 18 bit DAC, 18 bit ADC, KS Waves 3D
audio0 at auvia0
vr0 at pci0 dev 18 function 0 VIA RhineII-2 rev 0x74: irq 11, address
00:0f:ea:1a:02:74
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 10: OUI
0x0a, model 0x4063
isa0 at mainbus0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
midi0 at pcppi0: PC speaker
spkr0 at pcppi0
sysbeep0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
it0 at isa0 port 0x290/8: IT87
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
biomask ff6d netmask ff6d ttymask ffef
pctr: user-level cycle counter enabled
mtrr: Pentium Pro MTRR support
dkcsum: wd0 matches BIOS drive 0x80
dkcsum: wd1 matches BIOS drive 0x81
root on wd0a
rootdev=0x0 rrootdev=0x300 rawdev=0x302
wsdisplay0: screen 1 deleted
wsdisplay0: screen

sensorsd and mail alert

[Antoine Jacoutot]

Hi...

One quick stupid question. I'm looking for a way to get a mail when 
sensorsd logs something to syslog. Is there an easy way to do this ?


For instance, today sensorsd reported the following :
Aug 27 15:27:21 mcp sensorsd[6314]: failure for hw.sensors.0: 
46.40C/115.52F not within limits


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


Thanks in advance.
Regards,

Antoine

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