From 74a38f935e16cd2bd6658f854347e01c4a1a1dff Mon Sep 17 00:00:00 2001 From: =?utf8?q?J=C3=A9r=C3=B4me=20Benoit?= Date: Fri, 20 Feb 2026 20:35:16 +0100 Subject: [PATCH] chore(gitignore): untrack .sisyphus directory --- .../ocpp2-conformance-fixes/decisions.md | 25 ----------------- .../ocpp2-conformance-fixes/issues.md | 28 ------------------- .../ocpp2-conformance-fixes/learnings.md | 27 ------------------ .../ocpp2-conformance-fixes/problems.md | 26 ----------------- 4 files changed, 106 deletions(-) delete mode 100644 .sisyphus/notepads/ocpp2-conformance-fixes/decisions.md delete mode 100644 .sisyphus/notepads/ocpp2-conformance-fixes/issues.md delete mode 100644 .sisyphus/notepads/ocpp2-conformance-fixes/learnings.md delete mode 100644 .sisyphus/notepads/ocpp2-conformance-fixes/problems.md diff --git a/.sisyphus/notepads/ocpp2-conformance-fixes/decisions.md b/.sisyphus/notepads/ocpp2-conformance-fixes/decisions.md deleted file mode 100644 index 49af1445..00000000 --- a/.sisyphus/notepads/ocpp2-conformance-fixes/decisions.md +++ /dev/null @@ -1,25 +0,0 @@ -# Architectural Decisions - -## [2026-02-20] Task 2: TxUpdatedInterval - -### Decision 1: Separate TxUpdatedInterval from MeterValues - -- **Context**: Both send periodic messages during transactions -- **Decision**: Keep completely separate timers (`transactionSetInterval` vs `transactionTxUpdatedSetInterval`) -- **Rationale**: - - Different intervals (MeterValueSampleInterval vs TxUpdatedInterval) - - Different message types (MeterValues vs TransactionEvent) - - Different trigger reasons (Periodic vs MeterValuePeriodic) - - OCPP spec treats them as independent features - -### Decision 2: Export Strategy for OCPP Types - -- **Context**: Circular dependency issues with OCPP20ServiceUtils import -- **Decision**: Export from `ocpp/index.ts` as single source of truth -- **Rationale**: Prevents circular imports, maintains clean module boundaries - -### Decision 3: Interval Validation Approach - -- **Context**: Need to validate TxUpdatedInterval from variable manager -- **Decision**: Default to 30s if variable missing/invalid, no error thrown -- **Rationale**: Graceful degradation, aligns with OCPP "SHOULD" requirement (not "SHALL") diff --git a/.sisyphus/notepads/ocpp2-conformance-fixes/issues.md b/.sisyphus/notepads/ocpp2-conformance-fixes/issues.md deleted file mode 100644 index a8b697a9..00000000 --- a/.sisyphus/notepads/ocpp2-conformance-fixes/issues.md +++ /dev/null @@ -1,28 +0,0 @@ -# Known Issues & Gotchas - -## [2026-02-20] Task 2: TxUpdatedInterval - -### Issue 1: Import Path for OCPP20ServiceUtils - -- **Problem**: Direct import caused circular dependency errors -- **Solution**: Export via `ocpp/index.ts` centralized exports -- **Files affected**: ChargingStation.ts, ocpp/index.ts - -### Issue 2: Timer Safety with Large Intervals - -- **Problem**: JavaScript setTimeout/setInterval has MAX_SAFE_INTEGER limit -- **Solution**: Use `clampToSafeTimerValue()` utility (max 2147483647ms ~= 24.8 days) -- **Reference**: src/utils/Utils.ts lines 388-396 - -### Issue 3: TransactionEvent During Transaction - -- **Context**: sendTransactionEvent needs active transaction check -- **Validation**: Check `transactionStarted === true` AND `transactionId != null` before sending -- **Reason**: Timer may fire after transaction ends if stop is delayed - -## Patterns to Avoid - -- ❌ Hardcoded intervals (use variable manager) -- ❌ Missing OCPP version guards (breaks 1.6 compatibility) -- ❌ Unhandled promise rejections in setInterval callbacks -- ❌ Forgetting to clear timers on transaction end (memory leak) diff --git a/.sisyphus/notepads/ocpp2-conformance-fixes/learnings.md b/.sisyphus/notepads/ocpp2-conformance-fixes/learnings.md deleted file mode 100644 index 0b52eeef..00000000 --- a/.sisyphus/notepads/ocpp2-conformance-fixes/learnings.md +++ /dev/null @@ -1,27 +0,0 @@ -# Learnings & Conventions - -## [2026-02-20] Task 2: TxUpdatedInterval Implementation - -### Patterns Established - -- **Timer management**: Use `clampToSafeTimerValue()` wrapper for all setInterval calls -- **Variable retrieval**: Use `OCPP20VariableManager.getVariables()` with component/variable lookup -- **Lifecycle hooks**: START at RequestStartTransaction, STOP before transaction cleanup -- **ConnectorStatus fields**: Store timer references in connector status for cleanup -- **Error handling**: Catch promise rejections in setInterval callbacks with logger.error - -### Code Conventions - -- Import enums from `src/charging-station/ocpp/index.ts` (centralized exports) -- Follow existing MeterValues pattern for periodic message sending -- Validate OCPP version at method entry (`if (ocppVersion !== VERSION_20) return`) -- Check connector null and interval validity before starting timers -- Prevent duplicate timers (check if timer already exists) - -### File Structure - -- ChargingStation.ts: Public start/stop methods -- OCPP20IncomingRequestService.ts: Private helper + START lifecycle -- OCPP20ServiceUtils.ts: STOP lifecycle hook -- ConnectorStatus.ts: Timer field storage -- ocpp/index.ts: Centralized type exports diff --git a/.sisyphus/notepads/ocpp2-conformance-fixes/problems.md b/.sisyphus/notepads/ocpp2-conformance-fixes/problems.md deleted file mode 100644 index 87a0d391..00000000 --- a/.sisyphus/notepads/ocpp2-conformance-fixes/problems.md +++ /dev/null @@ -1,26 +0,0 @@ -# Unresolved Problems - -## Task 3: Offline TransactionEvent Queueing (PENDING) - -### Key Questions to Answer - -1. Where does WebSocket offline detection happen? -2. How does existing messageQueue pattern work? -3. How is seqNo currently tracked and incremented? -4. Where should queue flush logic hook into reconnection flow? -5. What happens to in-flight TransactionEvent messages during disconnect? - -### Research Needed - -- Explore WebSocket lifecycle hooks (disconnect/connect events) -- Find existing queue implementation patterns -- Understand seqNo persistence across offline periods -- Identify transaction context preservation during offline -- Review OCPP 2.0.1 requirements for offline message ordering - -### Potential Risks - -- seqNo gaps during offline period -- Message loss if queue not persisted -- Out-of-order delivery on reconnection -- Race conditions during reconnection flood -- 2.53.0