Recording data from two adxl345 sensors

that log is strange, order and timing of log makes no sense

21:52:32 S1 disconnected

21:52:44 S1 ok

22:28:54 S1 ok

22:28:54 S1 disconnected

23:00:39 S1 disconnected

23:01:09 S1 ok

in theory, because of your change inserted, you can not have

multiple ok messages without disconnected and opposite,

and no way to get ok and disconnected at same time ?

it is maybe because how you pack the messages .

I can not control every corner of code you write.

do you have Overdrive on and Audio Interrupt off as it should be ?

also remove all unneeded visual garbage from the patch.

at the end could js play a role ?

you could try to log to text file in parallel and compare.

.......

next thing to check is sender /receiver code, was there a lot of sensor messages

at disconnection time ?

.........

when you load recorded file into coll, you have to analyse pauses and or active periods.

and there you have many lines in 8 hours, if windy, max 2880000.

.......

I will test again with your original unmodified code and see if it works smoothly. The main discconectd I am almost 100% sure happens because my MAC went to sleep

I'm back to your original logger file:

Do you think I should use this same logger (with small changes to make the file readable by coll — adding semicolons, etc.) to also record the data from the 3 sensors? Is it the safest method for that too?

Also, I wanted to circle back to something I asked before — about showing active-time windows instead of inactive/pause windows. Did you have a chance to look into that, or is there anything more you need from me to help build it?

you should turn audio interrupt OFF

you should turn audio interrupt OFF

Did so now.

small updated regarding your new codes:

I made those small changes:

In the Receiver:

• onDataRecv used esp_now_data_t, I reverted it to the standard v3 signature (const esp_now_recv_info_t *info, const uint8_t *data, int len)

• The struct copy (packet = sharedPacket) is a direct assignment from a volatile struct, which throws a C++ compile error ("ambiguous overload for operator=") — I went back to copying field-by-field

• analogRead(A2) was reverted back to A2, but my moisture sensor is wired to A10 — I changed it back

In all 3 Senders:

• onSent used the old core-2.x signature (const uint8_t *mac_addr, esp_now_send_status_t status), which doesn't match Lib v3 — I restored the correct v3 signature with the explicit cast

I kept the improvements that did work well — the calibrate() guard against the 4-second freeze, and the explicit peerInfo.ifidx = WIFI_IF_STA.

--

Separately from your changes, I also added something of my own: an LED on the Receiver that only pulses when two things happen together — the 5-second Alive/OK heartbeat fires, AND something arrives back from Max over serial in that same window:

if (millis() - Alive >= 5000) {
  Alive = millis();
  Serial.println("OK");

  if (Serial.available() > 0) {
    while (Serial.available() > 0) { Serial.read(); }
    digitalWrite(LED_PIN, LOW);
    ledOn = true;
    blinkOnTime = now;
  }
}

Right now, I have Max sending something back every 5 seconds too, so this effectively confirms the full round-trip (Receiver → Max → Receiver) is alive, not just that the Receiver itself is running.

Everything's uploaded and running now with those fixes and this addition in place.

sorry for the libs confusion, I worked years with most optimal v 1.06, and somewhat with 2.0.17

but v3 is not in my brain.

did you keep that new loop in receiver ?

if (newPacketReceived) {noInterrupts();

I deketed my codev4.

about showing active periods, you should have understood that thy are allready marked with pauses, where pause ends activity starts, whre activity ends,pause starts, when longer then set time,

one only needs to group that 2 number differently.

If you can't manage it, post and I will try but my tume is really short this days

To answer your question directly: no, I didn't keep that specific change. Checking the code, newPacketReceived = false is still placed before noInterrupts(), same as in the original V3. When I fixed the volatile struct assignment (packet = sharedPacket → field-by-field copy), I kept the reset where it originally was, rather than moving it inside the critical section like your V4 attempt did.

Here's the full Receiver code I'm actually running right now, so you can see exactly what's in place:

// ==========================================
// RECEIVER V4 (corrected)
// ==========================================
// THIS IS FOR ESP32 Lib v3 ONLY - 3 axes as LIST, PREFIX to Serial A1 / A2

#include <WiFi.h>
#include <esp_now.h>

unsigned long Alive = 0;
volatile bool signal11Received = false;
volatile bool signal12Received = false;

#define LED_PIN LED_BUILTIN
unsigned long blinkOnTime = 0;
bool ledOn = false;
const unsigned long BLINK_DURATION = 500;

typedef struct {
  uint8_t id;
  float x;
  float y;
  float z;
} SensorPacket;

volatile SensorPacket sharedPacket;
volatile bool newPacketReceived = false;
SensorPacket packet;

float currentM1 = 0.45;
float prevM1 = -1.0;
unsigned long lastMRead = 0;
const float HUMIDITY_THRESHOLD = 0.005;

void onDataRecv(const esp_now_recv_info_t *info, const uint8_t *data, int len) {
  if (len == 1) {
    if (*data == 11) {
      signal11Received = true;
    } else if (*data == 12) {
      signal12Received = true;
    }
  } else if (len == sizeof(SensorPacket)) {
    memcpy((void*)&sharedPacket, data, sizeof(SensorPacket));
    newPacketReceived = true;
  }
}

void checkHumidity() {
  unsigned long now = millis();
  if (now - lastMRead >= 2000) {
    lastMRead = now;
    currentM1 = analogRead(A10) / 4095.0;
    if (abs(currentM1 - prevM1) > HUMIDITY_THRESHOLD) {
      prevM1 = currentM1;
      Serial.print("M1 ");
      Serial.println(currentM1, 3);
    }
  }
}

void setup() {
  Serial.begin(460800);
  pinMode(LED_PIN, OUTPUT);
  digitalWrite(LED_PIN, HIGH);
  WiFi.mode(WIFI_STA);
  if (esp_now_init() != ESP_OK) { while (1); }
  esp_now_register_recv_cb(onDataRecv);
}

void loop() {
  unsigned long now = millis();

  if (ledOn && (now - blinkOnTime >= BLINK_DURATION)) {
    digitalWrite(LED_PIN, HIGH);
    ledOn = false;
  }

  if (signal11Received) {
    signal11Received = false;
    Serial.println("S1");
  }
  if (signal12Received) {
    signal12Received = false;
    Serial.println("S2");
  }

  if (newPacketReceived) {
    newPacketReceived = false;
    noInterrupts();
    packet.id = sharedPacket.id;
    packet.x = sharedPacket.x;
    packet.y = sharedPacket.y;
    packet.z = sharedPacket.z;
    interrupts();

    if (packet.id == 1) {
      Serial.print("A1 ");
      Serial.print(packet.x, 3);
      Serial.print(" ");
      Serial.print(packet.y, 3);
      Serial.print(" ");
      Serial.println(packet.z, 3);
    } else if (packet.id == 2) {
      Serial.print("A2 ");
      Serial.print(packet.x, 3);
      Serial.print(" ");
      Serial.print(packet.y, 3);
      Serial.print(" ");
      Serial.println(packet.z, 3);
    }
  }

  if (millis() - Alive >= 5000) {
    Alive = millis();
    Serial.println("OK");

    if (Serial.available() > 0) {
      while (Serial.available() > 0) { Serial.read(); }
      digitalWrite(LED_PIN, LOW);
      ledOn = true;
      blinkOnTime = now;
    }
  }

  checkHumidity();
}

And understood on the active-periods logic — no rush at all, I know your time is tight right now. If you get a moment at some point to show how you'd wire it, I'd really appreciate it — but I'll try building it myself in the meantime (previous pause-end = next activity-start, grouped in pairs) and will only post again if I get stuck.

ok, i thought that interrupts could have caused that erratic serial traffic with disconnects.

when I come back later I wil send also js code to write coll format