python-mobius 0.2.1__py3-none-any.whl → 0.3.1__py3-none-any.whl

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",

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

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

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)
             )

mobius/schedule.py

@@ -88,6 +88,41 @@ def interpolate_light_schedule(points: list[SchedulePoint], minute_of_day: int)
     schedule points and a target time (0-1439, minutes since midnight),
     returns {VisualID: intensity_permille} by linearly interpolating between
     the two points that bracket that time, wrapping around midnight.
+
+    Applies LightPrimitive.flatten()'s confirmed semantics (see that
+    method and its two call sites in getIntensitiesAtTime() in the real
+    smali -- 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 raw bytecode
+    rather than trusted from the decompile alone): the "Brightness"
+    channel (VisualID.Brightness) is a master dimmer that multiplies
+    every OTHER channel -- confirmed via real hardware testing that this
+    was missing entirely: MoonlightBlue/White (and every other color
+    channel) were computed without ever being scaled by Brightness,
+    which the real app clearly does (a light showing ~1% in the app's
+    own "Current Intensities" 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 -- consistent with the missing
+    multiplication, not a lunar or scheduling bug).
+
+    Critically, this flattening happens to EACH bracketing point
+    SEPARATELY (each point's own non-Brightness channels multiplied by
+    that SAME point's own Brightness value) BEFORE interpolating between
+    the two already-flattened points -- not interpolate raw values first
+    and apply a single Brightness value at the end. These are NOT
+    mathematically equivalent whenever Brightness itself changes across
+    the segment (which it usually does, e.g. ramping 0->1000 during a
+    dusk/dawn transition) -- confirmed by the smali calling flatten() on
+    both point copies before the interpolation loop, not after it.
+
+    "Brightness" itself is deliberately NOT flattened to 1000 in the
+    returned dict the way the real flatten() call does internally --
+    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, not a
+    constant 100%. Returned as the plain raw interpolation between the
+    two points' own Brightness values, same as before this fix.
     """
     if not points:
         return {}
@@ -109,12 +144,26 @@ def interpolate_light_schedule(points: list[SchedulePoint], minute_of_day: int)
         if t1 <= m <= t2:
             span = (t2 - t1) or 1
             frac = (m - t1) / span
+
+            # Each point's own Brightness value, defaulting to 1000 (a
+            # no-op multiplier) if that point doesn't have a Brightness
+            # channel at all -- matches flatten()'s own
+            # visuals().contains(Brightness) guard, which skips scaling
+            # entirely rather than treating an absent channel as 0.
+            b1 = p1.light.get(VisualID.Brightness) if VisualID.Brightness in p1.light.channels else 1000
+            b2 = p2.light.get(VisualID.Brightness) if VisualID.Brightness in p2.light.channels else 1000
+
             result = {}
             all_channels = set(p1.light.channels) | set(p2.light.channels)
             for ch in all_channels:
                 v1 = p1.light.get(ch)
                 v2 = p2.light.get(ch)
-                result[ch] = v1 + (v2 - v1) * frac
+                if ch == VisualID.Brightness:
+                    result[ch] = v1 + (v2 - v1) * frac
+                else:
+                    flattened1 = v1 * b1 / 1000.0
+                    flattened2 = v2 * b2 / 1000.0
+                    result[ch] = flattened1 + (flattened2 - flattened1) * frac
             return result
     return {}
 

{python_mobius-0.2.1.dist-info → python_mobius-0.3.1.dist-info}/METADATA

@@ -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.dist-info → python_mobius-0.3.1.dist-info}/RECORD

@@ -1,21 +1,21 @@
-mobius/__init__.py,sha256=LxDxIbucDGqf1DhloOxCxeC8Ta2rYM0Sy3T2UGYkXKI,5334
+mobius/__init__.py,sha256=pUvLAuR2ubblIn1v_bfunHnaCosr7TJys_LNFbnYUHw,5596
 mobius/cli.py,sha256=s1zZa4P4rws-XRLLd1B_J67mjMbdImcfgNeDet44cYo,21494
 mobius/coap.py,sha256=n-_wBuSY88_c1TAjfXPZsPnpG0IcZZLFRjxTzd1c0Us,10859
-mobius/constants.py,sha256=rXaywY6WIK36HobZ1E3w-HfEWtZDCFzXqKbo4Bbe1V8,19259
+mobius/constants.py,sha256=N98whYfTAdzydP18kn0ycXQubbc6F-CJUSr-o_KlepU,24129
 mobius/crc.py,sha256=WwIfUXGN_UKdsv-_Q303-L1-L1Rc1fvJnB5176ftzqU,2669
-mobius/device.py,sha256=GZ-Ucqt7lE_teOjXdHBf7DbgiTGtry88KwMr7a3NmHk,68859
+mobius/device.py,sha256=8iNc9fX01Cns00bGYXmSPxXb80THjBd-h47iV02b2KU,70462
 mobius/device_status.py,sha256=373a7BRGY1CoByLYkxTELAewkiSj4Wzm8yAilQrh0co,5812
 mobius/discovery.py,sha256=anJXZEwwhYwvQhFdYOwl6HGTrnMGUfb5CNg6H7Ah-iI,7737
 mobius/frame.py,sha256=zG2vh8PceJHD8R43MwZiJnm0Ge1dr8nFcKsJR9_c9LM,6135
 mobius/manufacturer.py,sha256=8-vBzckN8xmsPSMj5EWtOCXenbyQueoY5pnZHePgb_k,1937
 mobius/mesh_address.py,sha256=PNUi3VyRQZCitB1R3IbzXCg1LcP6azSg1sigHAqaP7E,4942
-mobius/modifiers.py,sha256=pFNjGYX-_bNumNEpv3jJLYPCb9ZuSKYpQ0DDd2GmicQ,6451
+mobius/modifiers.py,sha256=TQD__OvHAvUO14Z8SNp2I4lb7XYSbw_iZT2D2DXaeJ4,7315
 mobius/power.py,sha256=cZBpfYh2yg4xhmOQ0ILpACYdJSd7jMvSrhxat0yaH-g,3851
 mobius/pump_status.py,sha256=vqJXFAb16S-4oyzAzZIcwR5if7lXoTj67qwBJdbH1gI,1604
 mobius/relay.py,sha256=YnIAtX0vHPPSazgRT_g8ocP2WJNyvW02JQOafabmsbM,16497
-mobius/schedule.py,sha256=kHr684TIKPZ2BplIySoeD-Yn1Xa_2bE6rfGUs-waWMQ,7483
-python_mobius-0.2.1.dist-info/METADATA,sha256=EHtIqy5HkJRrHGzPnbgdpM4PoAPyTnqgJU3lKpTt56U,5959
-python_mobius-0.2.1.dist-info/WHEEL,sha256=lCkmxWfQsSc9CfIClYeavTdQeEX2toPqufh9gI35EQA,87
-python_mobius-0.2.1.dist-info/entry_points.txt,sha256=Q2hlcek-bWm70zvd12v32essflPgC2su-dKDHAqbPoE,48
-python_mobius-0.2.1.dist-info/licenses/LICENSE,sha256=7a72Msu2Q-TnoiFxemxEGkwafJGObk1W3rw9hzmyM_Y,17984
-python_mobius-0.2.1.dist-info/RECORD,,
+mobius/schedule.py,sha256=hKTlVoxw4eZpDcWUL9wpxShLacmoQZd7MR4kn6ZNvWs,10492
+python_mobius-0.3.1.dist-info/METADATA,sha256=FV_rjO4y1wL8ews26uvabsG87XtNgjuH2ZLz9oK6LHo,5959
+python_mobius-0.3.1.dist-info/WHEEL,sha256=lCkmxWfQsSc9CfIClYeavTdQeEX2toPqufh9gI35EQA,87
+python_mobius-0.3.1.dist-info/entry_points.txt,sha256=Q2hlcek-bWm70zvd12v32essflPgC2su-dKDHAqbPoE,48
+python_mobius-0.3.1.dist-info/licenses/LICENSE,sha256=7a72Msu2Q-TnoiFxemxEGkwafJGObk1W3rw9hzmyM_Y,17984
+python_mobius-0.3.1.dist-info/RECORD,,