EDV-mathematische Frage [Erledigt]

[Herbert]

...womit man schon nahe einer IP-Adressierung wäre...
...und ich auch noch meinen Kommentar dazu gebe.jan stimmt der Typ 2?

Fall 1: Adresse Typ x.y.z
Zahlenwert := x*2048 + y*256 + z

Fall 2: Adresse Typ x.y
Zahlenwert := x*2048 + y

Dabei gilt:
x kann die Werte 1 bis vermutlich 999 haben.
y und z können die Werte 0 bis vermutlich 999 haben.

Wäre der Typ 2 nicht als
Adresse Typ x..z anzusehen?
Also, Zahlenwert = x*2048+z

So würde das Ganze formeltechnisch besser interpretierbar werden. Wobei die Einschränkungen und Bemerkungen von Tom und Martin zutreffen.

[brandelh]

So wie ich Jans ersten Beitrag lese, kann es sein, dass sowohl Y als auch Z gleich 0 sind.

So, wie ich Jans ersten Beitrag lese, hat er keine Ahnung, welchen Wertebereich die einzelnen Komponenten annehmen können. Es gibt ja auch noch andere Probleme als null in X oder Y. Siehe erste Antworten. Um jedenfalls nach seiner Anleitung einen Wert wieder zu zerlegen, wäre der Code von mir, glaube ich, richtig. Ich sehe auch nicht, inwieweit Deine Zerlegung da helfen sollte.

Natürlich funktioniert dein zuletzt geposteter Code, der inhaltlich identisch mit der ganz oben ist (wobei ich mich ganz oben anfangs verlesen hatte ...) ...
Und er ist in der Wirkung identisch mit meiner bitweisen Bearbeitung. Du ermittelst den höchsten Wert und löschst durch INT die Reste unten.
Dann ziehst du den Höheren glatten Betrag ab, was meiner BAND der Bits von oben entspricht, nach der Teilung wird wieder mit INT die Reste unten abgeschnitten ...
Solange die BITs bei meiner Methode richtig gesetzt sind, ist die Wirkung die Gleiche. Meine String Zerlegung ist einfach und funktionell, eben ein anderer Weg.

Ich bin aber auch gerne bereit zuzugeben, dass mir der richtige Rechenweg nicht mehr eingefallen ist, so schwierige Mathe Aufgaben habe ich schon seit Jahrzehnten nicht mehr zu lösen gehabt
Allerdings musste ich mich bit shift left und bit shift right beschäftigen, daher viel mir das gleich ein

[DelUser01]

Hallo Jan

Du schreibst

Ich habe das Problem, das ich Adressen umrechne in Zahlenwerte. Das klappt natürlich sehr einfach

Wenn Du bzw. Dein Programm das bereits umrechnet sind vermutlich schon umgerechnete Werte da? Dann erübrigt sich ja eigentlich die weitere Überlegung wie man das besser machen könnte, dann bist Du ja schon gebunden...

Oder Planst Du erst die Umrechnung in Zahlenwerte?

[Fischkopp]

Hallo, Jan
Das ist ja ein schönes Zahlenspiel
So wie ich das sehe, hat Tom recht:

Wenn ich Dich richtig verstehe, kommt die Codierung der Adressen aus einem anderen System und muss von Dir so hingenommen werden.
Wenn das so ist, ist die Doku falsch, das System falsch - oder Du gibst eines von beiden falsch wieder. Die skizzierte Anordnung ist nicht eindeutig. Irgendwas fehlt da.

Die Faktoren als 2er-Potenzen machen keinen Sinn, wenn x, y und z derart `beliebig` groß sind, dann ergibt sich keine Eindeutigkeit

Kannst du wirklich nur mit vorhandenen Daten / Beispielen probieren ?
So wirst du keine sichere Lösung finden, alle vorgeschlagenen Rechenexempel basieren ja auch nur auf Vermutungen !

Wenn du sicher sein kannst, das die gelieferten Adressen eindeutig sind, könnte man rückwärts folgern, das z.B. y im Fall 1 nicht größer als 7 sein darf, usw
Aber eigentlich solltest du ja mitgeteilt kriegen, wie die Werte erstellt wurden, wenn du sie rückwärts auflösen sollst, oder

[brandelh]

Die Faktoren als 2er-Potenzen machen keinen Sinn, wenn x, y und z derart `beliebig` groß sind, dann ergibt sich keine Eindeutigkeit

