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

python_mobius-0.3.0/.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.0/.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.0}/CHANGELOG.md

@@ -1,5 +1,61 @@
 # Changelog
 
+## 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.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: python-mobius
-Version: 0.2.1
+Version: 0.3.0
 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.0}/documentation/06-light-schedule.md

@@ -110,18 +110,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.0}/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.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "python-mobius"
-version = "0.2.1"
+version = "0.3.0"
 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.0}/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.0"
 
 __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.0}/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

{python_mobius-0.2.1 → python_mobius-0.3.0}/src/mobius/device.py

@@ -31,6 +31,8 @@ from .constants import (
     C2Attribute, PrimitiveType, Model, ErrorState, SceneID, OperationState,
     FsciStatus, PhysicalValueID, VisualID, PumpOverrideMode, manufacturer_for_model,
     FirmwareType, FIRMWARE_TYPE_LABELS_ETM, HardwareInfo,
+    Color, COLOR_LABELS, RadioType, RADIO_TYPE_LABELS,
+    MotorType, MOTOR_TYPE_LABELS, ProductType, PRODUCT_TYPE_LABELS,
     PRIMITIVE_SIZE, LIGHT_PRIMITIVES, PUMP_PRIMITIVES_VERIFIED, PUMP_PRIMITIVES_EXPERIMENTAL,
 )
 from .schedule import (
@@ -105,6 +107,18 @@ class LightIntensityResult(dict):
         self.diagnostics = diagnostics or {}
 
 
+# Used by get_hardware_info() -- which HardwareInfo sub-fields are
+# themselves confirmed enums with confirmed display labels, vs. plain
+# integers with no confirmed meaning (Revision/Segments, deliberately not
+# in this map).
+_HARDWARE_SUB_ENUM_LABELS = {
+    HardwareInfo.Color: (Color, COLOR_LABELS),
+    HardwareInfo.ProductType: (ProductType, PRODUCT_TYPE_LABELS),
+    HardwareInfo.RadioType: (RadioType, RADIO_TYPE_LABELS),
+    HardwareInfo.MotorType: (MotorType, MOTOR_TYPE_LABELS),
+}
+
+
 class MobiusDevice:
     """
     High-level async client for a single Mobius-protocol BLE device.
@@ -828,12 +842,19 @@ class MobiusDevice:
         -- same pattern as get_firmware_versions(), including using
         get_attribute_raw_all() rather than get_attribute_raw() to avoid
         missing elements if the response splits across more than one
-        block (see get_attribute_raw_all()'s docstring). Unlike firmware
-        versions, 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) -- returns {HardwareInfo_name: raw_bytes}, not formatted,
-        until that's confirmed against real hardware.
+        block (see get_attribute_raw_all()'s docstring).
+
+        `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 here, 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, since unlike the four fields
+        above there's nothing confirmed to decode them into.
         """
         try:
             blocks = await self.get_attribute_raw_all(C2Attribute.HardwareRevision, index=0, count=0xFFFF)
@@ -849,7 +870,17 @@ class MobiusDevice:
                     hw_info = HardwareInfo(raw.index + i)
                 except ValueError:
                     continue
-                result[hw_info.name] = value_bytes
+                if not value_bytes:
+                    continue
+                raw_int = int.from_bytes(value_bytes, byteorder="little", signed=False)
+                if hw_info in _HARDWARE_SUB_ENUM_LABELS:
+                    enum_cls, labels = _HARDWARE_SUB_ENUM_LABELS[hw_info]
+                    try:
+                        result[hw_info.name] = labels.get(enum_cls(raw_int), f"Unknown ({raw_int})")
+                    except ValueError:
+                        result[hw_info.name] = f"Unknown ({raw_int})"
+                else:
+                    result[hw_info.name] = raw_int
         return result
 
     async def get_device_summary(self) -> dict:
@@ -873,11 +904,12 @@ class MobiusDevice:
         Pump devices additionally include "flow_range", "pump_override_mode",
         "battery_backup", "boosted_battery" (see get_pump_flow_range() etc.
         for details/confidence notes on each). Every device (regardless of
-        support tier) additionally includes "group", "calibration", and
-        "maintenance" (see get_group_info()/get_calibration_info()/
-        get_maintenance_info() -- calibration in particular is expected to
-        only actually populate on lights, not pumps; see
-        documentation/11-device-status-attributes.md).
+        support tier) additionally includes "group", "calibration",
+        "maintenance", and "hardware_info" (see get_group_info()/
+        get_calibration_info()/get_maintenance_info()/get_hardware_info()
+        -- calibration in particular is expected to only actually
+        populate on lights, not pumps; see documentation/
+        11-device-status-attributes.md).
 
         BUG NOTE: for a while after get_pump_flow_range()/
         get_pump_override_mode()/get_battery_backup_info()/
