Bill,
> I offer an opinion as an outside observer. As Gail suggests, the HRMIB
> hrPrinterDetectedErrorState is a bit map that allows the two
> conditions, toner low and off-line to be flagged. Off-line is the
> condition that prompts the hrDeviceStatus = down. When the user puts
> the device on-line, low toner remains, but device status is no longer
> down.
>> This reflects what is happening very well. I don't see why we want to
> monkey with it.
>> My own feeling is that, in the case where a toner low prompts an off
> line, the Alert table should have two alerts; one for low toner and
> another for off-line. The idea of a condition that changes from
> critical to warning is aesthetically displeasing. I guess you could
> have two sequential events..toner low unacknowledged, which was
> critical and toner low acknowledged which was a warning (and which
> terminated the former). But I think we are making things more
> complicated than necessary.
Perhaps you missed the recent (and intense) thread about this topic.
The consensus (not unanimous, but a majority opinion) is to maintain
this position:
If a condition results in a critical alert, then the alert entry should
describe the exact nature of the condition. Furthermore, two or more
alerts should not be added to the Alert Table for the same, singular
condition.
That is to say, if a printer goes offline due to a low toner condition,
then only a single alert should be added to the table; this single alert
should be tagged as "critical" and have an alert code corresponding to
"low toner". The HR MIB variables should be:
prtDeviceStatus = down(5)
prtPrinterStatus = other(1)
prtPrinterDetectedErrorState = lowToner(2) and offline(5)
The fact that the printer goes offline is a side effect of the low toner
condition.
...jay