leistungsbilanz-ts/docs/archive/revit-dynamo-leistungsbilanz-integration-konzept.md

Revit-/Dynamo-Anbindung an die Leistungsbilanz

Archiviert (September 2026), keine aktuelle Implementierungsanweisung. Die direkte Revit-Anbindung über Dynamo/Python, Revit-API und JSON wird nicht weiterverfolgt. Die weitere Revit-Arbeit ist zurückgestellt und erfolgt, wenn sie wieder aufgenommen wird, über den CSV-Export/-Import des Linear-Plugins in Revit. Siehe Revit-CSV-Anforderungen. Die zugehörigen Dynamo-Diagnoseskripte sind über den Git-Tag archive/dynamo-vorueberlegungen erreichbar.

Zweck dieses Dokuments

Dieses Dokument beschreibt den aktuellen Stand und die gewünschte Zielrichtung für die Anbindung von Revit an die Leistungsbilanz-App.

Es soll als Arbeitsgrundlage für Codex dienen. Codex soll zuerst die bestehende Architektur des Repositories analysieren und danach konkrete Vorschläge für:

1. die API-Struktur der Leistungsbilanz,
2. das Austauschformat zwischen Revit und Leistungsbilanz,
3. die benötigten Dynamo-/Python-Skripte,
4. die Synchronisationslogik Revit → Leistungsbilanz,
5. die spätere Rückrichtung Leistungsbilanz → Revit

erarbeiten.

Die nachfolgend genannten Klassennamen, Endpoints und DTOs sind Vorschläge und keine zwingenden Vorgaben. Sie sollen an die tatsächlich vorhandene Architektur angepasst werden.

---

1. Ausgangssituation

Die Leistungsbilanz-App soll Daten aus Revit übernehmen können.

Ursprünglich war dafür ein CSV-basierter Import vorgesehen, weil Revit-Bauteillisten nativ als CSV exportiert werden können.

Inzwischen ist klar, dass Dynamo mit Python genutzt werden kann und damit ein direkter Zugriff auf die Revit API möglich ist.

Dadurch ist eine wesentlich sauberere direkte Integration möglich.

Die CSV-Schnittstelle soll deshalb nicht zwingend entfallen, aber künftig eher als:

• manueller Importweg,
• Fallback,
• allgemeine Austauschmöglichkeit,
• Debug-/Testformat

verstanden werden.

Die primäre Revit-Integration soll perspektivisch über eine versionierte API mit JSON als Austauschformat erfolgen.

---

2. Aktueller Dynamo-Stand

Ein erster Dynamo-Python-Test funktioniert bereits.

Aktuell werden über die Revit API alle Exemplare der Kategorie:

BuiltInCategory.OST_ElectricalFixtures

also Revit Elektroinstallationen / Electrical Fixtures gesammelt.

Für den aktuellen Entwicklungsstand soll bewusst zunächst nur diese Kategorie betrachtet werden.

Andere Kategorien können später ergänzt werden.

---

3. Bereits erfolgreich aus Revit gelesene Daten

Der aktuelle Python-Ansatz kann bereits folgende Daten ausgeben:

ElementId
UniqueId
Familie
Typ
MEP_Raumnummer
MEP_Raumname
IFC_GUID

Die Zuordnung zum MEP-Raum erfolgt über den zum FamilyInstance gehörenden MEP Space.

Der aktuelle Test zeigt, dass das grundsätzliche Auslesen über Dynamo/Python funktioniert.

---

4. Relevante Identitäten

Für die Kopplung zwischen Revit und Leistungsbilanz sollen mehrere Identifikatoren berücksichtigt werden.

4.1 Revit UniqueId

Die UniqueId soll die primäre Revit-seitige Elementidentität darstellen.

Sie sollte für die dauerhafte Zuordnung eines Revit-Elements verwendet werden.

Beispiel:

revitUniqueId = "0a52cc55-..."

---

4.2 ElementId

Die Revit ElementId soll ebenfalls übertragen werden.

Sie ist nützlich für:

• Debugging,
• Fehlersuche,
• Anzeige für den Anwender,
• direkte Suche eines Elements in Revit.

