kb/concepts/ bekommt Areas: layout: fuer concept, Area-Titel aus jedem Type-Spec, Schwellen-Empfehlung im lint (schliesst #59)

Files changed: - CHANGES.md - README.md - VERSION - kb/concepts/Ambient Environment Dependency.md - kb/concepts/Anti-Cramming Heuristic.md - kb/concepts/Audit Trail.md - kb/concepts/BM25.md - kb/concepts/Bulk Operations.md - kb/concepts/CI Integration.md - kb/concepts/COLLECTION.md - kb/concepts/CPPC.md - kb/concepts/Checkpoint Audit.md - kb/concepts/Claude Code Auto Mode.md - kb/concepts/Command Round-Trip Integrity.md - kb/concepts/Confidence Scoring.md - kb/concepts/Consolidation Tiers.md - kb/concepts/Content Quality Control.md - kb/concepts/Context Isolation.md - kb/concepts/Contradiction Resolution.md - kb/concepts/Cross-platform Agent Skills.md - kb/concepts/Crystallization.md - kb/concepts/Delete Rather Than Anonymize.md - kb/concepts/Denylist over Allowlist.md - kb/concepts/Detect-Repair Asymmetry.md - kb/concepts/Diff-Reviewable Agent Edits.md - kb/concepts/Dual Licensing by File Plan.md - kb/concepts/Entity Extraction.md - kb/concepts/Episodic Memory.md - kb/concepts/Event-Driven Automation.md - kb/concepts/Filter on Ingest.md - kb/concepts/Forgetting.md - kb/concepts/Graph Traversal.md - kb/concepts/Green Suite Blind Spot.md - kb/concepts/Hooks.md - kb/concepts/Hybrid Search.md - kb/concepts/INDEX.md - kb/concepts/Implementation Spectrum.md - kb/concepts/Index Scaling.md - kb/concepts/Issue Label Scheme.md - kb/concepts/Iteration and Cost Limits.md - kb/concepts/KB Migration.md - kb/concepts/KB Stack Versioning.md - kb/concepts/Knowledge Compounding.md - kb/concepts/Knowledge Graph.md - kb/concepts/LLM Wiki Pattern.md - kb/concepts/Lint Workflow.md - kb/concepts/MCP-Leseserver.md - kb/concepts/Mass-Update Gate.md - kb/concepts/Memory Lifecycle.md - kb/concepts/Mesh Sync.md - kb/concepts/Modbus.md - kb/concepts/Multi-Agent Collaboration.md - kb/concepts/Naming Convention Conflict.md - kb/concepts/OKF Compatibility.md - kb/concepts/Optional Instance Context File.md - kb/concepts/Personalization Plane.md - kb/concepts/Privacy and Governance.md - kb/concepts/Procedural Memory.md - kb/concepts/Publish-Remote Gate.md - kb/concepts/Quality Scoring.md - kb/concepts/Quality and Self-Correction.md - kb/concepts/RAG.md - kb/concepts/Reciprocal Rank Fusion.md - kb/concepts/SSD TRIM.md - kb/concepts/Scale Ceiling.md - kb/concepts/Self-Healing.md - kb/concepts/Semantic Lint Automation.md - kb/concepts/Semantic Memory.md - kb/concepts/Session Orientation.md - kb/concepts/Shared vs Private.md - kb/concepts/Split Merge Reclassify.md - kb/concepts/Split Threshold.md - kb/concepts/Structural Enforcement over Documented Rule.md - kb/concepts/Stub Threshold.md - kb/concepts/Supersession.md - kb/concepts/Three-Layer Architecture.md - kb/concepts/Token Economics.md - kb/concepts/Typed Relationships.md - kb/concepts/User Management.md - kb/concepts/Vector Search.md - kb/concepts/Work Coordination.md - kb/concepts/Workflow Extraction.md - kb/concepts/Workflow Orchestration.md - kb/concepts/Working Memory.md - kb/concepts/Write-Once Frontmatter Fields.md - kb/concepts/architectures/Consolidation Tiers.md - kb/concepts/architectures/Context Isolation.md - kb/concepts/architectures/Cross-platform Agent Skills.md - kb/concepts/architectures/Episodic Memory.md - kb/concepts/architectures/Hybrid Search.md - kb/concepts/architectures/Implementation Spectrum.md - kb/concepts/architectures/Knowledge Graph.md - kb/concepts/architectures/LLM Wiki Pattern.md - kb/concepts/architectures/MCP-Leseserver.md - kb/concepts/architectures/Memory Lifecycle.md - kb/concepts/architectures/OKF Compatibility.md - kb/concepts/architectures/Optional Instance Context File.md - kb/concepts/architectures/Personalization Plane.md - kb/concepts/architectures/Procedural Memory.md - kb/concepts/architectures/RAG.md - kb/concepts/architectures/Scale Ceiling.md - kb/concepts/architectures/Semantic Memory.md - kb/concepts/architectures/Three-Layer Architecture.md - kb/concepts/architectures/Token Economics.md - kb/concepts/architectures/Working Memory.md - kb/concepts/decisions/Delete Rather Than Anonymize.md - kb/concepts/decisions/Denylist over Allowlist.md - kb/concepts/decisions/Diff-Reviewable Agent Edits.md - kb/concepts/decisions/Dual Licensing by File Plan.md - kb/concepts/decisions/Issue Label Scheme.md - kb/concepts/decisions/KB Stack Versioning.md - kb/concepts/decisions/Structural Enforcement over Documented Rule.md - kb/concepts/patterns/Audit Trail.md - kb/concepts/patterns/BM25.md - kb/concepts/patterns/Command Round-Trip Integrity.md - kb/concepts/patterns/Confidence Scoring.md - kb/concepts/patterns/Contradiction Resolution.md - kb/concepts/patterns/Entity Extraction.md - kb/concepts/patterns/Filter on Ingest.md - kb/concepts/patterns/Forgetting.md - kb/concepts/patterns/Graph Traversal.md - kb/concepts/patterns/Mesh Sync.md - kb/concepts/patterns/Quality Scoring.md - kb/concepts/patterns/Reciprocal Rank Fusion.md - kb/concepts/patterns/Self-Healing.md - kb/concepts/patterns/Shared vs Private.md - kb/concepts/patterns/Typed Relationships.md - kb/concepts/patterns/Vector Search.md - kb/concepts/patterns/Work Coordination.md - kb/concepts/problems/Ambient Environment Dependency.md - kb/concepts/problems/Detect-Repair Asymmetry.md - kb/concepts/problems/Green Suite Blind Spot.md - kb/concepts/problems/Naming Convention Conflict.md - kb/concepts/problems/Write-Once Frontmatter Fields.md - kb/concepts/protocols/CPPC.md - kb/concepts/protocols/Modbus.md - kb/concepts/protocols/SSD TRIM.md - kb/concepts/workflows/Anti-Cramming Heuristic.md - kb/concepts/workflows/Bulk Operations.md - kb/concepts/workflows/CI Integration.md - kb/concepts/workflows/Checkpoint Audit.md - kb/concepts/workflows/Claude Code Auto Mode.md - kb/concepts/workflows/Content Quality Control.md - kb/concepts/workflows/Crystallization.md - kb/concepts/workflows/Event-Driven Automation.md - kb/concepts/workflows/Hooks.md - kb/concepts/workflows/Index Scaling.md - kb/concepts/workflows/Iteration and Cost Limits.md - kb/concepts/workflows/KB Migration.md - kb/concepts/workflows/Knowledge Compounding.md - kb/concepts/workflows/Lint Workflow.md - kb/concepts/workflows/Mass-Update Gate.md - kb/concepts/workflows/Multi-Agent Collaboration.md - kb/concepts/workflows/Privacy and Governance.md - kb/concepts/workflows/Publish-Remote Gate.md - kb/concepts/workflows/Quality and Self-Correction.md - kb/concepts/workflows/Semantic Lint Automation.md - kb/concepts/workflows/Session Orientation.md - kb/concepts/workflows/Split Merge Reclassify.md - kb/concepts/workflows/Split Threshold.md - kb/concepts/workflows/Stub Threshold.md - kb/concepts/workflows/Supersession.md - kb/concepts/workflows/User Management.md - kb/concepts/workflows/Workflow Extraction.md - kb/concepts/workflows/Workflow Orchestration.md - kb/index.md - kb/log.md - tools/CONTRACT.md - tools/README.md - tools/chemenu/catalog.py - tools/chemenu/commands/index_build.py - tools/chemenu/lint_core.py - tools/chemenu/tests/conftest.py - tools/chemenu/tests/test_cite_cmd.py - tools/chemenu/tests/test_git_publish.py - tools/chemenu/tests/test_index_build.py - tools/chemenu/tests/test_lint.py - tools/chemenu/tests/test_new_page.py - tools/chemenu/tests/test_provenance.py - tools/chemenu/tests/test_type_resolver.py - tools/chemenu/tests/test_xref.py - types/concept.md - types/type-spec.md
2026-09-08 10:07:46 +02:00
parent 63b4bb82d9
commit 7f74303a00
103 changed files with 703 additions and 180 deletions
@@ -0,0 +1,87 @@
+---
+type: types/concept.md
+concept_type: protocol
+tags: [power-management, cpu, amd, hardware]
+created: 2026-07-31
+modified: 2026-08-29
+related:
+  - see-also: Linux Kernel
+  - mechanism: amd-pstate
+  - see-also: Kernel PM Governors
+sources: [Source - AMD Powermanagement CPU]
+confidence: 0.95
+confidence_base: 0.95
+provenance: sourced
+summary: Hardwareschnittstelle Collaborative Processor Performance Control für feingranulares CPU-Power-Management zwischen Betriebssystem und AMD-Prozessor.
+---
+# CPPC
+
+**Typ:** Protokoll
+
+## Definition
+
+**CPPC (Collaborative Processor Performance Control)** ist eine Hardware-Schnittstelle und ein Protokoll, das eine präzisere und kooperativere Energieverwaltung zwischen dem Betriebssystem und der CPU-Hardware ermöglicht. Es bietet eine standardisierte Möglichkeit für das OS, Leistungsanforderungen zu kommunizieren und Rückmeldungen von der CPU zu erhalten.
+
+## Kernpunkte
+
+- **Standard:** Collaborative Processor Performance Control
+- **Zweck:** Eine feingranulare CPU-Energieverwaltung ermöglichen
+- **Entwickler:** AMD (implementiert in neueren AMD-Prozessoren)
+- **OS-Unterstützung:** Linux Kernel 5.17+ via amd-pstate-Treiber
+- **Schnittstelle:** sysfs-exponierte Steuerelemente
+
+## Features
+
+CPPC bietet mehrere Schlüsselmöglichkeiten:
+
+- **Leistungsziele:** Hardware kommuniziert optimale Leistungsziele an das OS
+- **Performance-Hinweise:** Hardware bietet Hinweise zu effizienten Betriebspunkten
+- **Rückmelde-Mechanismus:** Bidirektionale Kommunikation zwischen OS und Hardware
+- **Feinkörnige Kontrolle:** Körnigere Kontrolle als traditionelle P-States
+- **Dynamische Anpassung:** Ermöglicht Echtzeit-Anpassung basierend auf Arbeitslast-Charakteristiken
+
+## Wie es funktioniert
+
+1. **Hardware-Fähigkeiten:** CPPC-fähige CPUs stellen ihre Leistungscharakteristiken zur Verfügung
+2. **OS-Abfrage:** Das Betriebssystem (via amd-pstate) fragt CPPC nach verfügbaren Leistungszuständen ab
+3. **Regulator-Bewertung:** Kernel-Regulatoren (schedutil, ondemand) bewerten CPPC-Ziele und Hinweise
+4. **Zustandsauswahl:** Regulatoren wählen angepasste Leistungszustände basierend auf Arbeitslast und CPPC-Anleitung
+5. **Hardware-Antwort:** CPU passt ihre Betriebsparameter entsprechend an
+
+## Vorteile gegenüber traditionellem ACPI
+
+| Merkmal | CPPC (amd-pstate) | ACPI (acpi-cpufreq) |
+|---------|-------------------|---------------------|
+| Granularität | Feingranular | 3 P-States |
+| Rückmeldung | Hardware-Hinweise und Ziele | Statische Tabellen |
+| Effizienz | Optimiert für aktuelle Arbeitslast | Generisch |
+| Energieeinsparung | Überlegen | Begrenzt |
+| Mobiler Vorteil | Erweiterte Akkulaufzeit | Standard |
+
+## Anwendungsfälle
+
+- **Mobile Geräte:** Erweiterte Akkulaufzeit durch optimierte Energieverwaltung
+- **Server:** Bessere Energieeffizienz in Rechenzentren
+- **Desktops:** Responsive Leistung mit reduziertem Stromverbrauch
+- **Gemischte Arbeitslasten:** Intelligente Anpassung an wechselnde Arbeitslast-Anforderungen
+
+## Beispiele
+
+- [[amd-pstate]] - Linux-Kernel-Treiber, der CPPC für AMD-Prozessoren implementiert
+- [[Kernel PM Governors]] - CPPC-Ziele und Hinweise für Entscheidungsfindung verwenden
+- [[Linux Kernel]] 5.17+ - Enthält amd-pstate-Treiber mit CPPC-Unterstützung
+
+## Verwandte Konzepte
+
+- Energieverwaltung
+- Leistungszustände (P-States)
+
+## Siehe auch
+
+<!-- wikitool:links -->
+## Beziehungen
+
+- **see-also:** [[Linux Kernel]]
+- **mechanism:** [[amd-pstate]]
+- **see-also:** [[Kernel PM Governors]]
+<!-- /wikitool:links -->
@@ -0,0 +1,269 @@
+---
+type: types/concept.md
+concept_type: protocol
+tags: [industrial, automation, communication, serial]
+created: 2026-07-25
+modified: 2026-08-29
+related:
+  - see-also: E3DC
+  - see-also: ha-core
+  - see-also: Home Assistant
+sources: []
+confidence: 0.90
+confidence_base: 0.90
+provenance: general
+summary: Industrielles Kommunikationsprotokoll von 1979 zur Anbindung speicherprogrammierbarer Steuerungen und Geräte über serielle oder TCP-Netze.
+---
+# Modbus
+
+**Typ:** Protokoll (Kommunikationsprotokoll)
+
+## Definition
+
+Modbus ist ein serielles Kommunikationsprotokoll, das 1979 von Modicon (jetzt Schneider Electric) veröffentlicht wurde und für die Verwendung mit seinen programmierbaren Steuerungsgeräten (PLCs) bestimmt ist. Es ist seitdem zu einem De-facto-Standard-Kommunikationsprotokoll in industriellen Umgebungen geworden und ist jetzt die am häufigsten verfügbare Mittel zum Verbinden industrieller elektronischer Geräte.
+
+## Kernpunkte
+
+- **Offener Standard** - Öffentlich verfügbar, keine Lizenzgebühren
+- **Serielles Protokoll** - Ursprünglich für serielle (RS-232/RS-485) Kommunikation konzipiert
+- **Client-Server-Modell** - Ein Master, mehrere Slaves (Geräte)
+- **Einfaches Frame-Format** - Leicht auf eingebetteten Geräten zu implementieren
+- **Weit verbreitet** - Wird in vielen Branchen und Gerätetypen verwendet
+
+## Varianten
+
+### Modbus RTU
+
+- **Transport:** Seriell (RS-232, RS-485)
+- **Kodierung:** Binär (RTU = Remote Terminal Unit)
+- **Prüfsumme:** CRC
+- **Anwendungsfall:** Industrielle Umgebungen, lange Entfernungen
+- **Geschwindigkeit:** Bis zu 115200 Baud
+- **Entfernung:** Bis zu 1200 Meter (RS-485)
+
+### Modbus ASCII
+
+- **Transport:** Seriell (RS-232, RS-485)
+- **Kodierung:** ASCII-Zeichen
+- **Prüfsumme:** LRC (Longitudinal Redundancy Check)
+- **Anwendungsfall:** Menschenlesbar, langsamer aber robuster in lauten Umgebungen
+- **Geschwindigkeit:** Langsamer als RTU aufgrund der ASCII-Kodierung
+
+### Modbus TCP
+
+- **Transport:** Ethernet TCP/IP
+- **Kodierung:** Wie Modbus RTU (binär)
+- **Port:** 502 (Standard)
+- **Anwendungsfall:** Moderne Netzwerke, Integration mit IT-Systemen
+- **Adressierung:** Verwendet IP-Adressen statt Slave-IDs
+- **Vorteil:** Keine serielle-zu-Ethernet-Konverter erforderlich
+
+### Modbus over TCP/IP (Modbus/TCP)
+
+Wie Modbus TCP - die häufigste TCP-Variante.
+
+## Adressierung
+
+### Geräte-Adressierung
+
+- **Slave ID:** 1-247 (0 ist Broadcast, 248-255 sind reserviert)
+- **TCP:** IP-Adresse ersetzt Slave ID, aber Slave ID ist noch im Protokoll-Frame
+
+### Daten-Adressierung
+
+Modbus organisiert Daten in vier primäre Tabellen:
+
+| Tabelle | Code | Beschreibung |
+|-------|------|-------------|
+| Discrete Inputs | 0x | Schreibgeschützt, 1-Bit (digitale Eingänge) |
+| Coils | 01 | Lesen-Schreiben, 1-Bit (digitale Ausgänge) |
+| Input Registers | 04 | Schreibgeschützt, 16-Bit (analoge Eingänge) |
+| Holding Registers | 03 | Lesen-Schreiben, 16-Bit (analoge Ausgänge, Konfiguration) |
+
+**Hinweis:** Adressen werden oft mit einem Präfix referenziert:
+- `0:` oder `I:` für Input (Discrete Inputs, Input Registers)
+- `1:` oder `Q:` für Output (Coils, Holding Registers)
+- `4:` für Holding Registers (häufige Konvention)
+
+## Datentypen
+
+Modbus überträgt 16-Bit-Werte. Größere Werte werden als mehrere Register übertragen:
+
+| Datentyp | Register | Byte-Reihenfolge |
+|-----------|-----------|------------|
+| INT16 | 1 | Big-Endian |
+| UINT16 | 1 | Big-Endian |
+| INT32 | 2 | Konfigurierbar |
+| UINT32 | 2 | Konfigurierbar |
+| FLOAT32 | 2 | IEEE 754, konfigurierbar |
+| FLOAT64 | 4 | IEEE 754, konfigurierbar |
+
+**Byte-Reihenfolge (Endianness):**
+- Big-Endian: Höchstwertiges Byte zuerst
+- Little-Endian: Niedrigstwertiges Byte zuerst
+- Wort-Reihenfolge: Hochwort zuerst oder Niedrigwort zuerst
+
+Häufige Kombinationen: 1211 (Big-Endian-Wort, Big-Endian-Byte), 2143, 4321 usw.
+
+## Funktionscodes
+
+Häufige Modbus-Funktionscodes:
+
+| Code | Name | Beschreibung |
+|------|------|-------------|
+| 01 | Read Coils | Mehrere Coil-Status lesen |
+| 02 | Read Discrete Inputs | Mehrere diskrete Eingänge lesen |
+| 03 | Read Holding Registers | Mehrere Holding Registers lesen |
+| 04 | Read Input Registers | Mehrere Input Registers lesen |
+| 05 | Write Single Coil | Ein einzelnes Coil schreiben |
+| 06 | Write Single Register | Ein einzelnes Holding Register schreiben |
+| 07 | Read Exception Status | Gerätekennstatus lesen |
+| 08 | Diagnostics | Diagnose-Funktionen |
+| 15 | Write Multiple Coils | Mehrere Coil-Status schreiben |
+| 16 | Write Multiple Registers | Mehrere Holding Registers schreiben |
+| 17 | Report Slave ID | Slave ID und zusätzliche Informationen melden |
+
+## Verwendung in Ihren Projekten
+
+Basierend auf der Repository-Struktur wird Modbus wahrscheinlich verwendet von:
+
+- [[E3DC]]-Systeme stellen Modbus-TCP-Schnittstellen bereit
+- [[ha-core]] kann Modbus verwenden, um mit E3DC-Wechselrichtern zu kommunizieren
+- [[Home Assistant]]-Integrationen verwenden häufig Modbus zur Gerätekommunikation
+
+### Beispiel: Lesen von E3DC-Daten über Modbus TCP
+
+```python
+# Python example using pymodbus
+from pymodbus.client import ModbusTcpClient
+
+client = ModbusTcpClient('192.168.1.100', port=502)
+client.connect()
+
+# Read battery SOC (Holding Register 40000, assuming INT16)
+response = client.read_holding_registers(0, 1, slave=1)
+soc = response.registers[0]
+
+print(f"Battery SOC: {soc}%")
+client.close()
+```
+
+```go
+// Go example using a Modbus library
+package main
+
+import (
+    "fmt"
+    "github.com/goburrow/modbus"
+)
+
+func main() {
+    handler := modbus.NewTCPClientHandler("192.168.1.100:502")
+    handler.SlaveId = 1
+    handler.Timeout = 5000 * time.Millisecond
+    
+    client := modbus.NewClient(handler)
+    if err := client.Connect(); err != nil {
+        panic(err)
+    }
+    defer client.Close()
+    
+    // Read holding register 0
+    results, err := client.ReadHoldingRegisters(0, 1)
+    if err != nil {
+        panic(err)
+    }
+    
+    fmt.Printf("Value: %d\n", results[0])
+}
+```
+
+## Häufige Probleme
+
+1. **Endianness-Fehler** - Daten erscheinen mit falschen Werten
+2. **Register-Adressierung um Eins daneben** - Verschiedene Hersteller verwenden unterschiedliche Adressierung
+3. **Baud-Raten-Fehler** - Für serielle Verbindungen
+4. **Parität/Stop-Bits** - Serielle Konfigurationsprobleme
+5. **Slave-ID-Konflikte** - Mehrere Geräte mit gleicher ID auf demselben Bus
+6. **Timeout-Probleme** - Gerät reagiert nicht innerhalb des Timeout-Zeitraums
+7. **Byte-Reihenfolge-Verwirrung** - Unterschiedliche Interpretationen von Register-Paaren
+
+## Best Practices
+
+1. **Die Modbus-Map immer dokumentieren** - Welche Register enthalten welche Daten
+2. **Zuerst mit Modbus-Tools testen** - Modbus Poll, QModMaster oder ähnliches verwenden
+3. **Timeouts elegant verarbeiten** - Geräte können vorübergehend nicht verfügbar sein
+4. **Werte zwischenspeichern** - Nicht zu häufig abfragen
+5. **Daten validieren** - Auf angemessene Bereiche prüfen
+6. **Ordnungsgemäße Fehlerbehandlung verwenden** - Nicht davon ausgehen, dass Lesevorgänge erfolgreich sind
+7. **Endianness dokumentieren** - Byte- und Wort-Reihenfolge angeben
+
+## Tools
+
+- **Modbus Poll** - Windows GUI-Tool zum Testen
+- **QModMaster** - Cross-Plattform-Modbus-Master
+- **modbus-palette** - Node-RED-Knoten für Modbus
+- **pymodbus** - Python-Bibliothek
+- **goburrow/modbus** - Go-Bibliothek
+- **libmodbus** - C-Bibliothek
+- **Wireshark** - Mit Modbus-Dissektor für Analyse
+
+## Wann Modbus zu verwenden
+
+- Verbindung zu industriellen Geräten (PLCs, Wechselrichter, Sensoren)
+- Wenn Ethernet oder Seriell verfügbar ist
+- Für einfache, zuverlässige Kommunikation
+- Wenn das Gerät Modbus nativ unterstützt
+
+## Wann Modbus NICHT zu verwenden
+
+- Wenn höherwertige Protokolle verfügbar sind (MQTT, HTTP REST)
+- Für komplexe Datenstrukturen
+- Wenn Sicherheit ein Problem ist (Modbus hat keine eingebaute Sicherheit)
+- Für Hochgeschwindigkeits-Datenübertragung mit hohem Volumen
+
+## Sicherheitsaspekte
+
+**Modbus hat keine eingebaute Sicherheit:**
+- Keine Authentifizierung
+- Keine Verschlüsselung
+- Keine Integritätsprüfung
+
+**Abhilfemaßnahmen:**
+- Auf isolierten Netzwerken verwenden (nicht dem Internet ausgesetzt)
+- VPNs oder Firewalls zum Einschränken des Zugriffs verwenden
+- Modbus Security (TLS) in Betracht ziehen, falls verfügbar
+- Netzwerksegmentierung verwenden
+
+## Leistung
+
+- **Latenz:** Normalerweise 10-100ms pro Anfrage
+- **Durchsatz:** 10-100 Anfragen/Sekunde (hängt vom Netzwerk und den Geräten ab)
+- **Nachrichtengröße:** Durch Protokoll begrenzt (normalerweise < 260 Bytes)
+
+## Verwandte Concepts
+
+- [[MQTT]] - Alternatives Protokoll für IoT/Industrie
+- [[OPC UA]] - Modernes Industrieprotokoll mit Sicherheit
+- Industrial-Automation-Konzept
+
+## Historie
+
+- [1979] - Ursprünglich von Modicon veröffentlicht
+- [2004] - Modbus IDA (Modbus Industrial Automation) gegründet
+- [2006] - Modbus/TCP-Spezifikation veröffentlicht
+- [2007] - Modbus-Organisation gegründet
+- [2026-07-25] - Concept-Seite erstellt
+
+## Siehe auch
+
+- [Modbus Organization](https://modbus.org/)
+- [Modbus Specifications](https://modbus.org/specifications/)
+
+<!-- wikitool:links -->
+## Beziehungen
+
+- **see-also:** [[E3DC]]
+- **see-also:** [[ha-core]]
+- **see-also:** [[Home Assistant]]
+<!-- /wikitool:links -->
@@ -0,0 +1,194 @@
+---
+type: types/concept.md
+concept_type: protocol
+tags: [storage, ssd, performance, optimization, linux]
+created: 2026-07-31
+modified: 2026-08-29
+related:
+  - see-also: LVM
+  - see-also: Arch Linux
+sources: [Source - Arch Linux Cheat Sheet]
+confidence: 0.90
+confidence_base: 0.90
+provenance: sourced
+summary: Datenträgerbefehl, mit dem SSDs ungenutzte Blöcke zurückgewinnen - für gleichbleibende Leistung und längere Lebensdauer.
+---
+# SSD TRIM
+
+**Typ:** protocol
+
+## Definition
+
+TRIM (oder Discard) ist ein Befehl, der einem Betriebssystem ermöglicht, eine Solid-State Drive (SSD) darüber zu informieren, welche Datenblöcke nicht mehr in Gebrauch sind und intern gelöscht werden können. Dies ist entscheidend für die Erhaltung der SSD-Leistung und Lebensdauer, da es der Garbage Collection der SSD ermöglicht, ungenutzte Blöcke freizugeben.
+
+## Kernpunkte
+
+- **Zweck:** Erhaltung der SSD-Leistung und Verlängerung der Lebensdauer
+- **Mechanismus:** OS benachrichtigt SSD über ungenutzte Blöcke
+- **Vorteil:** Verhindert Schreibverstärkung und Leistungsabbau
+- **Protokoll:** Teil des ATA- und SCSI-Befehlssatzes
+
+## Wie TRIM funktioniert
+
+### Ohne TRIM
+1. SSD schreibt Daten in einen Block
+2. Block wird „belegt"
+3. Datei wird vom OS gelöscht
+4. OS markiert Block als „frei", aber SSD weiß das nicht
+5. Nächster Schreibvorgang erfordert: alte Daten lesen → ändern → löschen → neue Daten schreiben
+6. Leistung verschlechtert sich im Laufe der Zeit
+
+### Mit TRIM
+1. SSD schreibt Daten in einen Block
+2. Block wird „belegt"
+3. Datei wird vom OS gelöscht
+4. **OS sendet TRIM-Befehl:** „Block X wird nicht mehr verwendet"
+5. SSD markiert Block intern als „veraltet"
+6. Nächster Schreibvorgang: SSD kann direkt in vorgelöschten Block schreiben
+7. Leistung bleibt konsistent
+
+## TRIM unter Linux aktivieren
+
+### TRIM-Unterstützung überprüfen
+
+```bash
+# Check if SSD supports TRIM
+lsblk -D | grep -i discard
+
+# Check if filesystem supports TRIM
+lsblk -f | grep -i discard
+```
+
+### Manuelles TRIM
+
+```bash
+# Run TRIM manually on a mount point
+fstrim /mount/point
+
+# Run TRIM on all mounted filesystems
+fstrim -a
+
+# Verbose output
+fstrim -v /mount/point
+```
+
+### Automatisches TRIM
+
+**systemd-Timer (empfohlen):**
+```bash
+# Enable weekly TRIM timer
+systemctl enable fstrim.timer
+systemctl start fstrim.timer
+
+# Check status
+systemctl status fstrim.timer
+
+# Manual trigger
+systemctl start fstrim.service
+```
+
+**Cron-Job (Alternative):**
+```bash
+# Add to root's crontab
+0 3 * * 0 fstrim -a
+```
+
+## TRIM mit Verschlüsselung
+
+Beim Einsatz von Laufwerksverschlüsselung (dm-crypt/LUKS) erfordert TRIM-Unterstützung besondere Aufmerksamkeit wegen Sicherheitsauswirkungen.
+
+### Sicherheitsaspekte
+
+**Warnung:** Das Zulassen von Discard (TRIM) auf verschlüsselten Geräten kann Informationen offenlegen über:
+- Welche Blöcke in Gebrauch sind
+- Dateisystem-Nutzungsmuster
+- Potenziell vertrauliche Metadaten
+
+### Optionen für verschlüsselte SSDs
+
+#### Option 1: Discard auf LUKS-Ebene zulassen
+```bash
+# For new encryption
+cryptsetup luksFormat --allow-discards /dev/sdX
+
+# For existing encryption (requires reencryption)
+cryptsetup reencrypt --encrypt --reduce-device-size 16M --allow-discards /dev/sdX
+```
+
+#### Option 2: Periodisches fstrim (Empfohlen für Sicherheit)
+```bash
+# Disable discard in crypttab
+# /dev/sdX1 /mnt/crypt ext4 defaults 0 2
+
+# Manually run fstrim after unlocking
+fstrim /mnt/crypt
+
+# Or use systemd timer (runs after boot)
+systemctl enable fstrim.timer
+```
+
+#### Option 3: Hybrid-Ansatz
+- Discard für unverschlüsselte Metadatenbereiche zulassen
+- Periodisches fstrim für Datenbereiche verwenden
+
+**Referenz:** https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discard/TRIM_support_for_solid_state_drives_(SSD)
+
+## TRIM-Status überprüfen
+
+```bash
+# Check if discard is enabled for device
+lsblk -D /dev/sdX
+
+# Check mount options
+mount | grep discard
+
+# Check filesystem support
+lsblk -o NAME,FSTYPE,DISC-GRAN,DISC-MAX
+```
+
+## Dateisystem-Unterstützung
+
+| Dateisystem | TRIM-Unterstützung | Hinweise |
+|------------|---------------|-------|
+| ext4 | Ja | Standard in modernen Kerneln |
+| XFS | Ja | Online-Discard unterstützt |
+| Btrfs | Ja | Subvolume-fähig |
+| NTFS | Ja | Via ntfs-3g |
+| FAT32 | Nein | Keine TRIM-Unterstützung |
+
+## Leistungsauswirkung
+
+- **Ohne TRIM:** Leistung kann sich nach längerer Verwendung um 30-50 % verschlechtern
+- **Mit TRIM:** Leistung bleibt nah bei Neu-Niveau
+- **Overhead:** TRIM-Befehle verursachen minimalen Overhead (~1-2%)
+
+## Wann zu verwenden
+
+- **Immer:** Auf SSD-Speichergeräten
+- **Empfohlen:** Auf NVMe-Laufwerken (TRIM ist noch kritischer)
+- **Erwägen:** Auf Hybrid-SSHD-Laufwerken
+- **Nicht nötig:** Auf HDD (rotierenden) Laufwerken
+
+## Wann NICHT zu verwenden
+
+- Auf HDD (rotierenden) Laufwerken - kein Nutzen
+- In hochsicheren Umgebungen, in denen Informationsverlust inakzeptabel ist (Kompromisse erwägen)
+- Auf Dateisystemen, die TRIM nicht unterstützen
+
+## Beziehungen
+
+(dm-crypt/LUKS)
+- **Wirkt sich aus auf:** Speicherleistung SSD-gestützter Systeme
+
+## Siehe auch
+
+- [[Source - Arch Linux Cheat Sheet]]
+- https://wiki.archlinux.org/title/Solid_State_Drives
+- https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discard/TRIM_support_for_solid_state_drives_(SSD)
+
+<!-- wikitool:links -->
+## Beziehungen
+
+- **see-also:** [[LVM]]
+- **see-also:** [[Arch Linux]]
+<!-- /wikitool:links -->