Daten mit ESP-NOW versenden

[Vincent (Gast)]

Guten morgen,
ich möchte mit ESP32 sensordaten über ESP-NOW versenden.
Das funktioniert auch schon soweit

typedef struct
{
    uint16_t id;
    uint8_t x;
    uint8_t y;
}message_ts;

static message_ts message_s;

static void onDataRecv(const uint8_t * mac_addr, const uint8_t *incomingData, int len);

// callback when data is received
static void onDataRecv(const uint8_t * mac_addr, const uint8_t *incomingData, int len)
{
    static const char *TAG = "onDataRecv";

    memcpy(&message_s, incomingData, sizeof(message_s));
    ESP_LOGI(TAG, "Packet received from: %02X:%02X:%02X:%02X:%02X:%02X", mac_addr[0], mac_addr[1], mac_addr[2], mac_addr[3], mac_addr[4], mac_addr[5]);
    ESP_LOGI(TAG, "\tid: 0x%02X\tx: %d\ty: %d", message_s.id, message_s.x, message_s.y);
}

Die Idee war es, eine ID zu schicken (welcher ESP (z.B. 
Küche/Wohnzimmer..)), x für den Sensor (Temperatur/Fensterkontakt...) y 
für den Wert.

Diese bekomme ich  (getestet mit einem HAL-Sensor)

Reichen diese Werte? Also sorgt ESP-NOW schon dafür, dass die Daten 
richtig ankommen? Oder sollte ich auch einen CRC dazu packen? und diesen 
dann überprüfen das das alles richtig ist?

[Wolfgang (Gast)]

Vincent schrieb:
> Diese bekomme ich  (getestet mit einem HAL-Sensor)

Was ist ein HAL-Sensor?
Gewöhnlich steht HAL in der Software eines uC für Hardware Abstraction 
Layer.

[Vincent (Gast)]

Wolfgang schrieb:
> Was ist ein HAL-Sensor?
> Gewöhnlich steht HAL in der Software eines uC für Hardware Abstraction
> Layer.

Ja, da bin ich bei was ganz großem neuem dran. Das wird die Welt 
revolutionieren ;)

meinte einen HALL-Sensor

[Stefan F. (Gast)]

Vincent schrieb:
> Also sorgt ESP-NOW schon dafür, dass die Daten
> richtig ankommen? Oder sollte ich auch einen CRC dazu packen?

Ethernet Pakete sind bereits durch eine CRC abgesichert. Fehlerhafte 
Pakete werden verworfen.

Beim TCP Protokoll werden automatisch mehrere Wiederholversuche gemacht. 
Falls auch das erfolglos warm bricht TCP die Verbindung ab. TCP kennst 
du vom Web Browser.

Beim UDP Protokoll werden (vom Netzwerk Stack/Treiber) keine 
Wiederholungen gemacht. Es gibt keine Verbindung, also auch keinen 
Abbruch. Es gibt auch kein Signal an das Anwendungsprogramm, dass ein 
Paket verloren wurde. Oft ergänzen die Anwendungsprogramme das 
Protokoll, um verlorene Pakete wenigstens zu bemerken (z.B. anhand einer 
fortlaufenden Sequenz-Nummer). UDP kennst du vom Video Streaming (z.B. 
Netflix).

ESP-NOW ist ein Spezialfall, weil es weder TCP noch UDP nutzt. Ich bin 
nicht 100% sicher, aber ich denke dass fehlerhafte Pakete nicht 
entschlüsselt werden können.

Ofenbar findet wie bei UDP keine automatische Wiederholung statt, und 
das Anwendungsprogramm erfährt nicht, ob das Paket beim Empfänger 
angekommen ist. Denn Espressif empfielt:

"If necessary, send back ack data when receiving ESP-NOW data. If 
receiving ack data timeouts, retransmit the ESP-NOW data. A sequence 
number can also be assigned to ESP-NOW data to drop the duplicate data."

Siehe 
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/network/esp_now.html

Zusammengefasst: Was du sendest, kann verloren gehen. Was du empfängst 
ist garantiert richtig (unverändert).

[J. S. (jojos)]

Sequence Counter halte ich auch für eine gute Idee, damit kann man eine 
Anzeige der Verbindungsqualität in Prozent realisieren. Bei einem Sensor 
der zyklisch sendet spielt es ja keine Rolle wenn mal ein paar Pakete 
verloren gehen. Schlechter wäre das bei einm Kontakt der nur bei 
Ereignis sendet, da macht ein Protokoll mit Quittung und Watchdog Sinn.