Update: Battery Optimizer v3.4.0 mit allen Fixes und Features
This commit is contained in:
269
docs/CLAUDE.md
Normal file
269
docs/CLAUDE.md
Normal file
@@ -0,0 +1,269 @@
|
||||
# CLAUDE.md
|
||||
|
||||
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
|
||||
|
||||
## Project Overview
|
||||
|
||||
Intelligent battery charging optimizer for Home Assistant integrated with OpenEMS and GoodWe hardware. The system optimizes battery charging based on dynamic electricity pricing from haStrom FLEX PRO tariff and solar forecasts, automatically scheduling charging during the cheapest price periods.
|
||||
|
||||
**Hardware**: 10 kWh GoodWe battery, 10 kW inverter, 9.2 kWp PV (east-west orientation)
|
||||
**Control**: BeagleBone running OpenEMS, controlled via Modbus TCP and JSON-RPC
|
||||
**Home Assistant**: PyScript-based optimization running on /config/pyscript/
|
||||
|
||||
## Repository Structure
|
||||
|
||||
This repository contains **versioned iterations** of the battery optimization system:
|
||||
|
||||
```
|
||||
/
|
||||
├── v1/ # Initial implementation (threshold-based)
|
||||
├── v2/ # Improved version
|
||||
├── v3/ # Latest version (ranking-based optimization, sections dashboards)
|
||||
├── battery_charging_optimizer.py # Current production PyScript (v3.1.0)
|
||||
├── hastrom_flex_extended.py # Tomorrow-aware price fetcher
|
||||
├── ess_set_power.py # Modbus FLOAT32 power control
|
||||
├── EMS_OpenEMS_HomeAssistant_Dokumentation.md # Comprehensive technical docs
|
||||
└── project_memory.md # AI assistant context memory
|
||||
```
|
||||
|
||||
**Important**: The root-level `.py` files are the **current production versions**. Version folders contain historical snapshots and documentation from development iterations.
|
||||
|
||||
## Core Architecture
|
||||
|
||||
### Control Flow
|
||||
|
||||
```
|
||||
14:05 daily → Fetch prices → Optimize schedule → Store in pyscript state
|
||||
↓
|
||||
xx:05 hourly → Read schedule → Check current hour → Execute action
|
||||
↓
|
||||
If charging → Enable manual mode → Set power via Modbus → Trigger automation
|
||||
If auto → Disable manual mode → Let OpenEMS manage battery
|
||||
```
|
||||
|
||||
### Critical Components
|
||||
|
||||
**1. Battery Charging Optimizer** (`battery_charging_optimizer.py`)
|
||||
- Ranking-based optimization: selects N cheapest hours from combined today+tomorrow data
|
||||
- Runs daily at 14:05 (after price publication) and hourly at xx:05
|
||||
- Stores schedule in `pyscript.battery_charging_schedule` state with attributes
|
||||
- Conservative strategy: 20-100% SOC range, 2 kWh reserve for self-consumption
|
||||
|
||||
**2. Price Fetcher** (`hastrom_flex_extended.py`)
|
||||
- Fetches haStrom FLEX PRO prices with tomorrow support
|
||||
- Creates sensors: `sensor.hastrom_flex_pro_ext` and `sensor.hastrom_flex_ext`
|
||||
- **Critical**: Field name is `t_price_has_pro_incl_vat` (not standard field name)
|
||||
- Updates hourly, with special triggers at 14:05 and midnight
|
||||
|
||||
**3. Modbus Power Control** (`ess_set_power.py`)
|
||||
- Controls battery via Modbus register 706 (SetActivePowerEquals)
|
||||
- **Critical**: Uses IEEE 754 FLOAT32 Big-Endian encoding
|
||||
- Negative values = charging, positive = discharging
|
||||
|
||||
### OpenEMS Integration Details
|
||||
|
||||
**Controller Priority System**:
|
||||
- Controllers execute in **alphabetical order**
|
||||
- Later controllers can override earlier ones
|
||||
- Use `ctrlBalancing0` with `SET_GRID_ACTIVE_POWER` for highest priority
|
||||
- Direct ESS register writes can be overridden by subsequent controllers
|
||||
|
||||
**ESS Modes**:
|
||||
- `REMOTE`: External Modbus control active
|
||||
- `INTERNAL`: OpenEMS manages battery
|
||||
- Mode switching via JSON-RPC API on port 8074
|
||||
|
||||
**Modbus Communication**:
|
||||
- IP: 192.168.89.144, Port: 502
|
||||
- Register pairs use 2 consecutive registers for FLOAT32 values
|
||||
- Example: Register 2752/2753 for SET_GRID_ACTIVE_POWER
|
||||
|
||||
### PyScript-Specific Considerations
|
||||
|
||||
**Limitations**:
|
||||
- Generator expressions with `selectattr()` not supported
|
||||
- Use explicit `for` loops instead of complex comprehensions
|
||||
- State values limited to 255 characters; use attributes for complex data
|
||||
|
||||
**Timezone Handling**:
|
||||
- PyScript `datetime.now()` returns UTC
|
||||
- Home Assistant stores times in local (Europe/Berlin)
|
||||
- Always use `datetime.now().astimezone()` for local time
|
||||
- Explicit timezone conversion required when comparing PyScript times with HA states
|
||||
|
||||
**State Management**:
|
||||
```python
|
||||
# Store complex data in attributes, not state value
|
||||
state.set('pyscript.battery_charging_schedule',
|
||||
value='active', # Simple status
|
||||
new_attributes={'schedule': [...]} # Complex data here
|
||||
)
|
||||
```
|
||||
|
||||
## Development Commands
|
||||
|
||||
### Testing PyScript Changes
|
||||
|
||||
```bash
|
||||
# In Home Assistant Developer Tools → Services:
|
||||
service: pyscript.reload
|
||||
```
|
||||
|
||||
### Manual Schedule Calculation
|
||||
|
||||
```bash
|
||||
# In Home Assistant Developer Tools → Services:
|
||||
service: pyscript.calculate_charging_schedule
|
||||
```
|
||||
|
||||
### Manual Execution Test
|
||||
|
||||
```bash
|
||||
# In Home Assistant Developer Tools → Services:
|
||||
service: pyscript.execute_charging_schedule
|
||||
```
|
||||
|
||||
### Check Schedule State
|
||||
|
||||
```bash
|
||||
# In Home Assistant Developer Tools → States, search for:
|
||||
pyscript.battery_charging_schedule
|
||||
```
|
||||
|
||||
### OpenEMS Logs (on BeagleBone)
|
||||
|
||||
```bash
|
||||
tail -f /var/log/openems/openems.log
|
||||
```
|
||||
|
||||
## Key Integration Points
|
||||
|
||||
### Required Home Assistant Entities
|
||||
|
||||
**Input Booleans**:
|
||||
- `input_boolean.battery_optimizer_enabled` - Master enable/disable
|
||||
- `input_boolean.goodwe_manual_control` - Manual vs auto mode
|
||||
- `input_boolean.battery_optimizer_manual_override` - Skip automation
|
||||
|
||||
**Input Numbers**:
|
||||
- `input_number.battery_capacity_kwh` - Battery capacity (10 kWh)
|
||||
- `input_number.battery_optimizer_min_soc` - Minimum SOC (20%)
|
||||
- `input_number.battery_optimizer_max_soc` - Maximum SOC (100%)
|
||||
- `input_number.battery_optimizer_max_charge_power` - Max charge power (5000W)
|
||||
- `input_number.charge_power_battery` - Target charging power
|
||||
|
||||
**Sensors**:
|
||||
- `sensor.esssoc` - Current battery SOC
|
||||
- `sensor.openems_ess0_activepower` - Battery power
|
||||
- `sensor.openems_grid_activepower` - Grid power
|
||||
- `sensor.openems_production_activepower` - PV production
|
||||
- `sensor.energy_production_today` / `sensor.energy_production_today_2` - PV forecast (east/west)
|
||||
- `sensor.energy_production_tomorrow` / `sensor.energy_production_tomorrow_2` - PV tomorrow
|
||||
|
||||
### Existing Automations
|
||||
|
||||
Three manual control automations exist (in Home Assistant automations.yaml):
|
||||
- Battery charge start (ID: `1730457901370`)
|
||||
- Battery charge stop (ID: `1730457994517`)
|
||||
- Battery discharge
|
||||
|
||||
**Important**: These automations are **used by** the optimizer, not replaced. The PyScript sets input helpers that trigger these automations.
|
||||
|
||||
## Dashboard Variants
|
||||
|
||||
Multiple dashboard configurations exist in `v3/`:
|
||||
|
||||
- **Standard** (`battery_optimizer_dashboard.yaml`): Detailed view with all metrics
|
||||
- **Compact** (`battery_optimizer_dashboard_compact.yaml`): Balanced mobile-friendly view
|
||||
- **Minimal** (`battery_optimizer_dashboard_minimal.yaml`): Quick status check
|
||||
- **Sections variants**: Modern HA 2024.2+ layouts with auto-responsive behavior
|
||||
|
||||
All use maximum 4-column layouts for mobile compatibility.
|
||||
|
||||
**Required HACS Custom Cards**:
|
||||
- Mushroom Cards
|
||||
- Bubble Card
|
||||
- Plotly Graph Card
|
||||
- Power Flow Card Plus
|
||||
- Stack-in-Card
|
||||
|
||||
## Common Troubleshooting
|
||||
|
||||
### Battery Not Charging Despite Schedule
|
||||
|
||||
**Symptom**: Schedule shows charging hour but battery stays idle
|
||||
**Causes**:
|
||||
1. Controller priority issue - another controller overriding
|
||||
2. Manual override active (`input_boolean.battery_optimizer_manual_override == on`)
|
||||
3. Optimizer disabled (`input_boolean.battery_optimizer_enabled == off`)
|
||||
|
||||
**Solution**: Check OpenEMS logs for controller execution order, verify input boolean states
|
||||
|
||||
### Wrong Charging Time (Off by Hours)
|
||||
|
||||
**Symptom**: Charging starts at wrong hour
|
||||
**Cause**: UTC/local timezone mismatch in PyScript
|
||||
**Solution**: Verify all datetime operations use `.astimezone()` for local time
|
||||
|
||||
### No Tomorrow Prices in Schedule
|
||||
|
||||
**Symptom**: Schedule only covers today
|
||||
**Cause**: Tomorrow prices not yet available (published at 14:00)
|
||||
**Solution**: Normal before 14:00; if persists after 14:05, check `sensor.hastrom_flex_pro_ext` attributes for `tomorrow_available`
|
||||
|
||||
### Modbus Write Failures
|
||||
|
||||
**Symptom**: Modbus errors in logs when setting power
|
||||
**Cause**: Incorrect FLOAT32 encoding or wrong byte order
|
||||
**Solution**: Verify Big-Endian format in `ess_set_power.py`, check OpenEMS Modbus configuration
|
||||
|
||||
## Data Sources
|
||||
|
||||
**haStrom FLEX PRO API**:
|
||||
- Endpoint: `http://eex.stwhas.de/api/spotprices/flexpro?start_date=YYYYMMDD&end_date=YYYYMMDD`
|
||||
- Price field: `t_price_has_pro_incl_vat` (specific to FLEX PRO tariff)
|
||||
- Supports date range queries for multi-day optimization
|
||||
|
||||
**Forecast.Solar**:
|
||||
- Two arrays configured: East (90°) and West (270°) on flat roof
|
||||
- Daily totals available, hourly breakdown simplified
|
||||
|
||||
**InfluxDB2**:
|
||||
- Long-term storage for historical analysis
|
||||
- Configuration in Home Assistant `configuration.yaml`
|
||||
|
||||
## File Locations in Production
|
||||
|
||||
When this code runs in production Home Assistant:
|
||||
|
||||
```
|
||||
/config/
|
||||
├── pyscripts/
|
||||
│ ├── battery_charging_optimizer.py # Main optimizer
|
||||
│ ├── hastrom_flex_extended.py # Price fetcher
|
||||
│ └── ess_set_power.py # Modbus control
|
||||
├── automations.yaml # Contains battery control automations
|
||||
├── configuration.yaml # Modbus, InfluxDB configs
|
||||
└── dashboards/
|
||||
└── battery_optimizer.yaml # Dashboard config
|
||||
```
|
||||
|
||||
## Algorithm Overview
|
||||
|
||||
**Ranking-Based Optimization** (v3.1.0):
|
||||
1. Calculate needed charging hours: `(target_SOC - current_SOC) × capacity ÷ charge_power`
|
||||
2. Combine today + tomorrow price data into single dataset
|
||||
3. Score each hour: `price - (pv_forecast_wh / 1000)`
|
||||
4. Sort by score (lowest = best)
|
||||
5. Select top N hours where N = needed charging hours
|
||||
6. Execute chronologically
|
||||
|
||||
**Key Insight**: This approach finds globally optimal charging times across midnight boundaries, unlike threshold-based methods that treat days separately.
|
||||
|
||||
## Version History Context
|
||||
|
||||
- **v1**: Threshold-based optimization, single-day planning
|
||||
- **v2**: Enhanced with better dashboard, improved error handling
|
||||
- **v3**: Ranking-based optimization, tomorrow support, modern sections dashboards
|
||||
|
||||
Each version folder contains complete snapshots including installation guides and checklists for that iteration.
|
||||
359
docs/EMS_OpenEMS_HomeAssistant_Dokumentation.md
Normal file
359
docs/EMS_OpenEMS_HomeAssistant_Dokumentation.md
Normal file
@@ -0,0 +1,359 @@
|
||||
# EMS mit openEMS und Home Assistant - Projektdokumentation
|
||||
|
||||
## Projektübersicht
|
||||
|
||||
Intelligentes Batterie-Optimierungssystem für eine Wohnanlage mit dynamischer Strompreissteuerung und Solarprognose-Integration.
|
||||
|
||||
### Hardware-Setup
|
||||
- **Batterie**: GoodWe 10 kWh
|
||||
- **Wechselrichter**: 10 kW GoodWe
|
||||
- **PV-Anlage**: 9,2 kWp (Ost-West-Ausrichtung auf Flachdach)
|
||||
- **Steuerung**: BeagleBone mit openEMS
|
||||
- **Kommunikation**: Modbus TCP (IP: 192.168.89.144, Port: 502)
|
||||
|
||||
### Stromtarif & APIs
|
||||
- **Tarif**: haStrom FLEX PRO (dynamische Preise)
|
||||
- **Preisabruf**: Täglich um 14:00 Uhr für Folgetag
|
||||
- **PV-Prognose**: Forecast.Solar API
|
||||
- **API-Feldname**: `t_price_has_pro_incl_vat` (spezifisch für FLEX PRO)
|
||||
|
||||
## Systemarchitektur
|
||||
|
||||
### Komponenten-Übersicht
|
||||
```
|
||||
┌─────────────────────────────────────────────────┐
|
||||
│ Home Assistant + PyScript │
|
||||
│ - Optimierungsalgorithmus (täglich 14:05) │
|
||||
│ - Stündliche Ausführung (xx:05) │
|
||||
│ - Zeitzonenhandling (UTC → Local) │
|
||||
└──────────────────┬──────────────────────────────┘
|
||||
│
|
||||
┌─────────┴─────────┐
|
||||
│ │
|
||||
┌────────▼────────┐ ┌──────▼───────────────┐
|
||||
│ Modbus TCP │ │ JSON-RPC API │
|
||||
│ Port 502 │ │ Port 8074 │
|
||||
│ (Batterie- │ │ (ESS Mode Switch) │
|
||||
│ steuerung) │ │ │
|
||||
└────────┬────────┘ └──────┬───────────────┘
|
||||
│ │
|
||||
└─────────┬─────────┘
|
||||
│
|
||||
┌─────────▼──────────┐
|
||||
│ openEMS │
|
||||
│ - Controller-Prio │
|
||||
│ - ESS Management │
|
||||
│ - GoodWe Integration│
|
||||
└────────────────────┘
|
||||
```
|
||||
|
||||
## Kritische technische Details
|
||||
|
||||
### 1. Modbus-Kommunikation
|
||||
|
||||
#### Register-Format
|
||||
- **Datentyp**: IEEE 754 FLOAT32
|
||||
- **Register-Paare**: Verwenden 2 aufeinanderfolgende Register
|
||||
- **Beispiel**: Register 2752/2753 für SET_GRID_ACTIVE_POWER
|
||||
|
||||
#### Wichtige Register (aus Modbustcp0_3.xlsx)
|
||||
- **Batteriesteuerung**: Register 2752/2753 (SET_GRID_ACTIVE_POWER)
|
||||
- **SOC-Abfrage**: Register für State of Charge
|
||||
- **Leistungswerte**: FLOAT32-codiert
|
||||
|
||||
#### Python-Implementierung für Register-Schreiben
|
||||
```python
|
||||
import struct
|
||||
from pymodbus.client import ModbusTcpClient
|
||||
|
||||
def write_float32_register(client, address, value):
|
||||
"""
|
||||
Schreibt einen FLOAT32-Wert in zwei Modbus-Register
|
||||
"""
|
||||
# FLOAT32 in zwei 16-bit Register konvertieren
|
||||
bytes_value = struct.pack('>f', value) # Big-Endian
|
||||
registers = [
|
||||
int.from_bytes(bytes_value[0:2], 'big'),
|
||||
int.from_bytes(bytes_value[2:4], 'big')
|
||||
]
|
||||
client.write_registers(address, registers)
|
||||
```
|
||||
|
||||
### 2. openEMS Controller-Prioritäten
|
||||
|
||||
#### Kritisches Verhalten
|
||||
- **Alphabetische Ausführungsreihenfolge**: Controller werden alphabetisch sortiert ausgeführt
|
||||
- **Override-Problem**: Spätere Controller können frühere überschreiben
|
||||
- **Lösung**: `ctrlBalancing0` mit SET_GRID_ACTIVE_POWER nutzt
|
||||
|
||||
#### Controller-Hierarchie
|
||||
```
|
||||
1. ctrlBalancing0 (SET_GRID_ACTIVE_POWER) ← HÖCHSTE PRIORITÄT
|
||||
2. Andere Controller (können nicht überschreiben)
|
||||
3. ESS-Register (können überschrieben werden)
|
||||
```
|
||||
|
||||
#### ESS-Modi
|
||||
- **REMOTE**: Externe Steuerung via Modbus aktiv
|
||||
- **INTERNAL**: openEMS-interne Steuerung
|
||||
- **Mode-Switch**: Via JSON-RPC API Port 8074
|
||||
|
||||
### 3. Existierende Home Assistant Automationen
|
||||
|
||||
Drei bewährte Automationen für Batteriesteuerung:
|
||||
|
||||
1. **Batterieladung starten** (ID: `1730457901370`)
|
||||
2. **Batterieladung stoppen** (ID: `1730457994517`)
|
||||
3. **Batterieentladung** (ID: weitere Details erforderlich)
|
||||
|
||||
**Wichtig**: Diese Automationen werden vom Optimierungssystem gesteuert, nicht ersetzt!
|
||||
|
||||
## Optimierungsalgorithmus
|
||||
|
||||
### Strategie
|
||||
- **Konservativ**: Nur in günstigsten Stunden laden
|
||||
- **SOC-Bereich**: 20-100% (2 kWh Reserve für Eigenverbrauch)
|
||||
- **Ranking-basiert**: N günstigste Stunden aus Heute+Morgen
|
||||
- **Mitternachtsoptimierung**: Berücksichtigt Preise über Tageswechsel hinweg
|
||||
|
||||
### Berechnung
|
||||
```python
|
||||
# Benötigte Ladestunden
|
||||
needed_kwh = (target_soc - current_soc) / 100 * battery_capacity
|
||||
needed_hours = needed_kwh / charging_power
|
||||
|
||||
# Sortierung nach Preis
|
||||
combined_prices = today_prices + tomorrow_prices
|
||||
sorted_hours = sorted(combined_prices, key=lambda x: x['price'])
|
||||
|
||||
# N günstigste Stunden auswählen
|
||||
charging_hours = sorted_hours[:needed_hours]
|
||||
```
|
||||
|
||||
### PyScript-Ausführung
|
||||
|
||||
#### Zeitplan
|
||||
- **Optimierung**: Täglich 14:05 (nach Preisveröffentlichung um 14:00)
|
||||
- **Ausführung**: Stündlich xx:05
|
||||
- **Prüfung**: Ist aktuelle Stunde eine Ladestunde?
|
||||
|
||||
#### Zeitzonenhandling
|
||||
```python
|
||||
# PROBLEM: PyScript verwendet UTC
|
||||
from datetime import datetime
|
||||
import pytz
|
||||
|
||||
# UTC datetime von PyScript
|
||||
utc_now = datetime.now()
|
||||
|
||||
# Konvertierung nach deutscher Zeit
|
||||
berlin_tz = pytz.timezone('Europe/Berlin')
|
||||
local_now = utc_now.astimezone(berlin_tz)
|
||||
|
||||
# Speicherung in Home Assistant (local time)
|
||||
state.set('sensor.charging_schedule', attributes={'data': schedule_data})
|
||||
```
|
||||
|
||||
**KRITISCH**: Home Assistant speichert Zeiten in lokaler Zeit, PyScript arbeitet in UTC!
|
||||
|
||||
## Datenquellen & Integration
|
||||
|
||||
### haStrom FLEX PRO API
|
||||
```python
|
||||
# Endpoint-Unterschiede beachten!
|
||||
url = "https://api.hastrom.de/api/prices"
|
||||
params = {
|
||||
'start': '2024-01-01',
|
||||
'end': '2024-01-02' # Unterstützt Datumsbereichsabfragen
|
||||
}
|
||||
|
||||
# Feldname ist spezifisch!
|
||||
price = data['t_price_has_pro_incl_vat'] # Nicht der Standard-Feldname!
|
||||
```
|
||||
|
||||
### Forecast.Solar
|
||||
- **Standortdaten**: Lat/Lon für Ost-West-Arrays
|
||||
- **Dachneigung**: Flachdach-spezifisch
|
||||
- **Azimut**: Ost (90°) und West (270°)
|
||||
|
||||
### InfluxDB2
|
||||
- **Historische Daten**: Langzeit-Speicherung
|
||||
- **Analyse**: Performance-Tracking
|
||||
- **Backup**: Datenredundanz
|
||||
|
||||
## Home Assistant Dashboard
|
||||
|
||||
### Design-Prinzipien
|
||||
- **Maximum 4 Spalten**: Mobile-First Design
|
||||
- **Sections Layout**: Moderne HA 2024.2+ Standard
|
||||
- **Keine verschachtelten Listen**: Flache Hierarchie bevorzugen
|
||||
|
||||
### Verwendete Custom Cards (HACS)
|
||||
- **Mushroom Cards**: Basis-UI-Elemente
|
||||
- **Bubble Card**: Erweiterte Visualisierung
|
||||
- **Plotly Graph Card**: Detaillierte Diagramme
|
||||
- **Power Flow Card Plus**: Energiefluss-Darstellung
|
||||
- **Stack-in-Card**: Layout-Organisation
|
||||
|
||||
### Dashboard-Varianten
|
||||
1. **Minimal**: Schneller Status-Check
|
||||
2. **Standard**: Tägliche Nutzung
|
||||
3. **Detail**: Analyse und Debugging
|
||||
|
||||
## PyScript-Besonderheiten
|
||||
|
||||
### Bekannte Limitierungen
|
||||
```python
|
||||
# NICHT UNTERSTÜTZT in PyScript:
|
||||
# - Generator Expressions mit selectattr()
|
||||
result = [x for x in items if x.attr == value] # ✗
|
||||
|
||||
# STATTDESSEN:
|
||||
result = []
|
||||
for x in items:
|
||||
if x.attr == value:
|
||||
result.append(x) # ✓
|
||||
```
|
||||
|
||||
### State vs. Attributes
|
||||
```python
|
||||
# State Value: Max 255 Zeichen
|
||||
state.set('sensor.status', 'charging')
|
||||
|
||||
# Attributes: Unbegrenzt (JSON)
|
||||
state.set('sensor.schedule',
|
||||
value='active',
|
||||
attributes={
|
||||
'schedule': complete_schedule_dict, # ✓ Kann sehr groß sein
|
||||
'prices': all_price_data
|
||||
}
|
||||
)
|
||||
```
|
||||
|
||||
## Debugging & Monitoring
|
||||
|
||||
### Logging-Strategie
|
||||
```python
|
||||
# PyScript Logging
|
||||
log.info(f"Optimization completed: {len(charging_hours)} hours")
|
||||
log.debug(f"Price data: {prices}")
|
||||
log.error(f"Modbus connection failed: {error}")
|
||||
```
|
||||
|
||||
### Transparenz
|
||||
- **Geplant vs. Ausgeführt**: Vergleich in Logs
|
||||
- **Controller-Execution**: openEMS-Logs prüfen
|
||||
- **Modbus-Traffic**: Register-Scan-Tools
|
||||
|
||||
### Typische Probleme
|
||||
|
||||
#### Problem 1: Controller Override
|
||||
**Symptom**: Batterie lädt nicht trotz Befehl
|
||||
**Ursache**: Anderer Controller überschreibt SET_GRID_ACTIVE_POWER
|
||||
**Lösung**: ctrlBalancing0 verwenden, nicht direkte ESS-Register
|
||||
|
||||
#### Problem 2: Zeitzone-Mismatch
|
||||
**Symptom**: Ladung startet zur falschen Stunde
|
||||
**Ursache**: UTC/Local-Zeit-Verwechslung
|
||||
**Lösung**: Explizite Timezone-Konvertierung in PyScript
|
||||
|
||||
#### Problem 3: FLOAT32-Encoding
|
||||
**Symptom**: Falsche Werte in Modbus-Registern
|
||||
**Ursache**: Falsche Byte-Reihenfolge
|
||||
**Lösung**: Big-Endian IEEE 754 verwenden
|
||||
|
||||
## Datei-Struktur
|
||||
|
||||
```
|
||||
/config/
|
||||
├── pyscripts/
|
||||
│ ├── battery_optimizer.py # Hauptoptimierung
|
||||
│ └── helpers/
|
||||
│ ├── modbus_client.py # Modbus-Funktionen
|
||||
│ └── price_fetcher.py # API-Aufrufe
|
||||
├── automations/
|
||||
│ ├── battery_charge_start.yaml
|
||||
│ ├── battery_charge_stop.yaml
|
||||
│ └── battery_discharge.yaml
|
||||
├── dashboards/
|
||||
│ ├── energy_overview.yaml # Hauptdashboard
|
||||
│ └── energy_detail.yaml # Detail-Analyse
|
||||
└── configuration.yaml # InfluxDB, Modbus, etc.
|
||||
```
|
||||
|
||||
## Nächste Schritte & Erweiterungen
|
||||
|
||||
### Kurzfristig
|
||||
- [ ] Dashboard-Feinschliff (Sections Layout)
|
||||
- [ ] Logging-Verbesserungen
|
||||
- [ ] Performance-Monitoring
|
||||
|
||||
### Mittelfristig
|
||||
- [ ] Erweiterte Algorithmen (ML-basiert?)
|
||||
- [ ] Wetterprognose-Integration
|
||||
- [ ] Community-Sharing vorbereiten
|
||||
|
||||
### Langfristig
|
||||
- [ ] Multi-Tarif-Support
|
||||
- [ ] V2G-Integration (Vehicle-to-Grid)
|
||||
- [ ] Peer-to-Peer-Energiehandel
|
||||
|
||||
## Wichtige Ressourcen
|
||||
|
||||
### Dokumentation
|
||||
- openEMS Docs: https://openems.github.io/openems.io/
|
||||
- Home Assistant Modbus: https://www.home-assistant.io/integrations/modbus/
|
||||
- PyScript Docs: https://hacs-pyscript.readthedocs.io/
|
||||
|
||||
### Tools
|
||||
- Modbus-Scanner: Für Register-Mapping
|
||||
- Excel-Export: openEMS Register-Dokumentation (Modbustcp0_3.xlsx)
|
||||
- HA Logs: `/config/home-assistant.log`
|
||||
|
||||
## Lessons Learned
|
||||
|
||||
1. **Controller-Priorität ist kritisch**: Immer höchsten verfügbaren Channel nutzen
|
||||
2. **Zeitzone-Handling explizit**: UTC/Local nie vermischen
|
||||
3. **API-Spezifikationen prüfen**: Feldnamen können abweichen (haStrom!)
|
||||
4. **PyScript-Limitierungen kennen**: Keine komplexen Comprehensions
|
||||
5. **Attributes > State**: Für komplexe Datenstrukturen
|
||||
6. **Bestehende Automationen nutzen**: Nicht neuerfinden
|
||||
7. **Transparent loggen**: Nachvollziehbarkeit ist Schlüssel
|
||||
|
||||
---
|
||||
|
||||
## Quick Reference - Häufige Befehle
|
||||
|
||||
### Modbus Register auslesen
|
||||
```bash
|
||||
# Via HA Developer Tools > States
|
||||
sensor.openems_battery_soc
|
||||
sensor.openems_grid_power
|
||||
```
|
||||
|
||||
### PyScript neu laden
|
||||
```bash
|
||||
# HA Developer Tools > Services
|
||||
service: pyscript.reload
|
||||
```
|
||||
|
||||
### openEMS Logs prüfen
|
||||
```bash
|
||||
# Auf BeagleBone
|
||||
tail -f /var/log/openems/openems.log
|
||||
```
|
||||
|
||||
### Manueller Ladetest
|
||||
```yaml
|
||||
# HA Developer Tools > Services
|
||||
service: automation.trigger
|
||||
target:
|
||||
entity_id: automation.batterieladung_starten
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**Version**: 1.0
|
||||
**Letzte Aktualisierung**: November 2024
|
||||
**Autor**: Felix
|
||||
**Status**: Produktiv im Einsatz
|
||||
26
docs/project_memory.md
Normal file
26
docs/project_memory.md
Normal file
@@ -0,0 +1,26 @@
|
||||
## Purpose & context
|
||||
Felix is developing an advanced Home Assistant battery optimization system for his residential energy setup, which includes a 10 kWh GoodWe battery, 10 kW inverter, and 9.2 kWp PV installation split between east and west orientations on a flat roof. The system integrates with OpenEMS energy management software running on a BeagleBone single-board computer, using dynamic electricity pricing from haStrom FLEX PRO tariff and Forecast.Solar for PV predictions. The primary goal is intelligent automated battery charging that schedules charging during the cheapest electricity price periods while considering solar forecasts and maintaining optimal battery management.
|
||||
The project represents a sophisticated energy optimization approach that goes beyond simple time-of-use scheduling, incorporating real-time pricing data (available daily at 14:00 for next-day optimization), weather forecasting, and cross-midnight optimization capabilities. Felix has demonstrated strong technical expertise throughout the development process, providing corrections and improvements to initial implementations, and has expressed interest in eventually sharing this project with the Home Assistant community.
|
||||
|
||||
## Current state
|
||||
The battery optimization system is operational with comprehensive PyScript-based automation that calculates daily charging schedules at 14:05 and executes hourly at xx:05. The system successfully integrates multiple data sources: haStrom FLEX PRO API for dynamic pricing, Forecast.Solar for PV forecasting, and OpenEMS Modbus sensors for battery monitoring. Recent work focused on dashboard optimization, moving from cluttered multi-column layouts to clean 4-column maximum designs using both traditional Home Assistant layouts and modern sections-based approaches.
|
||||
Key technical challenges have been resolved, including timezone mismatches between PyScript's UTC datetime handling and local German time storage, proper Modbus communication with FLOAT32 register handling, and controller priority conflicts in OpenEMS where balancing controllers were overriding manual charging commands. The system now uses proven manual control infrastructure with three existing automations for battery control via Modbus communication, switching between REMOTE and INTERNAL ESS modes as needed.
|
||||
|
||||
## On the horizon
|
||||
Felix is working on dashboard refinements using the new Home Assistant Sections layout, which represents the modern standard for dashboard creation in Home Assistant 2024.2+. The sections-based approach provides better organization and automatic responsive behavior compared to traditional horizontal/vertical stack configurations. Multiple dashboard variants have been created with different complexity levels to accommodate various use cases from quick status checks to detailed analysis.
|
||||
Future considerations include expanding the optimization algorithm's sophistication and potentially integrating additional data sources or control mechanisms. The system architecture is designed to be extensible, with clear separation between optimization logic, data collection, and execution components.
|
||||
|
||||
## Key learnings & principles
|
||||
Critical technical insights emerged around OpenEMS controller priority and execution order. The system uses alphabetical scheduling where controllers execute in sequence, and later controllers can override earlier ones. Manual battery control requires careful attention to controller hierarchy - using ctrlBalancing0's SET_GRID_ACTIVE_POWER channel provides highest priority and prevents override by other controllers, while direct ESS register writes can be overridden by subsequent controller execution.
|
||||
PyScript integration has specific limitations that require workarounds: generator expressions and list comprehensions with selectattr() are not supported and must be replaced with explicit for loops. Home Assistant state attributes can store unlimited JSON data while state values are limited to 255 characters, making attributes ideal for complex scheduling data storage.
|
||||
Timezone handling requires careful consideration when mixing PyScript's UTC datetime.now() with local time storage. The haStrom FLEX PRO API uses different field names (t_price_has_pro_incl_vat) than standard endpoints and supports efficient date range queries for multi-day optimization across midnight boundaries.
|
||||
|
||||
## Approach & patterns
|
||||
The system follows a conservative optimization strategy, charging only during the cheapest price periods while maintaining battery SOC between 20-100% with a 2 kWh reserve for self-consumption. The optimization algorithm uses ranking-based selection rather than threshold-based approaches, calculating needed charging hours based on battery capacity and selecting the N cheapest hours from combined today-plus-tomorrow datasets.
|
||||
Development follows a systematic troubleshooting approach with comprehensive logging and debugging capabilities. Felix emphasizes transparent operation where the system can verify planned versus actual charging execution. The architecture separates concerns cleanly: PyScript handles optimization calculations and scheduling, existing Home Assistant automations manage physical battery control, and Modbus communication provides the interface layer to OpenEMS.
|
||||
Dashboard design prioritizes readability and mobile compatibility with maximum 4-column layouts, using Mushroom Cards and custom components like Bubble Card, Plotly Graph Card, and Power Flow Card Plus for enhanced visualization.
|
||||
|
||||
## Tools & resources
|
||||
The system integrates multiple specialized components: OpenEMS for energy management with GoodWe ESS integration, InfluxDB2 for historical data storage, haStrom FLEX PRO API for dynamic electricity pricing, and Forecast.Solar for PV generation forecasting. Home Assistant serves as the central automation platform with PyScript for complex logic implementation.
|
||||
Technical infrastructure includes Modbus TCP communication on port 502 (IP 192.168.89.144), OpenEMS JSON-RPC API on port 8074 for ESS mode switching, and proper IEEE 754 FLOAT32 encoding for register value conversion. The system uses HACS custom components including Bubble Card, Plotly Graph Card, Power Flow Card Plus, and Stack-in-Card for enhanced dashboard functionality.
|
||||
Development tools include Python-based Modbus register scanning utilities, comprehensive logging systems for debugging controller execution, and Excel exports from OpenEMS for register mapping verification.
|
||||
Reference in New Issue
Block a user