python-mobius 0.5.0__tar.gz → 0.7.0__tar.gz

{python_mobius-0.5.0 → python_mobius-0.7.0}/CHANGELOG.md

@@ -1,5 +1,49 @@
 # Changelog
 
+## 0.7.0
+
+- Added get_full_poll_batch() -- one round-trip for device identity +
+  metadata + light/pump state, confirmed 2-2.6x faster on real
+  hardware. Requires the caller to already know the device's own
+  PrimitiveType (permanent for its lifetime, so never re-fetched).
+- get_current_pump_block() now accepts an optional pre-fetched
+  `points` param, skipping its own redundant re-fetch of the same
+  schedule attribute.
+- Added get_light_poll_batch() -- one round-trip for a light's own
+  schedule, lunar/acclimation/insolation state, and Epoch/LocalTime,
+  falling back to the original individual reads if the batch fails.
+- Extracted every light-schedule-related method's own decode/compute
+  logic into pure, standalone functions, laying the groundwork for
+  get_light_poll_batch() above. No behavior change.
+
+## 0.6.0
+
+- get_metadata_batch() now falls back to individual reads if the
+  batched request itself fails (e.g. no batch support at all) --
+  never returns less than those would have. New `used_batch` field,
+  `force_individual_reads` param.
+- Added get_metadata_batch() -- one round-trip for AdvancedFeatures/
+  CalibrationInfo/hardware/firmware/channels/error state/time,
+  confirmed 6-14x faster than individual reads over relay.
+- Wired set_advanced_features() into cli.py -- one flag per field
+  (--set-local-control-enabled/--set-auto-dim-timeout/
+  --set-max-fan-speed/--set-fan-shutdown-enabled).
+- Added set_advanced_features() -- writes LocalControlEnabled/
+  AutoDimTimeout/MaxFanSpeed/FanShutdownEnabled, whichever are given.
+- get_current_light_intensities() now uses get_app_lunar_date(),
+  deliberately replicating a confirmed app bug in its lunar
+  calculation instead of the physically correct date.
+- Fixed RelayedMobiusDevice missing overrides for
+  get_supported_attributes()/get_attributes_batch() -- both bypassed
+  the relay path entirely.
+- Fixed --dump-attributes/--set-time-to-now in cli.py ignoring
+  --relay-target.
+- Added get_attributes_batch() -- reads multiple attributes in one
+  round-trip.
+- Added get_supported_attributes()/dump_attributes()/
+  enrich_attribute_dump(), replicating the app's own attribute-dump
+  feature. New CLI flags: --dump-attributes/--parse-dump.
+
 ## 0.5.0
 
 - get_pump_telemetry() now returns gph_reliable/minimum_gph/maximum_gph
@@ -333,8 +377,8 @@ branch has been merged into main as part of this release.
   is a bare, meaningless ack the app itself discards, confirmed
   byte-for-byte via real hardware testing showing exactly 1 byte in every
   relayed read's outer response), matched purely by CoAP token
