Add semantic class 0x2C percentage in whole percent #87
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/percentage-class"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The firmware added semantic class 0x2C percentage to the measured band (CCS-LLA-26). Spec section 6: uint16, 1 % per step, 0 to 100 — unlike a level, which is 0.1 %.
Its first user is the lighting node's bathroom night brightness setting (
PK_SETTING, range 1-100, default 30). It now shows as a config number in%, with a step of 1, derived from the newunits.WHOLE_PERCENTAGEquantity soCMD_SETTINGsends the raw percent unscaled.Also adds the class to the frame bench's
SC_table, pinned against the protocol library bytests/test_bench_agrees_with_the_protocol.py.Checked against https://git.robware.uk/rob/CampervanControlSystems raw docs/can-protocol.md sections 5.2 and 6. No shared vector for this class has been published from the firmware yet, so the new coverage is local to this repository.
Ticket: CCS-HA-53
Tested: full suite passes (1212 passed, 3 skipped), ruff check and format clean.
Traced the whole path:
SemanticClass.PERCENTAGE(0x2C) →READOUTS[PERCENTAGE]withunits.WHOLE_PERCENTAGE(factor=1) →_setting()'s genericreplace()turns it into aNUMBER/CONFIGshape without any new branch →number.py'snative_step(quantity.from_wire(1)= 1) and_range()both readendpoint.minimum/maximumunscaled →commands.setting_on_the_wire()multiplies byquantity.factor= 1, so 30 goes out as 30. All correct, and I couldn't find anywhere still reaching for the oldunits.PERCENTAGE(0.1 %) for this class — the twoor units.PERCENTAGEfallbacks incommands.py/number.pyare level-only defaults that aShapewithquantity=WHOLE_PERCENTAGEnever hits.The
SC_PERCENTAGEaddition to the bench table is pinned bytest_the_presentation_vocabulary_agrees, which compares the full{name: value}dict, so a wrong value (not just a missing entry) would fail it.CMD_SETTING'svaluefield carries no fixedquantityin the catalogue (a setting's unit is per-endpoint), sotest_the_scaling_agreeshas nothing to check here — correctly, nothing needed changing there.New tests are genuinely discriminating:
from_wire(30) == 30andsetting_on_the_wire(30, ...) == 30would both fail against the old 0.1 %-scaledPERCENTAGEquantity, so they're not vacuous.Ran the full suite,
ruff checkandruff format --check— all clean, matches what's stated.One thing to consider, not a blocker: other settings (the bathroom extractor's duration, the touch switch) each got a
tools/frame_bench/examples/*.jsonwhen they landed, letting the read-only path be exercised againstvcan0for that specific case. This PR adds none for the new percentage setting on lighting endpoint 7. Worth a follow-up if you want the bench to be able to rehearse this one too.Thanks for the review. Leaving the frame_bench example out of scope for this PR — the ticket (CCS-HA-53) doesn't ask for one, and there's no repo rule requiring one per semantic class (several existing classes have none). Happy to add one in a follow-up if the read-only path for this setting needs rehearsing against vcan0.