FM 3.2.0 - Changes to how HP devices are scanned

Some HP models may report all zeros or all 100% levels for toner when the device is in sleep mode, jammed or has it's covers open.  Prior to FM 3.2.0 these false readings could potentially cause spurious toner alerts and spurious toner change events, complicating the business of administering supplies for these devices.

As of FM 3.2.0 however changes were made in the scan processing engine to minimize the potential impact of these behaviors. As of FM 3.2.0 the scan engine now:

1) Checks if the scan is for an HP device.

2) Is the device reporting sleep mode, jammed or cover open

3) Are toner being reported as all 0? All 100? Or all Unknown?

In the case where all three of the above are true, FM considers this data to represent a bad scan.

When FM determines that a scan is bad, instead of writing the bad values to the database, and potentially raise spurious alert events, FM will load the last good scan, and use the values from that. In other words, when a bad scan is detected, FM will default to the "last known good scan" to prevent spurious alert triggering.

There are a couple of things to be aware of:

1) Sleep mode, jammed and covers open are three conditions we've positively pinpointed as being states which can cause a bad scan.  There may be others.  If we become aware of other machine states which can cause a bad scan, those states will be added to the list of conditions to evaluate.

2) "Last known good scans" can only be defaulted to when a good scan has been received.  This would only be a consideration for a new device, which would have no scans to fall back to.  Ensuring that an HP device's first scan doesn't coincide with the device being in any of the states listed above will prevent this, and receipt of a single good scan will give FM a value to fall back on going forward. From that point good scans should vastly outnumber bad scans, ensuring FM has reasonably current data to fall back on.

3) It is possible that a scan would be marked bad erroneously.  However this would be an exceedingly rare event, and it will correct very quickly. In this rare case an event might not be raised that should have, but this was considered to be an improvement over the alternative, lots of cases where alerts would be raised incorrectly as would have occurred prior to 3.2.0.

How did we do with this article?

Infinite Device Management