The problem
On an imported board that drives an LED-driver hub (BP5758D, SM2135, MY9231, BP1658CJ), adding the driver from the component catalog leaves the hub's Clock Pin and Data Pin empty. The board knows the real GPIOs (they are in the upstream devices.esphome.io config), but they never reach the form, so the user has to guess the pins.
Reproduce
- Add the board Arlec 9W 92mm Grid Connect Smart RGB+CCT LED Downlight (ALD295HA) (bk72xx / CB2S).
- Open the device, Add Component, pick the featured BP5758D LED driver.
- The output step pre-fills (ID
output_red, Channel 3), then the wizard descends into the BP5758D hub dependency.
- Clock Pin and Data Pin are empty dropdowns.
Expected: Clock Pin GPIO26 and Data Pin GPIO24 pre-filled and locked (the device's real wiring), exactly like the I/O-expander hubs (e.g. the es32a08 sn74hc595 board) already pre-fill via the requires chain.
Root cause
The devices.esphome.io importer (script/sync_esphome_devices.py) only lifts top-level hub blocks that are referenced by a pin preset (the I/O-expander path). An LED-driver hub is bound by the output.<driver> platform's catalog dependencies and owns its own clock_pin / data_pin, so its top-level block was dropped; no hub featured component, no requires, no pins. Separately, _gpio_number could not parse libretiny P<n> pin names (bk72xx P26), so even the pins it saw were skipped.
Affected imported boards
arlec_grid_connect_smart_led_9w_92mm_rgbcct_ald295ha, havells_glamax_9w_b22_wifi_led_rgb_cct_bulb (BP5758D); anwio_a19_e26_rgbww_8_5w_light_bulb (SM2135); ledvance_smart_wifi_b40_5w_rgbw_e14 (BP1658CJ); zemismart_bulb_br30 (MY9231).
The problem
On an imported board that drives an LED-driver hub (BP5758D, SM2135, MY9231, BP1658CJ), adding the driver from the component catalog leaves the hub's Clock Pin and Data Pin empty. The board knows the real GPIOs (they are in the upstream devices.esphome.io config), but they never reach the form, so the user has to guess the pins.
Reproduce
output_red, Channel3), then the wizard descends into the BP5758D hub dependency.Expected: Clock Pin
GPIO26and Data PinGPIO24pre-filled and locked (the device's real wiring), exactly like the I/O-expander hubs (e.g. thees32a08sn74hc595 board) already pre-fill via therequireschain.Root cause
The devices.esphome.io importer (
script/sync_esphome_devices.py) only lifts top-level hub blocks that are referenced by a pin preset (the I/O-expander path). An LED-driver hub is bound by theoutput.<driver>platform's catalogdependenciesand owns its ownclock_pin/data_pin, so its top-level block was dropped; no hub featured component, norequires, no pins. Separately,_gpio_numbercould not parse libretinyP<n>pin names (bk72xxP26), so even the pins it saw were skipped.Affected imported boards
arlec_grid_connect_smart_led_9w_92mm_rgbcct_ald295ha,havells_glamax_9w_b22_wifi_led_rgb_cct_bulb(BP5758D);anwio_a19_e26_rgbww_8_5w_light_bulb(SM2135);ledvance_smart_wifi_b40_5w_rgbw_e14(BP1658CJ);zemismart_bulb_br30(MY9231).