Asset tracking and component replacement

Keep identity, installation and placement separate

An asset is the continuing inventory record for an item. An installation observation says that a particular part was seen in a particular host or bay. Placement records where the organization says the asset belongs. These facts can disagree without meaning that the asset should be deleted.

A switch address identifies a place to read, not permanent hardware identity. A serial number, a trustworthy hardware address, the component's attachment and its model evidence help Cenovel decide whether a reading describes an existing item. A reported name by itself is not enough to prove that two devices are the same.

Before relying on automatic updates

• Enroll the network equipment and place it in the correct site and closet. Configure an active credential and management-network coverage that permits the required read.
• Review model and manufacturer records. Duplicate serials and ambiguous model names can prevent automatic matching even when the device answers.
• Confirm that the device reports the relevant hardware inventory. A successful login does not prove that every component command or table was read completely.
• Use an account with the permissions required for the inventory and monitoring actions. An observation does not grant the person viewing it permission to edit the asset.

Review a component change

1. Open the equipment and inspect its latest device reading, including whether the component inventory was complete.
2. Open the observed component and its linked asset. Compare its serial, model, manufacturer and attachment with the part that was installed.
3. Check whether Cenovel matched an existing asset, created a new one, retained weaker evidence for review, or reported a conflict.
4. For a replacement, review both the new installation and the old asset. Record the old item's actual destination through the appropriate inventory, repair or disposal workflow.
5. If the result is unexpected, retain the reading and inspect its time and completeness before changing inventory records to make them agree.

What the next supported hardware read can do

Scroll the table sideways to read all columns.

When readers report different levels of detail

A switch-level observation can confirm the same serial-numbered part without identifying the stack member that holds it. When the recorded member still belongs to that switch and its serial still matches the live host asset, Cenovel retains the more specific member installation. The switch-level reading keeps its own source and time; it does not refresh the older member-specific timestamp.

Fresh evidence from a different switch can supersede the former installation. A deleted host or a member whose serial no longer matches its asset does not receive this protection. Inspect the collection times and attachment details when the readers disagree; a broad observation alone does not prove a new member or bay.

Parts without serial numbers

A part without a serial may still be recorded by a stable, supported bay when it has a linked host asset and a resolvable model. That is a bay-based record, not proof of a globally unique physical item. Without sufficient attachment context, the part remains an observation rather than an individually identified asset.

This distinction matters when moving a serialless fan between two switches: the two bay observations alone do not prove that it is the same physical fan. Do not merge inventory items solely because their descriptions match.

Manufacturer and model rules

Cenovel considers reported part numbers and manufacturer evidence when selecting a catalog model. A compatible transceiver is not automatically manufactured by the switch vendor. Transceivers are excluded from switch-vendor inheritance; explicitly third-party components are also protected from that assumption.

For other components, the host model's manufacturer can supply a fallback only when the part reports no manufacturer, is not a transceiver, and is not explicitly third-party. A reported manufacturer that cannot be resolved is not replaced by the host vendor.

Following an asset to another address or site

Tracking is off by default. An administrator with Monitoring edit permission can configure it. In observation-only mode, Cenovel can record evidence of a possible move without transferring monitoring. Automatic transfer requires active tracking at the site, a unique supported asset and monitoring subject, current evidence, a serial-confirmed SSH or SNMP identity read, and unambiguous site-network coverage. SSH needs the device's host key to be trusted at the new address; Cenovel carries trust over by itself only when the device presents the same key that was trusted at its previous address. SNMP requires authenticated, approved engine identity.

A hardware-address match can help identify a candidate, but it does not by itself authorize automatic monitoring transfer. Shared stack addresses require review. Conflicting identities, overlapping site networks, deleted assets, unavailable credentials and an address outside the intended site can also prevent transfer.

A possible address or site move waits for a second matching identity read at least two minutes later. The pending evidence window follows the shared polling interval: two intervals plus one minute for scheduling delays. At the five-minute setting, that window is eleven minutes. A newly received observation must still be fresh and newer than the previously accepted observation; repeating the same reading does not confirm a move. This also applies when equipment has a recorded address but no active tracking binding. Conflicting answering addresses keep the move for review.

Background tracking follows the shared polling interval and stops starting new reads when automatic polling is disabled. Fallback scans search the configured networks in bounded batches. A long queue can delay a device beyond the confirmation window, so the interval alone does not establish complete coverage.

Storage placement and removal are different workflows

A serial-confirmed observation at a site can move an eligible, uniquely matched asset from storage to that site and change its status to Deployed. Assigned or otherwise ineligible assets are not treated as available storage stock. This action records an audit event; check the resulting placement rather than assuming every location disagreement is corrected automatically.

Removing network equipment is a deliberate user action with its own confirmation and linked-asset effects. A component disappearing from discovery is not that deletion workflow. Inspect the confirmation before deleting equipment, and do not infer that connected neighboring devices should be removed with it.

Example: replacing a transceiver

Suppose serial A is installed in a switch port. A later supported read reports serial B in that same attachment. If B uniquely matches inventory, that asset becomes the current installation; otherwise Cenovel may create it after resolving the model. A remains an asset with its previous installation history. You still need to record whether A went into storage, repair or disposal.

If the later read instead reports a blank serial, Cenovel retains A's established identity and explains that the read did not confirm every installed part. If the inventory command failed, an empty result alone does not establish that A was physically removed.

If A was deliberately deleted from inventory, a partial read of an unrelated part must not make A appear again. When a later read actually reports A, its physical observation becomes visible, but its deleted inventory record remains deleted. Confirm the physical identity before using the separate restoration workflow.

Evidence and limits

Review the original observation time, the latest attempt state and the successful evidence for the particular class of information. A later page refresh or a successful port read does not make an older component inventory current. Older or conflicting component readings are prevented from replacing a newer installation.

Automated tests with simulated devices cover addition, repetition, replacement, removal, blank identity and selected conflict cases. Those tests do not prove every vendor command or a physical swap on every supported switch.