@@ -959,6 +991,7 @@ class MobiusDevice:
         info["calibration"] = await self.get_calibration_info()
         info["maintenance"] = await self.get_maintenance_info()
         info["firmware_versions"] = await self.get_firmware_versions(model)
+        info["hardware_info"] = await self.get_hardware_info()
         info["device_time"] = await self.get_device_time_info()
 
         return info

{python_mobius-0.2.1 → python_mobius-0.3.0}/src/mobius/modifiers.py

@@ -131,14 +131,28 @@ class AcclimationInfo:
 def is_night_segment(points: list[SchedulePoint], minute_of_day: int) -> bool:
     """
     True specifically when minute_of_day falls in the segment whose START
-    point is NOT flagged NIGHT or SUNRISE and whose END point IS flagged
-    NIGHT (i.e. the dusk-transition-into-night segment), or when
-    minute_of_day exactly matches a point that is itself flagged NIGHT.
-    This is NOT simply "is it currently night" -- that's genuinely the
-    Java source's own semantics (confirmed by reading
-    PointSchedule.getIntensitiesAtTime() directly), used specifically to
-    decide whether to substitute the lunar-phase reduction in place of the
+    point IS flagged NIGHT (but not also SUNRISE) and whose END point is
+    ALSO flagged NIGHT (i.e. once actually into the night portion of the
+    schedule, up until the sunrise transition), or when minute_of_day
+    exactly matches a point that is itself flagged NIGHT. This is NOT
+    simply "is it currently night" as a general concept, but this
+    specific segment-boundary condition -- used specifically to decide
+    whether to substitute the lunar-phase reduction in place of the
     normal schedule-intensity scalar.
+
+    Confirmed directly from raw smali bytecode (JADX's decompiled Java
+    for PointSchedule.getIntensitiesAtTime() carried its own "Code
+    duplicated" warning on this exact method -- a real signal, not
+    noise: its decompilation of this specific condition had the first
+    check inverted, i.e. `!point.has(NIGHT)` instead of the actual
+    `point.has(NIGHT)`. Confirmed via real hardware testing too: a
+    23:00[NIGHT,SUNSET]->23:27[NIGHT] segment produced a value matching
+    schedule-intensity-only scaling from this library, while the real
+    app displayed a much 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 led back
+    to re-examining the raw bytecode instead of trusting the decompiled
+    Java a second time.
     """
     if not points:
         return False
@@ -160,7 +174,7 @@ def is_night_segment(points: list[SchedulePoint], minute_of_day: int) -> bool:
             if t1 == t2:
                 return p1.has(SchedulePoint.FLAG_NIGHT)
             return (
-                not p1.has(SchedulePoint.FLAG_NIGHT)
+                p1.has(SchedulePoint.FLAG_NIGHT)
                 and not p1.has(SchedulePoint.FLAG_SUNRISE)
                 and p2.has(SchedulePoint.FLAG_NIGHT)
             )

{python_mobius-0.2.1 → python_mobius-0.3.0}/tests/test_device_summary.py

@@ -71,9 +71,12 @@ async def test_get_device_summary_includes_all_pump_fields():
         return responses[attr_id]
 
     async def fake_get_attribute_raw_all(attr_id, index=0, count=1):
+        from mobius.frame import AttributeValue
         if attr_id == C2Attribute.FirmwareVersion:
-            from mobius.frame import AttributeValue
             return [AttributeValue(int(attr_id), index=1, values=[bytes([4, 0, 21])])]
+        if attr_id == C2Attribute.HardwareRevision:
+            # Color=White(2), Revision=3, ProductType=VorTech(3)
+            return [AttributeValue(int(attr_id), index=1, values=[bytes([2]), bytes([3]), bytes([3])])]
         raise AssertionError(f"unmocked attribute (raw) in get_device_summary: {attr_id}")
 
     device.get_attribute = fake_get_attribute
@@ -81,10 +84,12 @@ async def test_get_device_summary_includes_all_pump_fields():
     summary = await device.get_device_summary()
 
     # The actual regression check: every field from all 7 previously-
-    # unwired methods must be present, plus firmware_versions.
+    # unwired methods must be present, plus firmware_versions and
+    # hardware_info (the same class of gap, caught again -- see
+    # get_device_summary()'s own "BUG NOTE" docstring).
     for key in ("flow_range", "pump_override_mode", "battery_backup",
                 "boosted_battery", "group", "calibration", "maintenance",
-                "firmware_versions"):
+                "firmware_versions", "hardware_info"):
         assert key in summary, f"{key!r} missing from get_device_summary() -- this is the exact bug this test guards against"
 
     assert summary["support"] == "pump"
@@ -96,6 +101,7 @@ async def test_get_device_summary_includes_all_pump_fields():
     assert summary["calibration"] is None  # unsupported in this mock (pump, as expected)
     assert summary["maintenance"].recommended_interval is None
     assert summary["firmware_versions"] == {"Radio": "4.0.21"}  # VorTechMP40wG3QD -> EcoTech label
+    assert summary["hardware_info"] == {"Color": "White", "Revision": 3, "ProductType": "VorTech"}
     assert summary["device_time"].device_epoch == 1700000000
 
 
@@ -142,12 +148,13 @@ async def test_get_device_summary_includes_generic_fields_for_lights_too():
         return responses[attr_id]
 
     async def fake_get_attribute_raw_all(attr_id, index=0, count=1):
+        from mobius.frame import AttributeValue
         if attr_id == C2Attribute.FirmwareVersion:
-            from mobius.frame import AttributeValue
             return [AttributeValue(int(attr_id), index=3, values=[bytes([1, 0])])]  # MainMicroOS
         if attr_id == C2Attribute.SupportedColorChannels:
-            from mobius.frame import AttributeValue
             return [AttributeValue(int(attr_id), index=0, values=[bytes([18])])]  # RoyalBlue
+        if attr_id == C2Attribute.HardwareRevision:
+            return [AttributeValue(int(attr_id), index=4, values=[bytes([2])])]  # RadioType=QCA4020(2)
         raise AssertionError(f"unmocked attribute (raw): {attr_id}")
 
     device.get_attribute = fake_get_attribute
@@ -159,6 +166,8 @@ async def test_get_device_summary_includes_generic_fields_for_lights_too():
     assert "calibration" in summary
     assert "firmware_versions" in summary
     assert summary["firmware_versions"] == {"Product OS": "1.0"}  # RadionXR15wG6Pro -> EcoTech label
+    assert "hardware_info" in summary
+    assert summary["hardware_info"] == {"RadioType": "QCA4020"}
     assert "maintenance" in summary
     # unlike the pump case, calibration IS populated here -- matches the
     # confirmed real-world light-only gating

{python_mobius-0.2.1 → python_mobius-0.3.0}/tests/test_firmware_versions.py

@@ -179,7 +179,7 @@ async def test_get_firmware_versions_empty_when_no_blocks_returned():
 # --------------------------------------------------------------------------
 
 @pytest.mark.asyncio
-async def test_get_hardware_info_returns_raw_bytes():
+async def test_get_hardware_info_decodes_confirmed_enum_fields():
     device = MobiusDevice(_fake_ble_device())
 
     async def fake_get_attribute_raw_all(attr_id, index=0, count=1):
@@ -193,7 +193,10 @@ async def test_get_hardware_info_returns_raw_bytes():
     device.get_attribute_raw_all = fake_get_attribute_raw_all
     info = await device.get_hardware_info()
 
-    assert info == {"Color": bytes([2]), "Revision": bytes([1]), "ProductType": bytes([3])}
+    # Color and ProductType are confirmed enums with confirmed labels --
+    # decoded, not raw bytes. Revision has no confirmed enum meaning --
+    # a plain integer, not formatted, but also not raw bytes anymore.
+    assert info == {"Color": "White", "Revision": 1, "ProductType": "VorTech"}
 
 
 @pytest.mark.asyncio
@@ -214,7 +217,74 @@ async def test_get_hardware_info_merges_multiple_blocks():
     device.get_attribute_raw_all = fake_get_attribute_raw_all
     info = await device.get_hardware_info()
 
-    assert info == {"Color": bytes([2]), "Revision": bytes([1]), "ProductType": bytes([3])}
+    assert info == {"Color": "White", "Revision": 1, "ProductType": "VorTech"}
+
+
+@pytest.mark.asyncio
+async def test_get_hardware_info_decodes_all_four_enum_fields():
+    """Confirms RadioType and MotorType decode too, not just Color/
+    ProductType -- all four confirmed enums, in one response."""
+    device = MobiusDevice(_fake_ble_device())
+
+    async def fake_get_attribute_raw_all(attr_id, index=0, count=1):
+        if attr_id == C2Attribute.HardwareRevision:
+            return [AttributeValue(
+                attr_id=int(attr_id), index=1,
+                # Color=White(2), Revision=5, ProductType=VorTech(3),
+                # RadioType=QCA4020(2), MotorType=VorTechMP40G3(3)
+                values=[bytes([2]), bytes([5]), bytes([3]), bytes([2]), bytes([3])],
+            )]
+        raise AssertionError(f"unexpected attribute: {attr_id}")
+
+    device.get_attribute_raw_all = fake_get_attribute_raw_all
+    info = await device.get_hardware_info()
+
+    assert info == {
+        "Color": "White", "Revision": 5, "ProductType": "VorTech",
+        "RadioType": "QCA4020", "MotorType": "VorTech MP40 G3",
+    }
+
+
+@pytest.mark.asyncio
+async def test_get_hardware_info_falls_back_gracefully_for_unrecognized_enum_value():
+    """A value outside this library's confirmed enum coverage (e.g.
+    firmware newer than what's been confirmed) must not raise -- falls
+    back to a clearly-marked "Unknown (N)" string rather than crashing
+    the whole fetch."""
+    device = MobiusDevice(_fake_ble_device())
+
+    async def fake_get_attribute_raw_all(attr_id, index=0, count=1):
+        if attr_id == C2Attribute.HardwareRevision:
+            return [AttributeValue(
+                attr_id=int(attr_id), index=1,
+                values=[bytes([250])],  # Color -- not a recognized Color value
+            )]
+        raise AssertionError(f"unexpected attribute: {attr_id}")
+
+    device.get_attribute_raw_all = fake_get_attribute_raw_all
+    info = await device.get_hardware_info()
+
+    assert info == {"Color": "Unknown (250)"}
+
+
+@pytest.mark.asyncio
+async def test_get_hardware_info_obfuscated_motor_type_labels_decode_correctly():
+    """Confirms the base64-decoded MotorType labels (Nero 7/Orbit 2/
+    Orbit 4/Axis 20/40/90/200) work, not just the plain-literal ones."""
+    device = MobiusDevice(_fake_ble_device())
+
+    async def fake_get_attribute_raw_all(attr_id, index=0, count=1):
+        if attr_id == C2Attribute.HardwareRevision:
+            return [AttributeValue(
+                attr_id=int(attr_id), index=5,
+                values=[bytes([18])],  # MotorType=Turtle1(18) -> "Axis 20"
+            )]
+        raise AssertionError(f"unexpected attribute: {attr_id}")
+
+    device.get_attribute_raw_all = fake_get_attribute_raw_all
+    info = await device.get_hardware_info()
+
+    assert info == {"MotorType": "Axis 20"}
 
 
 @pytest.mark.asyncio

