Clone
3
api_reference DE
ispyisail edited this page 2026-09-12 08:09:09 +12:00

QElectroTech automatisieren

Wie man QET aus anderen Programmen heraus steuert, und wie die XML-Dateien aufgebaut sind.

Korrektur, September 2026. Frühere Fassungen dieser Seite behaupteten, QElectroTech unterstütze Python-Skripte und ein Plugin-System, und wiesen Leser an, Plugins nach ~/.local/share/QElectroTech/plugins/ und Entsprechendes zu installieren. Nichts davon existiert. Es gibt weder einen eingebetteten Interpreter noch eine Plugin-Schnittstelle noch ein Plugin-Verzeichnis — QET liest diese Pfade nie. Die folgende Seite beschreibt, was tatsächlich vorhanden ist. Das ist einiges, nur eben nicht das.

Was QET wirklich bietet:

Eine Kommandozeile ohne Oberfläche 13 Verben, die ein Projekt öffnen und exportieren, untersuchen oder neu schreiben, ohne GUI. Die eigentliche Automatisierungsfläche.
XML-Dateien .qet und .elmt sind gewöhnliches XML, mit jedem Werkzeug les- und schreibbar.
Ein externes Begleitprogramm qet_tb_generator, aus einem Menüeintrag gestartet.
C++-Quellcode Für alle, die QET selbst oder einen Fork bauen.

Was es nicht bietet: eingebettete Skripte in irgendeiner Sprache, eine Plugin-API, ein Verzeichnis ladbarer Module oder eine Automatisierungsschnittstelle zu einer laufenden Instanz.


1. Die Kommandozeile

Das ist der Teil, den die meiste Automatisierung nutzen sollte. Ein erkanntes Export-Flag wird vor dem Start der Oberfläche ausgewertet; der Prozess läuft ohne Anzeige, erledigt die Arbeit und endet — er öffnet kein Fenster und reicht nichts an eine bereits laufende Instanz weiter.

qelectrotech --export-pdf meinprojekt.qet ausgabe.pdf

Argumente sind positionsgebunden, nicht --flag=wert. Die Form lautet stets qelectrotech <flag> <projekt.qet> <ausgabe>, mit den beiden unten genannten Ausnahmen.

Die Verben

Flag Ausgabe Anmerkungen
--export-pdf ein PDF alle Folios, je eine Seite
--export-png ein Verzeichnis je ein NN_Titel.png pro Folio
--export-svg ein Verzeichnis je ein NN_Titel.svg pro Folio
--export-bom CSV Stückliste, aus der Projektdatenbank — dieselbe Quelle wie der GUI-Export
--export-wiring CSV Von-Nach-Verdrahtungsliste, eine Zeile je Leiter — entspricht dem Menü Projekt → Verdrahtungsliste (Datenbank) / Verdrahtungsplan exportieren
--export-cables CSV dieselbe logische Liste, aber aus dem Dokument-XML gebildet
--export-wires CSV Leiternummern — entspricht dem Menü Projekt → Liste der Leiternamen exportieren
--export-nets CSV elektrische Netze — zu Potentialen gruppierte Klemmen
--export-links CSV Querverweise, mit Kennzeichnung unverknüpfter Master und Slaves
--info JSON struktureller Abzug: Element- und Leiterzahlen je Folio, unverbundene Klemmen. Schreibt nach stdout, wenn kein Pfad angegeben ist
--resave .qet lädt das Projekt und schreibt sein XML zurück
--set-titleblock .qet trägt Schriftfeldwerte ein und speichert
--check-elements Bericht prüft .elmt-Dateien — erwartet eine Datei oder ein Verzeichnis, kein Projekt

Zwei zusätzliche Schalter:

  • --show-terminals — zeichnet Klemmenmarken und -namen in PDF-/PNG-/SVG- Ausgaben. Standardmäßig aus, passend zum Exportdialog der Oberfläche. Nützlich, um einen unverbundenen Anschluss sichtbar zu machen.
  • --set-titleblock nimmt nach dem Ausgabepfad Zuweisungen schlüssel=wert entgegen: date=today oder ein ISO-Datum JJJJ-MM-TT, die Standard-Schriftfeldschlüssel, oder jeden anderen Schlüssel, der als benutzerdefiniertes Feld abgelegt wird. Fehlerhafte Zuweisungen scheitern, bevor irgendetwas geschrieben wird.

Rückgabewerte

0 Erfolg · 1 die Arbeit schlug fehl (Projekt nicht zu öffnen, nichts zu exportieren, Datei nicht beschreibbar) · 2 falsch aufgerufen (fehlendes Argument, fehlerhafte Zuweisung). Damit lässt sich das Werkzeug direkt in einer CI-Kette verwenden.

