ETS Gruppenmonitor Telegramm entschlüsseln?

[skandal]

Hallo, ich hoffe jemand kennt sich etwas mit dem Entschlüsseln eines ETS-Datentelegramms aus. Ich hab eins als Beispiel angehängt. Ich verstehe aber nicht wie die ETS mit dem hex-Code: 58 04 auf konvertierte Daten von 81,92 kommt? Ich fände es auch interessant wenn jemand einen Tipp hat wie man den Rest des Telegramms entschlüsselt. Ich bin etwas verwirrt da dieses Telegramm eigentlich EIS5 sein müsste und ich aber auch gerade hier gelesen habe das es EIS nicht mehr gibt, da dies durch die DPT abgelöst wurde, stimmt das so?
Vielen Dank im voraus.

[Gaston]

58,04 = 0x5804 (22532 auf 16 bit). Der EIS5 Typ besteht aus 3 Bestandteilen: Vorzeichen (bit 15), einem Exponenten (bit 11-14) und der Mantisse (bits 0-10).

Splittet man die 16 Bits so auf ergibt sich folgendes Bild:

• Mantisse: 4
• Exponent: 11
• Vorzeichen: 0 (positiv)

Die Mantisse selbst repäsentiert keine ganze Zahlen sondern eine Zahl mit zwei Nachkommastellen und ist somit mit 0.01 zu Multiplizieren, was also 0.04 ergibt.

Der Exponent ist wie in der binären repräsentation von Zahlen üblich ein Expoinent von 2, somit 2^11=2048.

Multipliziert man jetzt beide Ergebnisse: 0.04*2048 ergibt sich die Zahl 81.92

Gruss,
Gaston

[do13]

Es gibt da bei Tapko ein ganz nettes Tool Tapko: Tools
Damit kannst du schnell mal die Werte umrechnen lassen.

Gruß
Dirk

[skandal]

Danke

Vielen Dank für die super Erklärung Gaston und für den Tip mit der Tapko-Seite an do13. Ihr habt mir wirklich sehr geholfen.
Sind jetzt aus den soweit ich mal gelesen habe 15 verschiedenen EIS-Typen wirklich eine Vielzahl von DPT-Typen geworden? Also dürfte man jetzt eigentlich nicht mehr EIS5 sagen sondern muss DPT9 dazu sagen?

[Gaston]

Sind jetzt aus den soweit ich mal gelesen habe 15 verschiedenen EIS-Typen wirklich eine Vielzahl von DPT-Typen geworden?

Beim direkten Vergleich zwischen der Vielzahl von DPT Typen und EIS muss man sagen dass es dann bei EIS auch viel mehr waren.

Sowohkl EIS als auch DPT (welche natürlich kompatibel sind) beschreiben einmal das binäre Format wie die Daten übertragen werden (z.B. EIS 5) als auch den Datentyp. So ist zb ein EIS.5 Wert der eine Temperatur in °C darstellt eigentlich der Typ EIS 5001 (EIS 5 subtyp 1).

Bei DPT ist man lediglich hingegangen und hat diesen Zusammenhang formalisiert und hierachschich sauberer geregelt.

Ein DPT bsteht somit aus 2 teilen, dem Datentyp und der Dimensionierung. Diese beiden Teile sind wieder unterteilt in Format und Codierung für den Datentyp, und Wertebereich und Einheit für die Dimensionierung.

Der EIS5001 Wert oben ist gleich mit dem DPT 9.001 (DPT 9 subtyp 001). Gleichzeitig hat man den Subtyp formalisiert indem Nummernbereiche spezifischen Aufgaben zugeordnet sind.

So ist der bereich 0-99 zudem auch 001 oben gehört für generelle Zwecke gedacht. Die Temperatur ind diesem Fall entspricht also keiner spezifischen Applikation und kann somit sowohl von Einer Heizung wie auch von einer Wetterstation, etc... stammen. Wäre der Typ hindegenb 9.101 (Bereich 100-409) so stammt die temperatur von einem HVAC System (also Heizung, ventilation oder Klimaanlage).

Alle EIS typen und Subtypen wurden also 1:1 in DPT übernommen. Bei DPT sind dann noch einige Haupttypen hinzugekommen, aber speziell bei den Untertypen die die Dimensionierung angeben wurde viel erweitert.

Also dürfte man jetzt eigentlich nicht mehr EIS5 sagen sondern muss DPT9 dazu sagen?

Formal, richtig

Gruss,
Gaston

[skandal]

Vielen Dank Gaston, wirklich sehr gute Erklärung von dir. Danke dir jetzt ist mir das viel klarer.

[makki]

Formal, richtig

