Konfiguration von DIY-Geräten

[tuxedo]

Hallo Alex,

am liebesten würde ich ja ein großes Whiteboard nehmen und uns zu dritt davorstellen, aber das ist geografisch vor allem für Bernhard blöd. Für uns beide wäre Heilbronn vermutlich halbe Strecke. Alternativ ginge auch Openmeeting o.ä. - kann das jemand aufsetzen?

Whiteboard... feine Sache, wenn das geografische Problem nicht wäre.
OpenMeeting ... gerade mal gegoogelt. Ebenfalls feine Sache. Zumindest wenn man Zeit hat das aufzusetzen.

Das war nach dem Motto: wenn ich nicht überzeugen kann, verwirre ich einfach
Prio 1: Ein lauffähiges Konfigurationstool für meine Multisensoren, mit dem auch ein Windows-Nutzer zurechtkommt.
Prio 2: Möglichst geringe Abweichung vom Standard. In ferner Zukunft sollen meine Geräte mit der ETS konfigurierbar sein, dafür will ich aber nicht die halbe Firmware neu schreiben müssen.
Prio 3: Möglichst weitgehend gemeinsame Entwicklung mit anderen Teilnehmern hier im DIY-Forum, um wenig Arbeit doppelt zu machen.
Prio 4: Verwenden des knxprod-Formats, um mit dem Tool auch Fremdkomponenten konfigurieren und damit die ETS ablösen zu können. Ein Einstieg darin kann auch die Unterstützung eines Subsets des knxprod-Formats sein; das korrespondiert dann mit Prio 2.

Prio 2 ff. ... Da hast du noch viel vor ;-)

Zu PDT/DPT: das habe ich in Calimero ebenfalls so vorgefunden, daran hatte ich mich orientiert. Der KNX-Standard unterscheidet auch zwischen beidem. Siehe Prio 2. Hier geht mir Standardkonformität vor Effizienz. Du kannst ja alternativ, wenn kein PDT angegeben ist, einen Defaultwert aus dem DPT ableiten.
Was machst du aber z.B. bei einer Bitmaske, zu der es gar keinen DPT gibt? Auch bei Strings bin ich mir nicht sicher (zum Nachsehen bin ich gerade zu faul).

Ah, daher weht der Wind. Ich hab das eher von einer Abstrakten Seite betrachtet: Was will der Benutzer in der GUI eingeben, bzw. was muss er eingeben, und wie bilder ich das dann ab. Eine Bitmaske vom Benutzer eingeben lassen... Ist schon sehr Advanced. Dann eher eine Optionslist. Von daher ist mein naiver Ansatz: Reduzieren auf das notwendigste. Und da sind eigentlich eine handvoll DPTs ausreichend und exakt genug definiert.

Nein, das war wieder meine Verwirrungstaktik - zwei Themen in einem Absatz.

Ich dachte sowas können nur Frauen?! Meine Frau beherrscht das in Perfektion: eine halbe Stunde über ein Thema reden und dann im Millisekundenbereich ohne Punkt und Komma oder Wechsel der Tonart das Thema wechseln ;-)

Ich habe die Duplizierung von "Kommunikationsobjekt" und "Objekt" (bei den Properties) nicht erfunden. Ich hatte anfangs ja versucht, "KO" = "Property-Objekt" für manche Properties zu setzen, das im letzten Vorschlag aber aufgegeben.

Duplizierung von "Kommunikationsobjekt" und "Objekt"

vs.

"KO" = "Property-Objekt"

Das hat für meine verwirrung gereicht.

Ja, die Referenzierung über eine eigene ID ist sinnvoller als über Object/Property, da hast du recht. Gut, dass wir das diskutiert haben.
Ich würde als ID aber den ohnehin vorhandenen "name" verwenden, auch aus Gründen der Lesbarkeit. Eine integer-ID ist zwar im Lookup im Dict ein bisschen schneller, aber das sollte auf einem aktuellen PC völlig egal sein.

Um den ggf. schnelleren Lookup wär's mir nicht. In der Hinsicht bin ich da dann doch wieder der komplizierte Informatiker der Nummern liebt. Aber ich kann mit einer textuellen ID zur Not auch leben.

Ein bisschen lesbarer wäre vielleicht

<condition depends-on="after-busvoltage-failure" value="3"/>

Exakt. Wenn die Bedingung nicht erfüllt ist, wird der Parameter auf seinen Default-Wert gesetzt. Der muss dann eben entsprechend passen. Oder brauchen wir einen eigenen Default-Wert für "disabled"?

Da bin ich noch uneins mit mir ob es für default-disabled etwas explizites geben müsste oder ob auch implizit reicht.

Möglich
Ich denke mit <group>,<condition>, <optionlist> etc. sind wir auf dem besten Weg das Rad neu zu erfinden, brauchts das bei der "einfachen" Konfiguration?
Wenn ja schmeiß ich halt wieder ein das es das im Standard schon in ähnlicher Form gibt also warum nicht gleich so übernehmen?

Bei all der Liebe zum Standard:

Der einzig "richtige" Weg wäre sich für 6 Monate aus dem Forum zu verabschieden, sich im Keller einschließen und erst wieder das Tageslicht zu erblicken wenn .knxprod und .knxproj vollständig unterstützt wird.

Wem nützt eine "halbe" Kompatibilität? Das eigene, halb-kompatible Format über die kommenden Jahr solange weiter zu deformieren bis es irgendwann 100% kompatibel ist: Macht es das ganze nicht wieder abwärtsinkompatibel?

Wieso nicht JETZT ein eigenes Format erstellen (und endlich mal fertig werden), das nach best-practices und mit bekannten Begriffen und Funktionen arbeitet, die interne Software- und Firmware-Schnittstelle aber soweit offen halten dass man alternativ zum "kleinen und einfachen Format" dann "die große KNX Standardkeule" anflanschen kann?

Auch die Zugriffsberechtigungen über die Keys etc. hab ich im Standard noch nicht entdeckt, wird evtl. auch anders gehandhabt....

Doku dazu würd mich auch interessieren, kenne nur das von Max verlinkte pdf....

Bin mir gerade nicht sicher ob besagtes Dokument sich von den Infos unterscheidet die euch offenbar schon vorliegen...

Hier mal der Link: https://drive.google.com/file/d/0B08...ew?usp=sharing

Gruß
Alex

[Bernator]

Weil ich der Meinung bin das es JETZT kein Mehraufwand ist die "Basics" aus dem Standard zu übernehmen da es ja fast identisch aufgebaut ist und nur die Nodes anderst bezeichnet werden!
Ich glaube auch nicht das <group> besser verständlich ist als <ParameterBlock> odgl..... bei beiden muss ich mal wissen um was es geht...

[l0wside]

<group> = <ParameterBlock>
<condition> = <choose><when>
<optionlist> = <ParameterTypes>

Einverstanden. Ich bastle noch einen neuen Vorschlag aus deinem, viel wird sich aber nicht ändern.

Die <devices> Liste hab ich mal rausgenommen, sowas hab ich im Standard nirgends gefunden. Denke auch das dies im Device abgebildet werden muss über die MaskVersion odg. denn sonst müsste jedesmal das xml erweitert werden wenn ein neues Device hinzukommt? Oder hab ich das falsch verstanden?

Nein, die möchte ich drin lassen. In der ETS kann man mindestens eine unpassende Applikation auf ein Gerät schieben, das sich dann gar nicht oder komisch benimmt. Dagegen möchte ich mich hier absichern.

Die DatapointType Angabe bei den KOs ist im Standard optional, Pflicht ist die Angabe von ObjectSize! Priority ist ebenfalls optional.

Dann würde ich das so übernehmen.

Den Speicherort für die Flags gibts in der Form (Property 0) auch nicht, glaub das ist aber eine "Erfindung" von Max oder? Wo wirds denn im Standard abgelegt? (ObjectTable?)

Wenn du´s rausfindest, sag Bescheid. Die "Property 0" ist eine Erfindung von mir, ich schiebe das auch gerne woanders hin. Ich war nur aus der Kögler´schen Doku diesbezüglich nicht schlau geworden.

Auch die Zugriffsberechtigungen über die Keys etc. hab ich im Standard noch nicht entdeckt, wird evtl. auch anderst gehandhabt....

Die müssen aber irgendwo stehen, jedenfalls werden regelmäßig auch von der ETS Keys übertragen.
[/QUOTE]

OpenMeeting ... gerade mal gegoogelt. Ebenfalls feine Sache. Zumindest wenn man Zeit hat das aufzusetzen.

Mein ISP hatte mich vor einer Weile mal nach einem Geburtstagswunsch gefragt. Ich glaube, ich versuche den mal einzulösen. Notfalls habe ich noch einen alten und jahrelang ungepflegten vServer, den man plattmachen und verwenden könnte.

Eine Bitmaske vom Benutzer eingeben lassen... Ist schon sehr Advanced. Dann eher eine Optionslist.

Ich muss die Bitmaske ja nicht unbedingt 1:1 dem Benutzer zumuten. Allerdings muss ich dann wieder eine Abbildung, d.h. einen DPT zuweisen...hm.

Von daher ist mein naiver Ansatz: Reduzieren auf das notwendigste. Und da sind eigentlich eine handvoll DPTs ausreichend und exakt genug definiert.

Da halte ich mich lieber an das, was Bernhard oben geschrieben hatte: im Standard ist die Größe verpflichtend und der DPT optional.
Einstellungen mit fehlendem DPT sind m.E. vor allem für Werte interessant, die das Tool von sich aus liest oder setzt, nicht für welche, die der Nutzer direkt verändert.

Ein bisschen lesbarer wäre vielleicht

<condition depends-on="after-busvoltage-failure" value="3"/>

Äh, das war mal mein Text - darf ich das als implizite Zustimmung werten?
Andererseits neige ich eher Bernhards knxprod-ähnlicher Variante zu, auch wenn die Lesbarkeit dort nicht besser ist.

Da bin ich noch uneins mit mir ob es für default-disabled etwas explizites geben müsste oder ob auch implizit reicht.

Vorschlag: default-disabled ist optional, wenn nicht vorhanden, gilt default.

Bei all der Liebe zum Standard:

Der einzig "richtige" Weg wäre sich für 6 Monate aus dem Forum zu verabschieden, sich im Keller einschließen und erst wieder das Tageslicht zu erblicken wenn .knxprod und .knxproj vollständig unterstützt wird.

So in etwa ist der Multisensor entstanden

Wem nützt eine "halbe" Kompatibilität? Das eigene, halb-kompatible Format über die kommenden Jahr solange weiter zu deformieren bis es irgendwann 100% kompatibel ist: Macht es das ganze nicht wieder abwärtsinkompatibel?

Zwei Seelen wohnen, ach, in meiner Brust. Ich sehe die Vor- und Nachteile von beidem, würde mich im Zweifelsfall eher am Standard orientieren (auch, um nicht das Rad, sondern meinetwegen nur die Speichen neu zu erfinden), stimme dir aber zu, dass knxprod nicht eben ein Musterbeispiel an händischer Lesbarkeit ist.

Max

[l0wside]

Ich wollte mich ja auch noch zu Bernhards Vorschlag auslassen.

<?xml version="1.0" encoding="UTF-8"?>
<ManufacturerData>
    <Manufacturer Id="0x001" Name="root1.de"> <!-- Kombination aus Master+ManufacturerData Manufacturer -->

So weit ok. Wie oben begründet, möchte ich aber gerne noch Order Code o.ä. in der Datei habe, um sicher zu sein, dass Applikation, Gerät und XML-Datei zusammenpassen.

        <ApplicationProgram Id="xy" Name="6CH KNX PWM LED Controller" ApplicationVersion="1" MaskVersion="MV-0021">
            <Code>
                <AbsoluteSegment Id="addr-table" Address="0xD000" Size="4" />
                <AbsoluteSegment Id="assoc-table" Address="0xE000" Size="8" />
            </Code>

