OPC Export Format

[makki]

Nichts anderes macht der OPC Export

Nein, Mike, das macht er nicht. Zeig mir doch mal nen esf von der ETS in der trotz eindeutiger Zuordung EIS 3,4 oder 5 steht ?
Genau das passiert hier, wenn bei einer Verbindung einer GA als DPT 9.001 eingestellt wird kommt hinten EIS 5 raus, das geht und macht wohl durchaus Sinn.
Schaus Dir mal an, vielleicht weisst Du dann was ich meine.
Ich versteh die Diskussion nicht ganz, wir reden hier nicht darüber aus der 90er-Jahre ETS mit ihrem halbgaren Gedankengut Gold zu machen sondern einfach etwas mehr rauszuholen.
Das löst auch nicht das Problem, dass die ganze Sache der DPTs innerhalb der ETS nicht durchdacht bzw. nicht ansatzweise durchgängig umgesetzt ist. Aber es lindert ein paar Probleme, indem man es wenigstens - so einmalig und an einer Stelle von Hand eingestellt - exportieren kann.

Geh doch einfach mal in die Applikation des AE/S 4.2, da kann man für die zwei Byte des Ausgangs, denen Du unterstellst sie wäre ein Float mit einer Temperatur, 3 verschiedene Datentypen einstellen. (hier liegt nun vermutlich der Fehler der Hersteller, dass das nicht automatisch übernommen wird bzw. man gleich den DPT dort auswählt)
aber man kanns wenigstens manuell einstellen und wenn man das tut, bringts einem jetzt im Export auch was
Wer da im KNX-Kartell nun genau Schuld dran ist und wieviele Ausreden es gibt, ist mir ehrlichgesagt auch Schnuppe. Ich konnte die Datendefinition nicht zentral einstellen und systemübergriefend zuverlässig und automatisch verwenden, darum gehts (mir)

"Mann" braucht das... da trennt sich eben Spreu von Weizen Das sind die Link Adressen, wenn der HS das auswerten könnte würdest Du Dir viel dummes geklicke sparen....

Gut, dann bau ma's halt rein Mit nem HS hab ich den Sinn vermutlich deswegen noch nicht erkannt.. Was sind denn das für Spreu-OPC-Server die dann mit unscharfer Datenbasis alles automatisch können ? (für mich ist diese ganze OPC-Sache immernoch ein kleines Nebelfeld unscharfer Gebäudeautomationsgeschichten (oder eine Windows-Schnittstelle dies seit 10J nimmer so recht gibt)..
Was wird mit diesen Link-Adressen angestellt ? (Das sin ja die zusätzlich hörenden sofern ich das auf die schnelle sehe)

Erkläre mal genauer, oder meinst Du eben das Übel, dass die Hersteller das in der PDB eben nicht "pflegen"

Nein! (wobei das in Einzelfällen wie dem AE/S zusätzlich sinnvoll und wünschenswert wäre)
Ich meine: ich klicke auf die mit dem B.IQ verundene GA "0/0/7 Datum", stelle ein Datentyp 11.001 date, im OPC-Export steht aber immernoch uncertain 3 byte statt EIS 4 (oder DPT 11.001)
Das ist IMHO kaputt.
Am besten wäre natürlich wenn es gleich automatisch eingestellt würde aber da musst Du Dich an die Konnex halten, da kann ich kaum helfen.

und wo soll das dann hinführen ??? Das ist doch genau der Punkt und erklärt nach kurzem Nachdenken doch schnell, warum es ist, wie es ist...

Also weil der "professionelle Programmierer" (Laien arbeiten ja nicht mit ETS oda?) die Datentypen an unterschiedlichen Stellen unterschiedlich einstellen kann (was wenn dann die ETS gleich abfangen sollte weils einfach keinen Sinn macht) lassen wir es gleich und machen ausserhalb des EIB 2 undefinierte Zahlen draus.
Das ist seitens der ETS nicht zuendegedacht, ich suche nur einen Workaround.

-> Man könnte allerdings problemlos beim Export inkosistente DPT-Definitionen auswerten und anzeigen.

Im Moment ist es so, dass es reicht ein DPT einmal zu setzen (egal wie oft verbunden), solange die anderen KO nicht falschen DPTs zugeordnet sind, geht es.

Ergo, muss ich die Tabelle doch auch prüfen und ggfl. anpassen... Ich meine, ich generiere diese Tabellen ja auch nicht erst seit gestern und auch mit vielen vielen 1000 GA's und glaub mir, ich hab das in 5min. im Griff

Na, dann teile doch Dein Wissen, wie finde ich raus obs ein 2 Byte signed, unsigned oder float ist ? Raten oder doch manuell in der ETS nachschauen was im Aktor eingestellt ist und dann am zweiten System von Hand eintragen. Bei vorhandnen Möglichkeiten q.e.d, will ich nichts manuell machen müssen.
Mike, ich will nichts, rein garnichts von Hand anpassen Sondern die Daten sollten sich möglichst 1:1 automatisch z.B. in eine Visu übertragen lassen (Einschränkung: sofern initial richtig definiert)
Davon sind wir zwar noch ein Stück weg aber jetzt auch ein Stück näher dran..

P.S.: Der HS hat von dem genaueren esf-Export natürlich so erstmal nichts, weil der Import-parser dort auch nur verarbeitet was die ETS seit ehedem ausgibt, sprich vermutlich nicht damit rechnet dass da ein EIS 3/4/5 reinkommt.

Makki

[tstalzer]

Ausserhalb der Elektrobrache nennt man das Datenbankabfrage, nicht hacken Da ist nichts obszönes dabei, es wird über vorhandene, offene Schnittstellen auf eine ganz normale DB zugegriffen.

Makki,

Sorry, ist wohl ein bisschen negativ rübergekommen, wie ich es geschrieben habe.

Ich sehe auch nicht die Datenbankabfrage als das "Problem" (Bitte bemerke die Anführungszeichen), sondern das Ermitteln der UserId und Passwort durch Tools (Hier fängt die Grauzone mit Hacken an...). Ich will jetzt auch nicht "den Teufel an die Wand malen", o.ä. Allerdings bin ich (gebranntes Kind scheut das Feuer...) an dieser Stelle sehr vorsichtig und sichere mich ggf. zweimal ab. Ich wollte es Euch als Hinweise geben, dass wenn Ihr ein O.k. der Konnex für diesen Zugriff habt, alles im grünen Bereich ist (Private Nutzung, etc.)

Gruß

Thomas

[meudenbach]

Makki, Makki....

ich hab das nun mal getestet. Und nochmal, Respekt vor Deiner Arbeit. Ich versuche lediglich auf die Sinnlosigkeit Deiner Bemühungen hinzuweisen. Ich beschäftige mich eben schon so lang mit dem Problem, dass ich es aufgegeben habe!!! Und selbst Deine Methode bringt mich keinen Schritt nach vorn.

Meine "klassiche" Methode, die ich nachfolgend auch gern erkläre, ist da immer noch besser. Weil für mich zählt einzig die Performance!!!

Nein, Mike, das macht er nicht. Zeig mir doch mal nen esf von der ETS in der trotz eindeutiger Zuordung EIS 3,4 oder 5 steht ?

Gut, er gibt eben "nur" die Länge der Nutzdaten aus, was aber für mich ausreichend ist. Eine GA für Zeit oder Datum spukt er eben dann wie folgt aus:

Uncertain (3 Byte)

Im OPC Server bekomme ich das angezeigt und muss dort einstellen, ob ich das nun in ein Zeit- oder Datumsformat skaliert haben möchte. Andernfalls werden die Daten als raw (Rohformat) übergeben.

Genau das passiert hier, wenn bei einer Verbindung einer GA als DPT 9.001 eingestellt wird kommt hinten EIS 5 raus, das geht und macht wohl durchaus Sinn

.

Nein, Makki !! Dein Ausgabeformat macht kein Sinn, weil kein OPC Server diesen interpretieren kann, auch der HS nicht !!!!

Deine Export generiert nun ein:

EIS 5 'DPT_Value_Temp' 2 byte float value

Diesen Typ gibt es nicht in der EIS Klassifizierung und führt zu einer Fehlermeldung. Der Typ müßte wie folgt ausschauen:

EIS 5 'Value' (2 Byte)

Bei oben beschriebenen 3 Byte Typ machst Du:

EIS 3 'DPT_TimeOfDay' Time

Und ausschauen muss das so:

EIS 3 'Time' (3 Byte)

Dies bestätigt eben meine Aussage, dass Du EIS und DPT nicht mischen kannst. Klar könnte man eine Übersetzungstabelle dazwischen bauen und das wäre sicherlich auch leicht für Dich umsetzbar. Ferner beziehe ich mich ja eben auf das Format, dass die Konnex für seinen OPC Server spezifiziert hat. In eibd könnt ihr das ja umsetzen, wie ihr wollt. Nur würde ich mich hier aus div. Gründen auch an die "schlechten" Standards halten. Das haben wir bei mmh auch getan, obwohl wir lieber nach DPT gearbeitet hätten, was auch folgt, sofern die KONNEX das Ausgabe Format spezifiziert hat. Wir sind schon exotisch genug, da müssen wir nicht noch exotische Schnittstellen erfinden.

Du unterstellst sie wäre ein Float mit einer Temperatur

Ich unterstelle das, weil in 99,9% der Fälle dies auch so ist. Und es kann ja bei Bedarf auch geändert werden. Einzig ein 2Byte Zähler würde durchfallen und müßte entsprechend nachgearbeitet werden. Ebenso verhält es sich mit einem:

Uncertain (1 Byte)

Der eben in 99,9% zu einem:

EIS 6 'Scaling - percent' (8 Bit)

wird.

Wir ändern das auch nicht in der esf sondern behandeln dies eben beim Import in mmh. So kann eben jederzeit der Anwender "nachpflegen". Ich arbeite da halt nach der "Mike'schen" Statistik und dies erleichtert dem Anwender den Umgang mit den Exporttabellen. In kleinen Privatobjekten liegt die eingeimpfte Regel bei nahezu 100%...

Was sind denn das für Spreu-OPC-Server die dann mit unscharfer Datenbasis alles automatisch können ?

Wer hat denn gesagt, dass die das können? OPC ist wie BACnet eine übergeordnete Ebene und jeder OPC Server hat aufgrund der verschiedensten Systeme die dort angebunden werden natürlich eigene Definitionen. Wie soll das auch anders Funktionieren ?? Das findest Du dann wieder auf Seiten des Protokolls der Managemant Ebene.

(Laien arbeiten ja nicht mit ETS oda?)

Lass Deinen Zynismuss doch einfach mal bei Seite !!!

die Datentypen an unterschiedlichen Stellen unterschiedlich einstellen kann

Das macht keiner !!! Und wenn, dann muss dies Seitens der Hersteller in der PDB definiert werden. Und das geht gar nicht, weil dies dann zu Kollisionen in der DPT Zuordnung führen kann. Nimm als Beispiel mal einen Jalousiesensor mit kurz/lang Betätigung, der ja nun oft auch zum Schalten anderer Dinge verwendet wird.

Wenn dann alles "ordentlich" gepflegt wurde müßte an dem Kommunikationsobjekt ein DPT wie zB 1.008 up/down hängen und der wird nun mit einem Schaltaktor verbembelt, also einem 1.001 on/off...
Wie willst Du das nun plausibilisieren??? Ebenso bei Gruppenbefehlen...

Es ist idR auch nicht Aufgabe des Subsystemes (in unserem Fall eben KNX mit seiner ETS) die Anforderungen der Management Ebene abzudecken. Die Anpassungen geschehen in dieser Hirachie IMMER von oben nach unten.

Man könnte allerdings problemlos beim Export inkosistente DPT-Definitionen auswerten und anzeigen

Genau dies macht ja dann der OPC Server!!! Wie soll denn auch die ETS wissen, wie zT die Management Ebene die Daten skaliert haben möchte, vor allem da professionelle System meist über eigene Skalierungsmethoden verfügen und mit den Rohdaten der Subsysteme arbeiten.

Im Moment ist es so, dass es reicht ein DPT einmal zu setzen (egal wie oft verbunden), solange die anderen KO nicht falschen DPTs zugeordnet sind, geht es.

Super Methode, bei einer Übergeordneten Gruppe ist das dann gleich mal ausgeschlossen, dass dies funktioniert... Suchen ist also angesagt. Und wenn ich dann noch den Aufwand bedenke, den ich habe wenn ich die DPT alle einzeln einstellen muss, dann doch lieber auf Seiten der Management Ebene.

Unser beider Ziel ist doch klick und fertsch das wird aber aus vor genannten Gründen nie funktionieren !!! Und mit Deiner Methode IMHO nur mit einem ungerechtfertigtem Aufwand zu realisieren. Daher würde ich Dir/Euch auch nahelegen bei dem eibd Import ähnlich zu verfahren, wie wir das tun... aber das ist nur ein gut gemeinter Rat

Na, dann teile doch Dein Wissen, wie finde ich raus obs ein 2 Byte signed, unsigned oder float ist ?

Hab ich ja schon annähernd erklärt. Du kannst mir ja mal auf Deine DB bezogen mitteilen, wie oft der jeweilige Typ bei Dir daheim vorkommt. Also wieviel GA's mit dem Typen signed, unsigned hast Du ??? und natürlich wieviel float's ??

ich will nichts, rein garnichts von Hand anpassen

Musst Du doch aber in der ETS... solang eben die DPT's durch die Hersteller nicht belegt werden. Und wie gesagt, die Chancen, das dies umsetzbar ist fällt mit der Komplexität und DP Vielfallt in der DB.

aber jetzt auch ein Stück näher dran..

IMHO nicht wirklich...

Der HS hat von dem genaueren esf-Export natürlich so erstmal nichts

Wenn Du Dich an die EIS Spezifikationen halten würdest, könnte das auch der HS "verstehen"

Kurzum, eine Vereinfachung würdest Du dann schaffen, wenn Du eben in der ETS anstelle der DPT Definition die korrekte EIS Definition angibst, wie oben erklärt. Das aber setzt natürlich voraus, dass du jeden einzelnen DP in der ETS passend einstellst... und das erkläre mal der Masse der Anwender denn das ist das was die KONNEX interessiert, das auch eben ein Jedermann damit klar kommt und nicht wie es zB bei LON der Fall ist, der Anwender genau prüfen muss, dass Sensor auch zum Aktor passt, obwohl beide über ein SNVT switch verfügen aber Sensor zum Schalten eine "01" sendet und Aktor aber eine "10" (binär) haben möchte...

Na, dann teile doch Dein Wissen

Ich schaffe mir meine eigene Schnittstelle und hinterlege notwendige Informationen in dem GA Bezeichnungstext. Wir haben da verschiedenste Strategieen erarbeitet, hier mal ein:

Unsere GA Bezeichnungen definieren wir in einer Art Punktdefinition. Punktdefinition, damit eben die Feldlängen dynamisch sein können. Früher haben wir auch mal feste Feldlängen verwendet, aber da werden die Texte auch schnell mal kryptisch. So eine GA (Datenpunkt) könnte wie folgt aussehen:

Raum.Funktion.Typ.Klartext

Aufgelöst zB.

Wohnen.Beleuchtung.EIN/AUS.Wandlampe rechts

oder

Aussen.Wetterstation.TEMP.Aussentemperatur

usw...

Dann exportieren wir als ESF. Die ESF wird in Excel importiert, dass erledigt ein Macro, damit die GA's nicht in ein Datum gewandelt werden. Ein weiteres Makro parst eben den von uns vergebenen Typen und ersetzt diesen durch die korrekte Definition und generiert eine neue esf mit eben korrekten Definitionen. Für verschiedene OPC Server habe ich auch verschiedene Übersetzungstabellen. So kann mich mich ganz schnell an die Spezifikation der jeweiligen Importschnittstelle anpassen... Ist die Managemant Ebene zufällig B-CON, dann eben auch mit einem Klick ... Ist der OPC Server zufällig ein NET-x dann auch gleich deren Definitionstabelle, die wieder ganz anders ausschaut.

Also eigentlich ganz einfach, wenn man eben solch ein System von oben nach unten betrachtet, was in einer offenen Topologie immer zielführender ist....

So oder so, IMHO erheblich effikiver als Deine Methode.

Aber mal was persönliches lieber Makki, ich schätze Dich sehr und bin Dir noch immer ziemlich dankbar für Deine Hilfe bei meinen damaligen Datencrash.
Nur, höre doch bitte auf mit solchen pauschalen Aussagen wie:

90er-Jahre ETS mit ihrem halbgaren Gedankengut

KNX-Kartell nun genau Schuld dran ist

mit unscharfer Datenbasis

Die offizielle Antwort der Konnex ist "der OPC-Server unterstützt das nicht" Aha..

Ich finde das befremdend (hatten wir schonmal), da teilweise unbegründet, zumal Du offensichtlich die Hintergünde nicht verstehst wie das eben alles "gewachsen" ist. Für mich ist das in den hier Diskutierten Fall plausibel, da meine Denkrichtung (und nicht nur meine) eben anders ist.

