See the function read_sensor_states() in cmdlang/cmd_sensor.c. It gets
a reading and iterates through it. You really shouldn't be directly
using ipmi_get_reading_name(), you should use
ipmi_sensor_reading_name_string(). If there are OEM plugins that modify
these values, they may not exactly match up with
ipmi_get_reading_name(), or may have values that are OEM-specific.
You need to use ipmi_sensor_get_states() to get the current state
values. ipmi_sensor_get_event_enables() tells you if a specific sensor
is enabled to send an event when the specific offset changes. And being
both set, you will get an event if either bit changes :-).
-corey
[EMAIL PROTECTED] wrote:
> I am currently using OpenIPMI to discover sensors and get their current
> readings. So far I have been successful in implementing for threshold sensors
> and for discrete sensors of type "sensor-specific". However, for the other
> discrete sensors, I noticed that ipmitool can see additional information that
> I am not seeing. For example:
>
> SMI Timeout | 85h | ok | 7.1 | State Deasserted
>
> I can see that this description ("state deasserted") is equivalent to the
> descriptions found in OpenIPMI's event_reading_states array, which is
> acquired by ipmi_get_reading_name(). However, I do not seem to understand how
> one acquires the necessary offset. I have tried using the state event
> mechanisms (ipmi_sensor_get_event_enables(), where the callback function does
> a two-nested loop through direction and offsets), but this does not seem to
> yield up what I'm looking for. Again, given the above example,
> ipmi_is_discrete_event_set() tells me that event offset 1 is set for both
> asserted and deasserted. That offset maps to "State asserted", which is
> incorrect. I should be finding event offset 0 to be set in order to map to
> the correct description via ipmi_get_reading_name(). Is this a bug or am I
> simply not doing this correctly?
>
> I have also attempted using ipmi_sensor_get_states() and ipmi_is_state_set(),
> but those functions only seem to work for discrete sensors of type
> "sensor-specific". For the other discrete sensors, ipmi_is_state_set() always
> indicates that there are no states set at all. Thus I assumed that these
> functions are only used for sensor-specific types.
>
> --Jen
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Openipmi-developer mailing list
> Openipmi-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openipmi-developer
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
