[wiregate] ETS 5 Gruppenadressen Import wird nicht richtig unterstützt

[alltime]

Hallo,

ich habe ein Problem bei dem Import von (ETS 5) Gruppenadressen entdeckt.
Die Hauptgruppe hat einen Bereich von 0-31.
Wenn ich allerdings versuche eine Hauptgruppe mit der Nummer 20/.../... zu importieren wandelt das Wiregate diese in 4/.../... um.
Das Wiregate zählt also einfach hoch und nimmt nicht die richtige Hauptgruppennummer.
Jetzt kann ich mit einem Plugin nicht auf die Adresse 20/.../... schreiben, da immer gemeldet wird, dass die Adresse nicht existiert.
ets.PNG wiregate.PNG

[Hammer69]

Hallo Tim,

dein Problem ist, dass du dich auserhalb der GA spezifikationen bewegst.

Schau mal hier:
https://redaktion.knx-user-forum.de/...ruppenadresse/

Die Hauptgruppe darf die Nummern 0-15 haben. Deshalb wird dir das WG die GA in eine konforme Form ändern.

Schöne Grüße
Stefan

[alltime]

Hallo Stefan,

ich denke eher, dass die Spezifikation falsch/veraltet ist.
Die ETS (5) und der KNX Bus unterstützen 0-31.

Außerdem macht es keinen Sinn die Gruppenadresse in eine "konforme" Form zu ändern, da es die geänderte Form auf dem Bus überhaupt nicht gibt oder im schlimmeren Fall eine andere Gruppenadresse ist...

Leider kann ich sie auch nicht manuell im Wiregate ändern, da das Wiregate >15 nicht zulässt.

Viele Grüße,
Tim

[Hammer69]

Hallo Tim,
Dann bin ich noch auf einem alten Stand.
Ich halte mich einfach an die Vorgabe 0 bis 15. Denke das WG kennt auch nur diese Regeln und reagiert deshalb so.
Schönen Sonntag
Stefan

[alltime]

Aufbau
Grundsätzlich ist eine Gruppenadresse einfach eine 16-bit-Nummer (1-65535, die 0 ist reserviert).
...

HG 0-31 = 5 Bit
MG 0-7 = 3 Bit
UG 0-255 = 8 Bit
=16 Bit

D.h. die Spezifikation ist irreführend/falsch. 0-31 ist richtig.

[alltime]

Kann es ein Problem geben, wenn ich beim Import die HGs auf 0-31 erweiter?
Ich würde es einfach in der wiregate-lib.pl in der Zeile 232 ändern:

sub checkEIBGA {
    my $ga = shift;
    if ( $ga =~ /^\d+\/\d+\/\d+$/ ) {
        my ( $h, $m, $g ) = split '/', $ga;
        if (    $h > -1
            and $h < 16     <---------------------
            and $m > -1
            and $m < 8
            and $g > -1
            and $g < 256 )
        {
            return 1;
        }
    }
    return 0;
}

oder dass ich die benötigten Gruppenadressen wenigstens manuell ändern kann.
Dafür würde ich in der jqgrid-knxfmt.js die Zeile 43 modifizieren:

function checkknxga(value, colname) {
    var ary = value.split("/");
    var valid = true;
    if (ary.length==3) { 
        // Hauptgruppe=0-15, Mittelgruppe=0-7 und Untergruppe=0-255. Beispiel:
        valid = (!ary[0].match(/^\d{1,2}$/) || (Number(ary[0]) > 15) || (Number(ary[0]) < 0)) ? false : valid;   <----------------------------
        valid = (!ary[1].match(/^\d{1}$/) || (Number(ary[1]) > 7) || (Number(ary[1]) < 0)) ? false : valid;
        valid = (!ary[2].match(/^\d{1,3}$/) || (Number(ary[2]) > 255) || (Number(ary[2]) < 0)) ? false : valid;
    } else {
        valid = false;
    }
    if (valid)
        return [true,""];
    else 
        return [false,"Please enter a valid KNX GA in form HG/MG/GA"];
}

[GLT]

Naja - nicht ganz.
Es war früher nicht "erlaubt" HGs >15 zu verwenden - die Geräte waren allesamt darauf ausgelegt.
Als EIB zu KNX wurde, kamen auch erste Geräte auf den Markt, die HGs >15<=31 "verstanden" - z.B. die Siemens Syncos.

Obwohl z.B. die ETS3 auch solche Adressen handeln konnte, war das für OttoNormalo "gesperrt", damit er nicht in diese "Falle" läuft - heutzutage muß er halt dran denken, ob man das in einem Projekt so machen kann.

[StefanW]

Kann es ein Problem geben, wenn ich beim Import die HGs auf 0-31 erweiter? Ich würde es einfach in der wiregate-lib.pl in der Zeile 232 ändern:

Das ist der Sinn von OS-Software, dass es jeder für sich ändern und anpassen darf. Ob das alles richtig ist und die einzige Stelle kann ich nicht sagen, da wir das - wie GLT richtig ausgeführt hat - auf dem alten Stand gelassen haben, damit es keine Probleme gibt.

Es ist immer ein gewisses Problem, wenn Standards sich ändern aber dabei kompatibel zu Geräten sein sollen, die vor 10 bis 25 Jahren entwickelt wurden.

Ich denke nicht, dass wir das in die Serie überführen werden, Du bist auch der erste der danach fragt.

lg

Stefan

[alltime]

Ja, das ist wirklich schön, dass man selbst in den Code eingreifen kann!
Für mich ist das Problem erst einmal gelöst. Allerdings kann es mir auch passieren, dass meine Änderungen mit einem Update überschrieben werden.

Allerdings würde ich die Entscheidung nochmal überdenken:

1. Es scheint für das Wiregate wichtig zu sein, dass die Gruppenadressen bekannt sind. Man kann in einem Plugin nicht an eine Gruppenadresse senden, die unbekannt ist.
2. Warum muss beim Import (bei manuellem Update ist es ok) überprüft werden, ob die Gruppenadressen in einem bestimmten Zahlenbereich sind? Das ist doch Aufgabe der Ets.
3. Wenn schon überprüft wird, sollte beim Import ein Fehler gemeldet werden und nicht einfach die Gruppenadresse geändert werden. Das geht gar nicht. Mir ist das Problem erst im Plugin-Log aufgefallen.
4. Es gibt bestimmt viele, die neu mit KNX arbeiten, denen die alte Spezifikation unbekannt ist. Wenn die ETS (5) die Zahlenbereiche erlaubt, warum sollte man dann auf die Idee kommen diese nicht zu nutzen.
5. Dass ich der Erste bin, sollte keine Rolle spielen. Die Gruppenadressen sind essentiell.

Viele Grüße,
Tim

[StefanW]

Hallo Tim,

Warum muss beim Import (bei manuellem Update ist es ok) überprüft werden, ob die Gruppenadressen in einem bestimmten Zahlenbereich sind? Das ist doch Aufgabe der Ets.

Es ist üblich, dass Software beim Einlesen von Daten eine Plausibilitätsprüfung vornimmt. Dies passiert hier.

Wenn schon überprüft wird, sollte beim Import ein Fehler gemeldet werden und nicht einfach die Gruppenadresse geändert werden. Das geht gar nicht. Mir ist das Problem erst im Plugin-Log aufgefallen.

Richtig, da hast Du völlig recht. Ich gebe das weiter.

Es gibt bestimmt viele, die neu mit KNX arbeiten, denen die alte Spezifikation unbekannt ist. Wenn die ETS (5) die Zahlenbereiche erlaubt, warum sollte man dann auf die Idee kommen diese nicht zu nutzen.

Es ist ohnehin falsch, wenn ein Produkt intern mit Gruppenadressen arbeitet. Dies ist hier der limitierten Implementation des eibd geschuldet. Konform wäre, dass intern und auf der Oberfläche nur mit Objekten gearbeitet wird. Die Umsetzung auf Gruppenadressen passiert erst im Stack auf Basis der ETS Konfiguration. Im "WireGate New Generation" ist das konform implementiert und dann gibt es solche Probleme auch nicht mehr, weil Standardänderungen sich auf die ETS auswirken und ggfls. auf den Stack für neuere Geräte.

Damit muss nicht an jeder Stelle der Oberfläche geprüft werden.

Dass ich der Erste bin, sollte keine Rolle spielen.

Ich gebe Dir recht für eine ideale Welt. Wir werden prüfen, ob wir das noch in das letzte Update bekommen.


Danke, dass Du uns darauf aufmerksam gemacht hast.

lg

Stefan

[alltime]

Hallo Stefan,

vielen Dank! Entschuldigung, dass ich hier so hartnäckig war. Aber ich bin sonst sehr zufrieden mit dem Wiregate und war etwas enttäuscht, dass mein Problem so schnell abgeschrieben wurde.

LG
Tim

[NetFritz]

Hallo
Bevor ich das WG hatte habe ich für meine Scripts auf einem Ubuntu PC mit Eibd auch interne GA genutzt 100/x/x.
Beim WG ging das nicht mehr, da habe ich alle 100/x/x umgenannt auf 15/x/x.
Nutzt der Gira Homserver für interne Ga nicht auch die 100/x/x ?
Gruß NetFritz