Yeelight Bluetooth Rotary Dimmer Switch YLKG07YL/YLKG08YL

[Ernst79]

Request from @latel for support for Yeelight Bluetooth Rotary Dimmer Switch (model YLKG08L) https://www.aliexpress.com/item/32973439343.html?spm=2114.search0104.3.17.6edd4cb7NgQMcK&ws_ab_test=searchweb0_0,searchweb201602_2_10065_10068_319_10059_10884_317_10887_10696_321_322_453_10084_454_10083_10103_10618_10307_10820_10301_10821_10303_537_536_10902,searchweb201603_51,ppcSwitch_0&algo_expid=18475432-ec47-461e-b642-4cf806469bf6-5&algo_pvid=18475432-ec47-461e-b642-4cf806469bf6&transAbTest=ae803_5

I think what we need is here [nccchirag/yeelight-ble-rotary-dimmer#1]{https://github.com/nccchirag/yeelight-ble-rotary-dimmer/issues/1)

[rezmus]

in our logs its always 00 00 00 at the end. im sure encrypted 6 bytes are 4097 event with 3 bytes payload which encodes all clicks/rotates. look at answer for miio cmd sent to lamp, it says dimmer use 4097 just like remote.

mibeacon has many versions. current is v5 afaik so probably dimmer is using older one.

[Ernst79]

@rexbut Any battery readings received, or is it still "unknown"

[syssi]

@Ernst79 The battery reading of my YLYK01YL is always "unknown".

[rexbut]

@rexbut Any battery readings received, or is it still "unknown"

Still no data for the battery after 48 hours

[Ernst79]

YLYK01YL Ok, I've removed the battery. I also updated the code slightly, such that you get two binary sensors, one for short press, one for long press. This is released in version 2.0.2-beta. If there are no issues afterwards, I'll release it as final on Sunday.

YLKG08L Regarding the YLKG08L, some (very) good news. We figured out the decryption of the messages :tada: , so we can add this one as well. It turned out that the YLKG08L is using the old (legacy) XiaomiMiBeacon format. I have to give all kudo's to @rezmus who found out about the legacy format being used and helping with the decryption. I will add this device as well, but will do that in a new point release (2.1.0-beta), hopefully tomorrow.

[Ernst79]

2.1.0-beta has been released, which adds support for the Yeelight rotating dimmer (YLKG08L).

As I had to rewrite a lot, please be aware that it could contain bugs, also for previously working devices. YLKG08L needs a 24 character key.

Let me know if the state corresponds to what you do. @rexbut, could you do some thorough testing of this release. For now I assume the following states

011003000103 - short press (1x)
011003000203 - short press (2x)
011003000303 - short press (3x)
011003000403 - short press (4x)
011003000503 - short press (5x)

011003000104 - rotate right (1 click)
011003000504 - rotate right (2 clicks)
011003001104 - rotate right (3 clicks)
01100300ff04 - rotate left (1 click)
01100300f504 - rotate left (2 clicks)
01100300f004 - rotate left (3 clicks)

011003010004 - rotate right (pressed) (1 click)
011003050004 - rotate right (pressed) (2 clicks)
011003110004 - rotate right (pressed) (3 clicks)
011003ff0004 - rotate left (pressed) (1 click)
011003f50004 - rotate left (pressed) (2 clicks)
011003f00004 - rotate left (pressed) (3 clicks)

011003010103 - long press (1 second)
011003010203 - long press (2 seconds)
011003010303 - long press (3 seconds)
011003010503 - long press (5 seconds)
011003010f03 - long press (15 seconds)

Questions I still have

• is the time of the long press in seconds?
• @rezmus told me that his friend missed a lot of advertisements (bad reception?) and that the advertisements are only send once. This means that you can miss some changes, do you experience the same

[rexbut]

@Ernst79 It works perfectly 🎉

[rexbut]

@Ernst79 Yes, the time is in seconds

[syssi]

My dimmer is called YLKG07YL. I assume it's identical but I cannot verify it because I'm unable to retrieve the token (no ceiling light with yeelight firmware around).

[rezmus]

@syssi do some hcidump and post logs here. i have workaround for missing ceiling light ;)

