SCO Objekt - 6 byte - Definition

[modermatt]

Ich habe die Object-Beschreibung einmal mit einigen von mir aufgezeichneten Telegrammen verglichen und "Diskrepanzen" festgestellt. Z.B. Bei einem Fahrbefehl c=1 sollten in p1 eigentlich nur die Bits 1&0 eine Bedeutung haben. Bei mir finden sich aber auch Infos im oberen Nibble von p1. Habe bei Griesser schon angefragt und werde das Ergebnis ggf. hier posten.

Ich möchte das 6 Byte Objekt ebenfalls in einem Script decodieren. Dazu habe ich mal ein Telegramm genommen und versucht anhand der Datenpunkbeschreibung dies zu decodieren. Jedoch komm ich nicht dahinter, wie das genau aufgebaut ist.
zb.

Sektor "36" "Prioritätsbefehl" "Fahrbefehl: Beschattungsposition P4"

ist in HEX: 47 04 63 04 00 00
und in Binär: 1000111 00000100 01100011 00000100 00000000 00000000

1000111	00000100	01100011	00000100	00000000	00000000
sektor	command	P1	P2	P3	P4
			= Position 4

Das einzige was korrekt ist, ist P2 welches die Beschattungsposition ist. = Position 4
P1 müsste Fixposition Pn anfahren sein und somit den Wert 3 haben.
Command (nur 6bit) müsste den Wert 1 haben damit es ein Fahrbefehl ist.
Sektor (10bit) dementsprechend den Wert 36.

Weiss jemand, wie man dies richtig decodiert?

[wmichel]

Hi Modermatt,

die Dekodierung ist eingentlich relativ einfach:
Sektor: 0x47
Command: 1 -> motion
P1: 3 -> Move to position P2 (Was die 6 im obern Nibble des Octets bedeuten ist mir unklar und geht aus der Doku auch nicht hervor)
P2: 4 -> position

Hoffe das hilft. W

6bo_format.JPG

[modermatt]

Hi wmichel

Sektor: 0x47

Aber wie kommen die von 0x47 auf den Sektor 36 ?

(Was die 6 im obern Nibble des Octets bedeuten ist mir unklar und geht aus der Doku auch nicht hervor

Ja das ist mir auch nicht klar.


Ich habe ein Gebäude, mit 36 Sektoren, wo ich den Status der Beschattung (entweder P2 oder oben) jedes Sektors einzeln an die HLK Steuerung weitergeben muss. Da habe ich mir gedacht, dies so abzufangen und auszuwerten.

[wmichel]

Sind das wirklich Sektoren oder nur Storen/Jalousien?
Welche Storen etc. zu welchem Sektor gehören und wie diese Sektoren nummeriert sind legt meines Wissens nach der Programmierer fest der die Konfiguration für die Steuerung derfiniert. Z.B. Ich habe hier bei mir 33 Storen aber nur zwei Sektoren 0x9 & 0x4. Vielleicht solltest Du Deine Anlage etwas genauer beschreiben - physisch - damit wir hier weitekommen.

[modermatt]

Nein ich muss mich sogar korrigieren, ich habe 38 Sektoren, das ganze auf 2x FMX-32IH. Die Sektoren sind auf verschiedene Fassadenseiten verteilt (ziemlich komplizierte Anlage da mehrere Trakte). Pro Sektor habe ich von 10 - 40 Aktoren JAX am laufen welche dann die Jalousien fahren. Das FMX wird über das FlexTool von Griesser konfiguriert. Dort sind alle Sektoren von 1-38 durchnummeriert.
Mir stellt sich grundsätzlich die Frage, mit dem GPA Analyse Tool von Griesser werden die Monitoring Einträge ja decodiert. Und daraus folgt aus
0x47 der Sektor 36
und aus
0x2D der Sektor 23
0x33 der Sektor 26

Wobei 0x47, dezimal ja 71 wäre
0x2D --> 45
0x33 --> 51

Griesser Objekt 6-Byte.png

[daniel2037]

Ich weiss, das Thema ist uralt, ich wollte dennoch die Informationen nicht vorenthalten, in der Hoffnung, sofern jemand in Zukunft nochmal auf dieses Thema stösst, damit geholfen ist.

Für die Sektor Dekodierung ist relevant, wo das erste Bit gesetzt ist (von rechts nach links), denn damit wird entschieden, ob es sich um einen einzelnen Sektor oder um eine Gruppe von Sektoren handeln (2er, 4er, 8er, etc. Gruppen).

Sofern es sich nur um einen einzelnen Sektor handelt, muss man nur die Zahl um einen Bit nach rechts schieben und hat schon den Sektor.

Bei einer Sektorgruppe, ist es etwas komplizierter. Man muss zuerst rausfinden um was für eine Gruppengrösse es sich handelt (wie man das z.B. im Griesser DPT PDF sieht). Dann entsprechend von dort die Zahl nach rechts schieben und mit der Gruppengrösse multiplizieren und mit Eins addieren, damit erhält man den ersten Sektor.

Ich habe das ganze mit generierten Testdaten aufs KNX/IP gebracht, mit Griesser PA ETS App dekodiert und von da aus geprüft.

Ich habe das ganze in Elixir programmiert:

def decode_sector(a) do
  cond do
    # Reserved
    a == 0 ->
      :reserved

    # Ends with ...1 (Individual sectors)
    Bitwise.band(a, 0x01) == 1 ->
      Bitwise.bsr(a, 1) + 1

    # Ends with ...1xx (xx = any amount of 0) (Groups of y size)
    true ->
      group_size = Bitwise.band(a, -a)
      shift = byte_size(Integer.to_string(group_size, 2))
      base_sector = Bitwise.bsr(a, shift) * group_size

      {base_sector + 1, base_sector + group_size, group_size}
  end
end​

Und mit etwas Fremdhilfe ins Python portiert:

def decode_sector(a):
    if a == 0:
        return "reserved"

    # Check if the least significant bit is 1 (individual sector)
    if a & 0x01 == 1:
        base_sector = a >> 1
        return base_sector + 1

    # Group of sectors
    group_size = a & -a  # Lowest set bit value
    shift = len(bin(group_size)[2:])  # Length of binary string minus '0b' prefix
    base_sector = (a >> shift) * group_size

    return {
        "start": base_sector + 1,
        "end": base_sector + group_size,
        "group_size": group_size
    }​

Zum P1 Byte, welches das obere Nibble gesetzt hat: Dabei handelt es sich um eine Art Priorisierung des Fahrbefehls (z.B. gibt es da Grenzbefehl, Prioritätsbefehl, Sicherheitsbefehl). Was genau das in der Praxis bedeutet, weiss ich (bisher) nicht. Schade, dass es halt einfach nicht in dem hochgeladenen Griesser Dokument dokumentiert ist.

Auch wieder Elixir:

case Bitwise.bsr(p1, 4) do
    0 -> :grenzbefehl
    1 -> :grenzbefehl
    2 -> :automatikbefehl
    3 -> :automatikbefehl
    6 -> :prioritaetsbefehl
    7 -> :prioritaetsbefehl
    8 -> :warnbefehl
    9 -> :warnbefehl
  10 -> :sicherheitsbefehl
  11 -> :sicherheitsbefehl
  12 -> :gefahrenbefehl
  13 -> :gefahrenbefehl
  _else -> :unbekannt
end​