platform: epaper_spi / model: JD79660 - compiling error

[Officer-on-duty]

Version

2026.3.0

What type of installation are you using?

Home Assistant Add-on

Browser

Firefox

What happened?

Traceback (most recent call last):
File "", line 198, in _run_module_as_main
File "", line 88, in _run_code
... sys.exit(main())
... return POST_CONFIG_ACTIONS[args.command](args, config)
... exit_code = write_cpp(config, native_idf=native_idf)
... init_sequence = flatten_sequence(init_sequence)
... for x in sequence

TypeError: 'NoneType' object is not iterable

How to reproduce

1.) Minimal Yaml:
esphome:
name: test

esp32:
board: esp32-s3-devkitc-1
framework:
type: arduino

spi:
id: spi_bus
clk_pin: GPIO5
mosi_pin: GPIO4

display:

• platform: epaper_spi
  model: JD79660
  dimensions:
  width: 800
  height: 480
  cs_pin: GPIO10
  dc_pin: GPIO09
  reset_pin: GPIO01
  busy_pin:
  number: GPIO03
  inverted: True
  update_interval: never

2.) Valid but compiling error
3.) Debugging with copilot, Gemini and ChatGPT, (GPIOS, framework, display settings, borads...., syntax) - no success
4.) Testet with standallone 2025.12 - no success

Expected behavior

compailing without errors

Relevant log output

Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
...     sys.exit(main())
...    return POST_CONFIG_ACTIONS[args.command](args, config)
...     exit_code = write_cpp(config, native_idf=native_idf)
...    init_sequence = flatten_sequence(init_sequence)
...    for x in sequence

TypeError: 'NoneType' object is not iterable

Screenshots

No response

[schdro]

firstly, might be wrong tracker (not esphome/esphome)

2.) Valid but compiling error
(...)
compailing without errors

Not really valid config: You used the base class as model (jd79660), but omitted the internal (undocumented=nonpublic API) field init_sequence: for how to initialize EPD. That one is vital for any EPD of epaper_spi.

You did not mention which precise JD7966x based EPD you plan to use, and whether board entry already listed. E.g. recently added Waveshare-7.5in-H (800x480) might just be yours.

Normally, you would

• either use matching existing board models (e.g. Waveshare-1.54in-G or Waveshare-7.5in-H) which have defined all fields like init sequence and were tested,
• or for use of generic chipset Python base class, pass own needed field provisions like init sequence -- like existing predefined board definitions do. More for expert use, e.g. if some board is missing. You must know what you do, e.g. not to break/wear your EPD HW with invalid init. But therefore the generic base also lacks field like init seq. For me, base class does not have documented public API characteristics, i.e. not encouraged to use commonly.

Debatable if better to report when some YAML config erroneously refers to generic chipset baseclass while lacking info.