[rexbut]

@Ernst79 For a short press, I received 9 messages.

04 3E 25 02 01 03 00 54 88 C5 41 24 F8 19 18 16 95 FE 58 30 B6 03 D6 54 88 C5 41 24 F8 62 52 7A 05 BB C8 01 00 00 60 F0 
04 3E 25 02 01 03 00 54 88 C5 41 24 F8 19 18 16 95 FE 58 30 B6 03 D6 54 88 C5 41 24 F8 62 52 7A 05 BB C8 01 00 00 60 ED 
04 3E 25 02 01 03 00 54 88 C5 41 24 F8 19 18 16 95 FE 58 30 B6 03 D6 54 88 C5 41 24 F8 62 52 7A 05 BB C8 01 00 00 60 ED
04 3E 25 02 01 03 00 54 88 C5 41 24 F8 19 18 16 95 FE 58 30 B6 03 D6 54 88 C5 41 24 F8 62 52 7A 05 BB C8 01 00 00 60 EE 
04 3E 25 02 01 03 00 54 88 C5 41 24 F8 19 18 16 95 FE 58 30 B6 03 D6 54 88 C5 41 24 F8 62 52 7A 05 BB C8 01 00 00 60 F1 
04 3E 25 02 01 03 00 54 88 C5 41 24 F8 19 18 16 95 FE 58 30 B6 03 D6 54 88 C5 41 24 F8 62 52 7A 05 BB C8 01 00 00 60 F1 
04 3E 25 02 01 03 00 54 88 C5 41 24 F8 19 18 16 95 FE 58 30 B6 03 D6 54 88 C5 41 24 F8 62 52 7A 05 BB C8 01 00 00 60 EF 
04 3E 25 02 01 03 00 54 88 C5 41 24 F8 19 18 16 95 FE 58 30 B6 03 D6 54 88 C5 41 24 F8 62 52 7A 05 BB C8 01 00 00 60 EF 
04 3E 25 02 01 03 00 54 88 C5 41 24 F8 19 18 16 95 FE 58 30 B6 03 D6 54 88 C5 41 24 F8 62 52 7A 05 BB C8 01 00 00 60 F1 

[rezmus]

we already confirmed it's an issue with silabs_ncp_bt binary on mgl03 hub or chip itself. it only see 0 or 1 adv for dimmer, while for remote it seems multiple msgs. source of the problem is however still unknown.

[rexbut]

@rezmus Do you have a solution to have the beaconkey ? I'm testing with ylkg08y.md and mikettle to get the beaconkey but it doesn't allow me to decrypt the messages

# python3 demo.py connect F8:24:41:C5:3A:B6 950
DEBUG:mikettle.mikettle:Init Mikettle with mac F8:24:41:C5:3A:B6 and pid 950
Connect
Authenticating
DEBUG:mikettle.mikettle:handleNotification data (Handle:3, data: cc739e4007b897911ca33cf8)
DEBUG:mikettle.mikettle:token: 025ccba8800abdc12eb8ed83
DEBUG:mikettle.mikettle:HANDLE_VERSION b'\x00\x00'
DEBUG:mikettle.mikettle:test 0 : b'' :
DEBUG:mikettle.mikettle:test 1 : b'\x95\xfe' : 95fe
DEBUG:mikettle.mikettle:test 2 : b'\x18\x00' : 1800
DEBUG:mikettle.mikettle:test 3 : b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' : 000000000000000000000000
DEBUG:mikettle.mikettle:test 4 : b'\x00\x00' : 0000
DEBUG:mikettle.mikettle:test 5 : b'token' : 746f6b656e
DEBUG:mikettle.mikettle:test 6 : b'\x02\x00' : 0200
DEBUG:mikettle.mikettle:test 7 : b'\x00\x00' : 0000
DEBUG:mikettle.mikettle:test 8 : b'productid' : 70726f647563746964
DEBUG:mikettle.mikettle:test 9 : b'\x02\x00' : 0200
DEBUG:mikettle.mikettle:test 10 : b'\x86S\x0b\x12\xb7\xbe<\x80\x97\xea' : 86530b12b7be3c8097ea
DEBUG:mikettle.mikettle:test 11 : b'ver' : 766572
DEBUG:mikettle.mikettle:test 12 : b'\x18\x18' : 1818
DEBUG:mikettle.mikettle:test 13 : b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' : 0000000000000000000000000000000000000000
DEBUG:mikettle.mikettle:test 14 : b'wificfg' : 77696669636667
DEBUG:mikettle.mikettle:test 15 : b'\x08\x00' : 0800
DEBUG:mikettle.mikettle:test 16 : b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' : 0000000000000000000000000000000000000000
DEBUG:mikettle.mikettle:test 17 : b'eventrule' : 6576656e7472756c65
DEBUG:mikettle.mikettle:test 18 : b'\x08\x00' : 0800
DEBUG:mikettle.mikettle:test 19 : b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' : 0000000000000000000000000000000000000000
DEBUG:mikettle.mikettle:test 20 : b'authentication' : 61757468656e7469636174696f6e
DEBUG:mikettle.mikettle:test 21 : b'\n\x02' : 0a02
DEBUG:mikettle.mikettle:test 22 : b'H\x82\xc4\xc3y\x1e\xf2\x7fh\x15b\x9b\xd8`\x1c\x95|\xf2\xb9%' : 4882c4c3791ef27f6815629bd8601c957cf2b925
DEBUG:mikettle.mikettle:test 23 : b'sn' : 736e
DEBUG:mikettle.mikettle:test 24 : b'\n\x00' : 0a00
DEBUG:mikettle.mikettle:test 25 : b"A\xce\x81g\xe6:/ff\x81\x0c'" : 41ce8167e63a2f6666810c27
DEBUG:mikettle.mikettle:test 26 : b'beaconkey' : 626561636f6e6b6579

Source: https://github.com/rexbut/mikettle/

[rezmus]

@rexbut looking at the info you should be able to auth device using exactly the same mikettle code (with pid 950) and then read (write?) beaconkey like @archaron or @drndos did. maybe someone with bt experience can take a look. if this is not being handled within a few days i can provide alternative (not so neat) way to get the key via custom mi home app.

[Ernst79]

If you guys find out a method getting the beaconkey without ceiling light, please post it here, so I can add it to the FAQ.

The YLKG07YL from @syssi seems to use the same pid = 950 (B6 03) as the YLKG08YL.

[Ernst79]

@rexbut Did you get any states with rotate with value xx or rotate (pressed) with value xx? Is so, could you send me the numbers it displayed for xx, Or could you try when you make a real large turn on you dimmer. for now I assumed 1, 2 or 3 turns, but it might be possible that you could reach more.

    elif press == 4:
        if button == 0:
            if value == 1:
                press_type = "rotate right"
                dimmer = "1 turn"
            elif value == 5:
                press_type = "rotate right"
                dimmer = "2 turns"
            elif value == 17:
                press_type = "rotate right"
                dimmer = "3 turns"
            elif value == 255:
                press_type = "rotate left"
                dimmer = "1 turn"
            elif value == 245:
                press_type = "rotate left"
                dimmer = "2 turns"
            elif value == 240:
                press_type = "rotate left"
                dimmer = "3 turns"
            else:
                press_type = "rotate"
                dimmer = str("rotate with value " + str(value))
        elif button == 1:
            press_type = "rotate right (pressed)"
            dimmer = "1 turn"
        elif button == 5:
            press_type = "rotate right (pressed)"
            dimmer = "2 turns"
        elif button == 17:
            press_type = "rotate right (pressed)"
            dimmer = "3 turns"
        elif button == 255:
            press_type = "rotate left (pressed)"
            dimmer = "1 turn"
        elif button == 245:
            press_type = "rotate left (pressed)"
            dimmer = "2 turns"
        elif button == 240:
            press_type = "rotate left (pressed)"
            dimmer = "3 turns"
        else:
            press_type = "rotate (pressed)"
            dimmer = str("rotate (pressed) with value " + str(value))

[rezmus]

it's not constant value (1,5,17), it's range 1-17 (maybe more) based on how much you rotated right from last position. similar for rotate left.

[rexbut]

@Ernst79 Right: 1 to 20 Left: 255 to 236

However when I press it the value is always 0:

[rexbut]

@rezmus When the rotation is larger, the value is high. The last position has no influence on the value.

[Ernst79]

Ok, I think I will than change it to the actual number (now called value). Not sure how you call it in English.

• Rotate (20 x)
• Rotate (20 turns)
• Rotate (20 clicks)
• Rotate (20 swings)
• Rotate (20 steps)

I guess steps is the best word? what do you think? Left can be calculated as 256-value

[archaron]

Hi guys! Thank you for mention me. I've returned to make some investigations on this module. Please, keep in touch with my page.

Hardware

[rexbut]

@Ernst79 Yes, steps is the best word. I also think the value on the left should be 1 to 20.

[Ernst79]

Yes, of course, I will calculate that in the code as 256-value. E.g. if it sends 241, it will be rotate left 15 steps

[rezmus]

@archaron you can now decrypt yeelight dimmer adv payloads using mibeacon legacy decryption method and beaconkey. i saw on your github you managed to auth device and read beaconkey. can you share your code?

[Ernst79]

2.1.1-beta has been released, with an improved state of the dimmer.

For those who are interested, this is the logic I now use for the 0110 advertisements (remote, dimmer). Remote uses remote_command, remote_binary and press_type Dimmer uses press_type and dimmer

def obj0110(xobj):
    (button, value, press) = BUTTON_STRUCT.unpack(xobj)

    # remote command and remote binary
    if button == 0:
        remote_command = "on"
        remote_binary = 1
    elif button == 1:
        remote_command = "off"
        remote_binary = 0
    elif button == 2:
        remote_command = "sun"
        remote_binary = None
    elif button == 3:
        remote_command = "+"
        remote_binary = 1
    elif button == 4:
        remote_command = "m"
        remote_binary = None
    elif button == 5:
        remote_command = "-"
        remote_binary = 1
    else:
        remote_command = "unknown command"
        remote_binary = None

    # press type and dimmer
    if press == 0:
        press_type = "single press"
        dimmer = None
    elif press == 1:
        press_type = "double press"
        dimmer = None
    elif press == 2:
        press_type = "long press"
        dimmer = None
    elif press == 3:
        if button == 0:
            press_type = "short press"
            dimmer = str(value) + " x"
        if button == 1:
            press_type = "long press"
            dimmer = str(value) + " seconds"
    elif press == 4:
        if button == 0:
            if value <= 127:
                press_type = "rotate right"
                dimmer = str(value) + " step(s)"
            else:
                press_type = "rotate left"
                dimmer = str(256 - value) + " step(s)"
        elif button <= 127:
            press_type = "rotate right (pressed)"
            dimmer = str(button) + " step(s)"
        else:
            press_type = "rotate left (pressed)"
            dimmer = str(256 - button) + " step(s)"
    else:
        press_type = "no press"
        dimmer = None

[archaron]

@archaron you can now decrypt yeelight dimmer adv payloads using mibeacon legacy decryption method and beaconkey. i saw on your github you managed to auth device and read beaconkey. can you share your code?

I've found that info on some other sources, so not 100% sure that would work. But I'll try.

[archaron]

BTW, here is the firmware image, if you were interested in it.

[archaron]

Here is some strings from FW. As i can see, beacon key is stored @ location 0x77000 as firmware received it by the air(?).

F1.0.1_1
Telink tLight
telink_mesh1
yee-rc
consecutive_zero_count=%d
[arch_random]: %x
wificfg
productid
token
beaconkey
eventrule
authentication
on CCC write
on BeaconKey Write, len:%d
on EventRule Write, len:%d
on Token Read
on SN Write, len:%d
on WifiCfg Write, len:%d
on Auth Write, len:%d, v:%x
on Token Write, len%d
on Token CCC Write
on connected
on disconnected
on char written, h0:%x, h1:%x
[send notify], len:%d
out_of_mesh
(null)
12308<,
!'.28>
#(-27<AFL[
%|gg
0123456789abcdef
[D] [mible_state_machine]. cur:%d, e:%d
[D] flash write succ
[W] flash write fail
[D] mible_authTimeoutHandler
[E] SN timeout, clear token
[W] Weak SN timeout.
[E] mible_schedule_task: No Mem.
[D] mi_service, bond succ
[D] [mible_t1Handler]
[D] [mac]:%02x %02x %02x %02x %02x %02x
[D] [mible_onConnected]
[D] on char written, charIdx:%d, len:%d, data:
%02x 
[D] write rsp = %d
[D] retrive succ, 
[D] retrive token, %02x %02x
[W] flash read error
[E] mible_smtcfg_construct: last configuration is ongoing
[E] mible_smtcfg_construct: No Mem
[E] wifi uid length not match.
[E] wifi info not exist
[D] sn: 
[D] %02x
[D] 
[D] [mible_bindingCfmHandler]
[D] [mible_bindingCfmHandler]: Auth ack value
[D] Register succ, new token, encrypt sn, beaconkey.
[D] Not empty, mible_psm_save
[I] WEAK dev bind succ
[I] dev bind success
[D] mi_service, waiting SN
[D] Auth handler, %x
[D] decrypted auth, %x
[I] cloud bind succ
[I] cloud bind fail
Telink tLight
0123456789ABCDEF
%&'&
telink_mesh1
mesh_unpair
telink_mesh1

[andrewjswan]

For YLYK01YL i need bind key? Or?

[rezmus]

its plain, but if you randomly push some buttons it may switch to legacy encrypted (happend to my friend).

[keniji]

its plain, but if you randomly push some buttons it may switch to legacy encrypted (happend to my friend).

Many thanks, it's really a good news to get this progress...

I've both YLYK01YL and YLYK07YL, and I've tried the below things:

1. Directly add YLYK01YL and YLYK07YL (via yaml) with their MACs -- Three entites binary_sensor.ble_remote_binary_long_press_ylyk01yl and binary_sensor.ble_remote_binary_single_press_ylyk01yl and sensor.ble_remote_ylyk01yl are added, but they only have "unknown" status, no matter how I press the remote: -- No entity is added for YLYK07YL.
2. Follow the steps you provided, and successfully get the beaconkeys for both remotes.
3. Use the "encryption_key" option to add the beaconkeys for both remotes. -- Three entites for YLYK01YL are still in "unknown" status... -- An entity is added for YLYK07YL and it seems work normal: And btw it's detected as YLYK08YL of course...

Hey @andrewjswan, how about yours?

[rezmus]

hcidump your remote to confirm it use plain payload. not sure if @Ernst79 made it fixed plain or it use frame ctrl to check encryption type. about HA config can't help you, never used it ;)

[Ernst79]

It uses frame ctrl to check for encryption, so that should be OK. As @rezmus says, please make a HCI dump when clicking your remote.

I’ll update the name of the sensor to YLYK07YL/YLKG08YL and update the docs regarding the (partial) encryption of YLYK01YL

[andrewjswan]

@keniji I haven't tried it, I don't quite understand why I need this remote in HA, and I don't know how to determine its mac address. And it's in an area where the Yeelight button doesn't work well, so I'm not sure if this remote will work either.

[Ernst79]

@keniji sorry, I just remember that there is an extra check for the device type, before it will do the legacy encryption. I will add the remote in the next update

[syssi]

I was able to retrieve the BLE tokens of my YLYK07YL devices. Great work guys!

[Ernst79]

2.1.2-beta has been released, which

• adds support for decrypted YLYK01YL messages and
• updates the name of YLKG08YL to YLYK07YL/YLKG08YL

@syssi If I'm correct, I think the names of the devices are

• YLYK01YL
• YLYK07YL
• YLKG08YL

So, YK in the 07, and KG in the 08 device

I have to check the device not being added automatically (without encryption key). Will do that later

[syssi]

In my case the device is called YLKG07YL:

[Ernst79]

Hmm, ok. They make a mess of these numbers

I think the YLYK07YL doesnt exist, if you google it and check the pictures, it shows YLKG07YL

[keniji]

2.1.2-beta has been released, which

• adds support for decrypted YLYK01YL messages and
• updates the name of YLKG08YL to YLYK07YL/YLKG08YL

@syssi If I'm correct, I think the names of the devices are

• YLYK01YL
• YLYK07YL
• YLKG08YL

So, YK in the 07, and KG in the 08 device

I have to check the device not being added automatically (without encryption key). Will do that later

Hi @Ernst79 and @syssi, Yes, I made a typo 😂😂😂 The first 2 chars "YL" might means "Yeelight"; "YK" means "remote control" since it can be pasted anywere; and "KG" means "switch" as it needs to be wired to the light, really sorry to confuse you here.

I will try 2.1.2-beta later today after I get home, thanks again @Ernst79 👍👍👍

[keniji]

@keniji I haven't tried it, I don't quite understand why I need this remote in HA, and I don't know how to determine its mac address. And it's in an area where the Yeelight button doesn't work well, so I'm not sure if this remote will work either.

If you have a Yeelight light and your remote has been paired with it, please take a look at the last part of here about how to determine the remote's MAC. Also you can try lescan and press the remote's button to see if the MAC will show up, the MAC would probably begin with F8:24. One of my expected scenario is, to have a YLKG07YL to wired to a WiFi-light, e.g. a Xiaomi Philips Light, then I can use YLKG07YL to control the light. Furthermore, I can also hard-turn-off/on the light in case I need to reset it -- but firstly the YLKG07YL must not pair with a Yeelight light since I don't want 2 lights be controled by the same remote...

[Ernst79]

I've updated the instructions in the FAQ for the part about how to get the encryption key for V2/V3 legacy encryption.

Could you guys check if this is correct? @keniji Is it possible to get the TOKEN from the MiHome app as well (I now assumed that you used Xiami Cloud token extractor). In the post you refer to you show how to get the MAC from MiHome, but don't you need the TOKEN as well?

[keniji]

I've updated the instructions in the FAQ for the part about how to get the encryption key for V2/V3 legacy encryption.

Could you guys check if this is correct? @keniji Is it possible to get the TOKEN from the MiHome app as well (I now assumed that you used Xiami Cloud token extractor). In the post you refer to you show how to get the MAC from MiHome, but don't you need the TOKEN as well?

I use token_extractor.exe and it does not list my remotes. I think it's because the remotes are not connected to Xiaomi cloud directly: This tool/script retrieves tokens for all devices connected to Xiaomi cloud and encryption keys for BLE devices. So I still need rezmus's steps to get the beaconkeys.

I tried 2.1.2-beta but I get nothing updated, all BLE devices are with "unknown" status, including some like "YM-K1501" and "RTCGQ02LM". But ralling back to 2.1.1-beta is OK. Is there any troubleshoot I can do for it?

[rezmus]

@Ernst79 you should tag/ask guys from dimmer protocol reverse engineering issue (that 2y old one). i saw few of them confirmed in the past they could auth device and read beaconkey from it's characteristics. or maybe somebody can work on mikettle code mentioned above because auth should be almost the same. when it's done you don't need miio device or custom app anymore to get the key.

[Ernst79]

use token_extractor.exe and it does not list my remotes.

@keniji I meant the TOKEN of the ceiling light, as far as I understand it, you first get TOKEN and IP of the ceiling light, and with that info, you get the beaconkey from the remote/dimmer. My question was, how did you get the TOKEN of the ceiling light.