Gefällt mir von den bisherigen Vorschlägen am besten. Willst du mehr als ein ApplicationProgram in einer Datei unterstützen? Damit täte ich mich im Moment etwas schwer, da müsste ich im Programm ziemlich umbauen.

            <!--ersetzt die option List-->
            <ParameterTypes>
                <ParameterType Id="PT-1" Name="device_info">
                    <TypeNumber SizeInBit="8" Type="unsignedInt" />
                </ParameterType>

Wieso "unsignedInt" statt UNSIGNED_INT?

                <ParameterType Id="PT-2" Name="Busspannungsfehler">
                    <TypeRestriction SizeInBit="8">
                        <Enumeration Text="Aus" Value="0" Id="PT-2_EN-1" DisplayOrder="0" />
                        <Enumeration Text="An" Value="1" Id="PT-2_EN-2" DisplayOrder="1" />
                        <Enumeration Text="letzter Wert" Value="2" Id="PT-2_EN-3" DisplayOrder="2" />
                        <Enumeration Text="Helligkeitswert" Value="3" Id="PT-2_EN-4" DisplayOrder="3" />
                    </TypeRestriction>  
                </ParameterType>
            </ParameterTypes>

• Was machst du mit der Enumeration ID (PT-2_EN-1)?
• Wieso hat die zweite TypeRestriction keinen type?

            <!--Parameter des Geraets, Legt deren Speicherort fest und zeigt Default-Werte-->
            <Parameters>
                <Parameter Id="P-1" Name="device_object_type" Text="" ParameterType="PT-1" Access="ReadWrite" Value="0x00">
                    <Property ObjectIndex="0x00" PropertyId="0x01" /> <!-- Speicherort des Parameters -->
                </Parameter>
                <Parameter Id="P-2" Name="device_control" Text="" ParameterType="PT-2" Access="ReadWrite" Value="0x00">
                    <Property ObjectIndex="0x00" PropertyId="0x0E" /> <!-- Speicherort des Parameters -->
                </Parameter>
                <Parameter Id="P-3" Name="Busspannungsausfall" Text="Verhalten nach Busspannungsausfall" ParameterType="PT-1" Access="ReadWrite" Value="2">
                    <Property ObjectIndex="11" PropertyId="1" /> <!-- Speicherort des Parameters -->
                </Parameter>
            </Parameters>

Wieso quetschst du alles in Attribute statt in Tochterelemente? Außerdem meine ich mich in den knxprod an ein Attribut "location" für den Speicherort zu erinnern, das mir ganz gut gefiel. Das Ganze könnte dann so aussehen:
<parameter id="bus_voltage_failed" location="properties" parameter-type="PT-1">
<text>Verhalten nach Busspannungsausfall</text>
<text lang="en">Behavior after bus voltage failed"</text>
<value>2</value>
<disabled-value>0</disabled-value>
<read-access>FREE</read-access>
<write-access>CONFIG</write-access>
</parameter>
Beim Access können wir meinetwegen auch das "ReadWrite" verwenden. In der Mask-Version 0701 sind 16 Zugriffsstufen vorgesehen, das sehe ich in deinem Vorschlag (und WIMRE/IIRC auch im knxprod) aber nicht abgebildet.

            <!-- Beschreibt die KOs -->
            <ComObjectTable>
                <ComObject Id="10" FunctionText="Kanal A" Text="Schalten Ein/Aus" DatapointType="1" ObjectSize="1 Bit" Priority="Low" CommunicationFlag="Enabled" ReadFlag="Enabled" ReadOnInitFlag="Disabled" TransmitFlag="Enabled" UpdateFlag="Enabled" WriteFlag="Enabled"  />
                <ComObject Id="11" FunctionText="Kanal A" Text="Dimmkontrolle" DatapointType="3" ObjectSize="4 Bit" Priority="Low" CommunicationFlag="Enabled" ReadFlag="Enabled" ReadOnInitFlag="Disabled" TransmitFlag="Enabled" UpdateFlag="Enabled" WriteFlag="Enabled"  />
                <ComObject Id="12" FunctionText="Kanal A" Text="Absolutwert" DatapointType="5" ObjectSize="1 Byte" Priority="Low" CommunicationFlag="Enabled" ReadFlag="Enabled" ReadOnInitFlag="Disabled" TransmitFlag="Enabled" UpdateFlag="Enabled" WriteFlag="Enabled"  />
            </ComObjectTable>