Wissenswertes

  • --export-cables und --export-wiring sollen übereinstimmen. Eines wird aus dem Dokument-XML gebildet, das andere aus der Projektdatenbank. Beide laufen zu lassen und zu vergleichen prüft unmittelbar, ob die Datenbank das Projekt noch beschreibt — was sonst nur über die Oberfläche sichtbar ist.
  • Setzen Sie in Skripten immer eine Zeitgrenze. Ein mit einer älteren Version gespeichertes Projekt löst beim Laden eine Warnung aus; im Kommandozeilenmodus werden Meldungsfenster automatisch beantwortet, doch ein unerwarteter modaler Dialog ist der klassische Weg, einen Lauf ohne Oberfläche dauerhaft hängen zu lassen.
  • Absturzsicherungen sind im Kommandozeilenmodus bewusst abgeschaltet: Ihr Schreibvorgang im Hintergrund konkurriert mit dem Prozessende.
  • QT_QPA_PLATFORM=offscreen genügt für diese Verben. Xvfb wird nicht benötigt.
  • Das ist auch QETs echte Antwort auf „Drahtbeschriftungen drucken". QET hat keinen eingebauten Drucker für Drahtmarkierungen/Aderendhülsen (siehe den Abschnitt Diagramme drucken im Benutzerhandbuch für das, was Drucken tatsächlich abdeckt). Der im Forum dokumentierte Arbeitsablauf besteht darin, dieses CSV zu exportieren und in die eigene Software eines Etikettendruckers einzuspeisen — Brady, WAGO Smart-Printer und die Phoenix-Contact-Werkzeuge nehmen allesamt CSV direkt entgegen. Eine bekannte Einschränkung, von einem Schaltschrankbauer im Forum gemeldet: Der Export liefert eine Zeile je Leiter ohne Mengenzusammenfassung, N identische Etiketten erscheinen also als N doppelte Zeilen statt einer Zeile mit Mengenspalte — vor dem Druck einer größeren Charge in einer Tabellenkalkulation entdoppeln. Cembre-artige Drucker, die eine .FNR-Datei oder eine Support-Code-Spalte brauchen, werden von diesem Export gar nicht erst erzeugt; diese Zuordnung muss von Hand aus dem CSV gebaut werden.

Beispiel: eine Revisionskette

set -e
qelectrotech --set-titleblock in.qet gestempelt.qet indexrev=C date=today
qelectrotech --export-pdf gestempelt.qet "release/rev-C.pdf"
qelectrotech --export-bom gestempelt.qet "release/rev-C-bom.csv"

Siehe auch die Kommandozeilen-Referenz.


2. Die Dateien direkt lesen und schreiben

.qet und .elmt sind XML. Alles, was XML verarbeiten kann, kann sie verarbeiten — Pythons xml.etree, lxml, xmlstarlet, XSLT, ganz wie Sie mögen. Das ist gemeint, wenn jemand sagt, er „skripte QET“: Das Skript ist ein eigenes Programm, das die Dateien liest und schreibt und neben QET läuft, nicht darin.

Ein echtes .qet-Gerüst

<project title="ArduinoLCD" version="0.80">
    <properties>
        <property show="1" name="saveddate">17/04/2021</property>
    </properties>
    <newdiagrams>
        <border rows="8" cols="17" rowsize="80" colsize="60" .../>
        <inset folio="%id/%total" author="" title="" .../>
        <conductors type="multi" .../>
        <report label="%f-%l%c"/>
        <xrefs>
            <xref type="coil" master_label="%f-%l%c" slave_label="(%f-%l%c)" .../>
        </xrefs>
    </newdiagrams>
    <diagram title="LCD 4 DATA" order="1" folio="%id/%total" cols="11" rows="7" ...>
        <elements>
            <element x="390" y="570" z="10" orientation="0"
                     type="embed://import/oznaczenia/tekst_08.elmt"
                     uuid="{52d4b9e8-05c3-49a2-8455-a42ff651200a}"
                     prefix="" freezeLabel="false">
                ...
            </element>
        </elements>
        <conductors> ... </conductors>
    </diagram>
    <collection> ... </collection>
</project>

Stolpersteine:

  • Es gibt keine Hülle <diagrams>. <diagram>-Knoten sind direkte Kinder von <project>, einer je Folio, geordnet über ihr Attribut order.
  • <element> hat kein id. Es wird über uuid identifiziert, und sein Attribut type ist ein Ort, meist embed://… für ein in die projekteigene Sammlung kopiertes Element.
  • <newdiagrams> enthält die Vorgaben für neue Folios, nicht die Folios selbst.
  • Die Elementdefinitionen des Projekts liegen unter <collection>; ein Projekt ist daher in der Regel in sich geschlossen.

Vollständige Referenz: Project XML.

Ein echtes .elmt-Gerüst

<definition version="0.90" type="element" link_type="master"
            width="200" height="70" hotspot_x="100" hotspot_y="35">
    <uuid uuid="{2cbd2b72-1d04-f03d-758f-ce3a14dbb3c5}"/>
    <names>
        <name lang="en">UPS</name>
        <name lang="fr">UPS</name>
    </names>
    <kindInformations>
        <kindInformation name="type">coil</kindInformation>
    </kindInformations>
    <informations>Author: RDS for QelectroTech</informations>
    <description>
        <rect x="0" y="0" width="460" height="590" style="..."/>
        <terminal uuid="{73279019-…}" name="" x="-90" y="10" orientation="w" type="Generic"/>
    </description>