Sie soll aber nicht als alleiniger persistenter Schlüssel zwischen den Systemen verwendet werden.

---

4.3 IFC GUID

Die IFC GUID soll ebenfalls mitgeführt werden, sofern sie im Revit-Modell vorhanden ist.

Damit entsteht perspektivisch eine Verbindung:

Revit
  ↕ UniqueId
Leistungsbilanz
  ↕ IFC GUID
IFC

Die IFC GUID ist damit insbesondere für spätere IFC-basierte Integrationen relevant.

---

5. Zusätzlich benötigte Modellidentität

Die UniqueId identifiziert ein Element innerhalb eines Revit-Modells.

Deshalb benötigt die Leistungsbilanz zusätzlich eine stabile Identität des Revit-Modells.

Vorgeschlagener Schlüssel:

revitModelId

Beispiel:

550e8400-e29b-41d4-a716-446655440000

Diese ID darf nicht ausschließlich aus folgenden Informationen erzeugt werden:

Dateiname
Dateipfad
lokaler Speicherort

da sich diese ändern können.

Mögliche Speicherorte in Revit:

Variante A – Projektparameter

Zum Beispiel:

LB_ProjectId
LB_ModelId

Vorteile:

• einfach umzusetzen,
• sichtbar,
• leicht zu debuggen,
• direkt über Dynamo lesbar.

Variante B – Revit Extensible Storage

Langfristig eleganter, weil integrationsspezifische Metadaten unsichtbar im Modell gespeichert werden können.

Beispielsweise:

LeistungsbilanzConnector
{
    modelId
    projectId
    lastSync
}

Für einen ersten Prototyp ist ein Projektparameter wahrscheinlich ausreichend.

---

6. Grundprinzip der Zielarchitektur

Die Revit-Schnittstelle soll nicht direkt an interne Datenbanktabellen gekoppelt werden.

Empfohlen wird:

┌──────────────────────────── REVIT ────────────────────────────┐
│                                                               │
│  Revit API                                                    │
│      ↓                                                        │
│  Dynamo + Python                                              │
│      ↓                                                        │
│  Revit-Adapter                                                │
│      ↓                                                        │
│  definiertes Austauschmodell                                 │
│      ↓                                                        │
│  JSON                                                         │
│                                                               │
└───────────────────────┬───────────────────────────────────────┘
                        │
                        │ HTTP / REST
                        ▼
┌──────────────────── LEISTUNGSBILANZ ──────────────────────────┐
│                                                               │
│  Revit Integration API                                        │
│      ↓                                                        │
│  Import-/Sync-Service                                         │
│      ↓                                                        │
│  persistierte Revit-Referenz                                  │
│      ↓                                                        │
│  Zuordnung zu DeviceRow / Circuit / bestehendem Datenmodell   │
│                                                               │
└───────────────────────────────────────────────────────────────┘

Wichtig:

JSON ist das Austauschformat. HTTP ist nur der Transportweg.

Dasselbe Datenmodell soll deshalb bei Bedarf auch als JSON-Datei gespeichert und eingelesen werden können.

---

7. Austauschmodell / DTO

Es soll ein klar definiertes und versioniertes Austauschformat geben.

Beispiel:

{
  "schemaVersion": 1,
  "source": "revit",
  "model": {
    "id": "550e8400-e29b-41d4-a716-446655440000",
    "name": "26009_F60_ELT"
  },
  "elements": [
    {
      "uniqueId": "f4d3c...",
      "elementId": 471123,
      "ifcGuid": "2X9...",
      "category": "Electrical Fixtures",
      "family": "Steckdose JUNG LS990",
      "type": "Schuko 1-fach",
      "space": {
        "number": "1.03",
        "name": "Schlafen"
      },
      "parameters": {
        "power": 250,
        "cosPhi": 0.95
      }
    }
  ]
}

Das tatsächliche Schema soll durch Codex anhand des bestehenden Datenmodells der Leistungsbilanz konkretisiert werden.

---

