I have already attempted using ipmi_sensor_get_states(). It is not finding any states at all (please re-read the initial message, second paragraph). Ipmitool finds states for these sensors so something is not quite right. These sensors are in fact OEM; is there a different set of state functions that I need to use for OEM?
Thanks again, Jen -----Original Message----- From: Corey Minyard [mailto:[EMAIL PROTECTED] Sent: Thursday, July 26, 2007 5:16 PM To: Vanderputten, Jennifer Cc: [email protected] Subject: Re: [Openipmi-developer] Discrete sensor states 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/openipmi-developer
