python-mobius 0.2.1__tar.gz → 0.3.1__tar.gz

python_mobius-0.3.1/.forgejo/scripts/extract_changelog_section.py

@@ -0,0 +1,42 @@
+"""
+Extracts the section of CHANGELOG.md under the heading matching a given
+version (e.g. version "0.3.0" -> the content under "## 0.3.0", up to the
+next "## " heading or end of file), and writes it to release_notes.md.
+
+Used by .forgejo/workflows/release.yml to source Forgejo release notes
+from CHANGELOG.md directly, rather than letting Forgejo auto-generate
+notes from commits. Takes the tag name (e.g. "v0.3.0") as its one
+argument and strips the leading "v" itself, since tags use that prefix
+but CHANGELOG.md's own headings don't.
+
+Exits with a clear error (nonzero exit code) if no matching section is
+found, rather than silently producing an empty or wrong release.
+"""
+
+import re
+import sys
+
+
+def main() -> None:
+    if len(sys.argv) != 2:
+        raise SystemExit(f"usage: {sys.argv[0]} <tag-name>")
+
+    version = sys.argv[1].lstrip("v")
+    text = open("CHANGELOG.md", encoding="utf-8").read()
+    pattern = re.compile(
+        r"^## " + re.escape(version) + r"\s*$\n(.*?)(?=^## |\Z)",
+        re.MULTILINE | re.DOTALL,
+    )
+    match = pattern.search(text)
+    if not match:
+        raise SystemExit(
+            f"No CHANGELOG.md section found for version {version!r} "
+            f"(looked for a line starting with '## {version}')"
+        )
+
+    with open("release_notes.md", "w", encoding="utf-8") as f:
+        f.write(match.group(1).strip() + "\n")
+
+
+if __name__ == "__main__":
+    main()

python_mobius-0.3.1/.forgejo/workflows/release.yml