{python_mobius-0.2.1 → python_mobius-0.3.0}/tests/test_light_intensity_branching.py

@@ -18,17 +18,21 @@ def _fake_ble_device():
 
 
 def _night_schedule():
-    """A 2-point schedule: 18:00 (day, MoonlightWhite=0) -> 22:00 (NIGHT, MoonlightWhite=1000)."""
-    day_point = (
-        (1080).to_bytes(2, "little") + bytes([SchedulePoint.FLAG_ACTIVE])
+    """A 2-point schedule: 22:00 (NIGHT, MoonlightWhite=0) -> 23:00 (NIGHT,
+    MoonlightWhite=1000) -- a genuine night-to-night segment (confirmed
+    from raw smali bytecode: is_night_segment() requires the START point
+    to ALREADY be night-flagged, not the dusk-transition segment leading
+    into it -- see that function's own docstring for the full trace)."""
+    point_a = (
+        (1320).to_bytes(2, "little") + bytes([SchedulePoint.FLAG_ACTIVE | SchedulePoint.FLAG_NIGHT])
         + bytes([31]) + (0).to_bytes(2, "little")  # MoonlightWhite(31) = 0
     )
-    night_point = (
-        (1320).to_bytes(2, "little")
+    point_b = (
+        (1380).to_bytes(2, "little")
         + bytes([SchedulePoint.FLAG_ACTIVE | SchedulePoint.FLAG_NIGHT])
         + bytes([31]) + (1000).to_bytes(2, "little")
     )
-    return [day_point, night_point]
+    return [point_a, point_b]
 
 
 def _day_schedule():
@@ -51,14 +55,14 @@ async def test_night_segment_with_lunar_enabled_uses_lunar_reduction():
         raise AssertionError(f"unexpected attribute during night+lunar test: {attr_id}")
 
     device.get_attribute = fake_get_attribute
-    # 20:00, inside the dusk-to-night segment; real NEW moon date -> reduction 0.0
-    # (deliberately not a full-moon date, so this test is actually
-    # distinguishable from the "no lunar" case below, which stays at scalar 1.0
-    # regardless of date)
+    # 22:30, inside the night-to-night segment (22:00[NIGHT]->23:00[NIGHT]);
+    # real NEW moon date -> reduction 0.0 (deliberately not a full-moon
+    # date, so this test is actually distinguishable from the "no lunar"
+    # case below, which stays at scalar 1.0 regardless of date)
     now = datetime.datetime(2026, 1, 18, 20, 0)
-    result = await device.get_current_light_intensities(minute_of_day=1200, now=now)
+    result = await device.get_current_light_intensities(minute_of_day=1350, now=now)
 
-    # interpolated MoonlightWhite at 20:00 (50% through 18:00->22:00) = 500,
+    # interpolated MoonlightWhite at 22:30 (50% through 22:00->23:00) = 500,
     # times lunar reduction 0.0 (new moon) = 0.0
     assert result[VisualID.MoonlightWhite] == pytest.approx(0.0)
     # The actual diagnostic fields this test exists to cover -- added
@@ -85,7 +89,7 @@ async def test_night_segment_without_lunar_uses_full_scalar():
     # same new-moon date as the test above -- if lunar reduction were being
     # applied here too, this would also read ~0.0; confirms it isn't.
     now = datetime.datetime(2026, 1, 18, 20, 0)
-    result = await device.get_current_light_intensities(minute_of_day=1200, now=now)
+    result = await device.get_current_light_intensities(minute_of_day=1350, now=now)
 
     # scalar = 1.0 (no reduction) -> raw interpolated value (500) unchanged
     assert result[VisualID.MoonlightWhite] == pytest.approx(500.0)

{python_mobius-0.2.1 → python_mobius-0.3.0}/tests/test_modifiers.py

@@ -118,13 +118,31 @@ def _point(minute, flags):
     return SchedulePoint(minute, flags, LightPrimitive({}))
 
 
-def test_dusk_to_night_segment_detected():
+def test_dusk_transition_segment_itself_is_not_night_segment():
+    """Confirmed from raw smali bytecode (not the decompiled Java, which
+    had this exact condition inverted -- see is_night_segment()'s own
+    docstring): the segment transitioning INTO night (start point not
+    yet night-flagged) is explicitly NOT considered a night segment --
+    only segments where the START point is ALREADY night-flagged are."""
     # 18:00 (1080) not-night/not-sunrise -> 22:00 (1320) night
     points = [
         _point(1080, SchedulePoint.FLAG_ACTIVE),
         _point(1320, SchedulePoint.FLAG_ACTIVE | SchedulePoint.FLAG_NIGHT),
     ]
-    assert is_night_segment(points, 1200)  # 20:00, inside the dusk segment
+    assert not is_night_segment(points, 1200)  # 20:00, inside the dusk-transition segment
+
+
+def test_segment_between_two_night_flagged_points_is_a_night_segment():
+    """The actual real-world scenario this bug was found from: a light
+    showing lunar-consistent values in the app while this library
+    computed schedule-intensity-only values at the exact same moment, in
+    a segment where BOTH endpoints were night-flagged
+    (23:00[NIGHT,SUNSET] -> 23:27[NIGHT])."""
+    points = [
+        _point(1380, SchedulePoint.FLAG_ACTIVE | SchedulePoint.FLAG_NIGHT),  # 23:00
+        _point(1407, SchedulePoint.FLAG_ACTIVE | SchedulePoint.FLAG_NIGHT),  # 23:27
+    ]
+    assert is_night_segment(points, 1395)  # 23:15, well within this segment
 
 
 def test_segment_not_flagged_night_is_false():
@@ -144,10 +162,28 @@ def test_sunrise_flagged_start_point_is_not_dusk_segment():
     assert not is_night_segment(points, 1200)
 
 
-def test_exact_match_on_night_flagged_point():
+def test_exact_match_on_start_of_a_night_qualifying_segment():
+    """is_night_segment() is fundamentally about which SEGMENT the query
+    time falls into, not "is this point itself night-flagged" in
+    isolation -- a query time exactly at a segment's start still
+    evaluates that segment's own start/end flags normally, not some
+    separate "exact match" special case (that only exists for a
+    genuinely zero-width segment, i.e. two points sharing the same
+    time -- see the t1==t2 branch)."""
     points = [
         _point(1320, SchedulePoint.FLAG_ACTIVE | SchedulePoint.FLAG_NIGHT),
-        _point(480, SchedulePoint.FLAG_ACTIVE),
+        _point(1440, SchedulePoint.FLAG_ACTIVE | SchedulePoint.FLAG_NIGHT),  # wraps to 0 (midnight)
+    ]
+    assert is_night_segment(points, 1320)  # exactly at the segment's own start
+
+
+def test_exact_match_on_a_zero_width_segment():
+    """The genuine "exact match" special case -- two points sharing the
+    same time (t1==t2), where the segment's own start point flag decides
+    it directly, no end-point/sunrise check involved."""
+    points = [
+        _point(1320, SchedulePoint.FLAG_ACTIVE | SchedulePoint.FLAG_NIGHT),
+        _point(1320, SchedulePoint.FLAG_ACTIVE | SchedulePoint.FLAG_NIGHT),
     ]
     assert is_night_segment(points, 1320)