Entity helpers: the ethernet monitor sample reads status and rate
Those are the two fields you open that monitor for, and rate is now TikDataRate,
so the sample shows the bits-per-second value rather than a spelling.
Entity reference, value types and helpers: the coverage a reader could not see
Three pages for the part of the library the wiki named once and never listed.
Entity-reference answers one question -- is my menu covered, and what is the
class called -- for a reader who already knows RouterOS. No field descriptions,
no per-entity prose: a table per top-level menu, and five markers explained once
at the top instead of repeated per row (singleton, read-only, ordered, live
counters, has helpers). The table is GENERATED from the [TikEntity] attributes
and guarded by a unit test in the code repo, so it cannot quietly fall behind;
what reflection cannot know is hand-written around it -- why the four *-server
singletons refuse =detail=, and that wireless and wifi are two drivers the router
chooses between, not two spellings.
It also says how to guess a class name without the table, and what to do when the
answer is no, which is the case the page most needs to handle well.
Entity-value-types gives TikDuration, TikDataRate, TikRatePair and
TikRouterAddress a home outside the page you visit to WRITE an entity -- every
reader of the built-in ones meets these types. Each one leads with the RouterOS
spelling it corresponds to, per transport, because that divergence is why the
type exists: 5s vs 00:00:05, 1000000 vs 1M vs 1Gbps, 1000000/2000000 vs 1M/2M.
Entity-helpers collects the 17 verbs that are not CRUD, grouped by what you would
be doing in WinBox rather than by which class they live on.
Home's breadth claim now carries its evidence (169 menus, linked), and
High-level-API-entities becomes the hub that reaches all three.