Jan ist ja mit Zusatzinfos immer sparsam, aber ich denke, dass es mit der GIRA Steuerung zu tun hat, deren Rückgaben er letzthin erwähnt hat.
Und dann sieht das für mich wie eine IP-Adresse aus, die maskiert ist - ob nun 11 oder mehr lässt sich nicht sagen, aber wenn es etwas mit Hardware zu tun hat, ist es wahrscheinlicher, dass die 0 bis 999 von dezimalen Gedanken stammen (soviel passt in ein 3 stelliges Feld) als von Tatsachen

[Jan]

Moin Hubert,

wie so oft liegst Du absolut richtig. Es geht um die Aktoren-Adressen.

Ich habe inzwischen den Support von Gira angemailt, welche Regeln es für die Zusammenstellung dieser Adressen gibt.Die Diskussion hier zeigt mir, das ich ohne diese Angaben eindeutig nicht weiter kommen werde. Eure Vorschläge zur Rückrechung der Adressen waren sehr hilfreich, aber es hat sich halt auch gezeigt, das es nicht immer ganz eindeutig ausgehen muß.

Jan

[brandelh]

Eine Frage hätte ich noch

Du hast oben beschrieben, dass du das Ergebnis per Hand ausrechnen kannst ... also müsstest du doch den Zahlenwert (in einer INT Variablen) haben
und die Rechenregel bzw. ein Programm vom Hersteller, der die Werte ausgibt oder ?

Spielt es für deine Weiterverarbeitung eine Rolle um welche ART der Adresse sich handelt, oder brauchst du nur die 3 Werte ?
Wenn es Geräteadressen sind, wird GIRA sicherstellen, dass es keine Überschneidungen gibt !

[DelUser01]

Hallo Jan

Es geht um die Aktoren-Adressen...Gira...

Das muss ich überlesen haben dass es sich nicht um Wohnungsadressen handelt...

Warum musst Du das überhaupt umrechnen in eine kompakte Zahl?
Zum Ansprechen und identifizieren benötigst Du doch wieder die Original-Bezeichnung.

[Martin Altmann]

Hmm,
ist doch alles ganz einfach - und Jans Angaben sind unvollständig bzw. fehlerhaft!
Die Adressierung ist in zwei Byte kodiert - das rechte Byte ist die Adresse des "Teilnehmers" und das linke Byte wird - getrennt als zwei Halfbyte betrachtet - aufgeteilt in "Bereich" und "Linie"
Näheres dazu hier: http://de.wikipedia.org/wiki/KNX-Standard

Viele Grüße,
Martin

[Jan]

Ich glaube hier läuft was aus dem Ruder. Wobei das überhaupt nichts mehr mit meiner Eingangsfrage zu tun hat.

Ich habe keine Ahnung ob das KNX-Standard ist, oder eine individuelle Umsetzung von Gira. Für mich gilt in der Kommunikation mit dem Gira-Server aber, das ich die Knoten nicht mit der Knotenadresse wie "1,3,118" ansprechen kann, sondern mit der errechneten Gruppenadresse. Die eben so errechnet wird: x*2048 + y*256 + z. Wenn ich also einen Knoten ansprechen möchte, dann muß ich in dem Telegramm nicht die Knotenadresse einbauen, sondern die Gruppenadresse. Das ist ja auch überhaupt kein Problem.

Schwierig wird das, wenn der Gira-Server mir ein Telegramm schickt, dessen Gruppenadresse ich in meiner Datenbank nicht finde. Denn dann muß ich dem Admin Bescheid geben, für welchen Knoten ich da was bekommen habe, warum der in meiner Datenbank fehlt. Und der kann in dem Gira-Server eben nur nach der Knotenadresse suchen, nicht nach der Gruppenadresse. Also muß ich aus dem empfangenen Telegramm den Knoten zurück rechnen.

Beispiel: Ich möchte auf dem oben beispielhaft zitierten Knoten "1,3,118" einen Wert "12345" setzen. Dann schicke ich ein Telegramm "1|2934|12345". Als Bestätigung, daß das angekommen und umgesetzt wurde, bekomme ich vom Gira eine Rückmeldung "2|2934|12345". Solche Rückmeldungen bekomme ich alle naselang vom Gira, denn Aktorenwerte ändern sich ja nicht nur wenn ich eine Änderung manuell auslöse. Temperaturen ändern sich im Tagesverlauf, ein Licht wird manuell über den Schalter an oder aus gemacht, ein Bewegungsmelder schlägt an, usw. Und bei jeder dieser Änderungen bekomme ich ein entsprechendes Telegramm. Das ich auslese und mit den gespeicherten Werten abgleiche. Bei Änderungen wird das dann in einer Protokolldatei gespeichert. Und wenn da ein Telegramm zu einem mir noch unbekannten Knoten kommt, müssen wir das wissen, um das ergänzen zu können. Wofür ich aber wieder die zurückgerechnete Knotenadresse benötige.

Ist das jetzt verständlicher geworden?

Jan

[Martin Altmann]

Jan,
hier läuft nichts aus dem Ruder - und meine Antwort passt auf Deine Beschreibung ganz genau!
Du kannst es nur nicht so zurückrechnen, wie Du es hinrechnest! Du musst die einzelnen Bits betrachten und ins Verhältnis setzen - dabei beachten, dass die obere Hälfte des linken Bytes bei Deiner Berechnung so gerechnet wird, als wäre es die untere Hälfte eines Bytes (also: alle vier Bits gesetzt sind dann 1+2+4+8 (also 15) - und nicht 16+32+64+128 (also 240))!

Viele Grüße,
Martin

[brandelh]

Ob es KNX Standard ist weiß man zwar nicht, aber sei froh dass es überhaupt geht.
Ich habe mal bei Rademacher nachgefragt ob ich auch sowas tun könnte ... und die haben aktuell keine Schnittstelle nach außen bzw. dokumentieren diese aktuell nicht.

Die Bits direkt zu betrachten hatte ich ja schon ins Feld geführt, wenn es ein offener definierter Standard ist, wäre das natürlich gut ... ob das so ist - keine Ahnung !

Daher nochmals meine Frage, ob JAN aktuell (per Hand oder Programm) aus einer Gruppenadresse die gewünschte berechnen kann, wenn er nämlich Beispiele hätte,
könnte man untersuchen was wie läuft Aus dem Multiplikatoren schließe ich auf 8 Byte Z, 3 Byte Y und der Rest X (aus dem Kopf), die einzelnen BAND Masken hatte ich oben ja angegeben.
Gerade wenn man nur einzelne Bits eines Byte benutzen darf, ist es mit BAND viel einfacher und sicherer, als mit Dezimalzahlen, Teilen und int() ... alles Rechenoperationen die für unser HIRN im Dezimalsystem ablaufen

[Martin Altmann]

Moin Hubert,
es deutet alles darauf hin, dass es dem Standard entsprechend umgesetzt ist. Wenn er allerdings mit 2048 (statt 4096) multipliziert, dann ist es die Unterteilung in Hauptgruppe/Mittelgruppe/untergruppe auf der verlinkten Wikipediaseite - das oberste Bit steht dann gesondert für die Unterteilung in physikalische Adress (ein einzelnes Gerät) bzw. Gruppenadresse.

Viele Grüße,
Martin

[Jan]

Daher nochmals meine Frage, ob JAN aktuell (per Hand oder Programm) aus einer Gruppenadresse die gewünschte berechnen kann, wenn er nämlich Beispiele hätte,
könnte man untersuchen was wie läuft

Hubert,

was für Beispiele willst Du denn haben? Du hast das jetzt schon 2x bemerkt. Ich hatte doch geschrieben, wie die aussehen.

Martin, mit dem aus dem Ruder laufen meinte ich nicht Deine Bit-Diskussion. Sondern das plötzlich Dinge angeführt werden, die nichts mit der eigentlichen Problemstellung zu tun haben. Daher auch meine ausführlichere Beschreibung des Gesamtvorganges.

Jan

[Jan]

So, ich habe das ganze Problem gelöst. Besonderer Dank gilt hier Martin, der mir per PN eine Grundlagen-Lehrstunde in Bitrechnerei gegeben hat, und einem Hiwi, der zur Zeit bei meinem Kunden arbeitet und mich mit Hilfe der von Martin aufgeführten wikipedia-Seite auf den korrekten Weg gebracht hat.

Danach noch einiges aus Tante Google über Berechnung der Binärzahlen hin und wieder zurück, und es läuft absolut sauber.

Euch allen Vielen Dank für Eure Geduld und Eure Beiträge dazu.

Jan

[Tom]