-  (confirmed via reverse engineering: `coapRequest.getToken() ==
-  coapResponse.getToken()`), never by the outer FSCI message ID. Added
+  (confirmed via reverse engineering: the request's own token must
+  match the response's own token), never by the outer FSCI message ID. Added
   `MobiusDevice._register_coap_token()`/`wait_for_coap_response()` -- a
   token-keyed pending-response registry, entirely separate from the
   existing message-ID-based `self._pending` mechanism -- wired into
@@ -452,7 +496,8 @@ branch has been merged into main as part of this release.
   (`get_device_summary()`, `get_current_light_intensities()`, etc.) works
   transparently through relay, confirmed with a test that specifically
   exercises an inherited high-level method rather than just the
-  overridden primitives. Confirmed `request.getData(true)` builds a
+  overridden primitives. Confirmed via reverse engineering the app that its
+  own request wrapping builds a
   complete self-contained FSCI frame (byte-for-byte identical in
   structure to this library's own `build_frame()`), resolving an
   ambiguity flagged in an earlier commit -- relaying a request needed no
@@ -564,10 +609,11 @@ branch has been merged into main as part of this release.
 
 - **Major fix: device identity is now serial-number-based, not BLE-address-based.**
   Real-world testing surfaced a device whose advertised MAC address changed
-  between runs. Investigating the decompiled app's own `Peripheral` class
+  between runs. Investigating the app via reverse engineering
   confirmed the official app never relies on address stability at all --
-  `Peripheral.equals()`/`hashCode()` are based purely on serial number, and
-  `Peripheral.update()` explicitly replaces the stored BLE address whenever
+  its own equality and hash logic for a discovered device are based purely
+  on serial number, and
+  its own update logic explicitly replaces the stored BLE address whenever
   a new scan matches an existing device by serial. This library previously
   assumed address stability throughout.
   - New `find_device_by_serial()` and `dedupe_by_serial()`
@@ -644,8 +690,8 @@ branch has been merged into main as part of this release.
   0-100+ percentages instead of raw permille, flagging boosted channels via
   `.diagnostics["hyperdrive_channels"]`. Confirmed byte-identical to the
   old `raw/10` shortcut for the common (non-boosted) case; only changes
-  results for genuinely boosted channels. `LightPowerInfo`'s Prime/Hydra-
-  specific `gm8b4()` wattage override table is not replicated -- see
+  results for genuinely boosted channels. A confirmed Prime/Hydra-
+  specific wattage override table is not replicated -- see
   `documentation/06-light-schedule.md`.
   - Also refactored `get_attribute()` into a thin wrapper around a new
     `get_attribute_raw()`, which preserves the device-reported response
@@ -715,11 +761,11 @@ branch has been merged into main as part of this release.
   Home Assistant integration on top of this library -- the hex-encoded
   serial was producing unnecessarily long/ugly entity IDs.
 - `get_pump_telemetry()` now includes a confirmed `"speed_percent"` field
-  alongside the existing raw `"speed"`. `MotorSpeed` is confirmed (via the
-  decompiled app's own display code) to be a percentage of max pump power
-  in tenths of a percent, NOT RPM -- `String.format("%.0f%%",
-  Math.abs(currentSpeed / 10.0f))` is literally what the app does to this
-  exact value. `speed_percent` is that same `abs(speed)/10` conversion;
+  alongside the existing raw `"speed"`. `MotorSpeed` is confirmed (via
+  reverse engineering the app's own display code) to be a percentage of max pump power
+  in tenths of a percent, NOT RPM -- the app's own display logic formats
+  this same value with the exact same abs-value, tenths-to-percent
+  conversion. `speed_percent` is that same `abs(speed)/10` conversion;
   `speed` is still returned raw since its sign encodes rotation direction
   (reverse), which `speed_percent` discards.
 - Fixed a real connection leak in `MobiusDevice.connect()`: if

{python_mobius-0.5.0 → python_mobius-0.7.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: python-mobius
-Version: 0.5.0
+Version: 0.7.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
@@ -124,6 +124,12 @@ mobius-scan --adapter hci0
 - **Reboot a device** (`reboot()`) — a WRITE, matching the app's own
   "Restart" button exactly. Confirmed against real hardware directly
   connected; not yet confirmed via relay.
+- **Dump every attribute a device supports** (`dump_attributes()`),
+  matching the app's own Settings → Troubleshoot diagnostic feature's
+  data collection — confirmed against real hardware. Output is enriched
+  JSON (resolved names, decoded values where known), not the app's own
+  plain-text format. See
+  [13-attribute-dump.md](./documentation/13-attribute-dump.md).
 - **Low-level protocol access** (`build_frame`, `get_attribute`,
   `set_attribute`, ...) if you want to go beyond what's wrapped in
   `MobiusDevice`.

{python_mobius-0.5.0 → python_mobius-0.7.0}/README.md

@@ -92,6 +92,12 @@ mobius-scan --adapter hci0
 - **Reboot a device** (`reboot()`) — a WRITE, matching the app's own
   "Restart" button exactly. Confirmed against real hardware directly
   connected; not yet confirmed via relay.
+- **Dump every attribute a device supports** (`dump_attributes()`),
+  matching the app's own Settings → Troubleshoot diagnostic feature's
+  data collection — confirmed against real hardware. Output is enriched
+  JSON (resolved names, decoded values where known), not the app's own
+  plain-text format. See
+  [13-attribute-dump.md](./documentation/13-attribute-dump.md).
 - **Low-level protocol access** (`build_frame`, `get_attribute`,
   `set_attribute`, ...) if you want to go beyond what's wrapped in
   `MobiusDevice`.

{python_mobius-0.5.0 → python_mobius-0.7.0}/documentation/00-overview.md

@@ -34,7 +34,7 @@ Interface conventions, extended by EcoTech).
    and two Radion XR15 G6 Pro lights, all sharing one tank. Every field
    marked "confirmed" in these docs was checked this way — either by
    successfully round-tripping known values, or by cross-validating two
-   independent derivations (e.g. a value read via decompiled Java source
+   independent derivations (e.g. a value read via a decompiled source
    matching a value read live over BLE).
 
 ## Document map
@@ -53,12 +53,14 @@ Interface conventions, extended by EcoTech).
 | [10-known-gaps-and-open-questions.md](./10-known-gaps-and-open-questions.md) | Everything not yet confirmed or implemented |
 | [11-device-status-attributes.md](./11-device-status-attributes.md) | Flow range, override mode, battery backup, group/sync, calibration (light-only), maintenance |
 | [12-device-identity-and-address-stability.md](./12-device-identity-and-address-stability.md) | Why device identity is serial-number-based, not address-based |
+| [13-attribute-dump.md](./13-attribute-dump.md) | Reading every attribute a device supports, enriched JSON output, the app-compatible text format |
+| [14-batched-attribute-reads.md](./14-batched-attribute-reads.md) | Reading multiple, different attributes in one round-trip |
 
 ## On the use of AI assistance
 
 The decompiled-source analysis, protocol derivation, and Python
 implementation in this project were done with substantial assistance from
-Claude (Anthropic) — reading the decompiled Java sources, cross-referencing
+Claude (Anthropic) — reading the decompiled app sources, cross-referencing
 them against the public community research above, resolving several
 decompilation artifacts specific to the reverse-engineering process (see
 [03-attributes-and-opcodes.md](./03-attributes-and-opcodes.md) for a

{python_mobius-0.5.0 → python_mobius-0.7.0}/documentation/02-framing-and-crc.md

@@ -26,7 +26,7 @@ using this library's own encoder, matching the captured bytes exactly (see
 
 ## opGroup values
 
-Java's original constants are signed bytes:
+The app's own original constants are signed bytes:
 
 | Name | Signed | Unsigned (hex) |
 |---|---|---|

{python_mobius-0.5.0 → python_mobius-0.7.0}/documentation/06-light-schedule.md

@@ -190,32 +190,65 @@ automatically -- no separate calls needed for the common case.
 **`get_lunar_phase_info()`**: reads `LunarPhasesCurrentDay`/
 `LunarPhasesCurrentScalar` directly off the device -- its own
 firmware-computed lunar state, confirmed against real hardware to
-match `LUNAR_CYCLE_SCALERS[current_day]` exactly, even though the app
-itself never reads either attribute (it always computes the
-equivalent value client-side, the same way this library does). Useful
-as an independent cross-check against this library's own calculated
-value.
-
-**A confirmed bug in the app itself, not in this library**: the app's
-own `date`-to-calendar-day conversion
-(`LunarInfo.jdFromGregorianDate()`) applies the phone's own local
-timezone via `Calendar.getInstance()` on top of a value
-(`Tank.getDateTime().date()`) that's already timezone-adjusted once
-(the device's own `Epoch`-to-`LocalTime` offset). This double
-application means the app's own displayed lunar value rolls over to
-the next calendar day exactly one UTC-offset early, relative to the
-device's true local midnight (assuming the phone and device agree on
-timezone, the common case) -- confirmed via the exact arithmetic and
-via the general symptom matching (a real, reported case of the app
-showing the next day's value visibly before midnight, on a
-device/phone at UTC+1, consistent with this mechanism). The precise
-one-hour timing itself is a derived prediction from the arithmetic,
-not something separately checked against a clock. This library's own calculation (and the device's own
-firmware, per `get_lunar_phase_info()` above) doesn't have this bug --
-both correctly roll over at true local midnight. A mismatch between
-this library's own calculated lunar value and the app's own displayed
-one, specifically around midnight, is expected and doesn't indicate
-anything wrong with this library.
+match `LUNAR_CYCLE_SCALERS[current_day]` exactly. This is a THIRD,
+independent value from the two below -- see the real-hardware findings
+just below for why all three (this one, the app's own display, and
+what the LEDs physically do) can genuinely differ from each other.
+
+**A confirmed bug in the app itself -- and this library deliberately
+replicates it.** The app's own `date`-to-calendar-day conversion
+(confirmed via disassembling the actual raw bytecode with androguard,
+not just the decompile -- see `get_app_lunar_date()`'s own docstring
+in device.py for the full instruction-level trace) applies a timezone
+shift TWICE: once converting `Epoch` to `LocalTime` (the device's own
+job), and again via the phone's own equivalent calendar-day
+conversion, reading the PHONE's own
+timezone off a value that's already been shifted once. When phone and
+device agree on timezone (assumed here, since this library can't know
+the phone's own setting), the net effect is the SAME offset applied
+twice -- not once. For UTC+1, that means the app's own effective
+calendar day rolls over **two hours early**, not one -- confirmed by
+working the exact arithmetic (`2 * LocalTime - Epoch`) and
+independently verified against real captured device data spanning
+both a real summer evening and a forced-clock winter test:
+
+- **Summer (UTC+1)**: at 23:25 and again at 23:55 local -- both well
+  before that night's true midnight -- the app's own formula computed
+  the NEXT calendar day's scalar, while the device's own reported
+  `LunarPhasesCurrentDay`/`CurrentScalar` were both still on the
+  PREVIOUS day at those exact same moments. The two only agreed again
+  once true midnight had actually passed.
+- **Winter (UTC+0)**: the formula and the device's own reported values
+  agreed exactly at every point tested -- confirming the shift
+  magnitude really does scale with the timezone offset, and vanishes
+  entirely at zero.
+
+`get_current_light_intensities()` uses `get_app_lunar_date()`
+specifically (not `get_device_local_date()`, which is the physically
+correct one) for this calculation, because this method's own stated
+job is to replicate what the app itself shows -- bugs included, not to
+compute ground truth. A `ha-mobius` user comparing this library's
+output against the official app should see them agree, including
+during the window where the app is (confirmedly) wrong about the
+calendar day.
+
+**A separate, ALSO real-hardware-confirmed finding: the device's own
+physical LED output doesn't track EITHER of the above continuously.**
+Three real dumps of a real light, spanning an actual midnight
+rollover, cross-checked against the device's own live `Intensity`
+(1500) readback and direct visual/power observation, showed the
+device locks its own scalar in ONCE -- at the moment the evening's
+ramp into the night segment physically completes -- and holds that
+exact value fixed for the rest of the night, regardless of what
+`LunarPhasesCurrentDay`/`CurrentScalar` do afterward. Neither this
+library's own calculation nor the app's own display attempts to model
+this transition-locked behavior; both compute a value continuously,
+as if the physical output tracked the calendar day in real time. It
+doesn't. This is a third, genuinely different value from the two
+above, not a bug in either of them -- there's no confirmed way to
+predict the device's own physical value from `Epoch`/`LocalTime` alone
+without also knowing when the most recent schedule transition into
+the night segment actually completed.
 
 ## Insolation detection (flagged, not implemented)
 
@@ -242,22 +275,31 @@ from the manually-programmed one on a given day.
 
 `.diagnostics` also includes `"is_night_segment"`, `"lunar_enabled"`,
 `"scalar_source"` (one of `"lunar"`/`"night_no_lunar"`/
-`"schedule_intensity"`), and `"scalar"` (the actual final multiplier
-applied) -- useful for telling apart which branch/scalar produced a given
-value, e.g. when a computed value doesn't match the app's own displayed
-one and it isn't obvious whether `is_night_segment()` misjudged a
-schedule's point structure or `get_lunar_enabled()` read incorrectly:
+`"schedule_intensity"`), `"scalar"` (the actual final multiplier
+applied), and, specifically for the `"lunar"` case, `"lunar_date"` (the
+actual date `get_app_lunar_date()` computed -- see that section above
+for why this is deliberately the app's own, confirmed-buggy value, not
+the physically correct one) and `"lunar_date_source"` (one of
+`"app_lunar_date"`/`"local_fallback"`) -- useful for telling apart
+which branch/scalar produced a given value, e.g. when a computed value
+doesn't match the app's own displayed one and it isn't obvious whether
+`is_night_segment()` misjudged a schedule's point structure,
+`get_lunar_enabled()` read incorrectly, or the date computation itself
+went wrong:
 
 ```python
 result = await device.get_current_light_intensities()
 print(result.diagnostics)
 # {'insolation_active': False, 'is_night_segment': True,
-#  'lunar_enabled': True, 'scalar_source': 'lunar', 'scalar': 0.35}
+#  'lunar_enabled': True, 'scalar_source': 'lunar', 'scalar': 0.6,
+#  'lunar_date': datetime.date(2026, 8, 29), 'lunar_date_source': 'app_lunar_date'}
 ```
 
 `lunar_enabled` is `None` (not `False`) when `is_night_segment` is
 `False`, since it isn't checked/relevant outside the night segment --
-don't read a `None` here as "lunar phases are off."
+don't read a `None` here as "lunar phases are off." Similarly,
+`lunar_date`/`lunar_date_source` are both `None` whenever
+`scalar_source` isn't `"lunar"`.
 
 ## Hyperdrive (boosted channels above 100%)
 
@@ -271,7 +313,7 @@ how much headroom that specific channel actually has.
 `get_current_light_percentages()` accounts for this: it fetches
 `MaxPower`/`NormalPower` (`get_channel_power_info()`, attributes `1504`/
 `1513`) and applies `channel_percent_value()` (`mobius.power`, ported from
-`LightPowerInfo.getPercentValue()`) per channel. For the common case --
+the app's own confirmed equivalent logic) per channel. For the common case --
 non-hyperdrive channels/devices, i.e. any raw value at or below 1000 --
 this gives the same results as a simple `raw/10`; the extra machinery
 only changes anything for genuinely boosted channels. It also flags which
@@ -282,22 +324,39 @@ alone (two more `Get`s for `MaxPower`/`NormalPower`). Use
 `get_current_light_intensities()` directly if hyperdrive accuracy isn't
 needed, or to minimize round trips.
 
-**Not replicated**: `LightPowerInfo`'s `gm8b4()` lookup table -- a
+**Not replicated**: a lookup table confirmed present in the app -- a
 hardcoded wattage override for a handful of specific AquaIllumination
 Prime/Hydra model + channel combinations. Only relevant to those specific
 models; the general case (including every EcoTech Radion model this
 library has been verified against) doesn't use it.
 
-## Not implemented here
+## The insolation modifier itself -- not implemented here
+
+Raw reading of the underlying attributes IS implemented (see
+`get_insolation_tables()`/`InsolationTables` below) -- what's NOT
+implemented is the client-side modifier that would actually use this
+table to adjust intensity based on the calendar day, the way
+`mobius.modifiers`'s own lunar/acclimation modifiers already do for
+their own attributes.
 
 - "Insolation" -- a real per-calendar-day natural daylight simulation:
-  each light stores a 365-entry table (one per day of the year, packed
-  into 8 bytes via `InsolationTable1`/`InsolationTable2`), where every
-  entry holds sunrise time, sunset time, sun intensity (0-100%), moonrise
-  time, moonset time, and moon intensity (0-100%) for that specific
-  calendar day. Lets a light automatically track real seasonal daylight
+  each light stores a 365-entry table (one per day of the year), where
+  every entry holds sunrise time, sunset time, sun intensity (0-100%),
+  moonrise time, moonset time, and moon intensity (0-100%) for that
+  specific calendar day. Confirmed via reverse engineering the app that
+  each entry is packed into 8 bytes -- but the actual raw bytes read
+  from `InsolationTable1`/`InsolationTable2` (see
+  `get_insolation_tables()`/`InsolationTables` in device_status.py) are
+  9 bytes per entry on a real light; this discrepancy is unresolved,
+  and since every entry captured so far was all-zero (unconfigured),
+  there's no way to independently confirm the field-level byte layout
+  either way. `get_insolation_tables()` returns raw per-entry bytes
+  rather than decoding this structure, for exactly that reason. Lets a
+  light automatically track real seasonal daylight
   variation instead of running one fixed schedule year-round. Gated
-  behind `AccountSettings.hasPermission()` in the app -- likely a
-  paid/premium feature, not merely an obscure one. Not implemented here;
-  treated as always-disabled.
+  behind an account-level permission check in the app -- likely a
+  paid/premium feature, not merely an obscure one. The lunar/
+  acclimation MODIFIERS in `mobius.modifiers` are implemented and
+  confirmed; this separate, rarer modifier is not, and is treated as
+  always-disabled by those modifiers.
 - Writing/programming a schedule (only reading is implemented).

{python_mobius-0.5.0 → python_mobius-0.7.0}/documentation/08-manufacturer-data.md

@@ -25,15 +25,17 @@ care which company ID a payload came from.
 
 ## Payload format
 
-`bleak` strips the 2-byte company-ID prefix that the original Java parser
-(`Peripheral.parseManufactureData`) expects as part of its input — so this
+`bleak` strips the 2-byte company-ID prefix that the app's own equivalent
+parser expects as part of its input — so this
 library's `parse_manufacturer_data()` takes the already-stripped 23-byte
-`bleak` payload directly, which corresponds to `javaBArr[2:]`.
+`bleak` payload directly, which corresponds to the app's own byte array
+starting at its own index 2.
 
-The decompile has several format branches keyed by total length and a
+The app has several format branches keyed by total length and a
 "version" byte (the company ID's own low byte -- see "Company ID" above);
 **only the branch actually observed on real hardware is implemented**
-(23-byte `bleak` payload / 25-byte original Java `bArr` length) --
+(23-byte `bleak` payload / 25-byte length in the app's own byte-array
+numbering) --
 confirmed identical for both company IDs' own "version 1"/"version 2"
 variant of this specific length. Payloads of any other length return
 `None` rather than guessing at an unimplemented branch.
@@ -79,11 +81,12 @@ payload, i.e. what `parse_manufacturer_data()` actually receives.)
 
 ## "Flags" — deliberately not exposed
 
-`javaBArr[1]` is the company ID's own *high byte* — for EcoTech Marine
+The byte right after the company ID is the company ID's own *high byte* -- for EcoTech Marine
 (`0x0202`) that's a constant `0x02`; for AquaIllumination (`0x0001`)
-it's a constant `0x00`. The decompile still gives this byte its own,
-different treatment per company ID: the EcoTech branch just wraps it
-in an opaque `Flags` object with no further use shown; the
+it's a constant `0x00`. The app gives this byte its own,
+different treatment per company ID, confirmed via reverse engineering it: the
+EcoTech branch just wraps it
+in an opaque `Flags`-style value with no further use shown; the
 AquaIllumination branch reads it as `pendingNotifications = byte > 0`
 (always `False`, since the byte is a constant `0x00`). Either way,
 it's not independent payload data — decoding "flags" here would just

{python_mobius-0.5.0 → python_mobius-0.7.0}/documentation/09-thread-coap-relay.md

@@ -50,19 +50,21 @@ alongside the existing Get(`0x17`)/Set(`0x18`) attribute opcodes:
   response actually arrives, as a separate, asynchronous message
   ("indication"). Matched to its originating request purely by CoAP
   token, confirmed via reverse engineering the app's own exact
-  comparison:
-  `coapRequest.getToken() == coapResponse.getToken()`. The outer FSCI
+  comparison: the
+  request's own token must match the response's own token. The outer FSCI
   message ID is never used for this correlation -- it only has meaning
   for the single BLE hop to the gateway, not across a full Thread mesh
   round-trip.
 
-**Request** (`encode_coap_request()`) -- `CoapRequest`'s constructor:
+**Request** (`encode_coap_request()`) -- confirmed via reverse
+engineering the app's own equivalent request-construction logic:
 ```
 IPv6(16 bytes, REVERSED) + token(4, LE) + method(2, LE)
 + payload_length(2, LE) + request_type(1) + payload
 ```
 
-**Response** (`decode_coap_response()`) -- `CoapResponse`'s constructor:
+**Response** (`decode_coap_response()`) -- confirmed via reverse
+engineering the app's own equivalent response-construction logic:
 ```
 IPv6(16 bytes, NOT reversed) + token(4, LE) + response_code(2, LE)
 + payload_length(2, LE) + request_type(1) + payload

{python_mobius-0.5.0 → python_mobius-0.7.0}/documentation/10-known-gaps-and-open-questions.md

@@ -92,6 +92,28 @@ included as a starting point.
   matching it against known devices in a scan result is left to the
   caller.
 
+## Deferred: broader use of batched attribute reads
+
+`get_attributes_batch()` (see
+[14-batched-attribute-reads.md](./14-batched-attribute-reads.md)) reads
+multiple, different attributes in one round-trip — confirmed as a real
+capability, currently used only by `dump_attributes()`. `get_device_summary()`
+makes ~15-20 sequential single-attribute-ish sub-calls of its own, several
+of which are simple, few-attribute reads that could be consolidated the
+same way; `ha-mobius`'s own `coordinator.py` has a separate, independent
+~9-10 call sequence per poll that would need its own, similarly-scoped
+pass (it doesn't call `get_device_summary()` at all, so optimizing that
+method alone wouldn't help it).
+
+Deliberately deferred rather than attempted as one sweeping change: many
+of those sub-calls aren't simple attribute reads at all (schedule
+reading, model/primitive-dependent telemetry dispatch), and rewriting
+them to fit a shared batch risks regressing already-confirmed, working
+behavior for a broad efficiency gain that hasn't been scoped call-by-call
+yet. Left for a future pass — planned before a 1.0.0 release, not
+abandoned — starting with identifying which specific sub-calls in each
+repo are safely batchable vs. not, rather than assuming all of them are.
+
 ## Things that are correctness-affecting gotchas, not gaps
 
 - **`IntEnum` zero-value truthiness.** `ErrorState.NoError` and

{python_mobius-0.5.0 → python_mobius-0.7.0}/documentation/11-device-status-attributes.md

@@ -233,10 +233,10 @@ interpreted using its own block's starting index (never assuming one
 single starting index covers every returned value).
 
 **Firmware version display labels are fully confirmed against real
-hardware.** `FirmwareType.name(Model)` in the decompiled app maps each
+hardware.** The app's own confirmed firmware-label lookup maps each
 `FirmwareType` value to the exact label shown in the UI, gated by
-manufacturer. For EcoTech Marine devices specifically (the `isEtm()`
-branch), confirmed to match real output exactly:
+manufacturer. For EcoTech Marine devices specifically,
+confirmed to match real output exactly:
 
 | `FirmwareType` | Value | Label |
 |---|---|---|

{python_mobius-0.5.0 → python_mobius-0.7.0}/documentation/12-device-identity-and-address-stability.md

@@ -11,17 +11,11 @@ identity, never on address stability: its own equality and hash logic
 for a discovered device compares serial numbers only, and its own
 "update" logic for a re-seen device explicitly replaces the stored BLE
 address with whatever the device is currently advertising, rather than
-treating a changed address as a different device.
-
-`equals()`/`hashCode()` never reference the BLE address at all -- only
-`serialNumber`. `update()`, called whenever a new scan result matches an
-*existing* `Peripheral` by serial number, explicitly **overwrites** the
-stored `BluetoothDevice` (which encapsulates the address) with whatever
-came from the new scan result. This is the app's designed architecture
-for handling devices whose BLE address may change over time (plausibly
-BLE resolvable-private-address rotation, though this library doesn't
-need to know the mechanism, only that the address isn't a safe long-term
-identifier).
+treating a changed address as a different device. This is the app's
+designed architecture for handling devices whose BLE address may change
+over time (plausibly BLE resolvable-private-address rotation, though
+this library doesn't need to know the mechanism, only that the address
+isn't a safe long-term identifier).
 
 ## API