</definition>

Stolpersteine:

  • width, height, hotspot_x, hotspot_y sind Pflichtattribute von <definition>, und Breite/Höhe müssen Vielfache von 10 sein — sonst rundet QET auf den nächsten Zehner auf.
  • Die uuid ist ein Attribut (<uuid uuid="{…}"/>), nicht der Elementtext.
  • <name>-Einträge gelten je Sprache und brauchen ein lang-Attribut.
  • link_type macht ein Element zum Master, Slave oder zur Klemme — siehe Elemente verknüpfen.

Vollständige Referenz: Elements XML.

Prüfen Sie, was Sie erzeugen

Eine von Hand geschriebene Datei wird erst geprüft, wenn QET sie öffnet — die Kommandozeile prüft Elementdateien jedoch für Sie:

qelectrotech --check-elements meine_elemente/

Jede Datei wird als OK, WARN (lädt, aber verdächtig — etwa null Klemmen) oder FAIL (nicht lesbar, falsches Wurzel-Tag, fehlender Begrenzungsrahmen) gemeldet, und der Rückgabewert ist bei jedem Fehlschlag ungleich null. Gehört in die CI, wenn Sie .elmt-Dateien erzeugen.

Faustregeln

  • Schließen Sie das Projekt in QET, bevor Sie seine Datei neu schreiben. QET hält ein eigenes Modell im Speicher und überschreibt Sie beim Speichern.
  • --resave ist ein billiger Normalisierer: laden, zurückschreiben, dann vergleichen — so sehen Sie, was QET stillschweigend umschreibt, bevor Sie ein Werkzeug auf eine Annahme über das Markup stützen.
  • Elemente und Leiter werden über UUID identifiziert. Einen Elementknoten zu kopieren, ohne ihm eine neue uuid zu geben, erzeugt zwei Elemente, die QET für dasselbe hält.

3. qet_tb_generator — was „Plugin“ bei QET bedeutet

Es gibt einen Menüeintrag, Plugin zur Klemmenleistenerstellung starten, und ein Programm dahinter. qet_tb_generator ist ein eigenständiges Drittprogramm, über PyPI verteilt, das .qet-Dateien von außen liest und schreibt, um Klemmenleisten zu erzeugen.

python -m pip install --upgrade qet_tb_generator

QET startet es, indem es eine feste Liste von Orten durchsucht — QETApp::dataDir() + "/binary/", das aktuelle Verzeichnis, ~/.qet/ und dann, was PATH auflöst — und es als gewöhnlichen Kindprozess ausführt. Das ist die gesamte Integration: kein gemeinsamer Speicher, keine API, keine Rückrufe. Liegt die ausführbare Datei auf keinem dieser Pfade, findet der Menüeintrag sie nicht.

Unterstützung durch die Gemeinschaft gibt es im Forum: Skripte · Code/Programmierung

„Ein Plugin schreiben“ heißt daher: ein eigenständiges Programm schreiben, das die Dateien bearbeitet, genau wie in §2 beschrieben. Es gibt keine Schnittstelle zu implementieren und kein Verzeichnis, in das man installiert.


4. Der C++-Quellcode

Um QET selbst zu ändern oder einen Fork zu bauen:

Orientierungspunkte, alle in sources/:

Klasse Datei Rolle
QETProject qetproject.cpp ein Projekt: Folios, Sammlung, Laden und Speichern
Diagram diagram.cpp ein Folio (eine QGraphicsScene)
Element qetgraphicsitem/element.cpp ein platziertes Symbol
Conductor qetgraphicsitem/conductor.cpp ein Leiter
Terminal qetgraphicsitem/terminal.cpp ein Anschlusspunkt
projectDataBase dataBase/projectdatabase.cpp der Abfrage-Cache — siehe Die Projektdatenbank

Man beachte die Wortlücke: Die Oberfläche sagt Draht, Seite und Symbol, der Code sagt conductor, diagram und element. Nach dem Oberflächenwort zu suchen ist der übliche Weg, fälschlich zu schließen, etwas sei nicht implementiert.


5. Was es nicht gibt

Deutlich gesagt, weil diese Seite zuvor das Gegenteil behauptete:

Behauptung Wirklichkeit
Eingebettete Python-Skripte Es ist kein Interpreter eingebunden oder geladen. Jede Python-Erwähnung im Quellcode betrifft den Starter für qet_tb_generator.
Ein Plugin-System / eine Plugin-Schnittstelle Kein QPluginLoader, keine Plugin-ABI, nichts, was externen Code lädt.
~/.local/share/QElectroTech/plugins/ und Entsprechungen QET liest diese Pfade nie. Sie anzulegen bewirkt nichts.
Eine Automatisierungs-API zu einer laufenden Instanz Keine. SingleApplication reicht Dateiargumente an eine laufende Instanz weiter, mehr nicht.

Ob QET eine Skriptschnittstelle bekommen sollte, ist eine offene Frage — siehe die Seiten Vision und Entwicklungs-Roadmap. Wenn es so weit ist, wird diese Seite es sagen — dann, wenn es stimmt, und nicht früher.