Classify switch ports by hardware, not by display name (#146)
Reported by @Orhideous: a port renamed to "starlink1" moves into the SFP
group. The cause is that every classification in the faceplate tested the
display name -- copper if it started with "ether", a QSFP cage if it
started with "qsfp", SFP for everything else. The display name is the one
field guaranteed not to describe the hardware, because it is the one field
users are invited to change.
Six sites did this: the tile label, the cage label, lane grouping, two
bucket filters and the sort order. A renamed port lost its label and its
position as well as its group.
Two checks on real hardware before building anything:
type cannot help. RouterOS reports type=ether for every physical port --
copper ether1, sfp28 cages, qsfp28 breakout lanes alike -- confirmed across
a CRS510, a CCR2216, a CRS309 and a wAP ax.
default-name can. RouterOS keeps the factory name beside the current one.
Renaming sfp-sfpplus8 on the test switch gave exactly the reported
scenario, with the hardware identity intact:
name=starlink1 default-name=sfp-sfpplus8
It is already on the /interface/print detail call the collector makes, so
collecting it is one extra field rather than another round trip.
Classification now keys on default_name and falls back to name. The
fallback is not cosmetic: rows collected before this have no factory name
until their next slow poll, and falling back reproduces the old behaviour
exactly instead of mis-sorting a fleet for one cycle. Three of the four
devices here are in that state right now and render as they did before.
portLabel moved into the module unchanged rather than being rewritten, so
the labels people recognise are preserved -- sfp-sfpplus8 is still P8, not
S8. Unrecognised ports are now treated as copper instead of being swept
into SFP, because showing one plainly beats filing it under the wrong
heading.
Also deletes ~50 lines of dead geometry. Chassis width, per-section
offsets and lane sizes formed a coordinate chain where each constant was
consumed only by the next and the last was read by nothing; every
occurrence sat between lines 913 and 966 while the render begins at 982. It
is left over from an absolute-positioned faceplate that is now flexbox with
its own literal sizes. Worth removing on its own: it reads like the thing
that drives layout, and it misled my own analysis of this component
earlier this week, including a tile-width figure I quoted that came from
constants nothing uses.
Verified end to end: renamed the port on hardware, re-collected, confirmed
the store holds name=starlink1 with default_name=sfp-sfpplus8, and restored
it. 14 unit tests over the classifier using the real default-names from all
four boards. Full preflight green.
This is Part A. The layout half of #146 -- rows that scale, groups that
wrap, and a maxWidth that misses wrapping by 2px per port -- is next, and
is easier now that ports land in the right buckets.
Not pushed.
Container image: ghcr.io/2gt-media-group-llc/mikrotik-manager:0.24.15-beta
Documentation: https://2gt-media-group-llc.github.io/mikrotik-manager/