UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[paul53]

@sveni_lee:

Ich verste nicht so ganz was du mir damit sagen möchtest… ??? `
https://www.torsten-horn.de/techdocs/ascii.htm.

"." (Punkt) hat den hexadezimalen Wert 0x2e.

[sveni_lee]

jetzt verste ich was du meinst,

0a am ende steht für LF(line feed) und nicht für den Punkt… okay verstanden.

mein Problem ist das ein Antwort in mehreren Paketen gesendet wird und das ende immer "0A"...

Ich möchte nun die Pakete "zusammensetzen" im Moment werden sie leider als einzelne Teile verarbeitet...

[paul53]

Wenn es Strings sind, kann man diese einfach verketten (anhängen). Ob das LF enthalten ist, kann man testen.

if(str.indexOf('\n') != -1) { // LF ist enthalten
   ...
}

Das sollte Dir die ASCII-Anmerkung sagen.

[sveni_lee]

okay, aber dann müsste ich doch die strings so lange in einen Puffer schreiben bis ein LF zeichen kommt, richtig?

oder verstehe ich an der stelle etwas falsch?

[paul53]

@sveni_lee:

okay, aber dann müsste ich doch die strings so lange in einen Puffer schreiben bis ein LF zeichen kommt, richtig? `
So würde ich es versuchen.

[sveni_lee]

und dann kommen wir zu meiner ursprünlichen Frage…

wie kann ich in einen Puffer schreiben?

[paul53]

Wenn es sich tatsächlich um Strings handelt, dann ist der Puffer ein String, der als Leerstring initialisiert wird, und an den man die Stringbruchstücke solange anhängt, bis ein LF enthalten ist. Der Hex-Dump zeigt allerdings etliche Steuerzeichen innerhalb der Daten.

[sveni_lee]

die Antworten die ich erwarte sehen dann so aus…

NRI<response status="ok"><device id="TX-NR525"><brand>ONKYO</brand><category>AV Receiver</category><year>2013</year><model>TX-NR525</model><destination>xx</destination><firmwareversion>1060-9110-0000-</firmwareversion></device></response>

[paul53]

@sveni_lee:

die Antworten die ich erwarte sehen dann so aus… `
Das ist unvollständiger XML-Code.

NRI
 <response status="ok"><device id="TX-NR525"><brand>ONKYO</brand>
		<category>AV Receiver</category>
		<year>2013</year>
		<model>TX-NR525</model>
		<destination>xx</destination>
		<firmwareversion>1060-9110-0000-</firmwareversion></device></response> 

[sveni_lee]

richtig… das Problem ist das der xml code in teilen gesendet wird und nicht vollständig übergeben wird...

~~https://i.imgur.com/LFkxKiN.jpg" />

~~https://i.imgur.com/qLyVEPv.jpg" />

der komplette xml-code setzt sich den Paketen 920,921,922,923 und 924 zusammen…

darum möchte ich die enzelnen Teile wieder zusammensetzen um den kompletten und brauchbaren xml code zu bekommen...~~~~

[paul53]

Das Packet 920 enthält einen Header, der mit "!1NRI" endet. Haben die anderen Packete auch diesen Header ? Der müsste dann erst ausgefiltert werden, bevor man die XML-Teile verkettet.

Wie sieht das letzte Packet aus ?

[sveni_lee]

nein, die anderen haben diesen header nicht… der isr aber wichtig für die weiterverarbeitung müsste also am Anfang des Paketes bestehen bleiben...

~~https://i.imgur.com/sTO0PT2.jpg" />

~~https://i.imgur.com/jryLouz.jpg" />

~~https://i.imgur.com/E80eKKM.jpg" />

https://i.imgur.com/YKPAKSY.jpg" />~~~~~~

[paul53]

Sind das keine Header bis zum Byte 0x41 : "|" (senkrechter Strich) ? Müssten die nicht rausgefiltert werden ?

Wo erscheint das LF ?

[sveni_lee]

das ist richtig…

~~https://i.imgur.com/SaV0DU6.jpg" />

Wireshark sagt mir das der "Datenteil" immer erst mit byte 66 startet…

https://i.imgur.com/wzzsRhF.jpg" />~~

[paul53]

Werden die ersten 66 Zeichen auch an die Funktion übergeben ?

on('data', function (data) {

Oder sind sie an der Stelle schon ausgefiltert ?

[AlCalzone]

Ich gehe nicht davon aus, dass du die TCP-Header ebenfalls empfängst. Wireshark zeigt dir das gesamte Datenpaket an, das übers Netzwerk geht, Anwendungen sehen i.d.R. nur den Inhalt des TCP-Pakets (in deinem Fall vermutlich ab Byte 66).

[sveni_lee]

die sind an der stelle schon ausgefiltert…

die werden hier ausgefiltert:

function eiscp_packet_extract(packet) {
    /*
      Exracts message from eISCP packet
      Strip first 18 bytes and last 3 since that's only the header and end characters
    */
    return packet.toString('ascii', 18, packet.length - 3);

[sveni_lee]

@AlCalzone:

Ich gehe nicht davon aus, dass du die TCP-Header ebenfalls empfängst. Wireshark zeigt dir das gesamte Datenpaket an, das übers Netzwerk geht, Anwendungen sehen i.d.R. nur den Inhalt des TCP-Pakets (in deinem Fall vermutlich ab Byte 66). `

dann sind das also nur die 18 bytes die noch ausgfiltert werden

[paul53]

Wo hast Du diesen Code her ? Ich verstehe ihn nicht :oops:

[paul53]

Hier sollen die ersten 18 Zeichen nach dem TCP-Header ausgefiltert werden, so dass das Ergebnis mit "NRI<" beginnt. Das darf aber nur beim ersten Packet erfolgen, wie die Hexdumps zeigen.