Branches the DriversTab driver-add form on driver type:
- For DriverType=Modbus, render the typed <ModbusOptionsEditor> component
shipped in #145 instead of the generic JSON textarea.
- For other driver types, the existing textarea stays (other drivers ship
their own typed editors per decision #94).
On Save, when type is Modbus, the form serialises ModbusOptionsViewModel
into the JSON DTO shape ModbusDriverFactoryExtensions consumes (host /
port / unitId / family / keepAlive / reconnect / max*** / writeOnChangeOnly
/ etc.). Other types still pass the textarea contents verbatim.
Drive-by fix: the DriverType dropdown listed "ModbusTcp" but the actual
factory-registered name is "Modbus" — DriverInstanceBootstrapper would
silently skip a row created with the old label because the factory lookup
would miss. Renamed to match.
Tests (2 new in ModbusOptionsViewModelTests):
- DriversTab_Serialized_Defaults_RoundTrip_Through_Factory — unedited
view-model serializes to a JSON the factory accepts; resulting
ModbusDriverOptions matches the form defaults bit-for-bit.
- DriversTab_Serializes_Edited_Values_Correctly — flipping Host / Port /
UnitId / Family / MaxReadGap / WriteOnChangeOnly in the view model
surfaces in the constructed driver's options.
The serializer in the test mirrors DriversTab.razor's SerializeModbusOptions
helper. If the form's serialization shape drifts, both must be updated
together; that's the cost of testing through the JSON DTO without bUnit.
Follow-up still open: the per-tag editor (ModbusAddressEditor wiring into
EquipmentTab.razor + the bulk-import help-text update) — that's a separate
surface that touches the equipment-row CRUD flow; covered as a follow-up
when the equipment tag editor surface is next touched.
Two new Blazor components surface every Modbus knob added by #136-#144 so
users can configure the driver without hand-editing DriverConfig JSON.
ModbusAddressEditor.razor (live address-string parser preview):
- Bound to a string AddressString + a Family / MelsecSubFamily hint.
- On every input keystroke, runs ModbusAddressParser.TryParse and surfaces
the resolved breakdown (Region, Offset, DataType, Bit, ByteOrder,
ArrayCount, StringLength) inline as a green badge.
- On parse error, shows the parser's diagnostic in red.
- Re-uses the SAME parser the wire driver uses — grammar drift is
impossible by construction.
ModbusOptionsEditor.razor (driver-instance options panel):
- Connection group (Host / Port / UnitId).
- Family group (#144) with conditional MelsecSubFamily dropdown.
- Keep-alive group (#139): Enabled / Time / Interval / RetryCount.
- Reconnect group (#139): InitialDelay / MaxDelay / BackoffMultiplier.
- Protocol group (#140): MaxRegistersPerRead / Write / Coils / ReadGap.
- Behaviour toggles (#140 + #141): UseFC15 / UseFC16 / WriteOnChangeOnly.
- Bound to ModbusOptionsViewModel — defaults match ModbusDriverOptions
defaults so unedited rows produce the historical wire output verbatim.
Architecture:
- Admin project gains a ProjectReference to Driver.Modbus.Addressing
(the shared parser assembly extracted in #136). Admin does NOT take a
dep on Driver.Modbus itself — the addressing concerns are cleanly
separated from the wire driver.
- Same-namespace shared assembly means components reference
ModbusAddressParser / ModbusFamily / etc. without prefix gymnastics.
Tests:
- ModbusOptionsViewModelTests (1 test) — pins every default in the view
model against the corresponding ModbusDriverOptions default. A
regression that flips an unedited row to a non-default value gets
caught here. (Test references both Admin and Driver.Modbus to make the
cross-assembly comparison.)
- Live Blazor component testing requires bUnit, which isn't currently
in the test setup; the parser logic the component wraps is fully
covered by the 91 ModbusAddressParser tests in the addressing project,
so the glue layer's behaviour is verifiable end-to-end already.
Caveat: the wiring into the existing DriverInstance edit page lives in
DriversTab.razor — that integration is left as a follow-up because it
touches the cluster-edit workflow specifically and the components in
this commit are framework-agnostic enough to drop in. The components
build clean against the existing Admin project; no behavioural change
to other tabs.