8. Trennung zwischen Revit-Objekt und Leistungsbilanz-Objekt

Ein Revit-Element soll nicht direkt mit einer DeviceRow gleichgesetzt werden.

Das ist wichtig, weil:

• Revit den geplanten Modellstand enthält,
• Nutzer Werte in der Leistungsbilanz überschreiben können,
• ein importiertes Revit-Element erst vom Nutzer einem bestehenden oder neuen Stromkreis bzw. einer DeviceRow zugeordnet werden kann,
• ein erneuter Sync keine bewussten Benutzeränderungen überschreiben darf.

Konzeptionell sollte deshalb eine separate Revit-Referenz existieren.

Beispiel:

RevitElement
    │
    │ verknüpft mit
    ▼
LinkedDevice / Zuordnung
    │
    ▼
DeviceRow
    │
    ▼
Circuit

Die tatsächliche Umsetzung muss Codex mit der vorhandenen Architektur abgleichen.

Mögliche Eigenschaften einer persistierten Revit-Referenz:

id
revitModelId
revitUniqueId
revitElementId
ifcGuid

category
family
type

spaceNumber
spaceName

rawData
lastSeenAt
lastSyncAt

Die Bezeichnung RevitElement ist nur ein Vorschlag.

Wenn es im aktuellen Datenmodell bereits eine passende Entität gibt, soll diese verwendet oder erweitert werden.

---

9. Revit → Leistungsbilanz

Der erste zu implementierende Sync soll in diese Richtung erfolgen.

Revit
  ↓
Dynamo
  ↓
Python / Revit API
  ↓
JSON Payload
  ↓
HTTP POST
  ↓
Leistungsbilanz API
  ↓
Sync-Service

Vorgeschlagenes Verhalten

Der Benutzer startet in Dynamo bewusst einen Export bzw. Sync.

Das Python-Skript:

1. liest alle relevanten OST_ElectricalFixtures,
2. liest die definierten Revit-Daten,
3. erzeugt das versionierte JSON,
4. sendet es an die Leistungsbilanz,
5. wertet die HTTP-Antwort aus,
6. zeigt dem Benutzer das Ergebnis in Dynamo an.

---

10. Snapshot-Sync statt Delta-Sync

Für den ersten Stand soll kein komplexer Delta-Sync gebaut werden.

Stattdessen soll Revit bei jedem Sync einen vollständigen Snapshot aller aktuell relevanten Elektroinstallationen liefern.

Beispiel:

vorher                   aktueller Snapshot
------------------------------------------------
Element A vorhanden      Element A vorhanden
Element B vorhanden      Element B vorhanden
Element C vorhanden      Element C fehlt
                         Element D neu

Die Leistungsbilanz kann daraus ableiten:

A → unchanged oder updated
B → unchanged oder updated
C → missing / deleted / not seen
D → created

Das ist für zunächst einige hundert oder tausend Elemente ausreichend und deutlich robuster.

---

11. Upsert-Verhalten

Auf Leistungsbilanzseite soll ein Revit-Element anhand eines stabilen Schlüssels identifiziert werden.

Vorgeschlagen:

(revitModelId, revitUniqueId)

Beim Empfang eines Snapshots:

Element bereits vorhanden?
        │
        ├─ Nein
        │    ↓
        │  Create
        │
        └─ Ja
             ↓
           Update

Die Revit-Referenz soll dabei aktualisiert werden.

Benutzerseitig überschriebene Werte einer DeviceRow dürfen dadurch jedoch nicht ungeprüft überschrieben werden.

---

12. Mögliche API-Struktur

Nicht zwingend exakt so umsetzen.

Codex soll prüfen, wie die aktuelle API strukturiert ist.

Mögliche Endpoints:

POST /api/integrations/revit/v1/models/{modelId}/sync

Alternativ logisch getrennt:

POST /api/integrations/revit/v1/models/{modelId}/elements
GET  /api/integrations/revit/v1/models/{modelId}/writeback

Beispielantwort auf einen Revit-Sync:

{
  "syncId": "sync-9384",
  "received": 483,
  "created": 17,
  "updated": 45,
  "unchanged": 421,
  "missing": 3
}

