Skip to content

Multi-bridge Phase 2.2: Re-key AppStore by BridgeID #70

@tashda

Description

@tashda

Why

Today every collection in AppStore is flat (devices, groups, bridgeInfo, deviceStates, etc.). To hold both bridges' data simultaneously, every collection needs a bridge dimension. This is the largest pure-refactor of Phase 2.

What

Convert collections in Shellbee/Core/Store/AppStore.swift:

  • devices: [Device]devices: [BridgeID: [Device]]
  • groups: [Group][BridgeID: [Group]]
  • bridgeInfo: BridgeInfo?[BridgeID: BridgeInfo]
  • bridgeHealth: BridgeHealth?[BridgeID: BridgeHealth]
  • deviceStates: [String: [String:JSONValue]][BridgeID: [String: [String:JSONValue]]]
  • deviceAvailability: [String: Bool][BridgeID: [String: Bool]]
  • otaUpdates: [String: OTAUpdateStatus][BridgeID: [String: OTAUpdateStatus]]
  • logEntries: [LogEntry]LogEntry gains a bridgeID field; the array stays flat (so the master Logs view can show all-bridges-merged), but every consumer can filter by bridge.
  • operationErrors, pendingRenames, pendingRemovals, identifyInProgress, touchlinkDevices → all bridgeID-keyed.
  • deviceFirstSeen — already per-bridge from Implement stateful Z2M engine and enhance UI test coverage #1.4.

Add accessors:

  • devices(for: BridgeID) -> [Device], device(named: in: BridgeID), state(name: in:), isAvailable(_: in:), groups(for:).
  • Aggregations for "all bridges" views: allDevices, allLogs.

apply(_:) in AppStore+Events.swift takes a BridgeID (or ScopedEvent) and routes mutations to the correct slot.

reset() becomes reset(bridge: BridgeID) and resetAll().

Files

  • Shellbee/Core/Store/AppStore.swift
  • All Shellbee/Core/Store/AppStore+*.swift extensions.

Verification

Phase

Phase 2 of multi-bridge support. Depends on #2.1.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions