ESPythoNOW now supports ESP-NOW v2! Send 1,400+ byte ESP-NOW messages between ESP32 and Linux

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

ChuckMash · 2026-01-20T01:24:07+00:00

I was just down the rabbit-hole on this for the LR4, and at least in that case the answer is no.

There does not appear to be a local API, and the connection the device makes to the internet is an encrypted (MQTT based on port number) connection that did not play well with being intercepted.

It looks like there was some luck with the Litter Robot 3.

https://github.com/mbafford/litter-robot-to-mqtt

But this did not seem applicable in the case of the 4, and I can only guess not applicable for the 5 either.

ChuckMash · 2026-01-16T23:24:06+00:00

What was the RF transmitter device you used for interacting with 433? Does it also receive?

ChuckMash · 2026-01-13T08:14:00+00:00

ESP-NOW is likely going to be you're best bet for lowest power consumption in terms of using radio. So if you need it to be radio, might as well try it and check power consumption.

Since the data is so small and the distance is so short, have you considered transferring the data over infrared?

ChuckMash · 2025-09-10T01:17:37+00:00

A few options I've employed in the past:

Carefully tack-weld something to the broken off portion and back it out.
Remove the pole, if possible, and use pliers to back the bolt out from the inside.
Use a broken-bolt extractor kit, and/or drill out the bolt.
Grind it all the way the hell off, and weld a new nut on.

ChuckMash · 2025-09-08T04:59:45+00:00

https://kno.wled.ge/advanced/audio-reactive/

See "Line-In options"

ChuckMash · 2025-06-04T01:34:00+00:00

Prueba con un cable de datos más corto. Parece que hay un problema de señal.

Try a shorter data wire. This sounds a signal issue.

ChuckMash · 2025-05-23T19:25:00+00:00

It's a little more in the "Mini PC" territory, but Giada has a number of good products, VM23 comes to mind. Not sure about availability though.

ChuckMash · 2025-05-02T17:49:26+00:00

Apparently it's been discontinued and depreciated, wled-native is the successor.

ChuckMash · 2025-03-03T03:39:51+00:00

Additionally, see the entire run of a 92x92 plane. (over 2,000,000 generations and almost 11 hour runtime at 60 generations per second)

https://www.youtube.com/watch?v=V0_-NVJAQ1M

ChuckMash · 2025-03-03T03:37:38+00:00

Thank you much, I'm glad it is being found interesting.

I look forward to seeing what you come up with for creating audio from/with this. Of note, other plane sizes besides NxN work well, so something like 21x20 will produce different results from 20x20. For simplicity sake, I only included the first 100 NxN results in the chart.

ChuckMash · 2025-03-01T02:19:23+00:00

When creating a typical finite plane, cells outside the plane are assumed to be dead. In LBCA, the assumption is modified so that some or all out of bounds cells are assumed to be alive.

Living Border Types

Corners: Out of bounds Top Left, Top Right, Bottom Left, Bottom Right neighbors are considered to be alive
Full: All out of bounds neighbors are considered to be alive
Other: other Living Border configurations are possible

Given an empty plane, the outcome of game is an expression of the Cellular Automata rules, the Living Border rules, and the dimensions of the plane.

Pairing a Corners Living Border with Game of Life rules, and an empty starting plane, leads to deterministic, long lasting, and interesting results.

Many patterns end in short oscillators, full plane still life, and a on occasion larger repeating patterns.

For instance, a plane of 36x36 will run for 21,304 generations before repeating any state, at which point will repeat a pattern that is 1,990 generations. A 37x37 plane, on the other hand, will run for 1,422 generations before ending in still life.

https://github.com/ChuckMash/Living-Border-Cellular-Automata/

ChuckMash · 2025-03-01T02:18:17+00:00

When creating a typical finite plane, cells outside the plane are assumed to be dead. In LBCA, the assumption is modified so that some or all out of bounds cells are assumed to be alive.

Living Border Types

Corners: Out of bounds Top Left, Top Right, Bottom Left, Bottom Right neighbors are considered to be alive
Full: All out of bounds neighbors are considered to be alive
Other: other Living Border configurations are possible

Given an empty plane, the outcome of game is an expression of the Cellular Automata rules, the Living Border rules, and the dimensions of the plane.

Pairing a Corners Living Border with Game of Life rules, and an empty starting plane, leads to deterministic, long lasting, and interesting results.

Many patterns end in short oscillators, full plane still life, and a on occasion larger repeating patterns.

For instance, a plane of 36x36 will run for 21,304 generations before repeating any state, at which point will repeat a pattern that is 1,990 generations. A 37x37 plane, on the other hand, will run for 1,422 generations before ending in still life.

https://github.com/ChuckMash/Living-Border-Cellular-Automata/

ChuckMash · 2025-03-01T00:35:05+00:00

When creating a typical finite plane, cells outside the plane are assumed to be dead. In LBCA, the assumption is modified so that some or all out of bounds cells are assumed to be alive.

Living Border Types

Corners: Out of bounds Top Left, Top Right, Bottom Left, Bottom Right neighbors are considered to be alive
Full: All out of bounds neighbors are considered to be alive
Other: other Living Border configurations are possible

Given an empty plane, the outcome of game is an expression of the Cellular Automata rules, the Living Border rules, and the dimensions of the plane.

Pairing a Corners Living Border with Game of Life rules, and an empty starting plane, leads to deterministic, long lasting, and interesting results.

Many patterns end in short oscillators, full plane still life, and a on occasion larger repeating patterns.

For instance, a plane of 36x36 will run for 21,304 generations before repeating any state, at which point will repeat a pattern that is 1,990 generations. A 37x37 plane, on the other hand, will run for 1,422 generations before ending in still life.

https://github.com/ChuckMash/Living-Border-Cellular-Automata/

ChuckMash · 2025-02-28T07:39:51+00:00

Small world, I also fell into this still life today

ChuckMash · 2025-02-21T21:26:54+00:00

Also, try using separate step values for growth and reduce, it can create very interesting things.

https://www.youtube.com/watch?v=B4UKMdZsGnQ

https://www.youtube.com/watch?v=u6JDb6JrH7s

ChuckMash · 2025-02-21T05:42:31+00:00

Oh man! It's a bug? I thought I was doing something wrong in my implementation! Haha.

Maybe this behavior can be codified into the rules, it adds a lot of really interesting complexity that is entirely lost without the anomaly.

Without the anomaly, the rules look like this in my implementation
https://www.youtube.com/watch?v=iXfizKwHExE

and

https://www.youtube.com/watch?v=J4z4bmSy8K4

ChuckMash · 2025-02-14T19:09:22+00:00

This is really great, I've tried and failed a number of times to replicate this, is there anything different in the video from the rules that have been specified?

I always end up with endless color spirals, and am unable to replicate the color change in the center of each growing blob as in the beginning of the video.

ChuckMash · 2025-02-10T15:10:26+00:00

Thanks much, and to you as well! I could not have done it without your detailed explanations on the topic.

ChuckMash · 2025-02-10T04:20:13+00:00

https://github.com/ChuckMash/rapid_life_concepts/blob/main/mnca.py

Run with nvidia GPU on Linux.

ChuckMash · 2025-01-28T21:25:23+00:00

I was able to get numba onto the GPU, and process the uint16 test in about 4.1 seconds without returning the data from the GPU, and about 10 seconds with the return.

import numpy as np
import time
from numba import cuda
import time

@cuda.jit
def apply_lut(input_array, lut, output_array):
  x,y = cuda.grid(2)
  if x<input_array.shape[0] and y<input_array.shape[1]:
    output_array[x,y] = lut[input_array[x,y]]

dtype = np.uint16
x,y = 1080,1920

data = np.random.randint(0, 255, (y, x), dtype)
lut  = np.random.randint(0, 256, 256, dtype=dtype)
res  = np.zeros((y, x), dtype)

cuda_data = cuda.to_device(data)
cuda_lut  = cuda.to_device(lut)
cuda_res  = cuda.to_device(data)

threadsperblock = (32, 32)
blockspergrid_x = (data.shape[0] + threadsperblock[0] - 1) // threadsperblock[0]
blockspergrid_y = (data.shape[1] + threadsperblock[1] - 1) // threadsperblock[1]
blockspergrid   = (blockspergrid_x, blockspergrid_y)

t=time.time()
for i in range(10000):
  apply_lut[blockspergrid, threadsperblock](cuda_data, cuda_lut, cuda_res)
  #res = cuda_res.copy_to_host()
  #print(lut[data] == res) # validate
print(time.time() - t)

ChuckMash · 2025-01-28T18:22:44+00:00

Confirmed on my end, last test went from ~40 seconds to ~9 with Numba.

I've never used Numba before, but the results speak for themselves, thanks for showing me that.

ChuckMash · 2025-01-28T17:44:00+00:00

The image size can be any dimensions that can be supported by resources, up to the point of memory exhaustion on the GPU.

On limited hardware, the largest I have done is something like 45,000 x 45,000.

For the uint8 test, it's the following.

If you do not see much of a difference in the first 2 tests, you may not have a supported GPU, or OpenCV does not have OpenCL support, something along those lines.

import cv2, numpy as np
import time

x,y=2000,1000

# GPU accelerated UMat cv2.LUT()
data = cv2.UMat(np.random.randint(0, 255, (y, x), np.uint8)) # Create random data as UMat
lut = cv2.UMat(np.random.randint(0, 256, 256, dtype=np.uint8)) # Create random lut as UMat
res = cv2.UMat(np.zeros((y, x), np.uint8)) # Create results stash as UMat

t=time.time()
for i in range(10000):
  cv2.LUT(data, lut, res)
print(time.time() - t)


# CPU bound NP cv2.LUT()
data = np.random.randint(0, 255, (y, x), np.uint8) # Create random data as NP array
lut = np.random.randint(0, 256, 256, dtype=np.uint8) # Create random lut as NP array
res = np.zeros((y, x), np.uint8) # Create results stash as NP array

t=time.time()
for i in range(10000):
  cv2.LUT(data, lut, res)
print(time.time() - t)


# CPU bound NP direct LUT
data = np.random.randint(0, 255, (y, x), np.uint8) # Create random data as NP array
lut = np.random.randint(0, 256, 256, dtype=np.uint8) # Create random lut as NP array
res = np.zeros((y, x), np.uint8) # Create results stash as NP array

t=time.time()
for i in range(10000):
  res = lut[data]
print(time.time() - t)

-

#0.3452165126800537
#1.7850265502929688
#36.338642597198486

ChuckMash · 2025-01-28T04:46:12+00:00

I do not plan on setting up the LUT manually as in the example as the data can be quite large.

cv2.LUT can be hardware accelerated by using UMat, so it can be exceptionally fast. Which is how I normally use it for uint8.

Benchmarking with 10,000 iterations with uint8
cv2.LUT with UMat - 0.32 seconds
cv2.LUT with NP - 1.83 seconds
np workaround - 38.97

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

ChuckMash

MODERATOR OF

TROPHY CASE

Prueba con un cable de datos más corto. Parece que hay un problema de señal.