Hallo, Jan.

Nett wäre, wenn Du auch die anderen, die hier versucht haben, Dir bei der Problemlösung zu helfen, darüber informieren könntest, worin sie letztlich bestand. Danke!

[Jan]

Tom,

klar, kann ich machen. Wird aber etwas aufwändiger.

Ansatzpunkt ist, was Martin als Link gepostet hatte: Die Tabelle über Gruppen im KNX-Protokoll. Wichtig ist hier, daß der Part 2 Byte lang ist, also 16 Bit, wobei das erste Bit aus welchem Grund auch immer nicht benutzt wird.

KNX.jpg (12.45 KiB) 9186 mal betrachtet

Was ich jetzt machen muß ist, aus der Gruppenadresse, die ich aus dem Telegramm herauslesen kann, eine binäre Zeichenfolge zu machen.

Code: Alles auswählen

         nKnoten := Val(cKnoten)
         cBinaer := ""
         // Zuerst den Binärwert der Gruppenadresse berechnen
         DO WHILE .T.
            nRest := Int(nKnoten / 2)
            IF .NOT. nRest * 2 == nKnoten
               cBinaer := "1" + cBinaer

             ELSE
               cBinaer := "0" + cBinaer
            ENDIF
            nKnoten := nRest
            IF nRest < 1
               Exit
            ENDIF
         ENDDO

Das geht auch eleganter, das ist erstmal so hingeschrieben um zu sehen, wie das klappen kann. Modulo-Berechnungen wären z. B. ganz nett hier. Wichtig ist aber, die einzelnen Bits in der korrekten Reihenfolge zu schreiben - nicht hinten anhängen, sondern vorne vorsetzen!

Als nächstes sehe ich zu, das ich die 15 Bit zusammen bekomme, die ich maximal haben kann/muß.

Code: Alles auswählen

         cBinaer := PadL(cBinaer, 15, "0")

Und zuletzt baue ich mir aus den 15 Binärwerten die einzelnen Knotenpunkte zusammen:

Code: Alles auswählen

         nX := Val(cBinaer[1])  *   8 + ;
               Val(cBinaer[2])  *   4 + ;
               Val(cBinaer[3])  *   2 + ;
               Val(cBinaer[4])  *   1
         nY := Val(cBinaer[5])  *   4 + ;
               Val(cBinaer[6])  *   2 + ;
               Val(cBinaer[7])  *   1
         nZ := Val(cBinaer[8])  * 128 + ;
               Val(cBinaer[9])  *  64 + ;
               Val(cBinaer[10]) *  32 + ;
               Val(cBinaer[11]) *  16 + ;
               Val(cBinaer[12]) *   8 + ;
               Val(cBinaer[13]) *   4 + ;
               Val(cBinaer[14]) *   2 + ;
               Val(cBinaer[15]) *   1

OK, einen Punkt gibt es dann natürlich doch noch: Aus den drei Knotenpunkten die komplette Knoten-Adresse zusammen bauen:

Code: Alles auswählen

         cKnoten := Var2Char(nX) + "," + Var2Char(nY) + "," + Var2Char(nZ)

Das wars dann. Ich hab das gegengetestet mit den Einträgen in der Datenbank mit mehr als 800 Knoten. Ich habe da sowohl die Knotenadressen als auch die Gruppenadressen drin stehen. Und hab einfach geschaut ob das Resultat der Rückrechung jeder einzelnen Gruppenadresse identisch ist mit der Knotenadresse im gleichen Satz. Und es passte.

Jan

[Tom]

Danke für die Erklärung. Also lag ich mit meiner Vermutung richtig, dass der Wertebereich von y zwischen 1 und 7 liegen darf (ein Byte). In dieser Variante funktionieren dann auch die von Martin und mir geposteten Lösungsvorschläge.

[brandelh]

Hallo JAN,

du kannst die BITS einer Zahl direkt setzen, aber Bit 0 ist ganz rechts und Xbase beginnt mit der Zählung bei 1.

Nachdem Martin den richtigen Aufbau gefunden hat, ist die Umsetzung nicht schwer und natürlich geht die Umrechnung nach deiner "rustikalen" Methode genauso wie die mathematische von Tom ... aber ich denke die wirklich binäre Umsetzung (BIT für BIT) ist nicht nur leichter zu verstehen, sondern gerade wenn man den Aufbau noch nicht kennt, kann man so die Zwischenergebnisse besser prüfen und eventuell auch die Regel erkennen. Für sowas nehme ich normalerweise PowerBasic, da dieses native &H für HEX, &B für Binär etc. verarbeiten kann.

Hier meine Funktionen ...

Code: Alles auswählen

#include "Gra.ch"
#include "Xbp.ch"
#include "Common.ch"

procedure main()
   local x, y, z, nAdresse, cUG, cMG, cHG
   cls
   ? "Bitschiebereien"

   cUG := "........11111111" // leider können wir in Xbase++ keine BINÄREN Werte angeben !
   cMG := ".....111........"
   cHG := ".1111..........."

   x := 3
   y := 5
   z := 7

   ? "Interne Darstellung, BIT 0 ist ganz rechts,"
   ? "bei Xbase Syntax wird aber statt 0 die 1 verwendet: "
   ?
   ? "Setzen wir die Werte x,y,z auf 3,5,7 =>"
   ?
   ? "X",str(x,10),nWert2Bin16(x)
   ? "Y",str(y,10),nWert2Bin16(y)
   ? "Z",str(z,10),nWert2Bin16(z)
   ?
   ? "Nun Adresse mit Offsets bilden ... "
   ?
   ? "X",str(x*2048,10),nWert2Bin16(x*2048)
   ? "Y",str(y*256 ,10),nWert2Bin16(y*256)
   ? "Z",str(z,10),nWert2Bin16(z)

   nAdresse := x*2048 + y*256 + z  // Multipliziert haben wir ja schon !

   ? "=",str(nAdresse,10),nWert2Bin16(nAdresse)
   ?
   ? "Gruppenzuordnung der Bits, gut wenn man das gefunden hat ;-)"
   ? "Untergruppe  ",cUG
   ? "Mittelgruppe ",cMG
   ? "Hauptgruppe  ",cHG
   ?
   ? "Gegenrechnung ... stimmt !"
   ?
   ? "X",str(GetWertVonBin16(nAdresse, cHG ),10)
   ? "Y",str(GetWertVonBin16(nAdresse, cMG ),10)
   ? "Z",str(GetWertVonBin16(nAdresse, cUG ),10)
   ?
   Inkey(20)


return
*------------------------------------------------------------------
function nWert2Bin16(nIntWert) // nur 16 Bit / 2 Byte sind relevant
   local cStr16, nBit, nCharPos
   cStr16   := space(16)
   nCharPos := len(cStr16)
   for nBit := 1 to 16 // eigentlich ist es ja 0 bis 15, aber bei Xbase 1 bis 16 !
       cStr16[nCharPos] := iif(nIntWert[nBit],"1","0")
       nCharPos--
   next
return cStr16
*------------------------------------------------------------------
function GetWertVonBin16(nBuffer, cBitMaske)
   local nWert, nMask, x, nCharPos, nOffset
   nCharPos := len(cBitMaske) // ganz rechts steht Bit 0 => hier also 1
   nMask    := 0 // alle Bits auf 0 setzen
   nOffset  := NIL
   for x := 1 to 16
       if cBitMaske[nCharPos] $ "J1Xx" // flexibel bleiben ;-)
          nMask[x] := .t. // dieses Bit in der Maske setzen
          if nOffset = NIL
             nOffset := 2^(x-1)
          endif
       endif
       nCharPos--
   next
   nWert := BAND(nBuffer,nMask)
   nWert /= nOffset

return nWert

und hier die Bildschirmausgabe:

Code: Alles auswählen

Setzen wir die Werte x,y,z auf 3,5,7 =>

X          3 0000000000000011
Y          5 0000000000000101
Z          7 0000000000000111

Nun Adresse mit Offsets bilden ...

X       6144 0001100000000000
Y       1280 0000010100000000
Z          7 0000000000000111
=       7431 0001110100000111

Gruppenzuordnung der Bits, gut wenn man das gefunden hat ;-)
Untergruppe   ........11111111
Mittelgruppe  .....111........
Hauptgruppe   .1111...........

Gegenrechnung ... stimmt !

X          3
Y          5
Z          7

[UliTs]

Danke für die Erklärung. Also lag ich mit meiner Vermutung richtig, dass der Wertebereich von y zwischen 1 und 7 liegen darf (ein Byte). In dieser Variante funktionieren dann auch die von Martin und mir geposteten Lösungsvorschläge.

+1