Devices are coming on to the market which report as IDL or ISP lights but which use a different protocol. Support for these lights can be added by a sample of the lights will be needed OR the gathering of btsnoop debug logs from an Android device. If you are willing to help gather the data and test the new code, please log an issue.
- On / Off
- Set RGB colour of entire strip
- Set DIY LED patterns (not supported in Home Assistant)
- Set brightness
- Set effect
- Bulk paint entire strip using collections feature
- Automatic discovery of supported devices in Home Assistant
- Discovery of current light state
- On-chip timer functionality
There is a Home Assistant custom component to let you control these lights.
Add this repo to HACS as a custom repo. Click through:
- HACS -> Integrations -> Top right menu -> Custom Repositories
- Paste the Github URL to this repo in to the Repository box
- Choose category Integration
- Click Add
- The repo should show up in HACS as a new integration. Click on it and choose
DOWNLOAD. - Restart Home Assistant
- iDeal LED devices should start to appear in your Integrations page
There are a few other tools in this repo that might help you improve support or test your own lights.
- The btsnoop directory has a few HCI log dumps if you want to look at the raw values
aes_decrypt.pywas used to test the encryption implementationatt_protocol.mdhas notes on the protocol and the Android companion app
As bugs are fixed and new features are added it might be necessary to delete your existing devices and re-add them. If you experience strange behaviour after an upgrade please try to delete the device and re-add it. If this doesn't help, open an issue describing the problem.
I have bricked one set of lights by sending invalid data to them while building this integration. Use this repo at your own risk. You should be careful when sending bytes to these lights which are outside of the already discovered values.
You can read more on this here: https://www.whizzy.org/2023-12-14-bricked-xmas/
As far as I can tell this integration does not use any unsafe values by default. If you know otherwise, please open an issue, ideally with an accompanying PR.