Thread/Zigbee Support

[arunoruto]

I am just getting into using TRMNL and I was thinking to hook it up at a "remote place", i.e., no solid WiFi connection there. I do use Thread and Zigbee devices and those not using a battery are used as a repeater, meaning my Zigbee/Thread coverage is much better than WiFi.
I was wondering if there are any plans to utilize something like the ESP32-C6 for such a support. I guess the amount of data shouldn't be much of a problem, since it doesn't need to be blazing fast. And if I am not mistaken, Zigbee/Thread is using even less battery, so it should be even more power efficient!

[yankobogdan]

Hi @arunoruto

As of now, there is no plan to redesign HW with C6 to support Zigbee/Thread
We are aiming to release the OG gen 2 version, which will have stability improvements and support for WiFi 5GHz

We understand that Zigbee/Thread coverage could be interesting for our users
In case we release the replacement board based on C6, would you be willing to consider buying it to replace it in your device?

[arunoruto]

As of now, there is no plan to redesign HW with C6 to support Zigbee/Thread
We are aiming to release the OG gen 2 version, which will have stability improvements and support for WiFi 5GHz

Thats totally understandable! It was more meant to see if someone else was interested in supporting an alternative connectivity option for low-powered devices. Since discussions are disabled for this repo, I thought to open up an issue about it :)

We understand that Zigbee/Thread coverage could be interesting for our users
In case we release the replacement board based on C6, would you be willing to consider buying it to replace it in your device?

A C6 doesn't cost that much, so yeah, would be eager to swap it out in my device and test a firmware!
I guess the main user base would be home-assistant users, where ZHA and Zigbee2MQTT are mostly used, just so you know what you are dealing with! In the Zigbee2MQTT database, there are devices with e-ink displays (more as a secondary item to display stats). Maybe there are some examples for which messages are sent and how to do it :) I am not much into such development, but I could be helping a bit if you need the help!

[bitbank2]

@arunoruto The TRMNL firmware currently sends large image files over WiFi. Doing this over ZigBee or Thread using repeaters would be much slower and use even more battery than the current implementation. A future product which uses slower RF transmission methods would need to switch to some non-image arrangement to make it practical.

[arunoruto]

@arunoruto The TRMNL firmware currently sends large image files over WiFi. Doing this over ZigBee or Thread using repeaters would be much slower and use even more battery than the current implementation. A future product which uses slower RF transmission methods would need to switch to some non-image arrangement to make it practical.

I was aware of the slow speeds, but I neglected how slow it is... The display has 800*480 = 384000 pixels. Lets assume we only want to transmit on and off states, we only need one bit per pixel, so we need to transmit 384kb. Zigbee offers transmission speeds between of 20-250kbps, meaning the slowest we can transmit a full image is about 20s and the fastest is 1.5s. This is just the raw simplified data and we assume no (lossless) compression is happening.
I guess rendering on the client would be more feasible in this case by sending data in an appropriate format (like JSON?) and putting everything in place on the MC.
This would bring a lot of overhead, especially for the MC, but an approach as seen by ESP-Home would be possible to implement. Each plugin has a library and the user has to choose beforehand which plugins they will use on the device. Only those will be compiled and put on the device, resulting in a minimal footprint!
If I have any time, I will try to play around with a C6, ESP-Home and Zigbee2MQTT at home and try to see if something like this is feasible :)