The "profile" (the one you've chosen by firmware version) is only needed to run the exploit - just like you said. You can't use an incompatible profile on a factory new device, because it won't exploit it and flash custom FW.

If you've configured ESPHome for the 9W bulb and flashed the same file to the 11.5W one, the firmware will boot up provided that both use the same chip (T/N).

But since the firmware is configured to the specific GPIOs, that other bulb can use different pins. That's why moving the sliders might not do anything.

As long as you have esphome running, the device is not broken. You can just OTA-flash another firmware with different pin config.

Thank you for the nice explanation.

The working configuration I used for 11.5W is based on the generic-bk7231n-qfn32-tuya board.

The 9W bulb must have the same chip (7231N), because
a) the device profile I used seems to be for n
b) the firmware did boot (I could access the configured webserver for example) so based on your answer this also means I selected the correct board in esphome

If I understand you correctly the above would mean that the only thing I am doing incorrectly is the configuration of the pins.

I know that the brightness of the different channels is adjustable, which probably means only PWM pins are relevant from your pin mapping table.

Or maybe I managed to kill the leds just by uploading the firmware / starting it once? 🤔

Or maybe I managed to kill the leds just by uploading the firmware / starting it once?

Probably not. I'd try attaching 6 PWM light outputs on pins PWM0 through PWM5. You'll have 6 distinct sliders and you'll be able to check which does what. You'd better initialize them as OFF or with low brightness, so that if all of them (RGB+CW/WW) start together, it won't overload the power supply.

I added them all as separated monochromatic lights with "ALWAYS_OFF" as restore mode. Unfortunately I could not get any of the lights lit. Any other ideas? 😬

It's possible that the bulb has a LED controller, using I2C for example. Without knowing what controller is there, or having the stock firmware dump, you can only guess but that'll take ages. You can try popping the diffuser off, it's most often easy to mount it back.

As opposed to the 11.5W version this one has a BP5768 controller in it.

Do you think it is possible to create a dump using those connectors coming from the "base"? Atm I would prefer not to further disassemble it, as I don't consider it safe to use after once playing around the 220V part.

I believe you meant BP5758. There are at least a few configs for ESPHome using this chip on our Discord server. Here's an example:

external_components:
  - source:
      type: git
      url: https://github.com/Cossid/esphome
      ref: bp5758d
    components: [ bp5758d ]

bp5758d:
  data_pin: D1
  clock_pin: D0

# Individual outputs
output:
  - platform: bp5758d
    id: output_red
    channel: 3 # Valid channels are 1-5
    current: 28 # In mA, valid values are 0-90, default is 10.
  - platform: bp5758d
    id: output_green
    channel: 2 # Valid channels are 1-5
    current: 28 # In mA, valid values are 0-90, default is 10.
  - platform: bp5758d
    id: output_blue
    channel: 1 # Valid channels are 1-5
    current: 28 # In mA, valid values are 0-90, default is 10.
  - platform: bp5758d
    id: output_coldwhite
    channel: 5 # Valid channels are 1-5
    current: 50 # In mA, valid values are 0-90, default is 10.
  - platform: bp5758d
    id: output_warmwhite
    channel: 4 # Valid channels are 1-5
    current: 50 # In mA, valid values are 0-90, default is 10.

light:
  - platform: rgbww
    restore_mode: RESTORE_DEFAULT_OFF
    name: "Light"
    red: output_red
    green: output_green
    blue: output_blue
    cold_white: output_coldwhite 
    warm_white: output_warmwhite 
    cold_white_color_temperature: 6500 K
    warm_white_color_temperature: 2700 K
    color_interlock: true

Note that you probably need to tweak the "current" values somehow, as well as the data and clock pins.

Wow, this starts to get a bit too complex to me 😆

Unfortunately it is definitely BP5768:

Btw. do I need a similar configuration for BP5778 (11.5W) as well? I used just simple ledc pins there. It behave strange though so in the end I switched to monochromatic warm white only so at least I can do proper dimming in the evening.

BP5778 is controlled using PWM, so there's no driver needed. BP5758 is using I2C, there's no info about BP5768 at all, but it's probably I2C as well.

Indeed BP5768 looks like I2C: https://m.ic37.com/htm_news/companynews/1222704.htm

There is a table on that page "comparing" BP5768 vs BP5758. If I only understood a word of it...

It appears the BP5758D driver probably works for this, it looks like the 5768 is a 10-pin version with extra efficiency built-in, but the images linked appear to indicate it uses the same I2C communication protocol. We'd need to find a datasheet with I2C data to be sure though.

So I questioned myself: is the device profile only relevant for finding a way to exploit it, i.e. if I got a custom firmware on it, it doesn't matter which profile I used? That would mean that I just can't use the same esphome configuration as for the 11.5W (which would be pretty strange though).

Or is the profile also setting things internally meaning that my device is now broken regardless how I configure esphome?

The goal of the device profile is not clear to me.

The profile is related to how the firmware is compiled. Some firmwares are compiled to be specific to a single device, and some are compiled to cover a class of device (light, switch, etc) and allow configuration to each model. The profile is the part that identifies how to exploit the device.

Beyond that, tuya often has a "user_param_key" configuration that is specific to the device (we save this as "device_configuration" in device.json) when it shares a profile with many other devices.

Many devices can use the same profile, but that doesn't mean they are directly configured the same, just that they use the same firmware code and can be individually configured to use it.

Closing this, as the question has been answered. The LED driver and device configuration are beyond the scope of CloudCutter.

If you are able to dump the device using lightleak, we can likely tell you which pins the LED driver are mapped to so you can try the BP5758D LED driver in LibreTuya/ESPHome.