Nextion Component ID trennen

SkobyMobil:
Hallo Whandall,
ist ja nett, das Du Dir hier so viel Mühe gibst. Bringt mir aber leider nichts.
Dein Sketch läuft genau so gut, wie meiner. Zum einem gibt es nicht alles aus- (65 00 03 01 FF FF FF) das wollte ich ja haben,
zum anderem kommt er ins haspeln, wenn man ein anderes Objekt am Nextion aktiviert.
Zuerst wird nichts gefunden und dann sporadisch die Informationen.

Das ist vielleicht ein Dreck, es kann doch wohl nicht so schwer sein, einige binäre Daten zu lesen. Ich hatte das ja schon raus
bekommen. Nur am selektieren ist es gescheitert. Das muß doch sicher zum laufen bekommen zu sein.
Gruß und Dank
Andreas

Mein Sketch funktioniert einwandfrei, wenn von dem Nextion nur Nextion formatierte Nachrichten kommen.

print und printh können da dazwischenfunken, das ist Fehler des print und printh, nicht des Parsers.

Wo ist also bitte das HMI das du verwendest und das nicht parsbar sein soll?

Hallo,
“Wo ist also bitte das HMI”
Hier.
Gruß und Dank
Andreas

SeriellTest.zip (44.3 KB)

Touch move von Eingabe

print eingabe.val

Benutze kein print und kein printh, die sind vor allem für Anwendungen,
in denen alle Nachrichten per print und printh erzeugt werden.

Na ja, du konntest per print(h) Nachrichten erzeugen die einen eigenen Typ und die drei 0xFFs am Ende haben,
aber einfach mal den Wert einer Variablen in den Stream zu werfen funktioniert nicht.

ausgabe.val=eingabe.val

Das erscheint mir auch ungültig (Zahl=Text), müsste man nicht cov(x) benutzen?
Sah nur aus wie ein Text, bei einem Slider ist das natürlich absolut ok und funktioniert ja auch.

Nimm statt deinem print

get eingabe.val

das kannst du auf der Arduino Seite prima parsen, aber schau in den Debugger, was das produziert.

Damit du diese Zahlen besser zuordnen kannst,
wäre ein Haken bei Send Component Id bei Touch Press Event sinnvoll.

Dann käme die id-Press, dann (nackte 0x71) Zahlen beim Draggen und nachher ein id-Release.

Etwas das auch diese Zahlen anzeigen kann

const byte bufferSize = 64;

void setup() {
  Serial.begin(250000);
  Serial1.begin(115200); //19200);
}

void loop() {
  static uint8_t bIndex;
  static uint8_t buffer[bufferSize];
  bool allesDa = false;
  if (Serial1.available()) {
    uint8_t inChar = Serial1.read();
    buffer[bIndex++] = inChar;
    if (inChar == 0xFF && (bIndex >= (*buffer == 0x71 ? 8 : 3)) &&
        buffer[bIndex - 2] == 0xFF && buffer[bIndex - 3] == 0xFF) {
      allesDa = true;
    } else {
      allesDa = (bIndex == bufferSize);
    }
  }
  if (allesDa) {
    if (*buffer == 0x65) {
      Serial.print(F("TouchEvent: page "));
      Serial.print(buffer[1]);
      Serial.print(F(", id "));
      Serial.print(buffer[2]);
      Serial.print(F(", event "));
      Serial.println(buffer[3] ? F("PRESS") : F("RELEASE"));
    } else if (*buffer == 0x71) {
      Serial.print(F("Value: "));
      Serial.println(*((int32_t*)buffer + 1));
    } else {
      Serial.println(F("Unbekannter Typ"));
    }
    bIndex = 0;
  }
}

Jetzt sollte auch

(bIndex >= (*buffer == 0x71 ? 8 : 3))

klarer sein, bei diesen Paketen können sogar vier 0xFF Bestandteil des Pakets sein,
also ergibt es nur Sinn auf die Delimiter hinter dem Wert zu testen.

Erkennst du wie simpel das alles ist?

Als Denkaufgabe: warum könnte/sollte die obige 3 eine 4 sein? Was wäre der Unterschied?

Hallo,
das Zeugs treibt mich noch in den Wahnsinn.

Bei B1 gibt NextionSimulator 65 00 03 01 FF FF FF raus. Das wird auch im Terminal so ausgegeben.
Der Arduino gibt aber 65 00 03 01 FF FF FF FF raus.
Da sitzt schon einmal der erste Wurm drinne. Das mit dem Zählen kann man ohne eindeutigen Terminator
vergessen, dafür kommen die Daten nicht sauber genug rüber.

Wenn ich dann darüber nachdenke, das ich später einen Slider lesen will, dann wird mir schlecht.
Vielleicht ist es tatsächlich besser sich die Werte zu holen, als sie bringen zu lassen.
Oder ich nehme ein Number und hänge ein 0D bei Veränderung dran.

Ich muß erst einmal sehen, das das sauber übertragen wird. Ohne wenn und aber.
Den Zustand eines Buttom zu lesen ist ja kein Problem. Aber wenn etwas anderes dazwischen funkt...
Gruß und Spaß
Andreas

P.S.

Als Denkaufgabe: warum könnte/sollte die obige 3 eine 4 sein?

(bIndex >= (*buffer == 0x71 ? 8 : 3))

Bayern 8, Dortmund 3 ?

Ich glaube der Stern ist ein Pointer und zeigt auf 0x71 im Buffer.
Das ist aber auch alles. Ich habe das nie gebraucht, daher keine Ahnung.

Offensichtlich hast du dir meinen Kode nicht angesehen und/oder versucht zu verstehen
und aus deinen Ausführungen schließe ich, dass du auch nicht wirklich liest was ich schreibe.

Hast du dein HMI in Ordnung gebracht?

Hast du verstanden, was du falsch machst/gemacht hast?

Was heisst es wenn im ersten Byte eines Nextion Datensatzes eine 0x71 steht?

Der Arduino gibt aber 65 00 03 01 FF FF FF FF raus.

Kann mein Programm nicht ausgeben.

Hallo,
ich habe wirklich keine Lust mich mit Dir zu streiten.
Was wie auf dem HMI läuft/übertragen wird, spielt keine Rolle. Wichtig ist nur, sich dort das Richtige zum auswerten zu
sichern.
Und wie Du Dich erinnern kannst, wollte ich meine Ausgabe als eigenen Wert haben.

"
65
0
3
1
FFFFFFFF
FFFFFFFF
FFFFFFFF
"
Dein Sketch nützt mir also überhaupt nichts. Deine Hilfe ist ja wirklich nett, bringt mir aber so richtig nichts.
Ich werde mich einmal in mein Kämmerlein zurückziehen. Mit Deinen Informationen werde ich das wohl hinbekommen.
Also, vielen Dank dafür.
Gruß und Spaß
Andreas

SkobyMobil:
Und wie Du Dich erinnern kannst, wollte ich meine Ausgabe als eigenen Wert haben.
Dein Sketch nützt mir also überhaupt nichts.

Wenn du nicht in der Lage bist

aus meinem Beispiel zu entnehmen

  • wie man die Zeilen sauber erkennt
  • wie man auf die Id eines Touch Events zugreift

aus meinen Ausführungen zu entnehmen

  • wie man Werte übertragen kann, ohne print zu benutzen (und das zu ändern)
  • dass es sehr wohl eine Rolle spielt, was das HMI noch so außer Touch Events generiert

dann wird ein Zurückziehen - wohin auch immer - nicht das Problem lösen.

Versuchen kannst du es ja.

Bei Problemen bitte Kode und HMI beifügen.

Hallo,
Du hast ein dickes Fell, das rechne ich Dir hoch an und bin auch dankbar.
Versuche mir einmal zu erklären, warum man "printX" nicht nutzen sollte.
Und dann, was sollte das machen?

(*buffer == 0x71 ? 8 : 3)

Der Stern ist doch ein Pointer, der in einer Variable auf eine bestimmte Stelle zeigt.
Hier, 0x71 auf eine Ziffer, Zahl- 0x70 sollte Buchstabe/String sein, denke ich mir.

mit dem Fragezeichen kann ich nicht viel anfangen.

Bayern 8, Dortmund 3

Da sollten 8 Stellen gelesenwerden, und 3 werden ausgewertet.
Aber, da kann ich auch 8:5 oder 9:4 schreiben, Dein Sketch liefert immer noch.
Da komme ich nicht mit weiter, weil NullAhnung.
Gruß und Dank
Andreas

http://openbook.rheinwerk-verlag.de/c_von_a_bis_z/008_c_kontrollstrukturen_006.htm#mj26437d8e3d93c0cc1e9764c2f5d5d988

Hi

Wird wohl sinngemäß heißen:
Beginnt die Antwort des Nextion mit 0x71, dann gib '8' zurück, sonst '3'.
Das wird dann wohl die Anzahl der Stellen sein, Die für diesen Rückgabewert zutreffen (oder eben alle Anderen).
*puffer ist die Adresse auf den Anfang der Puffer - da stehen die Zeichen, Die das Nextion zurück geschickt hat, weil wir Die Da gerade hin gespeichert haben.

MfG

Du kannst print(hs) benutzen, wenn du damit Nachrichten baust, die am Anfang einen Typ haben
der sich von den Nextion Typen unterscheidet und die mit drei 0xff aufhören.
Oder wenn du ausschließlich solche prints benutzt.

Beides zu mischen ist Gebabbel das du nur sehr schwer wirst parsen können.

Statt den nackten Wert zu schicken, 'get' ihn, dann kommt er als Integer Datagramm verpackt.

Wenn du keinen basis C(++) Kode lesen kannst, betreibst du das falsche Hobby.

 if (inChar == 0xFF && (bIndex >= (*buffer == 0x71 ? 8 : 3)) &&
        buffer[bIndex - 2] == 0xFF && buffer[bIndex - 3] == 0xFF) {
      allesDa = true;
    } else {

Wenn das aktuelle Zeichen ein 0xFF ist und
mindestens drei (oder bei einem Integer Datagramm acht) Zeichen im Puffer sind und
das vorletzte Zeichen ein 0xFF war und das
vor-vorletzte Zeichen auch ein 0xFF war,
dann ist die Nachricht vollständig.

Nötig ist das, (die acht) weil ein Integer Datagramm auch vier 0xff enthalten kann und auch können sollte,
und (die drei) weil man nicht außerhalb eines Arrays rummachen sollte.

Bei der aktuellen Logik landen alle Zeichen immer im Puffer und der Index wird erhöht,
wenn wir also das letzte und vorletzte Zeichen testen wollen, haben die die Indices -2 und -3.
Damit man auch wirklich die Nachricht überprüft und nicht irgendwelche Zeichen vor deM Puffer,
sollte also der Index aktuell mindestens drei sein.
Bei einem Integer Wert (0x71 in der ersten Stelle des Datensatzes) testet man tunlichst erst nach dem Integer,
0x71, 4 Bytes Integer, 0xFF, 0xFF, 0xFF. wurde das letzte dieser Zeichen empfangen steht der Index bei acht.

Ich hoffe das trug etwas zu deiner Erleuchtung bei, es ist wirklich simpel wenn du es einmal geschnallt hast.

Hallo,
vielen Dank dafür.
Gruß und Spaß
Andreas