+++ /dev/null
-# 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")
+++ /dev/null
-# 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)
+++ /dev/null
-# 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
+++ /dev/null
-# 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
repositories / e-mobility-charging-stations-simulator.git / commitdiff