Du hast echt ein Faible für Attribute. Und: sollen die Flags tatsächlich hier schon angegeben werden?

            <ParameterBlock Id="PB-1" Name="Allgemein">
                <ParameterRefRef RefId="P-3" />   <!-- Parameter anzeigen -->
                <choose ParamRefId="PR-4">
                    <when test="0" default="false"> <!-- "Aus" Ausgewaehlt -->
                    </when>
                    <when test="1" default="false"> <!-- "An" Ausgewaehlt -->
                    </when>
                </choose>
            </ParameterBlock>

Um meine Frau zu zitieren: Bahnhof? Kofferklauen?
Was wird denn nun unter welchen Bedingungen angezeigt? Und wie werden KOs ausgeblendet?

        </ApplicationProgram>
    </Manufacturer>
</ManufacturerData>

Max

[Bernator]

So weit ok. Wie oben begründet, möchte ich aber gerne noch Order Code o.ä. in der Datei habe, um sicher zu sein, dass Applikation, Gerät und XML-Datei zusammenpassen.

Kann man das nicht im Device abbilden, sprich ich prüfe im Device welches xml file mich konfigurieren will? Hätte den Vorteil das keine neue XML Version mit dem neuen Device erstellt werden muss? Ansonsten gibts da evtl. was in der knxmaster.xml müsst ich aber nochmal genauer anschauen.

Willst du mehr als ein ApplicationProgram in einer Datei unterstützen?

Vorerst nicht aber in der .knxprod ist das so und es stört mich jetzt nicht. Der Witz an der Geschichte ist ja das .knxproj genau gleich aufgebaut ist wie .knxprod und da gibts dann eben fast für jedes Device ein ApplicationProgram. Sind zwar in eigene Files pro Application aufgesplittet aber die können auch gemerged gelesen werden. Zusätzlich kommt noch ein Node <Project> hinzu wo dann Projekt Topologie, GAs etc. abgeleg werden.

Wieso "unsignedInt" statt UNSIGNED_INT?

Weils so bei .knxprod gemacht wird (leider ist das Enum dafür nicht in der Doku), Grund ist denke ich folgender:
UNSIGNED_INT ist ein Property Data Type, ParameterType ist aber nicht zwingend ein Property sondern kann auch direkt im Speicher landen. Bei deinem Stack momentan ja nicht der Fall da landet alles in den Properties. Soweit ich das überblicke landet im Standard aber praktisch alles im Speicher was die spezifische Appconfig betrifft.

• Was machst du mit der Enumeration ID (PT-2_EN-1)?
• Wieso hat die zweite TypeRestriction keinen type?

Momentan nichts, ist aber in .knxprod vorhanden und wird dort zur Übersetzung verwendet, könnte also in der "Light" Version durchaus entfallen wenns stört.
Kommt auch aus .knxprod, Grund: weils immer ein enum ist? Genaugenommen steht da auch noch ein Base="value" Attribut dabei aber welchen Sinn das hat hab ich auch noch nicht rausgefunden....

Wieso quetschst du alles in Attribute statt in Tochterelemente? Außerdem meine ich mich in den knxprod an ein Attribut "location" für den Speicherort zu erinnern, das mir ganz gut gefiel.

Weil das im .knxprod genau so gemacht wird, persönlich finde ichs auch nicht übersichtlicher x childs zu produzieren.
Das Attribut Location gibts für Applicationsspezifische Dinge nicht sondern nur für Teile die was mit der MaskVersion etc. zu tun haben. Der Standard trennt das ganz klar und diese Teile stehen in der knxmaster.xml und sind allgemein gültig.

Beim Access können wir meinetwegen auch das "ReadWrite" verwenden. In der Mask-Version 0701 sind 16 Zugriffsstufen vorgesehen, das sehe ich in deinem Vorschlag (und WIMRE/IIRC auch im knxprod) aber nicht abgebildet.

"ReadWrite" kommt auch wieder aus der .knxprod und die Mask-Versions Geschichten hab ich ehrlich gesagt noch nicht recht behirnt, aber wie vorher schon erwähnt gibts da ne strikte Trennung und da müsste man das knxmaster.xml nochmal genauer anschauen.

Du hast echt ein Faible für Attribute. Und: sollen die Flags tatsächlich hier schon angegeben werden?

Naja hat sich auch die Konnex so ausgedacht also nicht meine Erfindung
Wo sollen die Flags sonst hin? Im Sandard werden sie auch hier mal felstgelegt können später aber von den ObjectRefs überschrieben werden aber ObjectRefs fallen hier ja erst mal weg.....

Um meine Frau zu zitieren: Bahnhof? Kofferklauen?
Was wird denn nun unter welchen Bedingungen angezeigt? Und wie werden KOs ausgeblendet?

Das läuft so: Standardmäßig wird nichts angezeigt d.h. wird ein ComObject oder ein Parameter nicht in einem <ParameterBlodk> angeführt kann es vom User nicht verwendet werden. Anführen schaut so aus:
<ParameterRefRef RefId="P-3" /> gibts ein RefRef von P-3 wirds angezeigt
<ComObjectRefRef RefId="10" /> gibts ein RefRef von ComObject 10 wirds freigeschalten
<choose><when> == switch, case
Ist übrigends auch nicht auf meinem Mist gewachsen --> .knxprod

        </ApplicationProgram>
    </Manufacturer>
</ManufacturerData>

??

So hoffentlich sind alle Klarheiten beseitigt

[l0wside]

Ich hatte heute auf der Heimfahrt von der Arbeit eine Stunde Zeit zum Nachdenken, und das war auch gut so.

Bernhard, ich fürchte, Alex hat recht. Wir sind gerade dabei, eine DIY-ETS zu stricken, und das ist zu viel des Guten. Das Format mag niemand freiwillig lesen oder gar schreiben. Ich schlage deswegen Folgendes vor:

• Das XML-Format orientiert sich grob an meinem Vorschlag in #77, angereichert um die vielen sinnvollen Ergänzungen der letzten Tage
• Bei den verwendeten Tags wird, wo es sinnvoll ist und keine Strukturanpassung erfordert, die Namenskonvention der knxprod verwendet.
• Der interne Aufbau des Programms (d.h. vor allem des Device- und des Property-Objekts) dagegen orientiert sich an der Struktur der knxprod-Datei.

So sind wir nach beiden Seiten offen. Es lässt sich mit überschaubarem Aufwand eine Konfigurationsdatei schreiben, die auch Alex´ DIY-Tool nutzt, und trotzdem kann bei Bedarf ohne Komplettumbau des Programms ein weiterer File-Importer für knxprod angebaut werden.

Können damit alle Beteiligten leben? Wenn ja, mache ich mich noch mal an einen Vorschlag fürs Dateiformat.
Der Rest der DIYler hier klickt wahrscheinlich nur noch im Zweistundentakt genervt auf "Thread als gelesen markieren"

Max

[Bernator]

• Das XML-Format orientiert sich grob an meinem Vorschlag in #77, angereichert um die vielen sinnvollen Ergänzungen der letzten Tage
• Bei den verwendeten Tags wird, wo es sinnvoll ist und keine Strukturanpassung erfordert, die Namenskonvention der knxprod verwendet.
• Der interne Aufbau des Programms (d.h. vor allem des Device- und des Property-Objekts) dagegen orientiert sich an der Struktur der knxprod-Datei.

Naja eigentlich hab ich gedacht genau so etwas gemacht zu haben, Grob die Struktur übernommen + Bezeichung aus knxprod aber gut ich lass mich da gerne überraschen
Bei der Menüstruktur würd ich aber gerne bei knxprod bleiben <choose><when> da hier das selber gestrickte in meinen Augen nicht "logischer" ist und die "light" Variante ja völlig darauf verzichten kann und wie in deiner ersten Version einfach alle Parameter angezeigt werden.

[tuxedo]

Ich hatte heute auf der Heimfahrt von der Arbeit eine Stunde Zeit zum Nachdenken, und das war auch gut so.

Bernhard, ich fürchte, Alex hat recht. Wir sind gerade dabei, eine DIY-ETS zu stricken, und das ist zu viel des Guten. Das Format mag niemand freiwillig lesen oder gar schreiben.

Hillem, meine Gebete wurden erhört ;-)

Ich schlage deswegen Folgendes vor:
* Das XML-Format orientiert sich grob an meinem Vorschlag in #77, angereichert um die vielen sinnvollen Ergänzungen der letzten Tage
* Bei den verwendeten Tags wird, wo es sinnvoll ist und keine Strukturanpassung erfordert, die Namenskonvention der knxprod verwendet.

Wäre super wenn du das nochmal als neues Beispiel zusammenfassen kannst.

* Der interne Aufbau des Programms (d.h. vor allem des Device- und des Property-Objekts) dagegen orientiert sich an der Struktur der knxprod-Datei.

So sind wir nach beiden Seiten offen. Es lässt sich mit überschaubarem Aufwand eine Konfigurationsdatei schreiben, die auch Alex´ DIY-Tool nutzt, und trotzdem kann bei Bedarf ohne Komplettumbau des Programms ein weiterer File-Importer für knxprod angebaut werden.

Und wenn man wirklich viel Zeit hat, kann man diesen Programmteil sogar noch Plugin-Fähig machen, so dass man AdHoc ein neues Fileimporter-Plugin dazuladen und einfach verwenden kann.
Das wäre endlich mal ein Ansatz wo ich das Netbeans RCP Framework sinnvoll einsetzen könnte ;-)

Können damit alle Beteiligten leben? Wenn ja, mache ich mich noch mal an einen Vorschlag fürs Dateiformat.

Nur her mit dem Vorschlag. *zerpflücken* können wir den ja immer noch *joke*

Gruß
Alex

[greentux]

Der Rest der DIYler hier klickt wahrscheinlich nur noch im Zweistundentakt genervt auf "Thread als gelesen markieren"

Dem ist nicht so. Hatte zwischendurch mal Bedenken, dass das auseinander läuft. Aber wenn ihr nun schon zu dritt dann EINE Lösung habt - prima!

[JuMi2006]

Ich hab garnicht die Zeit alle 2 Stunden so viel zu lesen ... Macht ruhig weiter! Ich bastel im Winter mein KNX-shield weiter und freue mich auf eure Ergebnisse. Der Reflow-Pizza Ofen macht morgen nen Testlauf .

[tuxedo]

Da gerade noch der eine oder vielleicht andere Formatvorschlag aussteht/in der Luft hängt:

Können wir uns vielleicht schon auf eine Tabelle mit Manufacturer-ID und ähnlichem einigen? Dann könnte man schon mal eine Liste/Formular aufsetzten um die IDs entsprechend zu verteilen/managen...

Sprich: Was für IDs/Zahlen/Daten braucht ein DIY-"Hersteller" um sich von den anderen abzugrenzen?

Mein Vorschlag hatte ja nur die "manufacturerid" (quasi uint16) vorgeschlagen. Der Rest (deviceid, revision, <wasauchimmer>) ist dann eigene Sache.

Auch wäre ein Oberbegriff für unsere "Basteleien" ganz praktisch. Mein Vorschlag "anx" (=Arduino KNX) ist ja etwas zu spezifisch. Fällt da jemand noch was tolles ein?

Etwas Brainstorming ...
DKNX ( = DIY KNX)
DNX ( = DIY KNX)
KNX@H / KNXAH ( = KNX AT HOME)
KAH ( = KNX AT HOME)





- Alex

[l0wside]

Da gerade noch der eine oder vielleicht andere Formatvorschlag aussteht/in der Luft hängt:

Können wir uns vielleicht schon auf eine Tabelle mit Manufacturer-ID und ähnlichem einigen? Dann könnte man schon mal eine Liste/Formular aufsetzten um die IDs entsprechend zu verteilen/managen...

Ich hatte für mich provisorisch die 0xAFFE verwendet...muss mal sehen, ob das so bleibt
Ansonsten stimme ich dir zu: wichtig wäre mir nur, dass die Mask Version, die Order ID und die Application Version überhaupt gesetzt sind. Was sie intern bedeuten, ist mir ziemlich egal.

Formatvorschlag ist noch in der Mache. Als Oberbegriff hatte ich ja <device-description>, von mir aus können wir auch <knx-device-description> draus machen. Kreative Kürzel sind mir weniger sympathisch - ich bin vergesslich und weiß dann in vier Wochen schon nicht mehr, wofür die drei Buchstaben denn nun stehen.

Max

[tuxedo]

Ich hatte für mich provisorisch die 0xAFFE verwendet...muss mal sehen, ob das so bleibt

Formatvorschlag ist noch in der Mache.

Max

Ging jetzt weniger drum wer welche ID nimmt. Sondern eher "was wird für eine zentrale Bastel-Hersteller-Liste für Daten benötigt und welches Format sollten etwaige Herstellernotwendigen IDs nun haben.

Aus deiner Antwort entnehme ich mal dass bisher nur ein uint16 als Herstellerkennung benötigt wird?! Oder kommt da in Hinblick auf "den Standard" doch noch was dazu?

[update]

Weitere Namensvorschläge:

KNOV ( = KNX Not Official Vendor)

KNOM ( = KNX Not Official Manufacturer)

KUV ( = KNX Unofficial Vendor)
KUM ( = KNX Unofficial Manufacturer)
KONUC ( = KNX ON μC)

Oder etwas recursives ;-)

CINO = CINO Is Not Official ... Wobei das C ohne weiteres durch was anderes ersetzt werden könnte. L zum Beispiel. Weil L kommt nach dem K von KNX. --> LINO

[l0wside]

Aus deiner Antwort entnehme ich mal dass bisher nur ein uint16 als Herstellerkennung benötigt wird?! Oder kommt da in Hinblick auf "den Standard" doch noch was dazu?

Exakt. Unter seinem eigenen uint16 kann im Prinzip jeder tun und lassen, was er will.

Da ich im Tool aber noch gerne prüfen möchte, ob auf der anderen Seite das richtige Gerät sitzt, hätte ich gerne die drei anderen erwähnten Daten noch implementiert. Was diese dann in sich aussagen, muss aber jeder mit sich ausmachen.


Noch was: du hattest mal geschrieben, dass du dem Otto-Normal-Ubuntunesen den eibd nicht zumuten willst und deswegen lieber das Java-Tool entwickelst. Was spräche aber dagegen, für das Qt-Tool ein .deb mit Dependency zum eibd zu erzeugen? Der eibd wird dann in einer eigenen Instanz vom Qt-Tool aufgerufen, die Konfiguration erfolgt über das Qt-Tool.
Allerdings ist das dann eben wieder C++...

Max

[tuxedo]

Exakt. Unter seinem eigenen uint16 kann im Prinzip jeder tun und lassen, was er will.

Da ich im Tool aber noch gerne prüfen möchte, ob auf der anderen Seite das richtige Gerät sitzt, hätte ich gerne die drei anderen erwähnten Daten noch implementiert. Was diese dann in sich aussagen, muss aber jeder mit sich ausmachen.

Max

Alles klar. Dann lag ich da ja schon richtig. Ich schau mal dass ich bei Gelegenheit da eine Online-ID-Liste bastel ...

Mein Vorschlag für die interne versionierung/device-kennung war ja:

* deviceid (uint16)
* revision (uint8)

Beides sollte eigentlich selbsterklärend sein (auch wenn die Namen nicht dem Standard entsprechen).
Reichen 2 weitere IDs nicht? Du hattest was von 3 weiteren geschrieben?!