New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Goal of the device profile #231
Comments
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 The 9W bulb must have the same chip (7231N), because 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? 🤔 |
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 |
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. |
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. |
Got Kanlux 9W and 11.5W A27 smart bulbs. The latter is already dumped and supported by tuya-cloudcutter, the smaller brother is not yet.
Yesterday I successfully flashed and integrated the Kanlux 11.5W into HA. Then I tried to use the same device profile in the hope that it also works with the smaller brother, but it failed.
Then I setup smartlife and checked the MCU version:
1.3.21
.So I retried the flashing, this time choosing by firmware:
1.3.21 - BK7231N / oem_bk7231n_light_ty
then randomly picking the first brand that showed up ("BNETA IoT").The device was successfully exploited and the firmware got uploaded. Note that I used the same libretuya firmware as for the 11.5.
Now it is integrated in HA, however regardless how I move the sliders it won't lit up.
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 text was updated successfully, but these errors were encountered: