Skip to content

feat: add SolaX cloud lattice fragment publisher - #4336

Open
mgazza wants to merge 1 commit into
feat/lattice-ge-fragment-adapterfrom
feat/lattice-solax-fragment-adapter
Open

feat: add SolaX cloud lattice fragment publisher#4336
mgazza wants to merge 1 commit into
feat/lattice-ge-fragment-adapterfrom
feat/lattice-solax-fragment-adapter

Conversation

@mgazza

@mgazza mgazza commented Jul 28, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • add a pure, default-off SolaX Cloud Lattice fragment publisher
  • model plants, real inverter hardware and provider-local synthetic battery references without touching the live SolaX API integration
  • publish immutable REFERENCE-only topology and strong serial identity only for real hardware
  • route discovery, liveness and removal changes through the common fragment invalidation / fresh-read recompile path

Safety

  • not registered or invoked by live BatPred runtime code
  • emits no capabilities, roles, runtime config or write authority
  • synthetic batteries cannot emit hardware identity aliases or masquerade as independently controllable devices
  • stale discovery/liveness versions are ignored and same-version divergence fails closed
  • identity collisions fail before publication
  • removal is a durable irreversible tombstone
  • no solax.py imports, edits, registration or cloud/control side effects

Invalidation contract

Every accepted semantic change advances the provider generation and invalidates the common compiler. The compiler drains invalidations using fresh provider reads, so coalesced discovery/liveness/removal updates cannot compile an event payload that has already become stale.

Validation

  • 99 focused and shared fragment/autoconfig/publication tests passed
  • Python 3.9 and 3.14 focused validation passed
  • black, ruff, cspell and diff checks passed
  • independent review: no blocking findings
  • GitNexus staged analysis: MEDIUM aggregate, 56 additive symbols, one internal set_livenessread_state flow; live SolaX code remains untouched

Follow-up boundary

When a live mapper is introduced, it must additionally prove each synthetic battery source_serial belongs to a real inverter in the same plant before accepting provider data. This pure fragment is still safe without that mapping because synthetic nodes carry no strong identity, capability, role, config or authority.

Stack

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant