Commandline-Tool für "KNX mit ETS"-Projekt

[mumpf]

sicher? Ohne Angabe der knxprod ?

Ja... wenn Du nur -o angibst, dann hast Du gar kein Input-File. Wenn Du kein -o angibst, dann wird von Namensgleichheit ausgegangen. Kürzeste Form (eben nochmal ausprobiert):

MultiplyChannels create Sensormodul

liest die Sensormodul.xml im gleichen Verzeichnis und erzeugt Sensormodul.knxprod und Sensormodul.h im gleichen Verzeichnis.

Ich hatte aber trotzdem was falsches geschrieben, denn ich hatte im Release nachgeschaut, bei dem kein debug erzeugt wird.
Mein Aufruf beim entwickeln ist

MultiplyChannels create --Debug src/Sensormodul

hier wird alles im Verzeichnis ./src erzeugt und auch ein Sensormodul.debug.xml geschrieben.

Weitere Infos nach dem Mittagessen .

Gruß, Waldemar

[Ing-Dom]

Ja... wenn Du nur -o angibst, dann hast Du gar kein Input-File. Wenn Du kein -o angibst, dann wird von Namensgleichheit ausgegangen. Kürzeste Form (eben nochmal ausprobiert):

ok... merkwürdigerweise funktioniert

MultiplyChannels.exe create -o SNS-8xTH.xml -d SNS-8xTH.knxprod

Obwohl ich anscheinend xml und knxprod vertauscht habe, funktioniert es trotzdem wie es soll.

Nun gut.

Ich mach jetzt

MultiplyChannels.exe create -d SNS-8xTH

und gut is.

Soweit ich weiß braucht auch jeder Parameterblock eine eindeutige ID. Auch wenn sie in anderen Channels sind, darf nicht zwei mal die gleiche ID vorkommen.

Genau deswegen hab ich ja dem Parameterblock, der im Sensorchannel-Template vorkommt, noch ein "SNS" verpasst.
So dass es sagen wir ein PB-1 und ein PB-2 im allgemeinen Part gibt und dann noch PB-SNS-1[...8] für die Channels.

Das war wohl aber unnötig, den das Tool hat da mehr intelligenz beim ersetzen des %C% wie es aussieht.
Gleich mal testen ob das bei den Channels auch so ist - nein ist es nicht.
Bei PB und PS scheint es so, als müsse man gar nichts tun, die nummeriert das Tool ganz automatisch durch. Richtig?

[mumpf]

So, Mittagessen ist vorbei...

Obwohl ich anscheinend xml und knxprod vertauscht habe, funktioniert es trotzdem wie es soll.

Ja, die Endungen hab ich mehr oder minder festgelegt (sollte man vielleicht nicht machen, hab ich aber): Ich erwarte als input ein .xml und erzeuge ein .knxprod.

Wenn das Format aber zwingend _P-<Zahl> lautet muss ich da wohl mit Magicnumbers arbeiten.

Ein Tipp: Lege keine Semantik in die IDs, das macht schon die ETS zu genüge . Lass an den Stellen eine Zahl stehen, an denen in standard-knxprods eine Zahl steht. Irgendwo in der ETS fällt es Dir sonst auf die Füße... nachdem ich das dann festgestellt hatte, geh ich auch in meinem Tool davon aus, dass da ne Zahl steht. Falls nicht, mag es auch bei mir schon potentiell parser-Errors geben.

Aber bei <ParameterRef Id ist es strenger - hier muss es _P-<ZAHL>_R-<ZAHL> heißen.

Bestes Pattern (bei dem man auch über verschiedene Includes nicht durcheinander kommt), dass ich für mich gefunden habe: _P-<Zahl_N>_R-<Zahl_N><Zahl_M>, wobei Zahl_M meist nur einstellig ist. Bei den ComObjectRef ist das noch wichtiger (_O-<Zahl_N>_R-<Zahl_N><Zahl_M>), da gibt es potentiell viele <Zahl_M> wegen unterschiedlicher DPT.
Beispiel:

              <Parameter Id="M-00FA_A-0001-01-0000_UP-160" Name="SensorDevice" .../>
              <ParameterRef Id="M-00FA_A-0001-01-0000_UP-160_R-1601" RefId="M-00FA_A-0001-01-0000_UP-160" />

oder im template:

    <ComObject Id="M-00FA_A-0001-01-0000_O-%K2%" Name="KOf%C%O" Text="Ausgang" Number="%K2%" FunctionText="Logik %C%, Ausgang" ... />
    <ComObjectRef Id="M-00FA_A-0001-01-0000_O-%K2%_R-%K2%01" RefId="M-00FA_A-0001-01-0000_O-%K2%" Text="{{0:Ausgang}}"   ... />
    <ComObjectRef Id="M-00FA_A-0001-01-0000_O-%K2%_R2%K2%02" RefId="M-00FA_A-0001-01-0000_O-%K2%" Text="{{0:Ausgang}}"   ... />
    <ComObjectRef Id="M-00FA_A-0001-01-0000_O-%K2%_R-%K2%03" RefId="M-00FA_A-0001-01-0000_O-%K2%" Text="{{0:Ausgang}}"   ... />

Bei PB und PS scheint es so, als müsse man gar nichts tun, die nummeriert das Tool ganz automatisch durch. Richtig?

Ja. Bei PB weiß ich das sicher, bei PS bin ich mir gerade nicht sicher, aber wenn Du das festgestellt hast, dann ist das so.
Hintergrund: Ich wollte mir die Arbeit leicht machen, und da ich auch den include-Gedanken verfolge, bin ich nicht daran interessiert, manuell in vielen Files umzunummerieren. Deswegen werden IDs, die nicht von woanders her referenziert werden, automatisch durchnummeriert (nach dem include). Da muss nur einfach irgendeine Nummer stehen. Bei Tabellen innerhalb von PB mache ich das auch noch.

Gruß, Waldemar

[Ing-Dom]

Bestes Pattern (bei dem man auch über verschiedene Includes nicht durcheinander kommt), dass ich für mich gefunden habe: _P-<Zahl_N>_R-<Zahl_N><Zahl_M>, wobei Zahl_M meist nur einstellig ist. Bei den ComObjectRef ist das noch wichtiger (_O-<Zahl_N>_R-<Zahl_N><Zahl_M>), da gibt es potentiell viele <Zahl_M> wegen unterschiedlicher DPT.

Hast du dann eine Lösung für das Problem doppelter IDs wenn man zwei unterschiedliche Channel-Templates in einem Gerät verwendet?

Bei deinem Sensormodul dürfte das bei den Paramtern mit Offsets gelöst sein, wenn ich das richtig verstehe:

WireGateway "share": Offset 500
Logikmodul "share": Offset 0
Sensormodul "share": Offset: 100

WireGateway "templ": 100<CHNO><01-99> also 100101 bis 1003099
Logikmodul "templ": <CHNO><001-999> also 1001 bis 80999


klar, das funktioniert. Wenn aber das Ziel ist, die verschiedenen Channels ohne viele aufhebens zu rekombinieren, dann müsste man sich wohl was besseres überlegen.
Wie groß dürfen denn die Zahlen nach dem _P-, _UP-, _O- etc... werden? anscheinend mehr als 16bit, sonst würde 1003099 nicht mehr passen.
32bit ?


Weiterhin sehe ich auch keine Lösung wie man mit mehr als einem "channel" typ arbeiten will.
wenn in beiden "templ" ein

<Channel Id="M-00FA_A-0000-00-0000_CH-%C%" Name="Sensor_%C%" Number="%C%" Text="Sensor %C%">

drin ist. Gut, bei den IDs könnte man wieder mit Offsets arbeiten.
Für was ist eigentlich "Number" genau gut?

und könntest du dir ein Literal vorstellen das die Channelnummer als A-Z ausgibt (1=A, 2=B, ...) damit man sowas wie "Sensor A", "Sensor B", ... realisieren kann?

[mumpf]

Hast du dann eine Lösung für das Problem doppelter IDs wenn man zwei unterschiedliche Channel-Templates in einem Gerät verwendet?

Parameter kann ich leider nicht selber "umnumerieren", da es da ja externe Referenzen gibt (ich hab das sogar mal probiert, aber das führt sehr schnell zu nicht mehr nachvollziehbaren Fehlern). Deswegen hab ich mich auf Nummernbereiche eingeschossen. Bei Parametern ist das nicht kritisch, die dürfen in dem <ZAHL>-Bereich groß werden, ich bin bisher nicht an Grenzen gestoßen - hab aber auch noch nicht explizit nach Grenzen gesucht.

WireGateway "share": Offset 500
Logikmodul "share": Offset 0
Sensormodul "share": Offset: 100

Die Offsets sind für KO-Nummern, Parameternummern ergeben sich wirklich nur durch Stringersetzung:

• Ich habe in einem Template-Include pro Kanal 20 Parameter 01-20.
  • Meine ID wäre so was wie _P-1%CCC%01 für Parameter 1
  • _P-1%CCC%02 für Parameter 2
  • bis _P-1%CCC%20 für Parameter 20
• In einem weiteren Template-Include pro Kanal 10 Parameter 0-9.
  • Hier mach ich z.B. _P-20%CCC%0 für P1
  • bis _P-20%CCC%9 für P10

Es geht nur um Kollisionsfreiheit. Ich kann jeden Kanal bis zu 999 mal "multiplizieren", ist kein Problem. Beim ersten include 2 mal und beim 2. 3 mal multipliziert ergibt sich:

_P-100101
_P-100102
_P-100103
...
_P-100119
_P-100120
_P-100201
_P-100202
_P-100203
...
_P-100219
_P-100220
_P-200010
_P-200011
...
_P-200018
_P-200019
_P-200020
_P-200021
...
_P-200028
_P-200029
_P-200030
_P-200031
...
_P-200038
_P-200039

Ist nur eine Möglichkeit, man kann sich beliebiges ausdenken, ist reine Stringersetzung, es geht nur um Eindeutigkeit. Das ist der Grund, warum ich %CCC% eingeführt habe, damit man was mit führenden Nullen bekommt und es so auch mitten in den ID einbauen kann.

Wenn aber das Ziel ist, die verschiedenen Channels ohne viele aufhebens zu rekombinieren, dann müsste man sich wohl was besseres überlegen.

Das kann schon sein, ich habe an multiply-channels immer weiter gearbeitet, aber natürlich nur im Rahmen dessen, was ich brauchte. An sich ist das, was die ETS jetzt mit Vervielfältigung von Kanälen bietet, auch besser - nur habe ich noch nicht darauf umgestellt. Und das ist auch eine große Änderung, deswegen werde ich da nicht kurzfristig rangehen. Wenn man aber keine Includes braucht, könnte man das mit ETS-Mitteln wahrscheinlich eleganter lösen.

Weiterhin sehe ich auch keine Lösung wie man mit mehr als einem "channel" typ arbeiten will.
wenn in beiden "templ" ein Code:

<Channel Id="M-00FA_A-0000-00-0000_CH-%C%" Name="Sensor_%C%" Number="%C%" Text="Sensor %C%">
drin ist. Gut, bei den IDs könnte man wieder mit Offsets arbeiten.

IMHO falscher Ansatz. Du hast einen Channel, in dem Du per per <choose> verschiedene Inhalte (abhängig vom Typ) einbringst. Deren Definition können dann in verschiedenen Templates stehen.

Für was ist eigentlich "Number" genau gut?

Für die ETS. Die nummerieren wohl die Channels durch.

Ich verwende die Channels derzeit eher zum Trennen der Funktionsbereiche, also Sensoreinstellungen, Logikeinstellungen, 1-Wire-Einstellungen. Innerhalb der Channels verwende ich dann geschachtelte Parameterblöcke.

und könntest du dir ein Literal vorstellen das die Channelnummer als A-Z ausgibt (1=A, 2=B, ...) damit man sowas wie "Sensor A", "Sensor B", ... realisieren kann?

Ja... soll ich mal %CT% für ChannelText machen? Da ich immer bis 999-fach multiplizieren kann, wie soll ich nach der 26 weiter zählen? AA, AB, AC usw, also einfach ne Zahl zur Basis 26?

Gruß, Waldemar

[Ing-Dom]

IMHO falscher Ansatz. Du hast einen Channel, in dem Du per per <choose> verschiedene Inhalte (abhängig vom Typ) einbringst. Deren Definition können dann in verschiedenen Templates stehen.

Ne, das verstehst du falsch.
Ich meine z.B. ein Gerät mit sagen wir:

3x Sensorchannel
8x Binäreingangchannel
8x Tasterchannel
8x LEDchannel

natürlich würde ich da mit einem Aktivieren der verschiedenen Kanäle arbeiten, damit es übersichtlich bleibt wenn man nicht alles braucht.
Aber in Summe hätte ich ja dann trotzdem 27 channels Sensor A-C, Binäreingang A-H, .... (jeder channel in einem <choose>.

Das würde man ja mit 4 <mc:includes> lösen.
Verwendet man jetzt z.B. (in je einer eigenen tmpl.xml)

<Channel Id="M-00FA_A-0000-00-0000_CH-100%CCC%" Name="Sensor_%C%" Number="%C%" Text="Sensor %CT%">

<Channel Id="M-00FA_A-0000-00-0000_CH-101%CCC%" Name="BinInput_%C%" Number="%C%" Text="Eingang %CT%">

<Channel Id="M-00FA_A-0000-00-0000_CH-102%CCC%" Name="Switch_%C%" Number="%C%" Text="Taste %CT%">

<Channel Id="M-00FA_A-0000-00-0000_CH-103%CCC%" Name="LED_%C%" Number="%C%" Text="LED %CT%">

id wäre jetzt eindeutig, Name auch, der Text passt ebenfalls. Aber bei Number gäbe es entweder Duplikate, oder man müsste es wie bei der ID mit Offsetts lösen (100%CCC% ist ja nichts anderes als ein Offset von 100000).

Ich hab vorhin schnell das das reingehackt: A, B, ..., Z, AA, AB, ...AZ, BA, BB, ... ZZZ

Auch als %Z%, %ZZ% oder %ZZZ% wobei ich glaube ZZZ ist way to much und eine einstellige Variante mit "wrap around" braucht man auch nicht. Also wäre %CT% auch brauchbar und lLen dann fix auf 2.

string ReplaceChannelTemplate(string iValue, int iChannel) {
string lResult = iValue;
Match lMatch = Regex.Match(iValue, @"%(C{1,3})%");
if (lMatch.Captures.Count > 0) {
int lLen = lMatch.Groups[1].Value.Length;
string lFormat = string.Format("D{0}", lLen);
lResult = iValue.Replace(lMatch.Value, iChannel.ToString(lFormat));
}

lMatch = Regex.Match(lResult, @"%(Z{1,3})%");
if (lMatch.Captures.Count > 0)
{
int lLen = lMatch.Groups[1].Value.Length;
string channelName = "";
int temp_Channel = iChannel-1;
for (int i = 0; i < lLen; i++) {
if(temp_Channel >= 0) channelName = Convert.ToChar((temp_Channel) % 26 + 65) + channelName;
temp_Channel /= 26;
temp_Channel--;
}
lResult = iValue.Replace(lMatch.Value, channelName);
}

return lResult;
}

[thewhobox]

dann trotzdem 27 channels Sensor A-C

Du könntest doch auch die Channels für die Überfunktion machen und danach dann Parameterblöcke verschachteln:

- Sensoren
  - Sensor A
    - EInstellungen etc...
  - Sensor B
    - Einstellungen etc
- Binäreingänge
  - Binäreingang A
    - Parameter xyz
  - Binäreingang B
    - Parameter xyz

Man kann ja mehrere Parameterblöcke nochmal in einem Parameterblock einfügen.

[mumpf]

Hi,

Ne, das verstehst du falsch.

Ok, ich denke, jetzt hab ich es verstanden.

Was mir nicht klar ist: Warum willst Du die Channel vervielfachen?

Bei mir würde Dein Beispiel so aussehen:

Sensoren (Channel):
- Sensor1-3 (je 1 Parameterblock)
Binäreingänge (Channel):
- Binäreingang 1-8 (je 1 Parameterblock)
Taster (Channel):
- Taster 1-8 (je 1 Parameterblock)
LED (Channel):
- LED 1-8 (je 1 Parameterblock)

Also 4 Channel (die nicht vervielfacht werden) und alles andere in Templates in Parameterblöcken, die ja automatisch durchnummeriert werden.

Gibt es denn irgendeinen Grund, warum das Channel sein sollen?

Gruß, Waldemar

P.S.: thewhobox: Mike, 2 Dumme ein Gedanke

[Ing-Dom]

Guten Morgen!

Du könntest doch auch die Channels für die Überfunktion machen und danach dann Parameterblöcke verschachteln:

Sensoren (Channel):
- Sensor1-3 (je 1 Parameterblock)
Binäreingänge (Channel):
- Binäreingang 1-8 (je 1 Parameterblock)
Taster (Channel):
- Taster 1-8 (je 1 Parameterblock)
LED (Channel):
- LED 1-8 (je 1 Parameterblock)

Ja das wäre durchaus auch eine Möglichkeit.
Warum ich bisher "anders" gedacht habe liegt einfach daran dass ich noch gar nicht so genau weiß was denn alles möglich ist!

Gibts denn einen relevanten Unterschied zwischen Channels und Parameterblöcken?
Können Parameterblöcke verschachtelt werden? braucht man überhaupt Channels? das obige Beispiel wäre dann ja auch auf der ersten Ebene mit PB umsetzbar.

[thewhobox]

Channels sind glaub einfach nur visuell deutlicher hervorgehoben als Parameterblöcke.

Und ja es können mehrere Parameterblöcke verschachtelt werden (wusste ich auch lange nicht...)
Bisher hab ich aber maximal 2 Verschachtelungen probiert. Keine Ahnung was das maximum ist.

braucht man überhaupt Channels

Du brauchst zwingend immer mindestens einen Channel.
Es gibt aber auch den IndependentChannel. Das besondere bei dem ist, dass er nicht angezeigt wird sondern direkt die Paremeterblöcke anzeigt.
So ist es auch möglich Erst normale Parameterblöcke anzuzeigen (evtl. für Allgemeine Einstellungen) und danach erst mit Channels unterteilt die Sensoren und Eingänge.

mumpf xD Das Schema hab ich glaube aber auch aus deinen Produktdatenbanken.

[mumpf]

Also für mich stellte sich das bisher so dar:

• Es gibt in der ETS einen Tab links im Editierbereich, das ist der ChannelIndependentBlock.
• Jeder neue Tab ist ein Channel, das ist die "Wurzel" eines Tab-Baums, dessen Knoten ParameterBlöcke sind.
• ParameterBlöcke können geschachtelt werden und ergeben neue Kinder.

Ich bin bisher davon ausgegangen, dass jeder Channel im XML explizit definiert wird, weil es so was wie der Main-Tab für eine Gruppe von Objekten ist. Und innerhalb des Channels wird dann vervielfacht, das sind dann die Einzelentitäten der Gruppe.

Channels zu vervielfachen ist eben auch problematisch, da man da auch was für Name, Text und für die Number machen musste, da geht es nicht nur um die ID.

Ob Channels noch eine weitere Bedeutung für die ETS haben, weiß ich nicht.

Gruß, Waldemar

[Ing-Dom]

Und ja es können mehrere Parameterblöcke verschachtelt werden (wusste ich auch lange nicht...)
Bisher hab ich aber maximal 2 Verschachtelungen probiert. Keine Ahnung was das maximum ist.

bist du dir sicher? Ich hab es gerade erfolglos versucht.

Zum einen hab ich in einem Paramterblock (PB) in ChannelIndependentBlock einen weiteren PB eingehängt.
Keiner Fehlermeldung, aber dieser PB wird auch nicht angezeigt.

Dann hab ich versucht direkt in einem Channel Parameter anzulegen - getht auch nicht.
Und auch in einem Channel können zwar mehrere PB sein, aber nur auf der selben Ebene. PB unterhalb von PB geht nicht - wird nicht angezeigt.


Also für mich stellt sich das jetzt so dar, dass ich im ChannelIndependentBlock PB haben kann, die liegen auf der selben Visu-Ebene wie die Channels.
Unterhalb der Channels gibt es aber 1 bis x PBs, und nur dort können Parameter angelegt werden.

[thewhobox]

bist du dir sicher?

Das geht definitiv. Ich habe eine Produktdatenbank von nem anderen DIY-ler hier, der das eingebaut hat.
Und die ETS stellt es genau so dar. (Hab hier grad keine ETS da, sonst könnte ich dir ein Bild davon schicken.
Der Namespace war allerdings "http://knx.org/xml/project/14", weiß nicht welche Version du probiert hast.

Mal ein kleiner Auszug:

<ChannelIndependentBlock>
    <ParameterBlock Id="M-0188_A-0001-01-4649_PB-1" Name="Settings" Text="Settings">
        <ParameterRefRef RefId="M-0188_A-0001-01-4649_P-1_R-1" />
        <ParameterSeparator Id="M-0188_A-0001-01-4649_PS-9" Text="" />
        <ParameterSeparator Id="M-0188_A-0001-01-4649_PS-10" Text="Tag Key" />
        <ParameterRefRef RefId="M-0188_A-0001-01-4649_UP-361_R-361" />
        <ParameterRefRef RefId="M-0188_A-0001-01-4649_UP-362_R-362" />
    </ParameterBlock>
    <choose ParamRefId="M-0188_A-0001-01-4649_P-1_R-1">
        <when test="0">
            <ParameterBlock Id="M-0188_A-0001-01-4649_PB-2" Name="Presets" Text="Presets">
                <ParameterBlock Id="M-0188_A-0001-01-4649_PB-3" Name="Preset A" Text="Preset A">

direkt in einem Channel Parameter anzulegen

Ja, das geht nicht^^
Aber du kannst gleichzeitig einen ChannelIndependentBlock und mehrere Channels haben.

[Ing-Dom]

Der Namespace war allerdings "http://knx.org/xml/project/14", weiß nicht welche Version du probiert hast.

11..
und genau das macht auch den Unterschied. Mit 13 gehts! Hab jetzt 3 Ebenen getestet. Geht.
14 sagt er "no valid .... found". (habe ETS 5.5)

Auch optisch unerscheidet sich ein PB mit "unter"-PBs nicht von einem Channel mit PBs.
Ich sehe daher keinen Grund, warum man die Channels überhaupt verwenden sollte. Man könnte alles in den
ChannelIndependentBlock packen und halt PBs generieren...

[thewhobox]

Es gibt noch einen weiteren Unterschied zwischen Channel und Parameterblock mit untergeordneten parameterblöcken:

Ein Channel kann ja keine Parameter unter sich haben, heißt man kann auch einen Channel selbst nicht auswählen.
Den Parameterblock selbst kann man auch auswählen, auch wenn er unter sich weitere Parameterblöcke hat.

- Channel
  - Parameterblock Text = Sensoren
    - Parameter xyz
    - Parameter zyx
    - ParameterBlock Text = Sensor A
      - Parameter zzz
      - Parameter yyy

So könnte man hier den Parameterblock Sensoren auswählen und Allgemeine Einstellungen zu den Sensoren anzeigen, und unterhalbe für jeden einzelnen Sensor nen eigenen Parameterblock.

Solch eine Konstellation ist mit Channels nicht möglich und oft auch nicht gewünscht, dass der Channel weitere Parameter anzeigen soll.