Naja, eigentlich nicht nur formal, EIS gibts seit ewig formal nicht mehr, obwohl es sich hartnäckig hält - ähnlich wie Class A/B/C/.. bei IP (ist seit geschlagenen 18 Jahren obsolet)

Wenn man da programmatisch weitermachen will, kann ich das hier anbieten (sub en/decode_dptXX).. Nicht schön aber selten und wenigstens mit allen DPT's implementiert..

Makki

[Gaston]

Naja, eigentlich nicht nur formal, EIS gibts seit ewig formal nicht mehr, obwohl es sich hartnäckig hält - ähnlich wie Class A/B/C/.. bei IP (ist seit geschlagenen 18 Jahren obsolet)

"eigentlich nicht nur formal ... gibts seit ewig formal nicht mehr", öhm Ja klar, eigentlich nicht nur grün weil die Farbe ist grün

Also echt, Ich frage mich ob solche Beiträge wirklich sein müssen.

Leuten die noch mit ETS2 arbeiten hilfts auch nicht wirklich weiter.

Mit den Netzwerkklassen verhält es sich ähnlich, diese wurden entgegen der Meinung vieler "Insider" soweit Ich weis nie abgeschafft. Vor 18 Jahren, dies dürfte sich auf supernetting und CIDR beziehen, war Ich noch für die IETF tätig, da auf jeden Fall nicht. Aber das tut hier eh nichts zur Sache.

Ich verfolge die RFCs heute jedoch nicht mehr so nah wie damals und lasse mich deshalb gerne eines besseren belehren.

Gruss,
Gaston

[makki]

"eigentlich nicht nur formal ... gibts seit ewig formal nicht mehr", öhm Ja klar, eigentlich nicht nur grün weil die Farbe ist grün

Also echt, Ich frage mich ob solche Beiträge wirklich sein müssen.

War eigentlich nicht angreifend gemeint.. Mich kekst es eher an, das es so manch Hersteller nach ein paar Jahren (ich weiss es nicht wieviele es sind, aber es sind ein paar) nicht schafft, DPT statt EIS konsequent selbst zu verwenden - und bis zur ETS4 noch nichtmal die Konnex selbst; es fühlt sich an wie "optional kannste..vielleicht.."
Ich halte DPT ggü. EIS für absolut besser&sinnvoller! Aber man muss es nun auch tun..

Leuten die noch mit ETS2 arbeiten hilfts auch nicht wirklich weiter.

Naja, Win98-Nutzern kann man heute auch nicht mehr so gut helfen

Mit den Netzwerkklassen verhält es sich ähnlich, diese wurden entgegen der Meinung vieler "Insider" soweit Ich weis nie abgeschafft.

Nah, da würde ich mich mal updaten, das war wirklich 1993 als CIDR im Internet verbindlich eingeführt wurde, ein paar Jahre Karenzfrist sind ja drin aber die sind um. Im RFC1918-LAN kann man ja machen was man will aber mit Class C weiss ich zwar was man meint, aber das gibts einfach seit 18J nicht mehr.. Und irgendwann muss irgendwer anfangen den Käse auszurotten

Makki

[Gaston]

War eigentlich nicht angreifend gemeint.. Mich kekst es eher an, das es so manch Hersteller nach ein paar Jahren (ich weiss es nicht wieviele es sind, aber es sind ein paar) nicht schafft, DPT statt EIS konsequent selbst zu verwenden - und bis zur ETS4 noch nichtmal die Konnex selbst; es fühlt sich an wie "optional kannste..vielleicht.."
Ich halte DPT ggü. EIS für absolut besser&sinnvoller! Aber man muss es nun auch tun..

Lol, makki, Ich hatte in der Nacht nicht mal drauf geachtet dass Du das geschrieben hattest . Aber so wie Du es jetzt hier schreibst, so unterschreibe Ich das auch.

Nah, da würde ich mich mal updaten, das war wirklich 1993 als CIDR im Internet verbindlich eingeführt wurde, ein paar Jahre Karenzfrist sind ja drin aber die sind um. Im RFC1918-LAN kann man ja machen was man will aber mit Class C weiss ich zwar was man meint, aber das gibts einfach seit 18J nicht mehr.. Und irgendwann muss irgendwer anfangen den Käse auszurotten

Sorry aber da liegst Du falsch. Damals als CIDR ausgearbeitet wurde wurde zwar davon gesprochen die Klassen (RFC791) zu obsoletten dies wurde aber aus verschiedenen Gründen nicht getan. Vielmehr wurde sich dazu entschlossen CIDR auf einen spzifischen Anwendungszweck abzuzielen ohne die bestehende Nomenklatur abzuschaffen die weiterhin für andere Anwendungen (z.B. private Netze) bestand hat.