Wenn ich Dich nicht besser kennen würde, würde ich nun Wörter wie großkotzig, neunmalklug oder Besserwisser verwenden. Ich finde Du hast das doch gar nicht nötig und auch Deine Ansichten, wie meine auch, sind nicht der Weisheit letzter Schluss...

Oder habe ich mal wieder was falsch verstanden und wir reden aneinander vorbei ?!

so long..

[makki]

Vorab, worums mir geht ist kein "OPC"-Export, das ist ein Nebenprodukt, sondern ich will ganz einfach die KOs inkl. der Definition aus der ETS in automatisch verarbeitbarer Form.

Im OPC Server bekomme ich das angezeigt und muss dort einstellen, ob ich das nun in ein Zeit- oder Datumsformat skaliert haben möchte. Andernfalls werden die Daten als raw (Rohformat) übergeben.

Ncihts für ungut, aber da stellts mir aus IT-Sicht (vermutlich genauso wie Dir bei meinen anderen Bastelein) im Jahr 2009 einfach grundlegend die Nackenhaare auf, dass sowas ohne Not hingenommen wird. Das geht ja nicht gegen Deine Methoden diese Thematiken zu umschiffen oder anderweitig zu lösen.
Das ist wie wenn Du beim öffnen eines eMail-Anhangs erst von Hand auswählen müsstest ob es mit Base64 oder Quoted-printable encoded ist..

Der Typ müßte wie folgt ausschauen:

EIS 5 'Value' (2 Byte)

Deswegen habe ich ja auch schon zweimal gefragt, wo das steht.. Damit man es eben so machen kann, konnte aber bisher keine Referenzinformation finden. Das mit dem EIS x ist ja klar aber was danach "'Irgendwas' (Länge)" kommt.. Drei mehr kenne ich jetzt.

Dies bestätigt eben meine Aussage, dass Du EIS und DPT nicht mischen kannst.

Das ist natürlich völlig richtig und an der Stelle vielleicht etwas ungünstig, nur wusste ich einfach nicht was ich reichschreiben sollte.

Ferner beziehe ich mich ja eben auf das Format, dass die Konnex für seinen OPC Server spezifiziert hat. In eibd könnt ihr das ja umsetzen, wie ihr wollt.

Der eibd ist keine Visu sondern eine Busschnittstelle der man, Du hattest das ja mit dem Uhrzeit-Bespiel sehr anschaulich illustriert die Werte im EIB-passenden Format geben muss.
Aber da liegt der Punkt, warum sollte ich mich an den omminösen "Konnex OPC-Server" (was ist das eigentlich, gibts da eine Software, Geheimbund? Tante Google weiss darüber leider nicht soviel) halten wenn dort keine ausreichende Spezifikation der Daten an der Schnittstelle herrscht.
Oder wenn es diese Spezifikation irgendwo gibt, warum gibt es die ETS dann nicht so aus ? (was ja - entnehme ich Deiner korrektur des EIS 5, offenbar der Fall ist dass es eine Spec gibt)

Das haben wir bei mmh auch getan, obwohl wir lieber nach DPT gearbeitet hätten, was auch folgt, sofern die KONNEX das Ausgabe Format spezifiziert hat. Wir sind schon exotisch genug, da müssen wir nicht noch exotische Schnittstellen erfinden.

Mike, das hätte ich auch, wenn nur einfach ein EIS 1-15 oder DPTs rauskommen würde wärs genug, aber so ist das *für mich* halt nicht zielführend dahinter Applikationen zu bauen.
Langzeitziel ist: wenig Wartungs- und Know-How intensiv. Bei Änderungen von GA's sollte es ein halbautomatischer ex/import tun. Ich denke langfristig an ein Format und System wo Otto Normaluser - der weder weiss noch wissen sollte was zum Henker EIS ist - das hinbekommt, dafür brauchts nunmal exakt spezifizierte Datenformate, so wie auf dem Rest der Welt auch üblich ist. Bei einem Anruf auf Deinem Handy musste auch nicht erst die Anrufernummer von Binär nach Dez. wandeln und bestimmen obs die Network-Provided CLI oder mit/ohne Orts|Landesvorwahl ist; es gibt im Alltag schon genug komplizierte Systeme, einige davon schaffen es die komplexität vom anwender ferzuhalten und haben damit teilw. sogar Erfolg, so muss es sein.
Exotisch muss auch nicht schlecht sein wenn die Heimat langweilig ist
Aber in dem Punkt verstehen wir uns glaub ich eh, der Mac ansich macht das ja (so weh es mir tut das zu sagen): richtig..

--- cut ---
...lassen wir das..

Also wieviel GA's mit dem Typen signed, unsigned hast Du ??? und natürlich wieviel float's ??

Jetzt kann ich ja nachzählen 39 floats, 4 unsigned. Dafür der ganze Aufwand ? Nein, darum geht nicht. Es geht darum dass beim Datenimport in dem Fall rund 10% von Hand von jemandem zu bearbeiten sind, der sich damit auskennt. Das will ich vermeiden.

Wenn Du Dich an die EIS Spezifikationen halten würdest, könnte das auch der HS "verstehen"

Wär schön gewesen, eben probiert, aus dem "EIS 4 'Date' (3 Byte)" wird trotzdem immer ein EIS 3 im HS (das 'Date' (3 Byte) ist ja ohnehin eine redundante Information) nur vermute ich halt stark dass aus verständlichen Gründen der HS nur versteht was die ETS ausspuckt.
Auch egal, wiegesagt darum geht und gings mir nicht (auch wenn ich es trotzdem lästig finde)

Kurzum, eine Vereinfachung würdest Du dann schaffen, wenn Du eben in der ETS anstelle der DPT Definition die korrekte EIS Definition angibst,

? den versteh ich jetzt nicht (liegt vielleicht an der Historie) ? Aber die DPT's sind doch eindeutig den EIS zuzuordnen. Würde mir ja eins von beidem völlig reichen.

Das aber setzt natürlich voraus, dass du jeden einzelnen DP in der ETS passend einstellst... und das erkläre mal der Masse der Anwender

Jetzt kommen wir langsam zum Punkt Ich sehe die ETS als zentrale konfigrationsinstanz und das ist IMHO noch eher zu vermitteln als es in noch spezielleren Anwendungen ggfs. mehrfach einzustellen.
Also je einmal im HS, mmh, mh, iKNX, Elvis, sonstwas
Vielleicht hab ich auch nur komisch Träume..

Ich schaffe mir meine eigene Schnittstelle und hinterlege notwendige Informationen in dem GA Bezeichnungstext. Wir haben da verschiedenste Strategieen erarbeitet, hier mal ein:

Ok, jetzt wiedersprichst Du Dir aber selbst Also strikt an die OPC halten und gleichzeitig eigene Schnittstellen (zwei damit der Spass auch ankommt)
Nichts anderes habe ich vor, aber ich denke mir halt eine Schnittstelle die alle hernehmen können wäre besser statt dass sich jeder selber was ausdenkt. Dann ist es IMHO auch in der Breite besser vermittelbar.
Nun, endgültig im Traum, die Vision sieht etwa so aus: man definiert in der ETS zentral alle DPT, sowie nach einem bestimmten (noch unklaren) System zusammen mit Gewerken/Räumen anderes. Obs ein Dimmer oder Jalo ist, leisse sich ja evtl. auch feststellen.
Und dann fällt da nach einem Export der Daten, die man bequem in einem vorhandenen, vertrauten Tool erstellt hat, eine Visu mit Räumen+Gewerken raus. Ich träume..

Raum.Funktion.Typ.Klartext

Das klingt stimmig, nur verfolge ich einen anderen Ansatz der Darstellung

Ein weiteres Makro parst eben den von uns vergebenen Typen und ersetzt diesen durch die korrekte Definition und generiert eine neue esf mit eben korrekten Definitionen.

Und wo liegt jetzt der Unterschied ? die Qualität ist bei Dir sicher besser, aber davon hat nur ein eingeschränkter Kreis was (Deine Kunden). Ich sehe das eben grundlegend anders, das man mit offenen Schnittstellen und Systemen langfristig weiterkommt. An diesem Punkt werden wir auch kaum einigkeit erreichen..

Ich frage mich echt: Wovon willst Du mich überzeugen ? Dass die ETS mit dem ominösen OPC-Export das Nonplusultra ist und es Gotteslästerung gleicht an der Perfektion dieser zu zweifeln ? Dass es auch 100000 ander Wege nach Rom gibt (das ist so) oder einfach nur dass man hier gegen Windmühlen proprietärer Systeme kämpft, die versuchen möglichst viel "drinnen" zu behalten ?
Gegen letztere nehme ich den sportlichen Wettkampf gerne auf

Für verschiedene OPC Server habe ich auch verschiedene Übersetzungstabellen. So kann mich mich ganz schnell an die Spezifikation der jeweiligen Importschnittstelle anpassen...

Na das ist doch das Problem. Schön wenn Du dafür einen Lösung hast nur funktionierende Schnittstellen und Definitionen ohne Übersetzungstabelle fände ich noch besser. Wir kommen vom Thema ab.. Aber MS,Apple und Novell haben auch allesamt jahrelang mit ihrer proprietären Suppe das LAN verseucht und heute müssen sie doch alle IP reden (bis auf Novell, die gleich den ganzen schmarrn eingestampft und Susie gekauft haben )
Nur damit wir uns richtig verstehen, wegen und mit diesen unzulänglichkeiten hab ich auch lange Zeit mein Geld verdient, aber deswegen war es IMHO weder sonders richtig noch gut oder zielführend..

Also eigentlich ganz einfach, wenn man eben solch ein System von oben nach unten betrachtet, was in einer offenen Topologie immer zielführender ist....

Ok, da sind wir einer Meinung. zu B-Con oder dem anderen kann ich aber mangels öffentlicher Information wenig sagen. Mag nett sein, das übergeordnete System ist für mich aber IP mit offenen Standards und Schnittstellen, die ich bei IETF o.ä. nachlesen kann, solange es die nicht gibt interessiert mich das ehrlichgesagt nicht. Mag hart klingen, ist aber so. (Diese Ignoranz kann ich mir aber natürlich nur leisten, weil ich nicht meine Brötchen damit verdiene)

So oder so, IMHO erheblich effikiver als Deine Methode.

Mike, mag sein dass das in Deinen Projekten so ist. Oder vielleicht sogar in vielen (von den wenigen die es gibt), es wird ja auch keiner gezwungen es zu verwenden.
Was mich nur etwas wundert ist dass Du diesen Zustand des fehlenden Datenformats beim Export verteidigst. Das, zurück zum Thema, ist IMHO kein Zustand, auch wenn es vielleicht viele halbwegs schlüssige ausreden seitens der KNX/Hersteller gibt..

Ich finde das befremdend (hatten wir schonmal), da teilweise unbegründet,

Natürlich überspitze ich gerne, ab und an auch zuviel, teilweise unbegründet aber nun im einzelnen

90er-Jahre ETS mit ihrem halbgaren Gedankengut

Begründung 1: Welche ernsthafte Anwendung nutzt heute eine Sybase-ASA ? Das ist IT-technisch Altmetall, die Plugins von z.B. B.IQ bestenfalls fahrlässige Köperverletzung, Zeitdiebstahl oder Freiheitsberaubung..
Begründung 2: Halbgar: Warum sind die DPTs drin ? welchen Sinn hat das wenn es weder intern ne Rolle spielt noch exportiert werden kann ?
Der Ansatz ist durchaus brauchbar aber IMHO eben in der Umsetzung halbgar.
(auf den Rest von "90er" gehe ich jetzt nicht ein, potential für kontroversen, aber soviel sei gesagt dass der Dongle doch eher überflüssig ist weil ein findiger Junge dafür geanusolang braucht wie manche fürs DB-Passwort)

KNX-Kartell nun genau Schuld dran ist

Begründung: mir ist als Anwender nunmal egal ob daran nun ABB, Konnex oder sonstwer Schuld ist.

mit unscharfer Datenbasis

Kommen die Datentypen raus oder nicht ? Das ist unscharf, meines erachtens unnötig weil es technisch kein Problem wäre dass ein EIS 3 oder EIS 4 oder DPT sonstwas rausfällt.
Der EIB ist da weiter als andere, keine Frage, ich darf aber trotzdem das bemängeln was eben noch nicht rund ist, denn nochmal: zuwas gibts DPTs wenn diese nirgends automatisch angewendet werden können.

Die offizielle Antwort der Konnex ist "der OPC-Server unterstützt das nicht"

Ich könnte jetzt das Orginalzitat rausholen, aber das war nunmal die Antwort.
Auf die folgende Frage wohlgemerkt:

Gibt es eine Möglichkeit oder ist dies zukünftig angedacht, einen Export der GAs/KO mit dem in der ETS eingestellten Datenformat (EIS-equivalent oder DPT) zu bekommen ?

Das ist nicht nur die Antwort, die ich nicht wollte, sondern eine Themaverfehlung. Zum bestimmt dritten mal: Was der OPC-xy macht ist mir eigentlich egal, ich wollte dafür nur aufgrund der zwar weitgehend ungenutzten aber bereits vorhandenen DPTs innerhalb der ETS mir eben kein neues System mit Punkten im GA-Namen ausdenken, um zu sagen was es ist.

zumal Du offensichtlich die Hintergünde nicht verstehst wie das eben alles "gewachsen" ist.

Kann gut sein, mit Geschichte können sich aber ehrlichgesagt von mir aus daran interessierte beschäftigen, meine Gedanken gehören Gegenwart und Zukunft.

Für mich ist das in den hier Diskutierten Fall plausibel, da meine Denkrichtung (und nicht nur meine) eben anders ist.

Siehe Threadtitel: es geht um den Export für eine Eigenentwicklung.

Wenn ich Dich nicht besser kennen würde, würde ich nun Wörter wie

Mike, wenn ich Dich nicht kennen und Deine Arbeit nicht schätzen würde, hätte ich das sicher nicht geschrieben. Hier prallen trotz vieler Gemeinsamkeiten einfach zwei grundlegend verschiedene Ansichten aufeinander.
Unterm Strich hast Du Dich vermutlich aus ganz banalen Gründen (effizienz,wirtschaftlichkeit) mit der bestehenden Realität ganz gut arrangiert (fehlende Definitionen, halbherzige Umsetzung). Das ist ja auch nachvollziehbar nur verstehe ich ehrlichgesagt auch nach nochmaligem lesen des Threads nicht was ich hier jetzt falsches gesagt haben sollte oder warum ich mich verteidigen muss eine 10% Verbesserung zu verschenken..

Und nach dem schreiben der ganzen Story frage ich mich auch ob es nicht besser ein Thema für die Raucherecke gewesen wäre, aber jetzt ist auch schon egal

Besorg mir eine Spec von dem OPC-Format, dann stehts auch bald in richtig drin

Und finally, mit oder ohne Konnex fände ich es sinnvoll ein brauchbares "Standard-Exportformat" zu haben! (die esf geben das IMHO nicht her und das ist auch mit Grund warum ich mich da überhaupt reinhänge).

P.S.: @tstalzer: Nichts für ungut, der Hinweis ansich war ja durchaus berechtigt, ich sehe aber in diesem speziellen Fall kein Problem.

Makki

[meudenbach]

Makki,

was ich Dir eigentlich vermitteln will, ist eben die Aussichtslosigkeit Deiner Wunschanwendung. Es wird Dir nach jetzigem Stand der Software nicht gelingen. Und alles Andere ist eben auch nur "halbgar", ob mit Deine Strategie, oder mit meiner...

Ich habe mich viele Jahre mit diesen gewachsenen Schwächen auseinandersetzen müssen und habe Optimierungen gesucht!!! Ergebnis und Vorgehensweise, siehe oben. Und da ist nix widersprüchlich !

UND SICHER FINDE ICH DAS ALLES NICHT TOLL, WIE ES IST und ärgere mich ebenso über die vielen Bug's!!! aber ich verschwende keine weiteren Energieen sondern warte erwartungsvoll auf die ETS4 !!

Die EIS Definitionen sammle ich Dir mal zusammen und poste das morgen hier.

LG

[Chris M.]

aber ich verschwende keine weiteren Energieen sondern warte erwartungsvoll auf die ETS4 !!

Das dauert aber noch ein Jahr (Google Translate spricht von Mai '10)

Aber evtl. ist ja jemand aus dem Forum am 16. Juni in Regensburg (http://www.knx.org/fileadmin/downloa...Program_DE.pdf - heute ist letzter Tag für eine Anmeldung!) und kann mehr erzählen...

[Dundi]

Jow....dass macht ja Sinn die ETS4 zur nächsten L&B herauszubringen.

[hari2]

Jetzt kommen wir langsam zum Punkt Ich sehe die ETS als zentrale konfigrationsinstanz und das ist IMHO noch eher zu vermitteln als es in noch spezielleren Anwendungen ggfs. mehrfach einzustellen.
Also je einmal im HS, mmh, mh, iKNX, Elvis, sonstwas
Vielleicht hab ich auch nur komisch Traume..

[...]
Und finally, mit oder ohne Konnex fande ich es sinnvoll ein brauchbares "Standard-Exportformat" zu haben! (die esf geben das IMHO nicht her und das ist auch mit Grund warum ich mich da überhaupt reinhange).

Absolute Zustimmung! Ich bin zwar noch blutiger Anfaenger was KNX betrifft, habe aber doch so einiges an Erfahrung mit diversen Protokollen (Z-Wave und EnOcean im Bereich der Heimautomatisierungstechnik). Ueber den Preis von ETS3 sag ich jetzt mal gar nichts. Aber dass die Software dann nicht mal nen vernuenftigen export hinbekommt ist echt frech. Ich erwarte ja nicht dass sich ein Sensor automatisch mit allen Eigenschaften zu erkennen gibt, wie das etwa Z-Wave macht, aber ein bisschen mehr Intelligenz waere fuer den Preis schon zu erwarten.
Ich programmiere gerade an einer "Datenuebernahme" fuer Plutohome/LinuxMCE (HA loesung mit Visu/Floorplans etc etc etc.). Ich hoffte auch ueber entsprechende Namenskonventionen in ETS3 die zusaetzliche Zuweisung von GA zu "devices" in pluto/lmce zu umgehen.

Wenn man sich ansieht was heutzutage bereits eine Ethernet/IP Schnittstelle hat und was preiswertere Systeme wie Z-Wave inzwischen koennen, frage ich mich ob der EIB Verein nicht mal umdenken will..
Nicht mehr lange und die Steckdosen/Lichtschalter sprechen WLAN und stellen ihre Funktionen per DLNA im Netzwerk bereit. Und auf der PS3 laeuft ne 3d Visu :-p

schoenes Wochenende,
Hari

[meudenbach]

Hallo Hari,

hey, interessante Dinge machst Du da... Plutohome wollte ich auch schon immer mal dran (ist in D ja leider nicht so verbreitet) und z-wave wird unsere nächste Baustelle.

Nicht mehr lange und die Steckdosen/Lichtschalter sprechen WLAN und stellen ihre Funktionen per DLNA im Netzwerk bereit. Und auf der PS3 laeuft ne 3d Visu :-p

das sehe ich sportlich... und evtl. in 20 Jahren ansatzweise "zumutbar". Nur werden hier wieder vergleiche gezogen, sportlich !!!

Wenn zB die Konnex über die Mittel verfügen würde, die zB die "braune Ware" Industrie und andere in DLNA investiert, würden wir uns vermutlich auch über eine höhere Fluktuation bei den ETS Versionen erfreuen dürfen.

Nur denke ich, hat die DLNA ähnliche Baustellen. Ich habe in komplexeren Umsetzungen bisher keine funktionierende Medienverteilung a la DLNA gesehen. Viele Köche verderben eben den Brei , Makki würde nun sagen "halbgares ..."

Zu Makkis Zitat...

Ich sehe die ETS als zentrale konfigrationsinstanz

Bezogen auf das Subsystem KNX ok, bezogen auf das Gesamtsystem ein klares nein. Ist halt rein eine Betrachtungsweise.

fände ich es sinnvoll ein brauchbares "Standard-Exportformat" zu haben!

Für mich ist es Sinnvoll und ausreichend. Sicherlich optimaler, wenn eben diese "uncertains" auch ordentlich übergeben werden. Der Aufwand der jedoch dafür in der ETS betrieben werden muss ist ungerechtfertigt hoch, solang es eben ist, wie es ist.

Makkis Wunschvorstellung ist sicherlich auch meine Wunschvorstellung, aber manche Wünsche werden eben immer Wünsche bleiben.

... such is life!!

[meudenbach]

wie versprochen, die EIS Typen Definitionen...


EIS 1 'Switching' (1 Bit)
EIS 2 'Dimming - position' (1 Bit)
EIS 2 'Dimming - control' (4 Bit)
EIS 2 'Dimming - value' (8 Bit)
EIS 3 'Time' (3 Byte)
EIS 4 'Date' (3 Byte)
EIS 5 'Value' (2 Byte)
EIS 6 'Scaling - percent' (8 Bit)
EIS 6 'Scaling - degree' (8 Bit)
EIS 7 'Drive control' (1 Bit)
EIS 8 'Priority - position' (1 Bit)
EIS 8 'Priority - control' (2 Bit)
EIS 9 'Float value' (4 Byte)
EIS 10 '16Bit Counter' (2 Byte)
EIS 11 '32Bit Counter' (4 Byte)
EIS 12 'Access' (4 Byte)
EIS 13 'EIB-ASCII-Char' (8 Bit)
EIS 14 '8Bit Counter' (8 Bit)
EIS 15 'Character String' (14 Byte)

Die in rot gekennzeichneten werden bei unserem mmh Import als Default gesetzt sofern die Ausgabe zu den entsprechenden Typen als uncertain spezifiziert ist.

Also steht in der ESF zB ein:

Uncertain (1 byte)

behandeln wir das autom. als:

EIS 6 'Scaling - percent' (8 Bit)

LG

[hari2]

Hallo Hari,

hey, interessante Dinge machst Du da... Plutohome wollte ich auch schon immer mal dran (ist in D ja leider nicht so verbreitet) und z-wave wird unsere nächste Baustelle.

Wohnfühlen mit Komfort bietet Plutohome mit einigen Verbesserungen und Anpassungen fuer den deutschen Markt an. Z-Wave ist fuer nachtraeglichen Einbau oder Mietwohnungen ganz ok. Aber das fehlende Kabel ist halt Fluch und Segen zugleich :-) (Batterieverbrauch, Funkstoerungen, ..)

das sehe ich sportlich... und evtl. in 20 Jahren ansatzweise "zumutbar". Nur werden hier wieder vergleiche gezogen, sportlich !!!

Wenn zB die Konnex über die Mittel verfügen würde, die zB die "braune Ware" Industrie und andere in DLNA investiert, würden wir uns vermutlich auch über eine höhere Fluktuation bei den ETS Versionen erfreuen dürfen.

Na Raketenwissenschaft ist KNX auch keine.
Guck mal wie SGI von "PC Grafikkarten" abgehaengt wurde. War auch nur im High End Bereich vertreten (Vergleich mit KNX: Zweckbau) und dann ploetzlich vom Mainstream ueberholt..

Nur denke ich, hat die DLNA ähnliche Baustellen. Ich habe in komplexeren Umsetzungen bisher keine funktionierende Medienverteilung a la DLNA gesehen. Viele Köche verderben eben den Brei , Makki würde nun sagen "halbgares ..."

Sicherlich, UPNP/DLNA ist sicherlich nicht "schlank" und es gab auch in der Vergangenheit so einige Probleme. Das funktioniert aber alles schon sehr viel besser. Medienverteilung (und sogar Fernsteuerung) ist mit entsprechenden Programmen heutzutage mit so ziemlich allen UPNP/DLNA playern moeglich. Lichschalter, Dimmer etc. sind auch schon lange im Standard drin. Z.b. MiCasaverde.com erlaubt bald zugriff per DLNA auf Z-Wave Komponenten. Das ist zwar alles sicher noch nicht das gelbe vom Ei, aber basiert auch auf Standards und ist aufgrund der Stueckzahlen einfach billiger. Fuer den Preis einer Merten BCU2 bekommt man ein ARM basiertes System, 400MHz, 64ram, flash, ethernet, 32 GPIO, i2c. Ist auch gar nicht viel groesser.

So koennte das "Halbgare", auch wenn derzeit sicher noch keine richtige Alternative, bald gar nicht mehr total verkehrt aussehen..

schoenen Restsonntag,
Hari

[makki]

Mike, danke hierfür!
Ich werds die Tage einbauen, auch wenn ichs eigentlich nicht brauche das gehts schon fast ums Prinzip (Konnex: geht nicht! kann nicht! und das ist so halt nicht ganz richtig, zumindest wenn die DPTs in der ETS gesetzt wurden)

Bezogen auf das Subsystem KNX ok, bezogen auf das Gesamtsystem ein klares nein. Ist halt rein eine Betrachtungsweise.

Da geb ich Dir 100% recht, vielleicht liegt da u.a. auch die Distanz in den Sichtweisen..
Von solch Themen in der gewerblichen Grossanlage habe ich gelinde ausgedrückt keine Ahnung. Darum gehts mir aber auch derzeit nicht, (obwohl es dort vermutlich reicht ein dokumentiertes UDP-Packerl zu schicken, wenn man an diesen Markt überhaupt rankommen kann und/oder will)
Dem Otto kann man eben IMHO leichter erklären, das in der ETS einzustellen als im selbstgestrickten Tool. Aber das ist eben nur meine Meinung, für diesen speziellen Fall.
Wir reden hier ja von (und das kann glaub ich als Entschuldigung für uns beide herhalten) von zweierlei völlig verschiedenen Dingen: übergeordnete Systeme im "richtigen" Männerbereich vs. EIB fürs kleine.
Die Marktdurchdringung von Heimautomatisierung im Privatbereich liegt IMHO aber nahe 0% - lassen wir das, s.u. keine Grundsatzdiskussion..
Ich muss es trotzdem erwähnen weil das das langfristige Ziel ist, über 0% zu kommen, ob mit oder ohne KNX, wiederum s.u.

Der Aufwand der jedoch dafür in der ETS betrieben werden muss ist ungerechtfertigt hoch, solang es eben ist, wie es ist.

Keine Frage, nur habe ich in meiner Phantasie nicht die Möglichkeit "danach" helfend einzugreifen. Das muss 100% fluppen oder erklärbar sein und genau da liegt vermutlich u.a. der unterschiedliche Ansatz

Makkis Wunschvorstellung ist sicherlich auch meine Wunschvorstellung, aber manche Wünsche werden eben immer Wünsche bleiben.

Aber ohne Visionen, die man umsetzt werden Wünsche immer Träume bleiben (hab ich das geschwollene grade geschreiben? kann nicht sein )

Die Grundsatzdiskussion mit KNX vs DLNA&Co heize ich jetzt sicher nicht weiter an..
Aber ich sehe das schon sehr ähnlich wie Hari; den Rest meiner Meinung kann man glaube ich ganz gut im digitalStrom-Thread nachlesen.
Ziel ist jedenfalls die Daten inkl Definition aus der ETS rauszubekommen und das ist bei entsprechender Vorarbeit machbar. Obs sinnvoll ist, steht auf nem anderen Blatt. (Als ESF nicht, da gebe ich Mike 100% recht!)

Makki

[hari2]

Mike, danke hierfür!
Ziel ist jedenfalls die Daten inkl Definition aus der ETS rauszubekommen und das ist bei entsprechender Vorarbeit machbar. Obs sinnvoll ist, steht auf nem anderen Blatt. (Als ESF nicht, da gebe ich Mike 100% recht!)

Ich werde mal zusehen dass ich das angereicherte Ausgabeformat uebernehmen kann.

lg, Hari

[makki]

Neue Version 0.91 inkl. der korrigierten EIS im OPC/.esf-Export liegt in den Downloads (und die hier entfernt)..
Die Zuordnung DPT->EIS im ESF wird nur gemacht wenn es eindeutig gesetzt ist, ansonsten bleibts "uncertain".

Makki

[meudenbach]

Ahh Respekt....

Dann wollen wir mal hoffen, dass die Hersteller nun auch die DPT's in deren PDB's ordentlich einpflegen...

LG