Migration and Maintenance Plan

[parker-int64]

Hi folks,

We sincerely apologize for the lack of maintenance on this repository over the past period; our priorities have shifted, leading to a change in our focus.

However, we will do our best to keep all external components up to date and maintain them.

🚀 Repository Migration

• Components currently maintained in m5stack/esphome-yaml will be migrated to m5stack/ESPHome, where they will be maintained going forward.
• These components will be gradually submitted as pull requests to upstream ESPHome.
• After the migration, m5stack/esphome-yaml will contain only YAML configurations and prebuilt firmware published through Releases.

We estimate to migrate all the components before the end of the year.

✏️Audio Product Renaming

The Echo product line is being renamed to the Voice product line:

Previous Name	Current Name	SKU
Atom EchoS3R	Atom VoiceS3R	C126-ECHO
Atom Echo	Atom Voice	C008-C
Echo Pyramid	Voice Pyramid	A167
Atomic Echo Base	Atomic Voice Base	A149

Related YAML configurations and firmware names will be migrated to the new product names.

Why migrating audio-related components?

To reduce GPIO usage, many M5Stack products share a single I2S bus. ESPHome currently does not provide duplex I2S initialization. To reduce configuration errors and latency, audio-related components will gradually move to n-IA-hane/esphome-audio-stack.
Many thanks to n-IA-hane for the incredible work enabling advanced native Espressif audio features in ESPHome!

What about power-management and I/O-expander components?

Some products make extensive use of power-management modules such as M5PM1, AXP2101, and AXP192, as well as I/O expanders such as M5IOE1, AW9523B, and PI4IOE5V6408.
Future products will primarily use M5Stack’s own M5PM1 and M5IOE1. We will prioritize supporting these components first, then gradually add support for the others.

How will display initialization be handled?
ESPHome already supports initialization protocols for many common display ICs, such as ST7798V and ILI934x. Many products with LCDs communicate over 4-wire SPI.
When no generic initialization protocol is available, we will first use the mipi_spi component with custom dimensions and init_sequence. For DSI displays, we will use mipi_dsi with the same approach.

What about custom communication protocols for Modules and Units?
Some Module and Unit devices contain dedicated MCUs running proprietary firmware to simplify communication with the ESP32 host. Supporting these devices also requires implementing corresponding ESPHome components.