Konfiguration von DIY-Geräten

[tuxedo]

Naja genau das hat Max mit seinem Config Tool ja bereits am laufen, also warum nochmal neu erfinden? Nur wegen Linux?

Jepp. Es gibt tatsächlich Menschen die kopmlett ohne Windows können und wollen.
Ich werd' mir deshalb kein Windows kaufen oder meine DIY Arduino-Entwicklung nach Windows (in die ETS-VM) verlagern.

Ich für meinen Teil will eben auch Digitale Eingänge konfigurieren und da wirds schnell unübersichtlich da viele properties benötigt werden. Ist zwar am Anfang wenn man in der Materie drinnen ist nicht unbedingt das Problem aber sobalt man später weider drauf schaut ist es eine Qual. Daher darf aus meiner Sicht das xml schon etwas "komplexer" sein, da steck ich einmal mein Hirnschmalz rein und später muss ich mich nicht mehr darum kümmern....

Okay, verständlich. Mit steigender Komplexität des Geräts macht es natürlich Sinn. Die meisten DIY Geräte werden das aber vielleicht gar nicht benötigen?

Von daher: Verschiedene Anwendungsfälle, verschiedene Tools?

Sehe ich auch so, zur Not werten die jeweiligen Tools halt bestimmte Teile des anderen gar nicht aus....

Das wäre schon mal gut.

Schöner wär trotzdem EIN Tool

Wenn es plattformübergreifend arbeitet und auch mit der Kommandozeile klar kommt: Von mir aus ;-)
Ansonsten werkelt ihr an der Windows-Variante, und ich "spezialisiere" mich auf den Linux-Nerd...

[l0wside]

Über sowas hab ich auch schon mal nachgedacht. Die Frage ist nur: Lohnt sich der Aufwand? Die KNX DIY "Szene" ist relativ klein und überschaubar. Muss es da gleich zu Anfang die Eierlegende Wollmilchsau geben? Und sind die ersten DIY-Geräte dann auch so umfangreich dass man das braucht?

Naja, ich habe immer noch eine kommerzielle Verwendbarkeit im Sinn, daher darf das Tool auch ein bisschen komplexer sein. Allerdings soll nicht das Tool kommerziell werden (wenn es einigermaßen stabil ist, würde ich es unter GPL veröffentlichen), sondern nur (meine) kommerziellen Geräte bedienen können.

Ein weiterer Punkt ist die Zielgruppe... Muss es wirklich ein recht aufwendiges XML-Format sein das sich bald nur noch mit einem grafischen Tool beherrschen lässt?

Der größte Teil der XML-Datei ist Standard (BCU2), einen neuen Parameter oder ein neues KO einzutragen ist in zwei Minuten erledigt. Ich finde es nicht übermäßig komplex und editiere im ganz normalen Texteditor.

AFAIK .. Ja, nur Windows. Einer der Gründe warum es die ETS nicht für Linux gibt. Kenne, außer Calimero (java....) keinen anderen umfangreichen KNX "Backendtreiber". Ob man das an Qt anflanschen kann um damit die Linux-Welt abzudecken?! Keine Ahnung.

Der eibd deckt im Grunde alles ab, was das Backend benötigt. Wie Bernhard korrekt schreibt, ist Qt portabel, und auch wenn mein Code sicher nicht optimal strukturiert ist: es genügt, die FalconIF.cpp durch eine eibd-basierte Variante auszutauschen, dann sollte das Programm genauso unter Linux laufen. Ich hätte dagegen nichts einzuwenden, im Gegenteil.

Es wäre ein Anfang wenn wir auf ein gemeinsames, kompatibles XML-Format kommen. Wenn es dann mehrere Tools gibt die damit umgehen können: Wieso nicht. Aber aktuell verfolgen wir teils unterschiedliche Ziele :-(

Ja, da hast du leider teilweise recht. Wenn sich das nicht vermeiden lässt, sollten wir sehen, dass wir wenigstens Code Sharing hinbekommen.
Ist es aus deiner Sicht machbar, Calimero (Java) an Qt unter Linux anzukoppeln? Wie schon gesagt: ich wäre froh, auch unter Linux ein Tool zu haben.

Sofern ich mich recht erinnere hat Max keine fest definierten Speicherblöcke für das ganze Property-Zeugs sondern schreibt die ganze Tabelle frei von vorne weg, das würde zumindest das 3. Byte erklären.

Nein, ich mache das hier nach dem Standard und habe deswegen zwei Tabellen (Address und Association Table). Es wäre mir sehr recht, wenn sich die DIY-Fraktion damit auch anfreunden könnte...
Der hier genannte Vorschlag ist dazu nicht kompatibel, aber eben leicht, schnell und speichersparend umzusetzen. Und die Arduino-Fraktion scheint mir ein ziemliches Speicherproblem zu haben und einzelne Bytes zu jagen (man korrigiere mich, wenn ich falsch liege).

Daher darf aus meiner Sicht das xml schon etwas "komplexer" sein, da steck ich einmal mein Hirnschmalz rein und später muss ich mich nicht mehr darum kümmern....

Full ACK.

Von daher: Verschiedene Anwendungsfälle, verschiedene Tools?

Wenn´s geht, nein. Kommandozeile wird gerne auch genommen; magst du das Qt-basierte Tool um Kommandozeilenhandling ergänzen? Ist eben C++ statt Java, kannst du damit leben?

Hast du Zugang zum Repository? Wenn nein, lasse mir bitte deine Mailadresse per PN zukommen, dann kannst du auf den SVN-Server.

Max

[Bernator]

...werkelt ihr an der Windows-Variante, und ich "spezialisiere" mich auf den Linux-Nerd...

indem du fürs Qt Projekt ein Linux Backend einbindest... perfekt! *duck und weg*

[l0wside]

Hab auf der Basis von Max auch mal bissl was gemacht in Richtung verschachtelter Konfiguration. Sprich bestimmte Properties werden nur zugänglich wenn übergeordnete entsprechend gesetzt sind.

So, jetzt habe ich mir deinen Beitrag endlich mal angeschaut. Finde ich gut, werde ich vermutlich demnächst ebenfalls brauchen können (werde noch Absolutfeuchte und Taupunkt integrieren müssen). Kannst du deinen Stand als Fork im SVN einchecken? Dann kann ich mit meinem aktuellen Stand mergen.
Deine XML-Datei habe ich noch nicht ganz verstanden. Du hast die meines Sensors ja erweitert, ich zitiere mal daraus:

    <object name="DI_1_Schaltobjekt" verbose="Switch Object" function="Digital I/O 1" id="10" dpt="1" prio="Low" length="1 bit">
          <property name="flags" id="0">
              <type>GENERIC01</type>
              <read_access>FREE</read_access>
              <write_access>CONFIG</write_access>
            <default>31</default>
          </property>
    </object>

...

        <menue>
            <Entry property="function" id="1">
                <Entry option="disable" id="1"></Entry>
                <Entry option="input" id="1">
                    <Entry property="ctype" id="2">
                        <Entry option="break_contact" id="1"></Entry>
                        <Entry option="closing_contact" id="1"></Entry>
                    </Entry>
                    <Entry property="job" id="3">
                        <Entry option="switching" id="1">
                            <Entry property="objekt" id="4">
                                <Entry option="bit" id="1">
                                    <Entry property="TON" id="14">
                                        <Entry option="onT" id="1"></Entry>
                                        <Entry option="offT" id="1"></Entry>
                                        <Entry option="noT" id="1"></Entry>
                                    </Entry>
                                    <Entry property="TOFF" id="15">
                                        <Entry option="onT" id="1"></Entry>
                                        <Entry option="offT" id="1"></Entry>
                                        <Entry option="noT" id="1"></Entry>
                                    </Entry>
                                </Entry>
                                <Entry option="level" id="1">
                                    <Entry property="LevelON" id="12"></Entry>
                                    <Entry property="LevelOFF" id="13"></Entry>
                                </Entry>
                                <Entry option="value" id="1">
                                    <Entry property="ValueON" id="6"></Entry>
                                    <Entry property="ValueOFF" id="7"></Entry>
                                </Entry>
                            </Entry>
                        </Entry>
                        <Entry option="toggle" id="1">
                            <Entry property="objekt" id="4">
                                <Entry option="bit" id="1">
                                    <Entry property="TON" id="14">
                                        <Entry option="onT" id="1"></Entry>
                                        <Entry option="offT" id="1"></Entry>
                                        <Entry option="noT" id="1"></Entry>
                                    </Entry>
                                    <Entry property="TOFF" id="15">
                                        <Entry option="onT" id="1"></Entry>
                                        <Entry option="offT" id="1"></Entry>
                                        <Entry option="noT" id="1"></Entry>
                                    </Entry>
                                </Entry>
                                <Entry option="level" id="1">
                                    <Entry property="LevelON" id="12"></Entry>
                                    <Entry property="LevelOFF" id="13"></Entry>
                                </Entry>
                                <Entry option="value" id="1">
                                    <Entry property="ValueON" id="6"></Entry>
                                    <Entry property="ValueOFF" id="7"></Entry>
                                </Entry>
                            </Entry>
                        </Entry>
                        <Entry option="dimming" id="1">
                            <Entry property="dimmdirection" id="8">
                                <Entry option="up" id="1"></Entry>
                                <Entry option="down" id="1"></Entry>
                                <Entry option="updown" id="1"></Entry>
                            </Entry>
                            <Entry property="dimmstepsb" id="9">
                                <Entry option="steps1" id="1"></Entry>
                                <Entry option="steps2" id="1"></Entry>
                                <Entry option="steps4" id="1"></Entry>
                                <Entry option="steps8" id="1"></Entry>
                                <Entry option="steps16" id="1"></Entry>
                                <Entry option="steps32" id="1"></Entry>
                                <Entry option="steps64" id="1"></Entry>
                            </Entry>
                            <Entry property="dimmstepsd" id="10">
                                <Entry option="steps1" id="1"></Entry>
                                <Entry option="steps2" id="1"></Entry>
                                <Entry option="steps4" id="1"></Entry>
                                <Entry option="steps8" id="1"></Entry>
                                <Entry option="steps16" id="1"></Entry>
                                <Entry option="steps32" id="1"></Entry>
                                <Entry option="steps64" id="1"></Entry>
                            </Entry>
                            <Entry property="stop" id="11">
                                <Entry option="yes" id="1"></Entry>
                                <Entry option="no" id="1"></Entry>
                            </Entry>
                        </Entry>
                    </Entry>    
                </Entry>        
                <Entry option="output" id="1"></Entry>
            </Entry>
        </menue>

Wie machst du die Zuordnung von Property zu Menu? Gilt eine Menüstruktur global für alle Properties eines Objects? Fände ich nicht gut, aber vielleicht habe ich das auch einfach falsch verstanden.

Dabei stellt sich mir die Frage wohin mit diesen Properties? Der Ursprüngliche Gedanke zu den entsprechenden KO's lässt sich da nicht wirklich verfolgen da eine unterschiedliche Konfiguration die KO's unterschiedlich verwendet.

Ich habe auch langsam den Eindruck, dass ich mich da verrannt habe. Ich würde die Funktionalität trotzdem drin lassen, es ist ja ziemlich egal, wo eine Property letztendlich steht.

Ich hätte mir grob so was vorgestellt (Änderungen farblich markiert):

    <object name="DI_1 Common" verbose="Digital I/O 1" id="200">
        <property name="function" verbose="Function" unit="" dpt="20" id="1"[COLOR=Orange] rangetype="list" range="list_digital_in"[/COLOR]>
[COLOR=Orange]             <condition object="10" property="15" cond=">=1"/>
[/COLOR]            <type>UNSIGNED_CHAR</type>
            <read_access>FREE</read_access>
            <write_access>CONFIG</write_access>
            <default>255</default>
        </property>
    </object>
[COLOR=Orange]    <menu>
        <list name="list_digital_in">
            <entry name="Off" value="0"/>
            <entry name="Input" value="1"/>
            <entry name="Output" value="2"/>
        </list> 
    </menu>
[/COLOR]

Mit der "Condition" bin ich noch nicht so recht zufrieden, vielleicht hat jemand einen besseren Vorschlag?

Generell will ich die Bedienung in Richtung ETS bringen und auch ganze Projekte damit abbilden inkl. GA Struktur um mit der lite version kommerzielle KNX Produkte zu konfigurieren und als "Dummy" dann hier einzubauen.

GA Baum und drag and drop der KO's hab ich auch schon grob hinbekommen...

Ui, das sieht ja viel besser aus als mein aktueller Stand. Magst du das Mergen übernehmen? Bei mir sind nur Speicher schreiben und Device Reset dazugekommen, also eher Kleinkram. Ersteres ist noch ziemlich rudimentär (funktioniert, blockiert aber das UI), Letzteres ist schnell nachimplementiert.

Was mir noch fehlt, ist das Auslesen von Parametern aus dem Device, das kommt irgendwann noch. Sollte sich mit deinen Ansätzen aber gut ergänzen.

Max

[tuxedo]

Naja, ich habe immer noch eine kommerzielle Verwendbarkeit im Sinn, daher darf das Tool auch ein bisschen komplexer sein. Allerdings soll nicht das Tool kommerziell werden (wenn es einigermaßen stabil ist, würde ich es unter GPL veröffentlichen), sondern nur (meine) kommerziellen Geräte bedienen können.

DIY == Selber machen == eher nicht so kommerziell

Die meisten Selbermacher kommen gerade so mit dem Arduino klar und sind sicher froh wenn es "einfach bleibt". Wobei "einfach" sowie "komplex" dehnbare Begriffe sind.

Der größte Teil der XML-Datei ist Standard (BCU2), einen neuen Parameter oder ein neues KO einzutragen ist in zwei Minuten erledigt. Ich finde es nicht übermäßig komplex und editiere im ganz normalen Texteditor.

Mit "komplex" bezog ich mich eher auf die verschachtelten Optionen.

Der eibd deckt im Grunde alles ab, was das Backend benötigt. Wie Bernhard korrekt schreibt, ist Qt portabel, und auch wenn mein Code sicher nicht optimal strukturiert ist: es genügt, die FalconIF.cpp durch eine eibd-basierte Variante auszutauschen, dann sollte das Programm genauso unter Linux laufen. Ich hätte dagegen nichts einzuwenden, im Gegenteil.

Mit eibd hab ich nur ein Problem: Der computerbildlesende Ubuntu-Nutzer braucht erstmal eine Anleitung wie eibd zu installieren ist. Es gibt da deutlich mehr Fallstricke als wenn man eine Zip runterlädt, entpackt und die Anwendung startet. Ohne weitere abhängigkeiten und konfigurationen (das wäre so mein Ziel).

Ja, da hast du leider teilweise recht. Wenn sich das nicht vermeiden lässt, sollten wir sehen, dass wir wenigstens Code Sharing hinbekommen.
Ist es aus deiner Sicht machbar, Calimero (Java) an Qt unter Linux anzukoppeln? Wie schon gesagt: ich wäre froh, auch unter Linux ein Tool zu haben.

Kenn mich mit Qt nicht wirklich aus und bin in der C/C++ Entwicklung auch nicht wirklich fit. Ich kann dir eine C/C++ Komponente an Java Anflanschen. Aber ohne weiteres den Umgekehrten Weg gehen...
Ich könnte höchstens auf Calimero ein Socket-Interface aufsetzen das man dann von Qt Seite anflanscht. Der Vorteil der wiederverwendung des Qt GUIs wird durch den Aufwand der Socketschnittstelle zunichte gemacht.

Nein, ich mache das hier nach dem Standard und habe deswegen zwei Tabellen (Address und Association Table). Es wäre mir sehr recht, wenn sich die DIY-Fraktion damit auch anfreunden könnte...
Der hier genannte Vorschlag ist dazu nicht kompatibel, aber eben leicht, schnell und speichersparend umzusetzen. Und die Arduino-Fraktion scheint mir ein ziemliches Speicherproblem zu haben und einzelne Bytes zu jagen (man korrigiere mich, wenn ich falsch liege).

Der EEPROM im Arduino ist groß genug. Ob da pro GA noch ein Byte mehr oder weniger dazu kommt ist quasi egal. Das speichern der GAs an vordefinierten Stellen im Eeprom ist platzsparend im EEPROM (2 byte pro GA) und der Code drum rum zum auslesen... Weiß nicht ob man da so viel spart wenn man den Index pro möglicher GA noch irgendwo im Code stehen hat. Arbeite hier eigtl. schon mit Index+Offset pro KO

Was im Arduino ein "Problem" ist, ist primär der RAM. Der KNX Stack hält (vor meiner Änderung) die ganzen Adressen als String. Und wenn man viele GAs braucht, ist ruck-zuck der RAM voll. Daran arbeite ich aber und hat mit diesem Thema hier eigtl. nix zu tun.

Wenn´s geht, nein. Kommandozeile wird gerne auch genommen; magst du das Qt-basierte Tool um Kommandozeilenhandling ergänzen? Ist eben C++ statt Java, kannst du damit leben?

Ich bin mir nicht sicher ob es ausreichend Überschneidung in unseren Ansätzen und Zielen gibt.
Ich seh mich aktuell eher als Vertreter "Einsteiger"-Fraktion, als der "Fortgeschrittenen"-Fraktion in Sachen DIY-Gerätebau.

Von daher würde ich erstmal schauen dass

a) mein Projekt überhaupt funktioniert
b) ich schau dass ich so weit wie möglich kompatibel zu eurem XML bin und nur den "Fortgeschrittenen-Teil" weg reduziere (auch wenn sich hier schon wieder unsere Ansätze beissen --> 1 vs. 2 File Ansatz)

Hast du Zugang zum Repository? Wenn nein, lasse mir bitte deine Mailadresse per PN zukommen, dann kannst du auf den SVN-Server.

Nein, hab ich noch nicht. Kann aber sicher nicht schaden. Hab meine Bastelei noch nicht in mein SVN eingepflegt. Ist noch zu sehr Bastelei. Wenn's etwas vorzeigbares gibt werde ich die URL veröffentlichen.

indem du fürs Qt Projekt ein Linux Backend einbindest... perfekt! *duck und weg*

Das überlasse ich den C/C++ Experten.

Gruß
Alex

[l0wside]

DIY == Selber machen == eher nicht so kommerziell

Ja, klar. Wenn die Tools aber gut sind, werden sie gerne genommen - als DIYler mit Eclipse zu arbeiten, ist ja auch nicht verpönt.

Die verschachtelten Optionen muss ja auch niemand nutzen.

Mit eibd hab ich nur ein Problem: Der computerbildlesende Ubuntu-Nutzer braucht erstmal eine Anleitung wie eibd zu installieren ist.

Das ist ein Punkt. Ich bin mir gerade nicht sicher, ob die Client-Library ganz normale cEMI-Messages erzeugt (dann könnte man auf Basis der eibd-Client-Lib direkt auf ein IP-gateway zugreifen) oder ob die Kommunikation mit dem eibd-Socket proprietär ist.

Kenn mich mit Qt nicht wirklich aus und bin in der C/C++ Entwicklung auch nicht wirklich fit. Ich kann dir eine C/C++ Komponente an Java Anflanschen. Aber ohne weiteres den Umgekehrten Weg gehen...

Ich sehe das Problem nicht so recht...letztendlich sind ein paar Aufrufe Java->C++ und C++->Java zu erledigen, egal, in welche Richtung du nun anflanschst. Das scheint seit fast 20 Jahren zu funktionieren, jedenfalls hat mir kurzes Googeln einen Artikel von 1996(!) ausgeworfen.

Der EEPROM im Arduino ist groß genug. Ob da pro GA noch ein Byte mehr oder weniger dazu kommt ist quasi egal. Das speichern der GAs an vordefinierten Stellen im Eeprom ist platzsparend im EEPROM (2 byte pro GA) und der Code drum rum zum auslesen... Weiß nicht ob man da so viel spart wenn man den Index pro möglicher GA noch irgendwo im Code stehen hat. Arbeite hier eigtl. schon mit Index+Offset pro KO
Was im Arduino ein "Problem" ist, ist primär der RAM.

Die AVR haben wohl Harvard-Architektur, d.h. ein direkter Zugriff aufs Flash im gleichen Speicherbereich wie das RAM wird wohl nicht funktionieren - da habe ich es einfacher.
Zu den Adresstabellen: kriegen wir hier ein einheitliches Format hin? Ich habe mich an die BCU2 gehalten und würde gerne dabei bleiben. Es gibt zwei Tabellen:

• Address Table, Format:
  [nentries|ga1|ga2|ga3...]
  nentries = 8 bit, ga1,... = 16 bit
• Association Table, Format:
  [nentries|assoc1|assoc2|...]
  nentries = 8 bit
  assoc:
  typedef struct { uint8_t cr_id; uint8_t index; } assoctable_entry_t;

nentries gibt jeweils die Anzahl der gültigen Einträge an. Die Indexzählung beginnt mit 1. cr_id ist das KO.
Geschrieben wird per MemoryWrite an eine vordefinierte Adresse.

Ich wäre sehr dankbar, wenn wir hier zu einem einheitlichen Format kämen. Das stammt nicht von mir sondern ist aus Köglers Doku zur BCU2.


Wenn wir nachher zwei Tools haben, die aber Richtung Konfigurationsdatei und Richtung Gerät die gleichen Schnittstellen haben, ist das meinetwege auch noch ok. Ich hatte dich so verstanden, dass du nur Java machen willst. In dem Fall kommen wir wohl nicht zu einem gemeinsamen Tool. Dann sollten wir wenigstens kompatibel bleiben.

Max

[tuxedo]

Ja, klar. Wenn die Tools aber gut sind, werden sie gerne genommen - als DIYler mit Eclipse zu arbeiten, ist ja auch nicht verpönt.

Ich schwöre auf Netbeans :-)

Die verschachtelten Optionen muss ja auch niemand nutzen.

... weshalb ich sie gerne optional weglassen würde. Zumindest Anfangs.

Das ist ein Punkt. Ich bin mir gerade nicht sicher, ob die Client-Library ganz normale cEMI-Messages erzeugt (dann könnte man auf Basis der eibd-Client-Lib direkt auf ein IP-gateway zugreifen) oder ob die Kommunikation mit dem eibd-Socket proprietär ist.

Bin ich überfragt.

Ich sehe das Problem nicht so recht...letztendlich sind ein paar Aufrufe Java->C++ und C++->Java zu erledigen, egal, in welche Richtung du nun anflanschst. Das scheint seit fast 20 Jahren zu funktionieren, jedenfalls hat mir kurzes Googeln einen Artikel von 1996(!) ausgeworfen.

Jepp, mit JavaNativeInterface (JNI) kann man von Java aus Nativen Code aufrufen und von nativen Code aus Java Code. Der Haken: Die "Hauptanwendung" ist eine Java-Anwendung. D.h. die Java-Anwendung kümmert sich mit JVM Bordmitteln um das laden des nativen Programmteils.

Mit JNI habe ich schon gearbeitet. Geht, ist aber alles andere als "toll". Ich versuch's zu vermeiden wo's nur geht.

Mit JNI kannst du meines Wissens keine "Native Anwendung" (C/C++) haben die dann auf Java-Code zugreift. Die Basis der Funktionalität ist nämlich die JVM. Eventuell kann man den Spiess umdrehen und die native Anwendung aus Java heraus starten um so als "Basis" die JVM im Boot zu haben. Aber das ist eher Murks.

Die AVR haben wohl Harvard-Architektur, d.h. ein direkter Zugriff aufs Flash im gleichen Speicherbereich wie das RAM wird wohl nicht funktionieren - da habe ich es einfacher.

Offenbar. Der Arduino-Stack erlaubt byte-Weise auf den EEPROM zuzugreifen. Alles was du brauchst ist ein Index. Da kann ich mir die KO-Nummer im EEPROM dann sparen. Aber für das XML-Format wäre es kein abbruch. Ich kann das zusätzliche Byte ja einfach verwerfen.

Zu den Adresstabellen: kriegen wir hier ein einheitliches Format hin? Ich habe mich an die BCU2 gehalten und würde gerne dabei bleiben. Es gibt zwei Tabellen:

• Address Table, Format:
  [nentries|ga1|ga2|ga3...]
  nentries = 8 bit, ga1,... = 16 bit
• Association Table, Format:
  [nentries|assoc1|assoc2|...]
  nentries = 8 bit
  assoc:
  typedef struct { uint8_t cr_id; uint8_t index; } assoctable_entry_t;

nentries gibt jeweils die Anzahl der gültigen Einträge an. Die Indexzählung beginnt mit 1. cr_id ist das KO.
Geschrieben wird per MemoryWrite an eine vordefinierte Adresse.

MemoryWrite ... Hab mich bis jetzt auf die Properties eingeschossen. MemoryWrite müsste ich mir anschauen. Wenn das im Softwarestack anders gehandhabt werden muss wie die Properties, dann würde ich darauf verzichten wollen. Spart mit im Flash doch einiges an Platz wenn ich nicht zwei Daten-Speicher-Mechanismen drin haben muss.

Ich wäre sehr dankbar, wenn wir hier zu einem einheitlichen Format kämen. Das stammt nicht von mir sondern ist aus Köglers Doku zur BCU2.

Ist ja schön einen Standard zu haben. Aber was bringt er an dieser Stelle? Wir entwickeln ja DIY-Geräte die leicht vorbei am Standard gehen. Für den späteren Betrieb ist es irrelevant wie die Daten in das Gerät kamen und wo sie intern wie gespeichert sind. Der Benutzer hat nix davon wenn die GAs über memorywrite geschrieben wurden und somit BCU2 kompatibel gearbeitet wurde.
Aber vielleicht hab ich auch zu wenig Ahnung von memoryWrite um zu verstehen wo der Vorteil darin liegt. Weil aktuell macht es für mich keinen Unterschied ob ich mich jetzt einen Millimeter näher am "Standard" bewege oder nicht.
Ich geh mal lesen ...

Wenn wir nachher zwei Tools haben, die aber Richtung Konfigurationsdatei und Richtung Gerät die gleichen Schnittstellen haben, ist das meinetwege auch noch ok. Ich hatte dich so verstanden, dass du nur Java machen willst. In dem Fall

"nur Java machen wollen" ist etwas zu hart ausgedrückt und erweckt ggf. den falschen Eindruck.

Wenn die Plattformunabhängigkeit als Requirement mit ins Spiel kommt wäre hier Java eben das Mittel der Wahl. Denn sowohl die Sprache als auch der KNX-Stack (weil komplett in Java) sind plattformunabhängig. Alles andere deckt sich nicht 100%ig mit den Anforderungen und bedarf entweder zusätzlichen Aufwand oder irgendwelcher Adapter/Krücken.
Ergänzend kommt hinzu: Mein Java-Wissen baut auf ca. 11 Jahre aktives Arbeiten damit auf. C/C++ hab ich effektiv zusammengerechnet vllt. 1 Jahr gemacht. Traue mir nicht wirklich zu eine C/C++ Anwendung in gleicher Qualität wie eine Java-Anwendung zu schreiben. Deshalb Java.

kommen wir wohl nicht zu einem gemeinsamen Tool. Dann sollten wir wenigstens kompatibel bleiben.

Das wäre toll. Allem voran steht noch das Thema 1- vs. 2-File Ansatz ...

Sofern du dich nicht vom 2-File-Ansatz überzeugen lässt: Wie schaut's denn mit dem File-Format für die Benutzereinstellungen bei dir aus?
Vielleicht kann ich dem ja noch was abgewinnen ;-)

[Bernator]

Kannst du deinen Stand als Fork im SVN einchecken? Dann kann ich mit meinem aktuellen Stand mergen.

hab ich gemacht, aber Vorsicht da ist noch nicht aufgeräumt also dementsprechend wild schauts aus

Wie machst du die Zuordnung von Property zu Menu? Gilt eine Menüstruktur global für alle Properties eines Objects? Fände ich nicht gut, aber vielleicht habe ich das auch einfach falsch verstanden.

Genau es gilt global für das gesamte Objekt, aber sehe jetzt nicht warum das nicht gut sein soll?
Das eigentliche Objekt ("DI_1_Common") dient ja quasi nur als Container für die Funktion DI/O1 und hier muss ich mir dann überlegen wie ich die Properties verschachteln will.
Etwas blöd dabei ist nur das eine Object_ID verbraten wird, mir fällt da aber keine bessere Variante ein außer das mans halt an irgend ein beteiligtes KO hängt aber das ist dann nicht mehr so nachvollziebar finde ich?

Ich hätte mir grob so was vorgestellt (Änderungen farblich markiert):

Ich denke ich hab ungefähr verstanden worauf du hinaus willst aber sehe hier auch noch nicht den Vorteil außer das ich solche "Listen" öfter verwenden könnte und damit das xml etwas schlanker wird und bei der Erstellung bissl copy paste entfällt. Im Gegenzug verliert man aber den Überblick bei der Erstellung da die "Verschachtelung" nicht hierachisch abgebildet ist, somit bräuchte es noch ein "Manufacturer Tool" um das überschaubar zu machen was etwas übertrieben ist in meinen Augen... Oder aber ich habs nicht ganz behirnt was auch nicht ausgeschlossen ist

Ui, das sieht ja viel besser aus als mein aktueller Stand. Magst du das Mergen übernehmen?

Leider hab ich aktuell mal wieder gar keine Zeit, das müsste also ne ganze Weile warten....auch ist das Speichern und Laden des Projektes noch nicht angepasst, da wird also ein Blödsinn rauskommen. Da es aber beim Testen langweilig ist jedes mal eine GA Struktur aufzubauen werden paar test GA's hardcodiert in knxcfgmain erstellt..... kurz es ist noch einiges zu tun

[Bernator]

hab jetzt mal schnell dein verlinktes Dokument von der Konnex durchstöbert (kannte ich noch nicht) dort scheint es mir als ob so ein Parameter nicht nur an ein Propertie und somit Objekt geschrieben werden kann sondern auch an definierte Speicherstellen im Device (übers MemoryInterface)



somit würde sich der Punkt mit dem "verbratenen Object" auflösen, allerdings ist das sowei ich weiß im Stack nicht implementiert oder?

Ziel Propertie:

<Parameter Id="M-000C_A-705C-01-57E3-O00F4_P-1436" Name="Hardwaretype" ParameterType="M-000C_A-705C-01-57E3-O00F4_PT-Type.5FHardware" Text="Ausgabe der Stellgröße Heizen" Access="None" Value="0" LegacyPatchAlways="false">
                <Property ObjectIndex="0" PropertyId="78" Offset="0" BitOffset="0" Occurrence="0" />
              </Parameter>

Ziel Memory:

<Parameter Id="M-000C_A-705C-01-57E3-O00F4_P-1429" Name="Heizen Kühlen nach Reset" ParameterType="M-000C_A-705C-01-57E3-O00F4_PT-Type.5F0.2E.2E.2E255" Text="" Access="None" Value="3" LegacyPatchAlways="false">
                <Memory CodeSegment="M-000C_A-705C-01-57E3-O00F4_AS-4E00" Offset="109" BitOffset="0" />
              </Parameter>

[l0wside]

Deinetwegen besorge ich mir irgendwann noch einen Bildschirm wie den hier...dann muss ich nicht mehr links und rechts scrollen...

Ansonsten: richtig, die Property-Verwaltung über definierte Speicherstellen ist bisher nicht (oder nur höchst rudimentär) implementiert. Ist auf der Todo-Liste, aber im Moment ist mein Fokus eher darauf, endlich mal Geräte in die Nähe der Serienreife zu bekommen. Mir stehen die ersten Kunden auf den Zehen...

Gruß,

Max

[tuxedo]

@Bernator ... Das rechts/links gescrolle ist irgendwie stressig. Könntest du schauen dass du nichts mehr überbreites postest?

@l0wside
Hab mir mal MemoryWrite angesehen. Mit Calimero kein Ding. Ist bereits implementiert und mindestens genauso easy wie property-write zu benutzen.
Allerdings beherrscht das der KNX Stack für den Arduino noch nicht.
Ich könnte das wohl nachrüsten. Allerdings kostet das wiederum Platz im Flash...
Vielleicht können wir uns auf eine Option einigen:
Nicht-Arduino-Device: MemoryWrite
Arduino-Device: Gleicher Config-File-Aufbau (deine zweite, mir noch unbekannte File), aber das Tool weiß (Attribut, Device-ID, ... <wasauchimmer>): Ist ein Arduino. Mapping der MemoryWrite-Aktion auf PropertyWrite-Funktionalität.

Hab dir ne PM geschrieben wegen SVN Zugang. Würde mir das eine oder andere gerne anschauen/abschauen.

Was mich immer noch brennend interessiert: Wie sieht die Config-File mit den Benutzereinstellungen aus?!

Damit mein 1-File-Ansatz nicht ganz verloren geht: Wenn das User-File auch XML ist: Vielleicht können wir uns auf ein gemeinsames Document-Root-Tag einigen, so dass man wahlweise alles in einer File hat, oder in zwei Files. Dann wäre im 1-File-Ansatz Deklaration von Definition anhand der Dokumentenstruktur getrennt und im 2-File-Ansatz das ganze nochmal auf zwei Files getrennt.

[tuxedo]

Hab mir die Sache nochmal gründlich angeschaut und bin vorerst zum Schluss gekommen, dass in der Arduino-KNX-Welt das eine oder andere doch einfacher/anders sein müsste/sollte.

Hab mein bisheriges Format über den Haufen geworfen und fast bei 0 angefangen und das eure Format angeschaut, geschaut was man als Benutzer so in der ETS an Daten, Spalten und Tabellen vorfindet und selbst nochmal überlegt...
Die - so finde ich - wichtigen Anforderungen für DIY Bastelprojekte mit dem Arduino sind:

* ein überschaubares Format (ja, ich weiß, ist relativ...) --> KISS
* Community-tauglich was Selber-Bastler und Hilfesuchende betrifft (1-File-Ansatz --> ohne erklärende Worte im Forum postbare Konfig-File)
* möglichst platzsparend im Arduino-Flash, d.h. möglichst nur einen Mechanismus zum Schreiben der Parameter
* Trennen der Gerätedefinition von den Geräteeinstellungen, wenn auch nur strukturell
* Möglichst viele Freiheiten für den Geräteentwickler wie er nun was wo ablegt um eine möglichst große akzeptanz zu erreichen. Auch hier wieder: KISS Prinzip


Daraus habe ich folgendes Format - welches nicht wirklich kompatibel zu dem hier diskutierten ist - abgeleitet (KOs und Parameter sind nicht vollständig und dienen nur der Erklärung des Formats. Die vielen erklärenden Kommentar-Tags machen es ohne Syntax-Highlighting leider nicht wirklich gut lesbar):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<anx version="1.0"> <!-- anx = Arduino KNX -->

    <!--
        Eindeutige Gerätetyp-Identifikation

        manufacturerid: 2 byte HEX 
        deviceid: 2 byte HEX
        revision: 1 byte HEX
    -->
    <device manufacturerid="0x0001" deviceid="0x0001" revision="0x01">
        <!-- Lesbarer Name des Herstellers, Optional -->
        <manufacturer>root1.de</manufacturer>
    
        <!-- Lesbarer Gerätename, Optional -->
        <name>6CH KNX PWM LED Controller</name>  
    
        <!-- 
            Beschreibt die KOs (informell für den Anwender) und 
            legt den Speicherort der zugehörigen GAs fest
        -->
        <commobjects>
            <commobject id="0" object="10" property="1"> <!-- id=KO-Nummer als Integer; object+property = Speicherort der GA im Device-->
                <name>Schalten Ein/Aus Kanal A</name> <!-- In Anlehung an die "Kommunikationsobjecte" Spalte unter "Geräte" in der ETS -->
                <function>Schalten</function>
                <length>1bit</length> <!-- In Anlehnung an ETS: 1bit, 4bit, 1byte, 2byte, 3byte, ... rein informeller Natur, damit der Anwender weiß wie das KO kompatibel ist -->
                <dpt>1</dpt> <!-- In Anlehnung an ETS: 1,2,3,4,5,6,7,8,9,... rein informeller Natur, damit der Anwender weiß wie das KO kompatibel ist -->
            </commObject>
            <commobject id="1" object="10" property="2">
                <name>Dimmkontrolle Kanal A</name>
                <function>Relativ Dimmen</function>
                <length>4bit</length>
                <dpt>3</dpt>
            </commObject>
            <commobject id="2" object="10" property="3">
                <name>Absolutwert Kanal A</name>
                <function>Helligkeitswert</function>
                <length>1byte</length>
                <dpt>5</dpt>
            </commObject>
        </commobjects>
        
        <!--
            Parameter des Geräts, ggf. gruppiert.
            Legt deren Speicherort fest und zeigt Default-Werte
        -->
        <parameters>
            <!-- 
                <group> = Gruppierung der Parameter, z.B. in einem 
                Parameter-"Baum" in der Anwendung. Könnte man theoretisch auch 
                ineinander verschachteln: "group in group"
            -->
            <group name="Allgemein"> 
                
                <!-- options = mit '|' getrennte key=value Liste. Nutzbar für DropDown Listen etc. -->
                <parameter id="0" object="11" property="1">
                    <description>Verhalten nach Busspannungsausfall</description>
                    <value type="uint8" default="2" options="0=Aus|1=An|2=letzter Wert|3=Helligkeitswert"/>
                </parameter>
                
                <parameter id="1" object="11" property="2">
                    <description>Helligkeitswert nach Busspannungsausfall (0=0%, 255=100%)</description>
                    <value type="uint8" default="127" min="0" max="100"/>
                </parameter>
                
                <parameter id="2" object="11" property="3">
                    <description>Verhalten nach Busspannungswiederkehr</description>
                    <value type="uint8" default="2" options="0=Aus|1=An|2=letzter Wert|3=Helligkeitswert"/>
                </parameter>
            
                <parameter id="3" object="11" property="4">
                    <description>Helligkeitswert nach Busspannungswiederkehr (0=0%, 255=100%)</description>
                    <value type="uint8" default="127" mapping="0|100"/>
                </parameter>
            
            </group>
            
            <group name="Kanal A">
            </group>
            <group name="Kanal B">
            </group>
            <group name="Kanal C">
            </group>
            <group name="Kanal D">
            </group>
            <group name="Kanal E">
            </group>
            <group name="Kanal F">
            </group>
        </parameters>
    </device>
    
    <!-- 
        Dieser Abschnitt ist im Ursprungsfile des "Herstellers" nicht vorhanden 
        und wird bei Bedarf von der Anwendung nach den Benutzereingaben geschrieben.
        Alternativ kann dieser Abschnitt auch in einem separaten File, ohne 
        zugehöriges <device> Tag stehen. Wichtig ist dann nur, dass die Anwendung 
        die "Hersteller-File" (enthält den <device> Tag) kennt und die IDs passen:
        
        'manufacturerid', 'deviceid' und 'revision' Attribut des <configuration> Tags müssen zu 
        selbigen im <device> Tag passen
    -->
    <configuration manufacturerid="0x0001" deviceid="0x0001" revision="0x01">
        <pa>1/1/1</pa>
        <!-- 'id' referenziert obige KOs. Alles andere sind Benutzerdaten -->
        <commobjects>
            <commobject id="0" ga="1.1.1" userdescription="Schalten - LED Beleuchtung Eingangsbereich" flags="0x00"/> <!-- Optional könnte man hier noch KNX Flags mit dazu nehmen, z.B. als Hex-Wert -->
            <commobject id="1" ga="1.1.2" userdescription="Dimmen - LED Beleuchtung Eingangsbereich"/>
            <commobject id="3" ga="1.1.3" userdescription="Wert setzen - LED Beleuchtung Eingangsbereich" />
        </commobjects>
        <!-- 'id' referenziert obige Parameter. Alles andere sind Benutzerdaten -->
        <parameters>
            <parameter id="0" value="2"/>
            <parameter id="1" value="127"/>
            <parameter id="2" value="2"/>
            <parameter id="3" value="127"/>
        </parameters>
    </configuration>
</anx>

Das einzige was dieses Format dem Geräteentwickler wirklich vorschreibt ist, dass alles über Properties läuft.
Denn arg viel mehr wie "writeAddress" (und ein bisschen drum herum so dass man auch aus der ETS die Adresse setzen könnte) und "writeProperty" wird das Tool nicht auf den Bus senden.
Damit ist das ganze wohl nicht BCU2 kompatibel, aber das muss es auch nicht unbedingt. Man ist völlig frei was das Belegen der Properties betrifft.
Wird sicher noch den einen oder anderen Gerätespezifischen Parameter geben der hilfreich sein wird. Aber als Gerüst ist das Format sicher tauglich und erweiterbar.



Ich tauche dann mal wieder ab und schau dass das ganze funktioniert....

[l0wside]

Die - so finde ich - wichtigen Anforderungen für DIY Bastelprojekte mit dem Arduino sind:

* ein überschaubares Format (ja, ich weiß, ist relativ...) --> KISS
* Community-tauglich was Selber-Bastler und Hilfesuchende betrifft (1-File-Ansatz --> ohne erklärende Worte im Forum postbare Konfig-File)
* möglichst platzsparend im Arduino-Flash, d.h. möglichst nur einen Mechanismus zum Schreiben der Parameter
* Trennen der Gerätedefinition von den Geräteeinstellungen, wenn auch nur strukturell
* Möglichst viele Freiheiten für den Geräteentwickler wie er nun was wo ablegt um eine möglichst große akzeptanz zu erreichen. Auch hier wieder: KISS Prinzip

So weit gehe ich d´accord.

Bei deinem Format sehe ich den grundlegenden Unterschied zu unserem noch nicht. Mit folgendem Mapping:
anx -> device-description
parameters -> common-properties
group -> object
parameter -> property
int8 -> UNSIGNED_CHAR

sind die beiden Formate fast identisch. Die Manufacturer ID u.ä. muss ich im Qt-Tool sowieso noch nachrüsten. Wo die "Options" landen, ist noch zu diskutieren - ich möchte sie gerne zentral haben, um Redundanzen zu vermeiden, das Wort "Code-Duplizität" war von dir...

Dass du dir Memory Write sparen willst, kann ich nachvollziehen. Meine Applikation auf Device-Seite unterstützt auch das Schreiben der GAs per Property (statt per MemoryWrite). Das sieht dann z.B. so aus für das KO 10:
Property 10/0, Index 0: Flags
Property 10/0, Index 1: Erste GA
Property 10/0, Index 2: Zweite GA
...

Angebot:

• Wir vereinheitlichen auf Basis der o.g. Punkte die Beschreibungsdateien.
• Die geschriebenen Daten speichert jeder nach seinem Gusto, hier kommen wir gefühlt nicht zusammen
• Wir überlegen uns eine Form, wie in der Beschreibungsdatei dokumentiert wird, ob die GAs nun per PropertyWrite oder per MemoryWrite übertragen werden
• Ich implementiere im Qt-Tool noch das GA-Schreiben per Property-Interface

Auf diese Weise hat jeder dann wenigstens die Wahl, welches Tool er einsetzt. Dann haben wir für Linux und Windows eine Lösung.


Max

[tuxedo]

So weit gehe ich d´accord.

Bei deinem Format sehe ich den grundlegenden Unterschied zu unserem noch nicht. Mit folgendem Mapping:
anx -> device-description
parameters -> common-properties
group -> object
parameter -> property
int8 -> UNSIGNED_CHAR

sind die beiden Formate fast identisch.

Auch wenn das eine oder andere matched: Dein bisheriger Format-Vorschlag ist ein wenig fülliger und - so finde ich subjektiv - schwerer zu lesen.
Ich hab mir Mühe gegeben es wirklich auf das wesentliche zu reduzieren.

Die Manufacturer ID u.ä. muss ich im Qt-Tool sowieso noch nachrüsten. Wo die "Options" landen, ist noch zu diskutieren - ich möchte sie gerne zentral haben, um Redundanzen zu vermeiden, das Wort "Code-Duplizität" war von dir...

Die Options auslagern: Hatte ich auch darüber nachgedacht. Aber dann muss man an der Parameter-Stelle nochmal auf die jweilige Option referenzieren. Das macht es nicht wirklich leserlicher.
Wenn es jetzt mehr als ein halbes Dutzend Stellen gäbe wo mehr als ein Dutzend Optionen verwendet werden.. Ja, dann würde es vllt. Sinn machen Redundante Optionen zu verhindern.
Aber so (denke großartige Optionen-Redundanzen wird es eher selten geben) sehe ich noch nicht den wirklichen Vorteil ohne die Lesbarkeit (auch ohne Programm) einzuschränken.

Dass du dir Memory Write sparen willst, kann ich nachvollziehen. Meine Applikation auf Device-Seite unterstützt auch das Schreiben der GAs per Property (statt per MemoryWrite). Das sieht dann z.B. so aus für das KO 10:
Property 10/0, Index 0: Flags
Property 10/0, Index 1: Erste GA
Property 10/0, Index 2: Zweite GA
...

Angebot:

1. Wir vereinheitlichen auf Basis der o.g. Punkte die Beschreibungsdateien.
2. Die geschriebenen Daten speichert jeder nach seinem Gusto, hier kommen wir gefühlt nicht zusammen
3. Wir überlegen uns eine Form, wie in der Beschreibungsdatei dokumentiert wird, ob die GAs nun per PropertyWrite oder per MemoryWrite übertragen werden
4. Ich implementiere im Qt-Tool noch das GA-Schreiben per Property-Interface

Kannst du nochmal kurz drauf eingehen warum KO10 auf Objekt10 steht? Wäre das "Pflicht" oder eine "Konvention" die man zur Not auch im XML anders belegen kann? Mein Ansatz würde das unterstützen. Bei all der Informationsflut bin ich mir gerade nicht mehr sicher ob das bei dir auch so wäre.

Zu 1)
Kannst du hierzu mal einen konkreten Vorschlag machen?
Meine Benennung der Nodes und Optionen habe ich nach Möglichkeit versucht an die ETS anzulehnen, so dass man zur Not auch ohne GUI und Entwickler-Wissen die Einträge in der File "wiedererkennt".
Würde mich freuen wenn wir die Benennung in diese Richtung bekämen.

Zu 2)
Ich warte noch auf dein Format.... Das aus dem Code heraus zu lesen ist etwas umständlich. Deshalb der Vorschlag von mir. Dank der IDs für KO und Parameter, ist der Abschnitt kurz und übersichtlich und kann im gleichen File, oder auch separat gespeichert werden.
Aber vielleicht kannst du dich aufraffen und deine Lösung beschreiben?

Zu 3)
In Anlehnung an mein Format hier ein Vorschlag: Attribute "object" und "property" weglassen, und dafür deinen Abschnitt

<tables>
<addr-table entries="4" address="0xD000"/>
<assoc-table entries="8" address="0xE000"/>
</tables>

noch in <commobjects> stecken. Entweder gibt es object/property, dann wird per PropertyWrite geschrieben, oder es gibt tables, dann wird per memwrite geschrieben.

Auf diese Weise hat jeder dann wenigstens die Wahl, welches Tool er einsetzt. Dann haben wir für Linux und Windows eine Lösung.

;-) Mein Tool läuft auf Windows und Linux, und Mac.

[tuxedo]

1) Wenn du oben schon den "dpt" angibst, wozu dann unten nochmal den type?! Definiert der dpt nicht schon eindeutig den Typ?
Nein, hier ist der KNX-Standard m.E. nicht ganz optimal. Siehe ftp://85.214.247.170/Download/Datapoint.pdf und die immer hilfreiche CHM-Datei von Martin Kögler.

Leider bist du auf meine Nachfrage wieso das nicht ganz optimal ist (noch) nicht eingegangen. Deshalb hier nochmal explizit danach gefragt.

Bin die DPTs 1-16 durchgegangen (dürfte wohl das allermeiste abdecken) und habe nichts "nicht ganz optimales" gefunden. In der BCU2Help hab ich auch nicht wirklich was dazu gefunden.

Kannst du das bitte genauer erläutern was genau nicht optimal daran ist?

Gruß
Alex