RFCs haben wie jedes standardisierungs Dokument Ihre eigenen Formalitäten. So werden Adressklassen obsoletted wenn ein RFC dies explixizt tut und zusätzlich RFC791 obsolettet. Dies ist soweit Ich weis bis heute nicht der Fall.

CIDR (RFC1518/1519) und das Vorbereitungsdokument über suppernetting (RFC1338) von vor 18 Jahren tun dies nicht. Es ist sogar so dass CIDR explizit auf den Klassen aufbaut.

Es ist sogar so dass man sich rein formal in Anlehnung an diese RFCs sich im privaten Netzwerk sich an die Adressklassen halten müsste da private Netzwerke ausserhalb des scopes dieser RFCs liegt.

Gruss,
Gaston

[EPIX]

sorry Jungs aber DAS ist jetzt echt fachchinesisch..

aber zum Glück gibt's ja Wayne

[Gaston]

sorry Jungs aber DAS ist jetzt echt fachchinesisch..

Hast ja recht

[EPIX]

manchmal geht so richtig die Begeisterung durch wenn man gerade in "seinem Element" ist
Da sieht man aber auch die Begeisterung und breite Streuung der Kompetenzen hier im Forum...

[makki]

@Gaston: Ich denke wir müssen das nicht vertiefen, ich hab halt in 1-2 RIPE-Schulungen (also der Verein; RIR; der in EMEA die angeblich seit 10J knappen IP's vergibt) gelernt, das Classful auch nur gedanklich nun mal garnicht geht..
Bin auch zu faul das jetzt rauszugurgeln/kramen, weil es für den AW nun nicht wirklich wichtig ist, das sagt ihm der ISP (LIR) dann schon (hoffentlich?)

Wenns zum Thema (DPT) noch Fragen gibt: her damit.. Hat man es mal in 5 Programmiersprachen gemacht, ist es eigentlich einfach

Makki

[Gaston]

@Gaston: Ich denke wir müssen das nicht vertiefen, ich hab halt in 1-2 RIPE-Schulungen (also der Verein; RIR; der in EMEA die angeblich seit 10J knappen IP's vergibt) gelernt, das Classful auch nur gedanklich nun mal garnicht geht..
Bin auch zu faul das jetzt rauszugurgeln/kramen, weil es für den AW nun nicht wirklich wichtig ist, das sagt ihm der ISP (LIR) dann schon (hoffentlich?)

Schade dass Du nicht verstanden hast was Ich geschrieben habe. All das was Du hier schreibst ist nicht falsch. Bezieht sich aber rein auf Internet Adressen, und genau dafür war CIDR abgezielt. Adresseklassen wurden damit nicht abgeschaft.

Du hast in den Schulung bei der RIPE halt Sachen gelernt bei deren Entwickelung ich seitens der IETF an forderster Front dabei war . Dass die RIPE Dir dort vermittelt hat dass classfull routing im Internet nicht machbar ist, ist ja auch richtig. Dass die RIPE behauptet hat dass IP Adressklassen abgeschaft wurden, glaube ich nicht denn das ist eben nicht der Fall. Die RIPE vermittelt Inhalte eben im Kontext des Internets. Wie gesagt rein formal wäre eine Adresse wie 192.168.170.10 mit Makse 255.255.240.0 eigentlich "illegal", hier müsste man sich an die Klasse halten und 255.255.255.0 verwenden.

Müsste Ich jetzt erklären warum die Adressklassen nie obsolettet wurde müsste Ich einen Roman schreiben. Aber gottseidank kann ich die interne IETF Suppe weglassen denn es ist eigentlich ganz einfach für jeden zu kontrollieren ob Adresseklassen noch bestand haben oder nicht:

1. RFC791 definiert die Adressklassen. Wurde er jemals obsolettet ? Nein! (kann man überprüfen)
2. Distanzieren sich die CIDR RFCs (RFC1518 & 1519) von Adressklassen ? Nein, ganz im Gegenteil sie basieren darauf und machen regen Gebrauch davon. (das dürfte sogar ein schnelles überlesen karmachen)

Fazit:

• CIDR bezieht sich nur auf offizielle Internet Adressen
• CIDR bezieht sich nur auf das Routing der Adressen
• Formal behalten offizielle Internet Adressen behalten Ihre Klasse auch innerhalb des CIDR
• In privaten Netzen mit privaten Adressen findet CIDR formal keine Anwendung. Hier gelten offiziell die Regeln der Addresskalssen und subnetting.

So, das alles kann jeder in den RFCs überprüfen wenn er möchte. Damit ist alles gesagt.

Gruss,
Gaston