I see two possibilitys but is is clearly idea without research to that problem. Status is propeties of object. OID read by zenperfsnmp daemon and store value in rrd database, also it compare obtained value with threshhold if its provaded. Now only Min/Max threshold availabel. First idea is write threshold which analyse snmp data and change apropriate properties of object.  Or you can write new snmp daemon.

But second problem how change properties, directly take object or use event.

Using snmp get actualy very expensive. How frecuently status is changes? One or two times per day? Maybe right way is use trap.

Few words about traps. You not need track you data base for restore information about status after reboot, insted you should run modeling.  Information details depend of soft on you device. For example Cisco router can send all condition of BGP which it can accept (6 passible condition - 6 traps).

Anyway if you deside polling metod, i think right metod will be use treshold which will parsing recived snmp date and will generate event for  change status of object.

Can i ask you for which component you wish to now status (which goal you try to solve)?

IComponentInfo concerned to UI (display status) but this status on modeling moment (by default 24 hours). General guestion of this topic  is how track port status changes in real time. Right?

From nilie last post i see second problem, how to split User Port (which status can frequently changes) and UP-Link (which very important). First what come in mind

use Description filed with predetermined word (for example UP-Link-myisp, UP-Link-backbone), parse this field...

to dpetzel yes event not right way. I review minmaxthreshold and see it passible get object and directly change status.

I start my own zenpack with familiar goal. It can take one week, it will depend on my free time. I can share my experience.

components status control in Zenoss is a little bit tricky.

The getStatus method of the DeviceComponent class returned number of events with highest severity. Ths value will be converted to string

by getStatusString method of the same class. By default, this method returned 'Up' string if no events exist, or number of events will be returned.

So, as we can see Zenoss components status is not the same thing as components status value returned by most management software.

The main problem with Zenoss components status concept is that Zenoss doesn't provide simple way to get current (last known) status (raw value) of component.

The detailed components status is only available within events in Event Manager and can not be used in components grid view or in components Details view.

So, if we want to implement components status control, the following questions must be answered.

Q1. Where current status value must be stored?

Possible variants:

      1. additional components attribute (zodb)

      2. events database (MySQL)

Q2. How to update status value?

Possible variants:

      1. RRDDataPoint->Thershold->Transform->components attribute

      2. Event->Transform->components attribute

      3. AttrDataPoint(new datapoint type)->components attribute

      4. modify Event Manager to store last components status value in events database.

Q3. How to get status value?

Possible variants:

      1. from components attribute

      2. from Event Manager (components status from last event record)

Q4. How to manage severity (dot color)?

Possible variants:

      1. by displaying components status, calculate dots color based on status-severity map without event generation.

      2. generate event with severity based on status-severity map.

PS: In my case i've answered all questions with '1' (1,1,1,1).

Egor