dave-code-ruiz / elkbledom

Home Assistant custom component for LED STRIP NAME ELK BLEDOM
MIT License
77 stars 16 forks source link

ELK-BLE pattern support #49

Closed user154lt closed 10 months ago

user154lt commented 10 months ago

Hello there,

I saw in the readme that setting the pattern is not yet supported, if you are interested I have it working. I only own "ELK-BLE" lights so I am unable to test on the other types you support.

The bytes are:

0x7E 0x05 0x03 (patternNumber + 0x80) 0x03 0xFF 0xFF 0x00 0xEF

If this doesn't work for you, or you already know this, please disregard this and sorry to waste your time.

dave-code-ruiz commented 10 months ago

Great !! thanks !!! im try it and send you results

If work it is great, it will improve my code a lot

user154lt commented 10 months ago

Hopefully it works for you too! I have only tested on ELK-BLEDOM and ELK-BLEDOB strips. If you have any questions I'd be more than happy to answer as best I can.

I do have a repo on here where I have tried my best to document what I have found about these strips. I've tried to comment it as best I can, but if you do end up looking at it and something doesn't make sense please get in touch

dave-code-ruiz commented 10 months ago

oups !! i understand you send me bytes to read state of the led strip that i need so much .

I can set pattern and pattern speed with other bytes (there may be two ways to do it):

for pattern: write([0x7e, 0x00, 0x03, value, 0x03, 0x00, 0x00, 0x00, 0xef])

for pattern speed: write([0x7e, 0x00, 0x02, value, 0x00, 0x00, 0x00, 0x00, 0xef])

Thanks but i think your bytes dont help me to my code

thank you anyway

dave-code-ruiz commented 10 months ago

may be i could use you "mic" commands in the future, i have it in your repository

user154lt commented 10 months ago

Everything in my repo I got from a combination of hci logs and from the Lotus Lantern app logs. The data I have published to my repo is what I have tested to be working for the strips I have. The data that is sent to read the status I have not published to my repo because I haven't fully tested it yet, I believe you can get some information if you read from the same characteristic that is written to. Then some data is written to the characteristic, you read again and you get new information. I'm not 100% what all of the data I have read from the characteristic means, but some is definitely related to timing.

That being said, as you point out there it does appear that in some cases different data can be written to give the same result. For example you can change byte 8 of the color data from 0x10 to 0x20 and it just does exactly the same thing.