Die konkrete Antwortstruktur soll so gewählt werden, dass Dynamo dem Nutzer eine verständliche Zusammenfassung anzeigen kann.

---

13. Leistungsbilanz → Revit

Die Rückrichtung soll später ebenfalls unterstützt werden.

Sie soll jedoch zunächst logisch vom Revit-Import getrennt werden.

Also:

PUSH

Revit
  ↓
Leistungsbilanz

und:

PULL / WRITEBACK

Leistungsbilanz
  ↓
Revit

Der Benutzer soll bewusst entscheiden können, wann Daten nach Revit zurückgeschrieben werden.

Zum Beispiel:

[ Revit-Daten importieren ]

[ Änderungen nach Revit schreiben ]

---

14. Writeback nicht generisch ausführen

Die Leistungsbilanz soll nicht beliebige Parameter-Namen an Revit schicken, die Dynamo anschließend blind beschreibt.

Stattdessen soll es ein definiertes Writeback-Schema geben.

Beispiel:

{
  "updates": [
    {
      "uniqueId": "abcdef...",
      "values": {
        "circuitNumber": "UV01-2F17",
        "panel": "UV01",
        "connectedLoad": 250
      }
    }
  ]
}

Der Revit-Adapter besitzt anschließend eine feste Allowlist bzw. ein Mapping:

circuitNumber
    ↓
LB_Stromkreisnummer

panel
    ↓
LB_Verteiler

connectedLoad
    ↓
LB_Anschlussleistung

Damit ist kontrolliert, welche Revit-Parameter durch die Leistungsbilanz beschrieben werden dürfen.

---

15. Field Ownership / Datenhoheit

Für bidirektionale Synchronisation muss definiert sein, welches System für welches Feld führend ist.

Beispiel:

Information	Führendes System
Revit UniqueId	Revit
Revit ElementId	Revit
IFC GUID	Revit
Familie	Revit
Typ	Revit
MEP Raum	Revit
MEP Raumnummer	Revit
Zuordnung zu DeviceRow	Leistungsbilanz
Zuordnung zu Circuit	Leistungsbilanz
manuell überschriebene Leistung	Leistungsbilanz
Sicherung	Leistungsbilanz
Leitung	Leistungsbilanz
Stromkreisnummer	Leistungsbilanz, ggf. Writeback
Verteilerzuordnung	Leistungsbilanz, ggf. Writeback

Diese Tabelle muss anhand des bestehenden Datenmodells vervollständigt werden.

Ziel ist, Konflikte wie diesen zu vermeiden:

Revit:
Leistung = 500 W

Leistungsbilanz:
Nutzer überschreibt auf 750 W

nächster Revit-Sync:
Revit liefert wieder 500 W

Der bewusste Benutzerwert darf nicht kommentarlos verloren gehen.

---

16. Rohdaten und normalisierte Daten

Es sollte geprüft werden, ob zusätzlich zu den normalisierten Daten ein Teil des ursprünglichen Revit-Payloads gespeichert werden sollte.

Beispiel:

rawData / rawPayload

Vorteile:

• Debugging,
• spätere Erweiterung ohne sofortigen Revit-Neuexport,
• Nachvollziehbarkeit,
• Erkennung neuer Parameter.

Dabei soll aber vermieden werden, die eigentliche Business-Logik auf unstrukturiertem JSON aufzubauen.

---

17. CSV und JSON-Datei weiterhin unterstützen

Auch bei einer direkten API-Anbindung sollen Datei-basierte Wege sinnvoll bleiben.

Mögliche Architektur:

                        ┌─────────────────────┐
                        │ Leistungsbilanz     │
                        │ RevitSyncService    │
                        └─────────┬───────────┘
                                  │
                    ┌─────────────┴─────────────┐
                    │                           │
                  REST                        Datei
                    │                           │
                    ▼                           ▼
             Dynamo Python               JSON / CSV
                    │
                    ▼
                  Revit

Der gleiche interne Import-Service sollte möglichst sowohl:

HTTP JSON

als auch:

JSON-Datei

verarbeiten können.

CSV kann als separates allgemeines Importformat bestehen bleiben.

---

18. Kein direkter Datenbankzugriff aus Dynamo

Dynamo soll nicht direkt auf SQLite, PostgreSQL oder andere Datenbanken der Leistungsbilanz zugreifen.

Nicht empfohlen:

Dynamo
  ↓
direkte SQL-Verbindung
  ↓
DB

Empfohlen:

Dynamo
  ↓
API
  ↓
Business Logic
  ↓
ORM
  ↓
DB

Dadurch bleibt der Revit-Connector unabhängig von:

• Tabellenstruktur,
• ORM,
• Migrationen,
• internen Relationen,
• späteren Änderungen des Backends.

---

19. Zunächst kein WebSocket / Echtzeit-Sync

Für den aktuellen Anwendungsfall ist kein permanenter Echtzeitkanal erforderlich.

Nicht notwendig:

Leistungsbilanz wird geändert
        ↓
sofort automatische Änderung in Revit

Stattdessen soll zunächst mit expliziten Sync-Aktionen gearbeitet werden.

Das ist auch im Hinblick auf Revit sinnvoll, da Änderungen über die Revit API kontrolliert und innerhalb gültiger Revit-Transactions vorgenommen werden müssen.

---

20. Fehlerbehandlung

Die Integration muss mit Teilfehlern umgehen können.

Beispiele:

• ein Element besitzt keinen MEP Space,
• IFC GUID fehlt,
• ein erwarteter Parameter fehlt,
• ein Revit-Parameter ist schreibgeschützt,
• HTTP-Verbindung schlägt fehl,
• API antwortet mit Validierungsfehler,
• Element wurde zwischen Abfrage und Writeback gelöscht,
• Revit-Modell ist noch nicht mit einem Leistungsbilanz-Projekt verknüpft.

Das Dynamo-Skript soll möglichst nicht beim ersten fehlerhaften Element komplett abbrechen.

Stattdessen sollte die Antwort z. B. unterscheiden:

success
warnings
errors

und am Ende eine Zusammenfassung ausgeben.

---

21. Authentifizierung

Codex soll prüfen, welche Authentifizierung die aktuelle Leistungsbilanz-App bereits verwendet.

Der Dynamo-Connector soll keine unnötige zweite Authentifizierungsarchitektur einführen.

Mögliche Varianten:

• API Token,
• projektbezogenes Integration Token,
• bestehender Login-Mechanismus,
• kurzfristige Connector-Tokens.

Secrets sollen nicht fest im Dynamo-Python-Code hinterlegt werden.

---

22. Versionierung

Das JSON-Schema und die API sollen versioniert sein.

Beispielsweise:

schemaVersion = 1

und/oder:

/api/integrations/revit/v1/

Dadurch kann ein älteres Dynamo-Skript später noch mit einer neueren App-Version umgehen oder zumindest kontrolliert abgelehnt werden.

---

23. Langfristige Perspektive: Revit Add-in

Dynamo + Python ist für die erste Implementierung ideal, weil schnell getestet und angepasst werden kann.

Langfristig könnte daraus ein echtes Revit-Add-in in C#/.NET werden.

Beispiel:

Revit Ribbon

┌──────── Leistungsbilanz ─────────┐
│                                  │
│  ↑ Daten übertragen              │
│  ↓ Daten aus Leistungsbilanz     │
│                                  │
│  Projekt verbinden               │
│  Sync-Status                     │
│                                  │
└──────────────────────────────────┘

Wichtig ist deshalb, dass die API nicht speziell auf Dynamo zugeschnitten wird.

Ziel:

heute:
Dynamo + Python
       ↓
gleiche REST API

später:
Revit Add-in C#
       ↓
gleiche REST API

---

24. Aktuell gewünschter Dynamo-Umfang

Für den ersten produktiven Revit-Export soll Codex ein Dynamo-Python-Skript vorschlagen, das mindestens folgende Daten aus OST_ElectricalFixtures ermittelt:

revitModelId
ElementId
UniqueId
IFC GUID
Kategorie
Familie
Typ
MEP Raumnummer
MEP Raumname

Zusätzlich soll Codex anhand der aktuellen Leistungsbilanz-Datenstruktur prüfen, welche weiteren Felder bereits jetzt sinnvoll mitgegeben werden sollten.

Dazu könnten später gehören:

Ebene
BMK
Leistung
cosPhi
Spannung
Anzahl
Kommentar
Stromkreis
Verteiler
weitere Shared Parameters

Diese zusätzlichen Felder sollen aber nicht willkürlich eingebaut werden, sondern aus der bestehenden Architektur und den fachlichen Anforderungen der Leistungsbilanz abgeleitet werden.

---

25. Anforderungen an das Dynamo-Python-Skript

Das Skript soll möglichst:

• ohne externe Dynamo-Packages funktionieren,
• nur Revit API / Dynamo-eigene Python-Möglichkeiten verwenden,
• mit der im Projekt eingesetzten Revit-/Dynamo-Version kompatibel sein,
• alle Elektroinstallationen im gesamten aktuellen Revit-Dokument lesen,
• nicht nur die aktive Ansicht betrachten,
• fehlende optionale Parameter tolerieren,
• verständliche Fehlermeldungen liefern,
• eine gut lesbare Statusausgabe an OUT zurückgeben,
• JSON mit UTF-8 erzeugen,
• HTTP-Requests ohne unnötige externe Python-Abhängigkeiten ausführen,
• Timeouts behandeln,
• API-Fehler auswerten,
• keinen Datenverlust verursachen.

Für spätere Writebacks muss das Skript Revit-Änderungen ausschließlich innerhalb gültiger Revit-Transactions durchführen.

---

26. Gewünschter Arbeitsauftrag an Codex

Schritt 1 – Repository analysieren

Vor Änderungen zuerst:

1. AGENTS.md lesen.
2. Bestehende Architektur-Dokumentation lesen.
3. Datenmodell der Leistungsbilanz nachvollziehen.
4. Aktuelle Import-/CSV-Architektur untersuchen.
5. Vorhandene API-Routen analysieren.
6. Prüfen, ob bereits Entitäten oder Konzepte für:
   • externe Modelle,
   • Revit-Elemente,
   • Linked Devices,
   • Sync,
   • Imports,
   • Projekt-Historie existieren.
7. Authentifizierung und Berechtigungssystem prüfen.
8. Bestehende Tests und Testkonventionen prüfen.

Noch keine größere Implementierung beginnen, bevor diese Analyse abgeschlossen ist.

---

Schritt 2 – Bestehende Architektur gegen dieses Konzept abgleichen

Codex soll beantworten:

1. Welche vorhandenen Entitäten können wiederverwendet werden?
2. Brauchen wir überhaupt eine neue RevitElement-Entität?
3. Wie passt die Revit-Referenz in das bestehende LinkedDevice-/DeviceRow-Konzept?
4. Wo sollte das Sync-Verhalten im Backend liegen?
5. Wie soll die Modellidentität gespeichert werden?
6. Welche Felder sind Revit-Master?
7. Welche Felder sind Leistungsbilanz-Master?
8. Wie werden manuell überschriebene Werte geschützt?
9. Wie werden nicht mehr vorhandene Revit-Elemente behandelt?
10. Wie lässt sich das bestehende CSV-System sinnvoll weiterverwenden?

---

Schritt 3 – Konkreten Zielentwurf erstellen

Codex soll danach einen konkreten Entwurf liefern für:

Datenmodell

Mit tatsächlichen Namen passend zum Repository.

API

Mit:

HTTP Method
Route
Request DTO
Response DTO
Validierung
Fehlercodes
Authentifizierung

Sync-Service

Mit klarer Verantwortung für:

Create
Update
Unchanged
Missing
Deleted
Linking
Conflict handling

Dynamo-Schnittstelle

Mit dem exakten JSON, das Dynamo senden bzw. empfangen soll.

---

Schritt 4 – Dynamo-Skripte vorschlagen

Erst nachdem die Zielarchitektur feststeht, soll Codex konkrete Dynamo-Python-Skripte erstellen.

Mindestens:

Script A – Revit → Leistungsbilanz

Funktionen:

Revit-Modell-ID ermitteln
Electrical Fixtures sammeln
Daten auslesen
Payload erzeugen
JSON serialisieren
API aufrufen
Antwort auswerten
Status in Dynamo ausgeben

Script B – Leistungsbilanz → Revit

Noch nicht zwingend sofort implementieren, aber vollständig konzipieren.

Funktionen:

Writeback-Daten von API abrufen
Element über UniqueId finden
Allowlist-Mapping anwenden
Werte prüfen
Revit Transaction starten
Parameter schreiben
Ergebnis an API melden
Status ausgeben

Optional Script C – Debug-/Offline-Export

Export des exakt gleichen Payloads als lokale JSON-Datei.

Damit kann die Schnittstelle auch ohne erreichbare API getestet werden.

---

27. Erwartete Ausgabe von Codex

Codex soll nach der Analyse nicht sofort große Änderungen durchführen, sondern zuerst eine strukturierte Empfehlung liefern.

Gewünschte Reihenfolge:

1. Analyse des Ist-Zustands
2. Abweichungen / bereits vorhandene passende Architektur
3. Empfohlenes Zieldesign
4. Datenmodelländerungen
5. API-Design
6. Sync-Logik
7. Exaktes JSON-Schema
8. Vorschlag Dynamo Script A
9. Vorschlag Dynamo Script B
10. Migrations-/Implementierungsreihenfolge
11. Tests
12. Offene Entscheidungen

Bei Architekturentscheidungen soll Codex die einfachste robuste Lösung bevorzugen und unnötige neue Abstraktionen vermeiden.

---

28. Bevorzugte Implementierungsreihenfolge

Voraussichtlich sinnvoll:

Phase 1
────────────────────────────
Austauschformat / DTO festlegen

Phase 2
────────────────────────────
Backend API für Revit-Snapshot

Phase 3
────────────────────────────
Persistierung und Upsert-Logik

Phase 4
────────────────────────────
Dynamo Revit → API

Phase 5
────────────────────────────
UI für importierte / nicht zugeordnete Revit-Elemente

Phase 6
────────────────────────────
Zuordnungs- und Override-Verhalten

Phase 7
────────────────────────────
Writeback API

Phase 8
────────────────────────────
Dynamo API → Revit

Phase 9
────────────────────────────
ggf. später Revit C# Add-in

---

29. Zentrale Architekturentscheidung

Die wichtigste Vorgabe lautet:

Dynamo soll als Revit-Adapter dienen. Die eigentliche Fachlogik der Leistungsbilanz bleibt in der Leistungsbilanz-App.

Dynamo soll deshalb nicht entscheiden:

welche Sicherung gewählt wird
welche Leitung verwendet wird
wie Stromkreise aufgebaut werden
wie Geräte gruppiert werden
welche Leistungswerte fachlich gültig sind

Dynamo liefert primär Revit-Daten und schreibt später explizit freigegebene Ergebnisse zurück.

Die fachliche Entscheidung bleibt in der Webapp.

---

30. Zielbild

                        REVIT
                          │
                    Revit API
                          │
                   Dynamo / Python
                          │
                     JSON DTO
                          │
                    REST / HTTP
                          │
                          ▼
                Leistungsbilanz API
                          │
                    Sync Service
                          │
              ┌───────────┴───────────┐
              │                       │
        Revit-Referenz          Business Logic
              │                       │
              └───────────┬───────────┘
                          │
                    DeviceRow
                          │
                       Circuit
                          │
                    Distributor

Später:

Leistungsbilanz
       │
   Writeback
       │
       ▼
Dynamo / Python
       │
       ▼
     Revit

Das Ziel ist keine möglichst komplexe Echtzeitkopplung, sondern eine robuste, nachvollziehbare und versionierbare Integration, die zunächst über Dynamo/Python funktioniert und später bei Bedarf durch ein natives Revit-Add-in ersetzt werden kann.