# 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](../spec/revit-csv-integration-requirements.md). > 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text revitModelId ``` Beispiel: ```text 550e8400-e29b-41d4-a716-446655440000 ``` Diese ID darf nicht ausschließlich aus folgenden Informationen erzeugt werden: ```text Dateiname Dateipfad lokaler Speicherort ``` da sich diese ändern können. Mögliche Speicherorte in Revit: ### Variante A – Projektparameter Zum Beispiel: ```text 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: ```text 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: ```text ┌──────────────────────────── 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: ```json { "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: ```text 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: ```text 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. ```text 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: ```text 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: ```text 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: ```text (revitModelId, revitUniqueId) ``` Beim Empfang eines Snapshots: ```text 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: ```http POST /api/integrations/revit/v1/models/{modelId}/sync ``` Alternativ logisch getrennt: ```http POST /api/integrations/revit/v1/models/{modelId}/elements GET /api/integrations/revit/v1/models/{modelId}/writeback ``` Beispielantwort auf einen Revit-Sync: ```json { "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: ```text PUSH Revit ↓ Leistungsbilanz ``` und: ```text PULL / WRITEBACK Leistungsbilanz ↓ Revit ``` Der Benutzer soll bewusst entscheiden können, wann Daten nach Revit zurückgeschrieben werden. Zum Beispiel: ```text [ 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: ```json { "updates": [ { "uniqueId": "abcdef...", "values": { "circuitNumber": "UV01-2F17", "panel": "UV01", "connectedLoad": 250 } } ] } ``` Der Revit-Adapter besitzt anschließend eine feste Allowlist bzw. ein Mapping: ```text 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: ```text 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: ```text 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: ```text ┌─────────────────────┐ │ Leistungsbilanz │ │ RevitSyncService │ └─────────┬───────────┘ │ ┌─────────────┴─────────────┐ │ │ REST Datei │ │ ▼ ▼ Dynamo Python JSON / CSV │ ▼ Revit ``` Der gleiche interne Import-Service sollte möglichst sowohl: ```text HTTP JSON ``` als auch: ```text 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: ```text Dynamo ↓ direkte SQL-Verbindung ↓ DB ``` Empfohlen: ```text 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: ```text 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: ```text 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: ```text schemaVersion = 1 ``` und/oder: ```text /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: ```text 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: ```text 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: ```text 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: ```text 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: ```text HTTP Method Route Request DTO Response DTO Validierung Fehlercodes Authentifizierung ``` ### Sync-Service Mit klarer Verantwortung für: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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 ```text REVIT │ Revit API │ Dynamo / Python │ JSON DTO │ REST / HTTP │ ▼ Leistungsbilanz API │ Sync Service │ ┌───────────┴───────────┐ │ │ Revit-Referenz Business Logic │ │ └───────────┬───────────┘ │ DeviceRow │ Circuit │ Distributor ``` Später: ```text 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.