@rexbut is 2.1.2-beta working for you?

@rezmus I understand, but I wanted something in the faq for now, otherwise everybody starts a new issue "how do I get the key" 😄

[keniji]

use token_extractor.exe and it does not list my remotes.

@keniji I meant the TOKEN of the ceiling light, as far as I understand it, you first get TOKEN and IP of the ceiling light, and with that info, you get the beaconkey from the remote/dimmer. My question was, how did you get the TOKEN of the ceiling light.

@rexbut is 2.1.2-beta working for you?

@rezmus I understand, but I wanted something in the faq for now, otherwise everybody starts a new issue "how do I get the key" 😄

Well, I use token_extractor.exe to get the TOKEN for the ceiling light indeed 🤣🤣🤣

[Ernst79]

@keniji Don't you have errors in your log? I just tried it on my main HA installation, don't see any issue, including the encrypted one's. Otherwise, enable debug logging for BLE monitor (see faq) and show the logs.

[keniji]

@keniji Don't you have errors in your log? I just tried it on my main HA installation, don't see any issue, including the encrypted one's. Otherwise, enable debug logging for BLE monitor (see faq) and show the logs.

I got these errors:

2021-05-18 21:50:19 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/config/custom_components/ble_monitor/sensor.py", line 183, in async_run
    sensors = await async_add_sensor(mac, sensortype, firmware)
  File "/config/custom_components/ble_monitor/sensor.py", line 110, in async_add_sensor
    t_i, h_i, m_i, p_i, c_i, i_i, f_i, cn_i, bu_i, re_i, di_i, w_i, nw_i, im_i, vd_i, to_i, v_i, b_i = MMTS_DICT[sensortype][0]
KeyError: 'YLKG08YL'
2021-05-18 21:50:19 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/config/custom_components/ble_monitor/binary_sensor.py", line 135, in async_run
    sensors = await async_add_binary_sensor(mac, sensortype, firmware)
  File "/config/custom_components/ble_monitor/binary_sensor.py", line 82, in async_add_binary_sensor
    rb_i, sw_i, op_i, l_i, mo_i, mn_i, wr_i, b_i = MMTS_DICT[sensortype][1]
KeyError: 'YLKG08YL'

I tried remove/reinstall the component via HACS, remove the old entity which had been recognized as YLYL07YL before (I'm using YLKG08YL, but nothing changed. Should I try reinstalling HA? I'm using docker so that would not be complicated.

Update 1: Sorry my mistake again, mine is YLKG07YL. And YLKG08YL should not exist, it should be YLYK08YL.

Update 2: I search via Taobao.com and could not find YLYK08YL. I will see if I can find any picture to clarify the modules.

Update 3: OK, they're YLYK01YL, YLKG07YL and YLKG08YL:

[Ernst79]

@keniji I think HA is a bit stuck in the name change, its probably still stored with the old name in the entity registry. So, please first update to 2.1.3-beta with (hopefully) the correct name, as it has again a device name change, so better to do the update first.

After the update, do a HA restart and check if it solves the problem (probably not).

If not, try the following

• delete the device from the BLE monitor integration options, (select MAC at the devices option, click submit, type - at the MAC address to delete the device and click submit twice.

• Next, open the BLE monitor integration tile in the integrations menu, click on the dimmer device if it is still there and delete all entities of the dimmer, if present. (click on each one, and delete it)

• Next, go to Developer Tools, Services, and select ble_monitor.cleanup_entries, click on Call Service.

• Next, do a restart of HA. Hopefully this will solve the issue.

[keniji]

@keniji I think HA is a bit stuck in the name change, its probably still stored with the old name in the entity registry. So, please first update to 2.1.3-beta with (hopefully) the correct name, as it has again a device name change, so better to do the update first.

Thanks Ernst, I cleaned the old entities and now everything seems fine now:

Looking forward to find a way to "unpair" these remotes from Yeelight light so that we can use it somewhere else 😁😁😁