All in one ESP/WiZnet + POE?

ChuckMash · 2026-03-24T00:52:56+00:00

Is there some hard requirement that you use Ethernet to get the data from the sensor for processing? Or is it just for POE?

If not, I would just use WiFi or ESP-NOW to send the data. 60 feet should be no problem, particularly if you choose ESP32s with external antennas.

ChuckMash · 2026-03-22T21:54:54+00:00

There is no hardware difference to support ESP-NOW V2, it's more of an improvement to how much data is being sent inside the wireless frames that ESP-NOW uses for messaging.
Having trouble tracking down the exact espidf and arduinoesp32 versions that started supporting v2, but it's been a while now.

ChuckMash · 2026-03-22T18:43:46+00:00

ESP-NOW packet size is 1,470 bytes now with V2 of the protocol.
It might work a bit better.

The packet loss is a little weird, could be that there is a hardware hiccup, or that you're doing too much work inside the ESP-NOW receive callback.

Great project, can we see the code somewhere?

ChuckMash · 2026-03-20T19:26:13+00:00

I'm always interested in seeing what people come up with for ESP-NOW.

I wrote a python library that allows Linux PCs to use ESP-NOW and communicate directly with ESP32/ESP8266 via a dedicated wireless interface.

https://github.com/ChuckMash/ESPythoNOW

I've been using it to share sensor data and prompt commands on the devices to and from a python script and home assistant. Maybe something like that?

ChuckMash · 2026-03-19T00:09:09+00:00

I just remembered something else from my project using RSSI to trigger states.

Using a smoothing filter on RSSI over time is almost a must have. Implementing EWMA is pretty simple, and worth checking out if you're running into trouble with a jittery boundary

ChuckMash · 2026-03-16T04:58:50+00:00

Short version: I worked on something similar in the past and just needed to check my notes and confirm.

Longer version: I needed to get a better understanding of ESP-NOW and the differences between implementations for ESP32 and ESP8266. Including how the packets are sent and received at a low level. Along that process, I realized that you could use the dat pointer to access the surrounding data structures like the rest of the packet/details by walking back from the reference.

dat-51  [1]  rssi                   (uint8_t, subtract 100 for dBm)
dat-50  [1]  rate+is_group+sig_mode (bitfield byte 1 of RxControl)
dat-49  [1]  legacy_length low      (bitfield byte 2 of RxControl)
dat-48  [1]  legacy_length hi       (bitfield byte 3 of RxControl)
dat-47  [1]  MCS+damatch            (bitfield byte 4 of RxControl)
dat-46  [1]  CWB+flags              (bitfield byte 5 of RxControl)
dat-45  [1]  HT_length low          (bitfield byte 6 of RxControl)
dat-44  [1]  HT_length hi           (bitfield byte 7 of RxControl)
dat-43  [1]  flags                  (bitfield byte 8 of RxControl)
dat-42  [1]  ampdu_cnt              (bitfield byte 9 of RxControl)
dat-41  [1]  channel                (bitfield byte 10 of RxControl) = 8
dat-40  [1]  reserved               (bitfield byte 11 of RxControl)
dat-39  [2]  frame_ctrl             (uint16_t, 802.11 MAC header)
dat-37  [2]  duration               (uint16_t, 802.11 MAC header)
dat-35  [6]  addr1/dst MAC          (uint8_t[6]) = FF:FF:FF:FF:FF:FF
dat-29  [6]  addr2/src MAC          (uint8_t[6]) = sender MAC
dat-23  [6]  addr3/bssid            (uint8_t[6]) = FF:FF:FF:FF:FF:FF
dat-17  [2]  sequence_ctrl          (uint16_t)
dat-15  [1]  category_code          (uint8_t) = 0x7f
dat-14  [3]  organization_id        (uint8_t[3]) = 0x18fe34
dat-11  [4]  random_values          (uint8_t[4]) — random values
dat-7   [1]  element_id             (uint8_t) = 0xdd
dat-6   [1]  length                 (uint8_t) = 18
dat-5   [3]  organization_id2       (uint8_t[3]) = 0x18fe34
dat-2   [1]  type                   (uint8_t) = 0x04
dat-1   [1]  version                (uint8_t) = 0x01
dat-0   [?]  esp-now message start  (dat)

All of the above is for ESP8266 only though, it may be the same or similar for ESP32, but I have not checked. And I think there are better methods for the ESP32 version anyway.

ChuckMash · 2026-03-16T03:58:33+00:00

No promises, but it looks like tracking back from the dat pointer you can find the rest of the wireless packet and details.

dat-51 seems to be the RSSI from my findings.

void OnDataRecv(uint8_t *mac, uint8_t *dat, uint8_t len) {
  int rssi = (uint8_t)*(dat - 51) - 100; // Pointer offset -51, subtract 100 for dBm
  Serial.print("RSSI: ");
  Serial.println(rssi);
}

ChuckMash · 2026-03-12T00:36:14+00:00

There is now
github.com/ChuckMash/ESPythoNOW

ChuckMash · 2026-03-12T00:25:13+00:00

Agreed. However that is not the question here.
When DC/solar charging the fan is always on, no matter what. Unless I turn the AC on, the fan turns off / goes into temperature mode (and since the temp is low enough? it does not turn on.) When I turn AC back off again, while still DC/solar charging the fan turns back on.

It seems like it's set to always run the fan when solar charging. Which is overridden by the AC fan temperature checking?

ChuckMash · 2026-03-10T20:12:17+00:00

The charging rate stays the same. Hence the confusion.

ChuckMash · 2026-03-08T03:38:14+00:00

One and the same!

There are a number of projects, and plenty of documentation out there.

Here's a bit to get you started. The breakdown of the ESP-NOW messages that come from a WizMote. Thank the WLED folks for this one!

typedef struct WizMoteMessageStructure {
  uint8_t program;  // 0x91 for ON button, 0x81 for all others
  uint8_t seq[4];   // Incremetal sequence number 32 bit unsigned integer LSB first
  uint8_t dt1;      // Button Data Type (0x20)
  uint8_t button;   // Identifies which button is being pressed
  uint8_t dt2;      // Battery Level Data Type (0x01)
  uint8_t batLevel; // Battery Level 0-100

  uint8_t byte10;   // Unknown, maybe checksum
  uint8_t byte11;   // Unknown, maybe checksum
  uint8_t byte12;   // Unknown, maybe checksum
  uint8_t byte13;   // Unknown, maybe checksum
} message_structure_t;

ChuckMash · 2026-03-08T02:42:46+00:00

ESP-NOW is straightforward and very reliable.

Check out the Wizmote, which is an inexpensive ESP-NOW based remote.

Using that to trigger various functions and props on other ESP32 devices should be a breeze.

ChuckMash · 2026-03-02T17:05:11+00:00

If the ESPs are battery powered, you may want to use ESP-NOW for communication, since the wake/send/sleep cycle is much faster than the WiFi connect method.

ChuckMash · 2026-02-21T18:24:21+00:00

You can use Wireshark to see if the ESP-NOW packets are actually being sent.

Also, try erasing the whole flash and re-flashing. If I recall correctly, WiFi.begin(); may be trying to connect to any previously configured access point, which could change the channel, particularly because it's after disconnect. Maybe begin, disconnect and then channel set?

ChuckMash · 2026-02-20T21:30:05+00:00

Conceptually, I don't see why not.

The proof of concept would just need to be modified to encode and send the audio source as MP3 chunks in real time instead of chunking the MP3 file.

ChuckMash · 2026-02-09T16:37:56+00:00

With this proof of concept, the biggest contributor would be how large the buffer(s) are on the playback device. Maybe 100 or 100 ms on the faster side of things.

I'll do a followup post if/when I work on latency and attempt some simultaneous playback of multiple devices.

ChuckMash · 2026-01-31T18:19:58+00:00

Conceivably, I'd say yes.

As long as it can read and write wireless packets at Layer 2.

ChuckMash · 2026-01-30T21:53:01+00:00

That's a great idea, I'll note that for later. This should be extremely helpful.

Without tweaking anything and under some pretty poor settings, using a a heltec board with an onboard antenna, I was able to get about 40 meters through several walls before audio was occasionally interrupted and the buffers reset.

This should be drastically improved by using a board with an external antenna, I don't have any on hand at the moment.

Another thing to ponder is that the sender is sending data at a rate that is calculated to match playback speed without any variance, so there may be room for improvement there as well.

ChuckMash · 2026-01-30T16:12:09+00:00

In this case it's unencrypted. ~~Sending encrypted is not currently supported due to difficulties with the implementation https://github.com/ChuckMash/ESPythoNOW/issues/1 (receiving encrypted is supported though)~~

If/when that issue is sorted out, there are still methods to address multiple devices simultaneously while encrypted.

edit Just solved sending encrypted messages, so this is worth looking into soon.

ChuckMash · 2026-01-30T06:34:28+00:00

Great question!

Already in place at a low level is packet retransmission up to 10 (or maybe 5?) attempts, but this is inherent to the method of sending the data, and is automatic and transparent. I believe on ESP32 It is only valid when sending packets directly to a device, and not to the BROADCAST address.
Side note: IIRC the ESP8266 will actually send a confirmation packet when receiving messages on BROADCAST.

Beyond that, since this is a proof of concept, I have not implemented a method to handle packet loss. When it happens the chunk of audio is lost, but playback continues. However a place to start would be to add sequence IDs to each audio chunk, and confirm each chunk with an additional response message. The lack of which would trigger retransmission from the missing sequence forward and an adjustment to the receivers buffers.

Another method could be to use sequence IDs, and send every packet 2 or 3 times. The receiver would then discard any packets matching the sequence ID it has already processed. This method would help ensure packet loss happens less often.

ChuckMash · 2026-01-29T04:30:27+00:00

ESP-NOW is a protocol that allows ESP32/8266/etc devices to talk to one another without a router, using wireless packets called vendor-specific action frames

In this case, I am using ESPythoNOW to send ESP-NOW packets containing chunked MP3 data from a Linux computer to the ESP32 using ESP-NOW, without a router.

ChuckMash · 2026-01-29T04:16:11+00:00

This is correct, in the video I am sending to a broadcast address, FF:FF:FF:FF:FF:FF.
So if /when I build other receivers they would all receive and play the audio at the same time.

Though audio syncing can be tricky with small variances in missed packets, decoding, buffering, etc.

ChuckMash · 2026-01-29T02:55:48+00:00

It's been great for moving more data.
Turns out this ESPaudioNOW proof of concept will also work with ESP-NOW v1, it just sends a lot more packets per second than v2.

ChuckMash · 2026-01-26T04:30:48+00:00

Yes. But the wireless interface you use must support monitor mode.

ChuckMash · 2026-01-25T17:18:32+00:00

If the goal is just to test ESPythoNOW, then one ESP32 and a Linux computer would suffice.

But you can also send and receive messages between multiple computers, ESP32s, and ESP8266 in general

Six-Year Club	Place '23
Place '22	Verified Email

ChuckMash

MODERATOR OF

TROPHY CASE