Info: Dieser Thread gehört zum Wiki-Artikel Hausbus Diskussion Fortsetzung vom Thread "[OS-HB] PC-Steuersoftware" Von Reinhard kam folgender Vorschlag bezüglich einer Knotenbeschreibung in XML, welche folgende Struktur haben könnte: --- <?xml version="1.0" encoding="iso-8859-1"?> <HPCS Name="Local"> <Connections> <HPC ID="23" Name="xyz" ConnTyp="SER" Localisation="Heizung" NetPath="1.2.4.5"> <Var Name="s0" Value="0" Typ="Bool" /> <Var Name="s1" Value="-1" Typ="Bool" /> <Var Name="s2" Value="-1" Typ="Bool" /> <Var Name="temp1" Value="23" Typ="int" /> <Var Name="LCDOut" Value="Hallo Welt" Typ="String" /> <Var Name="s5" Value="-1" Typ="Bool" /> </HPC> <HPC ID="13" Name="otto" Localisation="Kueche" NetPath="1.1.7"> <Var Name="s0" Value="0" Typ="Bool" /> <Var Name="s1" Value="-1" Typ="Bool" /> <Var Name="s2" Value="-1" Typ="Bool" /> <Var Name="temp1" Value="23" Typ="int" /> <Var Name="LCDOut" Value="Hallo Welt" Typ="String" /> <Var Name="s5" Value="-1" Typ="Bool" /> </HPC> </Connections> </HPCS> --- Den prinzipiellen Aufbau finde ich okay, für XML wäre ich auch, da einfach zu erweitern, gut zu bearbeiten etc. Über Aufbau und Inhalt müsste man noch ein wenig diskutieren, denke ich. Prinzipiell bin ich der Meinung, dass es eine XML-Objektdatenbank geben sollte, bei der jeder Objekttyp durch eine eigene Datei dargestellt werden sollte, z.B. "schaltknoten.xml", "temperatursensor.xml" etc. Neben den oben schon vorgeschlagenen Elementen fände ich eine Beschreibung des Knotens im Klartext praktisch. Beim Netpath (soll vermutlich die Adresse darstellen) sehe ich noch Diskussionsbedarf, der aber nicht hier in diesen Thread passt - das ist eher Sache des Übertragungsprotokoll. Hier fände ich eine nachrichten- und adressorientierte Verbindung praktisch, aber mehr dazu im Protokoll-Thread. Das Ergebnis könnte man dann hier einfliessen lassen. Vielleicht könnten wir hier erst mal ein Brainstorming machen, welche Informationen ins XML einfliessen sollen, wenn wir das dann haben, besprechen wir wie wir das in XML strukturieren, was meint Ihr dazu?
@reinhard: Kannst du mal mit ein paar Worten erklären, 1.) was man allgemein aus dem XML-Dokument entnehmen können soll und dann 2.) was dein Beispiel konrekt beschreibt? Ich bin auch gerade dabei meinen Bus in eine virtuelle und auf den PC abbildbare Struktur zu fassen (C#/.net). Mit XML (bzw. dessen Vorzüge) kenne ich mich leider (noch) nicht aus. Vielleicht kannst du anhand des angehängten Screenshots kurz erläutern, ob meine Busstruktur/Parameter usw. durch deinen XML-Ansatz prinzipiell beschrieben werden können, oder ob es da zu große Abweichungen gibt. Ich kann deinen Ausführungen leider noch nicht ganz folgen - wäre aber an einem universellen Ansatz interessiert.
Ich habe mir mal ein paar Gedanken gemacht, wie man die XML-Dateien gestalten könnte: Einerseits sollte eine globale Objekt-Datenbank vorhanden sein, die alle möglichen Knotentypen beschreibt. Die liegt für alle verfügbar auf einem Server und ist an die Hardware, also die Platine, sowie an die Firmware des Knotens gebunden. Wenn wir also zusammen einen Schaltknoten entwickeln, sollte es dafür eine XML-Beschreibung geben, was der Knoten leisten kann, welche Daten er bereitstellt, etc. Wird eine neue Firmware entwickelt, gibt es auch eine neue XML-Beschreibung dazu. Welche Datei zu welchem Knoten gehört, könnte man in die Firmware einbauen. Dann wäre folgendes Szenario denkbar: Man baut sich einen Knoten anhand der Schaltpläne im Internet auf und spielt die Firmware drauf. Die Software scannt den Bus, findet eine neue Hardware und lädt sich anhand der ID in der Firmware die passende Knotenbeschreibung vom Server (sofern diese nicht schon vorhanden ist) und stellt den neuen Knoten auf der Oberfläche da, der nun konfiguriert werden kann. Natürlich soll man die Firmware auch selbst bearbeiten können, da müsste man halt ein Flag einführen, dass nun die Beschreibung nicht vom Server geladen wird, sondern lokal bereitgestellt wird. Wenn man nun den Knoten konfiguriert, müssen die Einstellungen ja auch abgespeichert werden, damit die Konfigurationsoberfläche die Einstellungen kennt. Natürlich könnte sie sie auch immer beim Start aus dem Bus auslesen, aber das denke ich ist unnötiger Overhead und sollte nur ab und zu bzw. auf Anfrage geschehen. Diese XML-Config (quasi eine Instanz von der Knotenbeschreibung) braucht natürlich noch zusätzliche Eigenschaften, die vielleicht getrennt im XML-File beschrieben werden können und jedem Knoten im Bus zugeteilt werden. Also wenn ich beispielsweise 3x einen Schaltknoten habe, existiert für jeden Knoten eine eigene Datei, da jeder Schalter eine eigene Adresse hat, evtl. einen Namen, also Informationen die nur im lokalen Netz wichtig sind. Mein Vorschlag für die globalen Knotenbeschreibungen wäre: - Name - Beschreibung - XML-Dateiversion - ID (zum Verlinken von XML-Datei und Firmware) - Fähigkeiten des Knotens (müssen noch aufgeschlüsselt werden) - Informationen, die der Knoten preisgeben kann (auch Aufschlüsselung nötig) - etc. Daten für die Instanzen (also die lokalen evtl. mehrfach vorhandenen Knoten): - Name - Ort - Adresse bzw. ID - Firmware-Version - Beschreibung - feste Einstellungen (z.B. Schwellwerte für Temperaturschalter, etc.) - etc. Diese Daten können für jeden Knoten abgeändert werden, sind also beschreibbar, die Fähigkeiten des Knotens sind ja für alle Knoten dieser Art gleich und können deshalb aus der oberen Datei ausgelesen werden. Was haltet Ihr von den Ideen? Es sind nur grobe Vorschläge, die noch sehr verfeinert werden müssen, können aber zumindest schon mal einen Überblick verschaffen, wie das Ganze aussehen könnte...
@andref >1.) was man allgemein aus >dem XML-Dokument entnehmen können soll Mein Beispiel war eigentlich nur als kurzes Beispiel gedacht xmlunkundigen einen Eindruck einer xmlStruktur zu geben. dementsprechend habe ich es in 2min hingeschrieben ohne großen Anspruch auf Projektrelevanz oder gar Vollständigkeit. Die eigentlichen Prozessrelevanten Inhalte/Elemente zu ermitteln sind das Ziel dieses threads. ++++++++++++++++++++++++++++++++++++++++++++++++++++ 2.) nochmal die kurze Beispiel erklärung aus dem Original Thread DokumentElement <HPCS>: HomeProzessControllerServer, repräsentiert die Abbildung des Netzes, ist sozusagen das BasisObjekt Steuersoftware , Name =lokal auf rechner, denkbar das noch andere Remoteserver vorhanden sind wie Name="RemoteServer1" oder "134.456.235.768" ChildElement <Connctions> Auflistung mehrerer Childelemente vom Typ HPC- HomeProzessController(Anm. in abgrenzung zur PLC/SPS für Industriesteuerungen) ChildElement <HPC> Repräsentiert eine einzelne HPC Als Attribute werden die spezifizierten unbedingt erforderlichen Eigenschaften wie ID und ConnTyp übergeben. ConnTyp "SER" könnte hier für ser COM verbindungstehen weiterhin wäre sinnvoll noch CAN und "W"LAN weiterhin ist zu überlegen ob hier auch die Vebindungsparameter wie portnr baudrate settings stehen sollten oder ob auf ein extra objekt referenziert wird. !!Gleichzeitig könnte dieses HPC element so auch als Format für den Nachrichtenaustausch verwendet werden!!!! evtl als attribut noch Empfängeradresse einfügen cHILDeLEMENT <Var>: repräsentiert optionale Umgebungsvariablen der einzelnen Controller es können beliebig viele eingefügt werden. ++++++++++++++++++++++++++++++++++++++++++++++ >Vielleicht kannst du anhand des >angehängten Screenshots kurz erläutern, ob meine >Busstruktur/Parameter >usw. durch deinen XML-Ansatz prinzipiell beschrieben werden können, so zBsp könnte dein Ansatz via xml formal beschrieben werden. (Ohne Anspruch auf inhaltliche Richtigkeit) <?xml version="1.0" encoding="iso-8859-1"?> <HPCS Name="Local"> <Connections> <Knoten ID="122" Name="Knoten122" ConnTyp="SLK" Localisation="Wohnzimmer Beschreibung="Wohnzimmerlampen"> <Vars> <Var Name="AnzahlResets" Value="651" Typ="int" Access="RW" Unit="h" /> <Var Name="Uptime" Value="2345126" Typ="long" Access="RW" Unit="s" /> </Vars> <Ports> <Port Portname="Dimmer0" ID="L104" PTyp="DA" GTyp="Taster"> <Port Portname="Taster0" ID="T102" PTyp="IO" GTyp="Dimmer"> </Ports> </Knoten> <Knoten ID="123" Name="Knoten123" ConnTyp="SLK" Localisation="Terasse" Beschreibung="Wohnzimmerlampen ..."> <Vars> <Var Name="AnzahlResets" Value="651" Typ="int" Acces="RW" Unit="h" ... /> <Var Name="Uptime" Value="2345126" Typ="long" Acces="RW" Unit="s" .../> .. .. </Vars> <Ports> <Port Portname="Dimmer0" ID="L104" PTyp="DA" GTyp="Taster"> <Port Portname="Taster0" ID="T102" PTyp="IO" GTyp="Dimmer"> .. .. </Ports> </Knoten> <Knoten......... </Knoten> </Connections> </HPCS>
@ithamar >Über Aufbau und Inhalt müsste man noch ein wenig diskutieren, denke >ich. ein wenig ist milde ausgedrückt... >Prinzipiell bin ich der Meinung, dass es eine XML-Objektdatenbank >geben sollte, bei der jeder Objekttyp durch eine eigene Datei >dargestellt werden >sollte , .B. "schaltknoten.xml", "temperatursensor.xml" etc. wie meinst du dies: Jedes Objekt eine eigene Datei?? Ein Sinn der Xml Darstellung liegt in der Strukturierungsmöglichkeit durch Verschachtelung - wie willst du eine Baumstruktur mit einer anzahl gleichberechtigter xml-Dateien darstellen?? oder meinst du zu jeden Typ (zusätzlich zur xml-Baumstruktur)nochmal eine zusätzliche xml-Beschreibung?? >Neben den oben schon vorgeschlagenen Elementen fände ich eine >Beschreibung des Knotens im Klartext praktisch. ja unbedingt. Allerdings würde ich diese nicht als xml-attribut einfügen (....beschreibung="bla bla"/>) sondern als innertext element ( <HPC id=..... > Bla Bla </HPC>) also zwischen Haupt Tag und einen zusätzlichen Terminierungs Tag einfügen. Dies hätte den Vorteil das auch längere Beschreibungen problemlos (bezüglich "" )und leserlich eingefügt werden können. Dies gilt übrigends für alle Elemente , also auch für Variablen und andere noch zu kreierenden Inhalte. Reinhard
Äh Baumstruktur? Ich meine eigentlich nur ein Element, eine Hardware. Also quasi die Beschreibung eines Busknotens in seinen Fähigkeiten. Was kann das Teil und wie kann ich es ansteuern. Bei der Beschreibung des Netzes oder so bin ich noch gar nicht, mir gehts jetzt erst mal um die (noch nicht verdrahteten) Elemente.
>Äh Baumstruktur? Ich meine eigentlich nur ein Element, eine >Hardware. >Also quasi die Beschreibung eines Busknotens in seinen Fähigkeiten. >Was >kann das Teil und wie kann ich es ansteuern. >Bei der Beschreibung des Netzes oder so bin ich noch gar nicht, mir >gehts jetzt erst mal um die (noch nicht verdrahteten) Elemente. Äh - unter "Baumstruktur" meinte ich jetzt folgendes HPCS | |---Connections |-----HPC1 | | | |-----oblVar1 | | | |-----oblVar2 | |-----optVar3 | |-----udefVar4 | | |-----HPC2 | | |-----Var1 | | | |-----Var2 | |-----Var3 | |-----HPC3 | |-----HPC4 und das ganze sollte meiner Meinung nach in einer xmlDatei abgebildet werden. (Dabei verstehe ich unter HPC(HomeProzessController) wohl das was du als BusKnoten bezeichnest. Ich differenziere hier noch zu anderen Knotentypen wie Repeater, Switche,Koppler usw. welche anders behandelt werden sollten.) Wie stellst du dir die Aufteilung in mehrere Dateien vor?
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.