@@ -0,0 +1,110 @@
+name: Release
+
+# Triggers on any tag matching v* (e.g. v0.3.0) -- confirmed to match every
+# tag this project has used so far -- or manually via workflow_dispatch
+# (Forgejo's web UI / API "Run workflow" button) for testing/debugging the
+# workflow itself. Does NOT trigger on regular pushes.
+# "on" is quoted deliberately -- unquoted, some YAML parsers (YAML 1.1)
+# interpret the bare word as the boolean `true` instead of the literal
+# key GitHub/Forgejo Actions expects.
+"on":
+  push:
+    tags:
+      - "v*"
+  workflow_dispatch: {}
+
+jobs:
+  release:
+    # ubuntu-22.04 label -> catthehacker/ubuntu:act-22.04, the only one of
+    # this runner's three labels with a full, GitHub-Actions-compatible
+    # environment (Python, Node, glibc). The "docker" label maps to a bare
+    # Alpine image, which lacks the glibc most published actions expect.
+    runs-on: ubuntu-22.04
+    steps:
+      # NOT using actions/checkout here -- it's broken for SHA256 repos
+      # (this one is): it initializes the local git repo before fetching
+      # without specifying --object-format=sha256, so the real 64-char
+      # SHA256 ref it then tries to fetch gets rejected by the freshly
+      # (SHA1-defaulting) initialized local repo, failing with "couldn't
+      # find remote ref". Confirmed via real testing on this exact
+      # workflow, and a known, still-open, ~1-year-old bug, tracked both
+      # upstream (actions/checkout#1843) and in Forgejo itself
+      # (forgejo/forgejo#9431) -- not something specific to this workflow.
+      # A plain `git clone` doesn't have this problem: cloning negotiates
+      # the object format with the remote from the start, rather than
+      # assuming SHA1 and fetching into it after the fact. Auth uses the
+      # same http.extraheader bearer-token approach actions/checkout
+      # itself uses internally (confirmed working in the earlier failed
+      # run -- "Setting up auth" succeeded; only the later fetch failed).
+      - name: Checkout
+        env:
+          FORGEJO_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        run: |
+          git -c http.extraheader="Authorization: Bearer ${FORGEJO_TOKEN}" \
+            clone --depth 1 --branch "${{ github.ref_name }}" \
+            https://code.r3pek.org/r3pek/python-mobius.git .
+
+      - name: Set up Python
+        uses: https://code.forgejo.org/actions/setup-python@v5
+        with:
+          python-version: "3.12"
+
+      - name: Install build and test dependencies
+        run: |
+          python -m pip install --upgrade pip
+          pip install -e ".[dev]"
+          pip install build twine
+
+      # Gate: the rest of this job (build, PyPI publish, release creation)
+      # only runs if this step succeeds.
+      - name: Run tests
+        run: pytest -q
+
+      - name: Build package
+        run: python -m build
+
+      - name: Validate built package
+        run: python -m twine check dist/*
+
+      - name: Publish to PyPI
+        # Only on a real tag push -- a workflow_dispatch run (manual, for
+        # testing/debugging this workflow itself) has no version tag to
+        # publish under and shouldn't attempt to.
+        if: github.event_name == 'push'
+        env:
+          TWINE_USERNAME: __token__
+          TWINE_PASSWORD: ${{ secrets.PYPI_API_TOKEN }}
+        run: python -m twine upload dist/*
+
+      # Pulls the section of CHANGELOG.md under the heading matching this
+      # tag's version (tag v0.3.0 -> "## 0.3.0") for the Forgejo release
+      # notes, rather than letting Forgejo auto-generate notes from commits.
+      # Fails the job (on purpose) if no matching section is found, rather
+      # than silently publishing a release with empty/wrong notes.
+      # Same event-gating reason as the PyPI step -- github.ref_name on a
+      # manual run is whatever branch was picked, not a version, so there's
+      # no matching CHANGELOG.md section to find at all.
+      - name: Extract changelog section for this version
+        if: github.event_name == 'push'
+        run: python3 .forgejo/scripts/extract_changelog_section.py "${{ github.ref_name }}"
+
+      # direction: upload with no release-dir set -- no wheel/sdist attached
+      # to the Forgejo release itself (PyPI is the source of truth for the
+      # built artifacts); this step only creates the release entry with the
+      # extracted changelog section as its notes. Worth confirming on the
+      # first real run that omitting release-dir doesn't pick up dist/ by
+      # some other default -- the action's own docs only show examples with
+      # release-dir explicitly set, so this specific "notes only" case
+      # isn't directly demonstrated there.
+      # Same event-gating reason as the two steps above -- nothing to
+      # release against on a manual, non-tag run.
+      - name: Create Forgejo release
+        if: github.event_name == 'push'
+        uses: https://code.forgejo.org/actions/forgejo-release@v2
+        with:
+          direction: upload
+          url: https://code.r3pek.org
+          repo: r3pek/python-mobius
+          token: ${{ secrets.GITHUB_TOKEN }}
+          tag: ${{ github.ref_name }}
+          release-notes-file: release_notes.md

{python_mobius-0.2.1 → python_mobius-0.3.1}/CHANGELOG.md

@@ -1,5 +1,90 @@
 # Changelog
 
+## 0.3.1
+
+- **Fixed a real, high-impact bug: `Brightness` (the master dimmer
+  channel) was never being applied to any other channel at all.**
+  Confirmed directly from raw smali (`LightPrimitive.flatten()`, called
+  on both bracketing schedule points in `getIntensitiesAtTime()` before
+  interpolating between them -- JADX's decompiled Java for this class
+  carried its own "Code duplicated" warning, the same signal that led to
+  finding the `is_night_segment()` bug, so this was re-verified against
+  bytecode rather than trusted from the decompile a second time). Every
+  channel -- moonlight included -- was being interpolated and returned
+  without ever being scaled by `Brightness`, found via real hardware
+  testing: a light showing ~1% in the app's own display came back as
+  ~25% from this library at the same moment, with `Brightness` itself
+  reading ~3.3% at that point in its own ramp -- fully consistent with
+  the missing multiplication, not a lunar or scheduling bug.
+  `interpolate_light_schedule()` now flattens each bracketing point
+  SEPARATELY (by that point's own `Brightness` value) BEFORE
+  interpolating between the two already-flattened points -- confirmed
+  via a dedicated test that this is NOT mathematically equivalent to
+  interpolating raw values first and multiplying by a single
+  interpolated `Brightness` at the end, whenever `Brightness` itself
+  changes across the segment (which it usually does, e.g. ramping
+  during dusk/dawn). `Brightness` itself is still returned as the plain
+  raw interpolated value, not flattened to a constant 100% the way the
+  real `flatten()` does to the primitive it's applied to -- callers
+  (e.g. a dedicated `Brightness` sensor) want the actual current
+  master-dimmer level. 4 new tests.
+
+## 0.3.0
+
+- **Fixed a real, high-impact bug in `is_night_segment()`: the condition
+  deciding whether to apply lunar-phase reduction had its first check
+  inverted**, confirmed directly from raw smali bytecode after JADX's
+  own decompiled Java carried a "Code duplicated" warning on this exact
+  method that turned out to be a real signal -- the decompiler had
+  produced `!point.has(NIGHT)` where the actual bytecode requires
+  `point.has(NIGHT)`. In practice this meant lunar reduction was applied
+  only during the single dusk-transition segment (and only if the query
+  time exactly matched a night-flagged point), while every other
+  night-to-night segment -- the bulk of an actual night -- silently used
+  the schedule-intensity scalar instead. Found via real hardware
+  testing: a light in a `23:00[NIGHT,SUNSET] -> 23:27[NIGHT]` segment
+  produced a value consistent with schedule-intensity-only scaling from
+  this library, while the real app displayed a noticeably lower,
+  lunar-consistent value at the same moment -- mathematically impossible
+  to explain by schedule-intensity alone within that segment's raw-value
+  range. 4 tests fixed/rewritten to match the confirmed correct
+  semantics (including one reproducing the exact real-world schedule and
+  moment this was found from), plus 2 more updated in
+  `test_light_intensity_branching.py` whose fixture schedule needed to
+  actually be a night-to-night segment rather than the (no longer
+  qualifying) dusk-transition segment it used before.
+
+- **Fixed a real bug, the same class of gap this project has hit before:
+  `get_hardware_info()` was never wired into `get_device_summary()`,**
+  meaning it worked correctly in isolation (with its own passing tests)
+  but was silently missing from the CLI's output and any other "give me
+  everything" caller built on the summary entrypoint -- see
+  `get_device_summary()`'s own "BUG NOTE" docstring, which describes the
+  exact same thing having happened to `get_group_info()`/
+  `get_calibration_info()`/etc. previously. Added `info["hardware_info"]
+  = await self.get_hardware_info()` alongside the existing
+  `firmware_versions` line. The CLI needed no changes at all -- its
+  summary printing is a generic loop over whatever `get_device_summary()`
+  returns, so this alone was the actual fix. 2 tests extended (not just
+  `"key" in summary`, but the actual decoded value) specifically so this
+  field can't silently regress the way it silently went missing.
+
+- **`get_hardware_info()` now decodes `Color`/`ProductType`/`RadioType`/
+  `MotorType` into confirmed display labels**, instead of returning raw
+  bytes. Each is itself a confirmed enum with confirmed labels
+  (`M.Color`/`M.ProductType`/`M.RadioType`/`M.MotorType` in the
+  decompile) -- added `Color`, `RadioType`, `MotorType`, `ProductType`
+  enums plus their `*_LABELS` dicts to `mobius.constants`. An
+  unrecognized value falls back to `"Unknown (N)"` rather than raising.
+  `Revision`/`Segments` still have no confirmed enum meaning -- returned
+  as plain integers (previously raw bytes) rather than formatted.
+  Several `MotorType`/`ProductType` labels were base64-string-obfuscated
+  in the decompile rather than plain literals (apparently to avoid
+  casual discovery of unannounced product names in a simple APK string
+  dump) -- decoded and included regardless, since it's plain base64, not
+  any actual protection. 3 new tests. **Breaking change** for any caller
+  relying on `get_hardware_info()`'s previous raw-bytes return shape.
+
 ## 0.2.1
 
 - **Fixed a real bug found via real hardware testing: some "get all

{python_mobius-0.2.1 → python_mobius-0.3.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: python-mobius
-Version: 0.2.1
+Version: 0.3.1
 Summary: Reverse-engineered Python client for the Mobius BLE protocol (EcoTech Marine VorTech/Radion, AquaIllumination, Neptune Systems, NYOS)
 Project-URL: Homepage, https://code.r3pek.org/r3pek/python-mobius
 Project-URL: Documentation, https://code.r3pek.org/r3pek/python-mobius/src/branch/main/documentation

{python_mobius-0.2.1 → python_mobius-0.3.1}/documentation/06-light-schedule.md

@@ -81,12 +81,51 @@ Ported from `PointSchedule.getIntensitiesAtTime()`:
 2. Find the two points that bracket the target minute-of-day, wrapping
    around midnight (the point after the last one is treated as being on
    "the next day," i.e. its time + 1440).
-3. For each channel present in either bracketing point, linearly
-   interpolate: `value(t) = v1 + (v2 - v1) * (t - t1) / (t2 - t1)`.
-4. Channels absent from a point default to `0` (off).
+3. **`Brightness` (`VisualID.Brightness`) is a master dimmer, applied to
+   EACH bracketing point separately, before interpolating between them**
+   -- confirmed from raw smali (`LightPrimitive.flatten()`, called on
+   both point copies in `getIntensitiesAtTime()` before the
+   interpolation loop -- JADX's decompiled Java for this class carried
+   its own "Code duplicated" warning, the same signal that led to
+   finding the `is_night_segment()` bug, so this was verified against
+   bytecode directly rather than trusted from the decompile). For each
+   point independently: every channel except `Brightness` itself is
+   multiplied by that same point's own `Brightness` value / 1000. This
+   was a real, confirmed-missing step for a while -- every channel
+   (moonlight included) was being interpolated and returned without
+   ever being scaled by `Brightness` at all, found via real hardware
+   testing (a light showing ~1% in the app's own display came back as
+   ~25% from this library at the same moment, with `Brightness` itself
+   reading ~3.3% at that point in its own ramp).
+4. For each channel present in either bracketing point, linearly
+   interpolate between the (already `Brightness`-scaled, for
+   non-`Brightness` channels) endpoint values:
+   `value(t) = v1 + (v2 - v1) * (t - t1) / (t2 - t1)`.
+   **Flattening happens per-endpoint before this step, not
+   interpolate-raw-then-multiply-by-a-single-`Brightness`-value after
+   it** -- these are NOT mathematically equivalent whenever `Brightness`
+   itself changes across the segment (which it usually does, e.g.
+   ramping during a dusk/dawn transition).
+5. Channels absent from a point default to `0` (off), except
+   `Brightness` itself: a point missing that channel entirely is treated
+   as a no-op 1000 (100%) multiplier for that point, matching
+   `flatten()`'s own `visuals().contains(Brightness)` guard (skips
+   scaling entirely rather than treating an absent value as 0, which
+   would zero out every other channel).
+6. `Brightness` itself is returned as the plain raw interpolated value
+   between the two points' own `Brightness` levels -- NOT flattened to
+   1000 the way the real `flatten()` call does internally to the
+   primitive it's applied to. Unlike the app's own dashboard (which
+   doesn't display `Brightness` as its own value at all, only as the
+   multiplier baked into every other channel), this library's callers
+   (e.g. a dedicated `Brightness` sensor) want the actual current
+   master-dimmer level itself.
 
 Verified against a synthetic two-point schedule (exact endpoint values,
-midpoint blending, and midnight-wraparound blending -- see
+midpoint blending, midnight-wraparound blending, and the `Brightness`
+master-dimmer behavior above, specifically including a case designed to
+mathematically distinguish flatten-then-interpolate from the wrong
+interpolate-then-multiply alternative -- see
 `tests/test_light_schedule.py`) and against a real 9-point schedule
 fetched live, which produces a coherent daily light-intensity curve (dim
 moonlight overnight → ramp to full blues/UV midday → wind back down).
@@ -110,18 +149,36 @@ full moon. Verified against independently-confirmed real 2026 moon phase
 dates (full moon Jan 3 2026, new moon Jan 18 2026) -- the ported
 algorithm matches exactly.
 
-This replaces the normal schedule-intensity scalar specifically during the
-**dusk-to-night segment** of the schedule (see `is_night_segment()` below),
-and only when `LunarPhasesEnabled` (attribute 907) is set on the device --
-otherwise that segment just uses a flat `1.0` (full/unreduced) scalar,
-matching the app's own fallback.
+This replaces the normal schedule-intensity scalar for any segment
+where `is_night_segment()` is true (see below), and only when
+`LunarPhasesEnabled` (attribute 907) is set on the device -- otherwise
+that segment just uses a flat `1.0` (full/unreduced) scalar, matching
+the app's own fallback.
 
 **`is_night_segment()`**: ported from the boolean half of
 `PointSchedule.getIntensitiesAtTime()`'s return value. This is *not*
-simply "is it night" -- it's specifically true for the segment whose
-start point is NOT flagged `NIGHT` or `SUNRISE` and whose end point IS
-flagged `NIGHT` (the dusk-transition segment), or when the query time
-exactly matches a `NIGHT`-flagged point.
+simply "is it night" as a general concept -- it's specifically true for
+the segment whose **start** point IS flagged `NIGHT` (but not also
+`SUNRISE`) and whose end point is ALSO flagged `NIGHT` -- i.e. once
+already into the night portion of the schedule, through to the sunrise
+transition -- or when the query time exactly matches a `NIGHT`-flagged
+point. In practice this covers essentially the whole night, *except*
+the two transition segments themselves: dusk (start point not yet
+night-flagged) and the sunrise segment (start point flagged `SUNRISE`).
+
+**Confirmed directly from raw smali bytecode, not the decompiled Java.**
+JADX's decompiler carried its own "Code duplicated" warning on this
+exact method -- a real signal, not noise: its decompiled Java had this
+condition's first check inverted (`!point.has(NIGHT)` instead of the
+actual `point.has(NIGHT)`), which an earlier version of this port
+carried forward uncorrected. Found via real hardware testing: a light
+in a `23:00[NIGHT,SUNSET] -> 23:27[NIGHT]` segment showed a value
+consistent with the schedule-intensity scalar from this library, while
+the real app displayed a noticeably lower, lunar-consistent value at
+the same moment -- mathematically impossible to explain by
+schedule-intensity alone within that segment's raw-value range, which
+is what prompted re-examining the raw bytecode instead of trusting the
+decompiled Java a second time.
 
 **Acclimation ramp** (`AcclimationInfo`): a linear intensity ramp from
 `start_intensity` (0-1000 permille) up to full (1000) over `period_days`,

{python_mobius-0.2.1 → python_mobius-0.3.1}/documentation/11-device-status-attributes.md

@@ -170,17 +170,37 @@ response bytes** (e.g. `[4, 0, 21]` -> `"4.0.21"`) -- confirmed via
 nothing more exotic.
 
 `get_hardware_info()` follows the same fetch pattern for
-`HardwareRevision`/`HardwareInfo`, but **no display-formatting convention
-is confirmed** for those fields (`Color`/`Revision`/`ProductType`/
-`RadioType`/`MotorType`/`Segments` read more like small integer/enum
-codes than version numbers) -- returns raw bytes per field rather than
-guessing a format.
-
-Both are included automatically in `get_device_summary()`'s
-`"firmware_versions"` field (using the confirmed EcoTech labels, since
-`get_device_summary()` already has the device's `Model` on hand).
-`get_hardware_info()` is not currently wired into the summary -- call it
-directly if you want it.
+`HardwareRevision`/`HardwareInfo`. `Color`/`ProductType`/`RadioType`/
+`MotorType` are each themselves confirmed enums with confirmed display
+labels (`M.Color`/`M.ProductType`/`M.RadioType`/`M.MotorType` in the
+decompile -- see `mobius.constants`) -- decoded into those label
+strings, e.g. `{"Color": "White", "MotorType": "VorTech MP40 G3"}`. An
+unrecognized value (firmware newer than this library's confirmed enum
+coverage) falls back to `"Unknown (N)"` rather than raising.
+`Revision`/`Segments` have no confirmed enum meaning -- returned as
+plain integers, not formatted.
+
+Several `MotorType`/`ProductType` labels are base64-string-obfuscated in
+the decompile rather than plain literals (`Slack`/`Alpaca2`/`Alpaca4`/
+`Turtle1-4` under `MotorType`; several under `ProductType`) -- apparently
+to avoid casual discovery of unannounced product names in a simple APK
+string dump. Decoded and included as confirmed labels regardless, since
+it's plain base64, not any actual protection -- e.g. `MotorType.Turtle1`
+decodes to `"Axis 20"`, `ProductType.Cowboy` (a dedicated Thread hub
+device, see [09-thread-coap-relay.md](./09-thread-coap-relay.md)) to
+`"MXM"`. Some `ProductType` labels also intentionally diverge from the
+enum member's own name (`Chalupa` -> `"Sprout"`, `NachosBellGrande` ->
+`"Voltra"`) -- confirmed real display strings, not typos.
+
+Both are included automatically in `get_device_summary()`, as
+`"firmware_versions"` (using the confirmed EcoTech labels, since
+`get_device_summary()` already has the device's `Model` on hand) and
+`"hardware_info"` respectively -- confirmed reaching the CLI's output
+this way, not just working correctly in isolation (see
+`get_device_summary()`'s own "BUG NOTE" docstring for why this
+distinction matters: this exact class of gap, a method that works
+correctly on its own but was never wired into the aggregate entrypoint
+the CLI actually uses, has happened more than once in this project).
 
 ## Device clock drift (`get_device_time_info()`)
 

{python_mobius-0.2.1 → python_mobius-0.3.1}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "python-mobius"
-version = "0.2.1"
+version = "0.3.1"
 description = "Reverse-engineered Python client for the Mobius BLE protocol (EcoTech Marine VorTech/Radion, AquaIllumination, Neptune Systems, NYOS)"
 readme = "README.md"
 license = { text = "GPL-2.0-only" }

{python_mobius-0.2.1 → python_mobius-0.3.1}/src/mobius/__init__.py

@@ -28,6 +28,8 @@ from .constants import (
     SceneID, OperationState, FsciStatus,
     PumpMode, PumpOverrideMode, RampType, PumpParam, PUMP_PARAM_SIZE, PUMP_MODE_PARAMS,
     FirmwareType, FIRMWARE_TYPE_LABELS_ETM, HardwareInfo,
+    Color, COLOR_LABELS, RadioType, RADIO_TYPE_LABELS,
+    MotorType, MOTOR_TYPE_LABELS, ProductType, PRODUCT_TYPE_LABELS,
 )
 from .schedule import (
     LightPrimitive, SchedulePoint, interpolate_light_schedule,
@@ -61,7 +63,7 @@ from .discovery import (
     dedupe_by_serial, find_device_by_serial, discover_mesh_peers_via_direct_connect,
 )
 
-__version__ = "0.2.1"
+__version__ = "0.3.1"
 
 __all__ = [
     "__version__",
@@ -83,6 +85,8 @@ __all__ = [
     "SceneID", "OperationState", "FsciStatus",
     "PumpMode", "PumpOverrideMode", "RampType", "PumpParam", "PUMP_PARAM_SIZE", "PUMP_MODE_PARAMS",
     "FirmwareType", "FIRMWARE_TYPE_LABELS_ETM", "HardwareInfo",
+    "Color", "COLOR_LABELS", "RadioType", "RADIO_TYPE_LABELS",
+    "MotorType", "MOTOR_TYPE_LABELS", "ProductType", "PRODUCT_TYPE_LABELS",
     # schedule
     "LightPrimitive", "SchedulePoint", "interpolate_light_schedule",
     "PumpPrimitiveValue", "PumpSchedulePoint", "get_active_pump_block",

{python_mobius-0.2.1 → python_mobius-0.3.1}/src/mobius/constants.py

@@ -492,11 +492,12 @@ class HardwareInfo(IntEnum):
     """
     Confirmed literal values from M.HardwareInfo -- the sub-index used
     with C2Attribute.HardwareRevision, same "get all elements" pattern as
-    FirmwareVersion above. Unlike FirmwareVersion, no dot-joined-string
-    display convention is confirmed for these fields (Color/Revision/
-    ProductType/RadioType/MotorType/Segments read more like small
-    integer/enum codes than version numbers) -- returned as raw bytes,
-    not formatted, until that's confirmed.
+    FirmwareVersion above. `Revision` and `Segments` have no confirmed
+    display convention (read as plain small integers, not version
+    numbers or enum codes) -- but `Color`/`ProductType`/`RadioType`/
+    `MotorType` are each themselves confirmed enums (M.Color/M.ProductType/
+    M.RadioType/M.MotorType) with confirmed display labels -- see
+    Color/ProductType/RadioType/MotorType below and their *_LABELS dicts.
     """
     Unknown = 0
     Color = 1
@@ -507,6 +508,172 @@ class HardwareInfo(IntEnum):
     Segments = 6
 
 
+class Color(IntEnum):
+    """Confirmed literal values and display labels from M.Color --
+    the HardwareInfo.Color sub-value's own enum."""
+    Unknown = 0
+    Black = 1
+    White = 2
+
+
+COLOR_LABELS: dict = {
+    Color.Black: "Black",
+    Color.White: "White",
+}
+
+
+class RadioType(IntEnum):
+    """Confirmed literal values and display labels from M.RadioType --
+    the HardwareInfo.RadioType sub-value's own enum."""
+    Unknown = 0
+    KW41 = 1
+    QCA4020 = 2
+    K32W = 3
+    QCA4024 = 4
+    ESP32C3 = 5
+    ESP32H2 = 6
+    ESP32S3 = 7
+    ESP32C6 = 8
+
+
+RADIO_TYPE_LABELS: dict = {
+    RadioType.KW41: "KW41",
+    RadioType.QCA4020: "QCA4020",
+    RadioType.K32W: "K32W",
+    RadioType.QCA4024: "QCA4024",
+    RadioType.ESP32C3: "ESP32C3",
+    RadioType.ESP32H2: "ESP32H2",
+    RadioType.ESP32S3: "ESP32S3",
+    RadioType.ESP32C6: "ESP32C6",
+}
+
+
+class MotorType(IntEnum):
+    """Confirmed literal values and display labels from M.MotorType --
+    the HardwareInfo.MotorType sub-value's own enum. Several labels
+    (Slack/Alpaca2/Alpaca4/Turtle1-4) are base64-string-obfuscated in the
+    decompile rather than plain literals, apparently to avoid casual
+    discovery of unannounced product names in a simple APK string dump --
+    decoded here since it's plain base64, not encryption, and the
+    resulting strings are just as much "confirmed from source" as the
+    unobfuscated ones."""
+    Unknown = 0
+    VorTechMP10 = 1
+    VorTechMP40Legacy = 2
+    VorTechMP40G3 = 3
+    VorTechMP60 = 4
+    VectraD12 = 5
+    VectraD8 = 6
+    VectraS1 = 7
+    Wavepuck30w = 8
+    Nero5 = 9
+    Nero3 = 10
+    VectraS2 = 11
+    VectraM2 = 12
+    VectraL2 = 13
+    VersaVX1 = 14
+    Slack = 15
+    Alpaca2 = 16
+    Alpaca4 = 17
+    Turtle1 = 18
+    Turtle2 = 19
+    Turtle3 = 20
+    Turtle4 = 21
+    Coffee1 = 22
+    Coffee2 = 23
+    VectraTester = 99
+
+
+MOTOR_TYPE_LABELS: dict = {
+    MotorType.VorTechMP10: "VorTech MP10",
+    MotorType.VorTechMP40Legacy: "VorTech MP40 Legacy",
+    MotorType.VorTechMP40G3: "VorTech MP40 G3",
+    MotorType.VorTechMP60: "VorTech MP60",
+    MotorType.VectraD12: "Vectra D12",
+    MotorType.VectraD8: "Vectra D8",
+    MotorType.VectraS1: "Vectra S1",
+    MotorType.Wavepuck30w: "Wavepuck 30w",
+    MotorType.Nero5: "Nero 5",
+    MotorType.Nero3: "Nero 3",
+    MotorType.VectraS2: "Vectra S2",
+    MotorType.VectraM2: "Vectra M2",
+    MotorType.VectraL2: "Vectra L2",
+    MotorType.VersaVX1: "Versa VX1",
+    MotorType.Slack: "Nero 7",
+    MotorType.Alpaca2: "Orbit 2",
+    MotorType.Alpaca4: "Orbit 4",
+    MotorType.Turtle1: "Axis 20",
+    MotorType.Turtle2: "Axis 40",
+    MotorType.Turtle3: "Axis 90",
+    MotorType.Turtle4: "Axis 200",
+    MotorType.Coffee1: "Coffee 1",
+    MotorType.Coffee2: "Coffee 2",
+    MotorType.VectraTester: "Vectra Tester",
+}
+
+
+class ProductType(IntEnum):
+    """Confirmed literal values and display labels from M.ProductType --
+    the HardwareInfo.ProductType sub-value's own enum. Several labels
+    are base64-string-obfuscated in the decompile the same way some
+    MotorType labels are -- see MotorType's docstring for why that's
+    still treated as confirmed. Note several of these labels intentionally
+    diverge from the enum member's own name (e.g. Chalupa -> "Sprout",
+    NachosBellGrande -> "Voltra", Cowboy -> "MXM") -- these are the actual
+    confirmed display strings, not typos."""
+    Unknown = 0
+    Radion = 1
+    Vectra = 2
+    VorTech = 3
+    Nero = 4
+    DosingPump = 5
+    Chalupa = 6
+    EnvironmentalSensor = 7
+    RFModule = 8
+    WiFiModule = 9
+    WiFiModuleBreakout = 10
+    ChalupaPowerSupply = 11
+    ChalupaDriver = 12
+    AIFiLight = 13
+    AIMobiusLight = 14
+    DosingPumpBase = 15
+    NachosBellGrande = 16
+    HotSauce = 17
+    Cowboy = 18
+    Alpaca = 19
+    Turtle = 20
+    Coffee = 21
+    CrunchyTaco = 22
+    SoftTaco = 23
+
+
+PRODUCT_TYPE_LABELS: dict = {
+    ProductType.Radion: "Radion",
+    ProductType.Vectra: "Vectra",
+    ProductType.VorTech: "VorTech",
+    ProductType.Nero: "Nero",
+    ProductType.DosingPump: "Dosing Pump",
+    ProductType.Chalupa: "Sprout",
+    ProductType.EnvironmentalSensor: "Sensor",
+    ProductType.RFModule: "RF Module",
+    ProductType.WiFiModule: "Wi-Fi Module",
+    ProductType.WiFiModuleBreakout: "Breakout",
+    ProductType.ChalupaPowerSupply: "Power Supply",
+    ProductType.ChalupaDriver: "Driver",
+    ProductType.AIFiLight: "AI-Fi Light",
+    ProductType.AIMobiusLight: "AI Light",
+    ProductType.DosingPumpBase: "Base Station",
+    ProductType.NachosBellGrande: "Voltra",
+    ProductType.HotSauce: "Sensor",
+    ProductType.Cowboy: "MXM",
+    ProductType.Alpaca: "Orbit",
+    ProductType.Turtle: "Axis",
+    ProductType.Coffee: "Quantum",
+    ProductType.CrunchyTaco: "Hera",
+    ProductType.SoftTaco: "Hera Backplane",
+}
+
+
 class PumpOverrideMode(IntEnum):
     """
     Confirmed literal values from M.PumpOverrideMode. Confirmed only as a