Devices for WS281x strip control over SPI #919
Conversation
WalkthroughThis update enhances support for WS281X and RGBW LED strips through SPI on Raspberry Pi 5. It introduces new classes for managing these LEDs, offering functionalities like SPI connection initialization, LED data management, and customization of white channel behavior. Moreover, the optional dependency on the Changes
Recent Review DetailsConfiguration used: CodeRabbit UI Files selected for processing (1)
Files skipped from review as they are similar to previous changes (1)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
for more information, see https://pre-commit.ci
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
Out of diff range and nitpick comments (1)
ledfx/devices/spi_ws281x_rgbw.py (1)
18-34: Ensure the description in theCONFIG_SCHEMAis clear and concise.Consider simplifying the description for the
white_modefield to enhance clarity and readability.
ledfx/devices/spi_ws281x.py
Outdated
| def activate(self): | ||
| try: | ||
| import spidev | ||
| except ImportError as e: | ||
| described = ImportError("Unable to load spidev module. If you are on a raspberry pi, or another SPI capable linux device, " | ||
| "you can install spidev with 'pip install spidev' inside the ledfx venv.") | ||
| _LOGGER.error(described) | ||
| self.deactivate() | ||
| raise described from e | ||
|
|
||
| self.spi = spidev.SpiDev() | ||
| try: | ||
| self.spi.open(self._config["spi_bus"], self.SPI_DEVICE) | ||
| except OSError as e: | ||
| described = OSError("Unable to open SPI device. If you are on a raspberry pi, " | ||
| "you may need to enable SPI in 'sudo raspi-config'. Otherwise make sure the device is not used by another process.") | ||
| _LOGGER.error(described) | ||
| self.deactivate() | ||
| raise described from e |
There was a problem hiding this comment.
Improve error handling in the activate method.
- described = ImportError("Unable to load spidev module. If you are on a raspberry pi, or another SPI capable linux device, "
- "you can install spidev with 'pip install spidev' inside the ledfx venv.")
- _LOGGER.error(described)
- self.deactivate()
- raise described from e
+ _LOGGER.error("Unable to load spidev module. If you are on a raspberry pi, or another SPI capable linux device, "
+ "you can install spidev with 'pip install spidev' inside the ledfx venv.")
+ self.deactivate()
+ raise ImportError("Unable to load spidev module.") from eRefactor to separate the logging and exception raising for clarity and maintainability.
Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| def activate(self): | |
| try: | |
| import spidev | |
| except ImportError as e: | |
| described = ImportError("Unable to load spidev module. If you are on a raspberry pi, or another SPI capable linux device, " | |
| "you can install spidev with 'pip install spidev' inside the ledfx venv.") | |
| _LOGGER.error(described) | |
| self.deactivate() | |
| raise described from e | |
| self.spi = spidev.SpiDev() | |
| try: | |
| self.spi.open(self._config["spi_bus"], self.SPI_DEVICE) | |
| except OSError as e: | |
| described = OSError("Unable to open SPI device. If you are on a raspberry pi, " | |
| "you may need to enable SPI in 'sudo raspi-config'. Otherwise make sure the device is not used by another process.") | |
| _LOGGER.error(described) | |
| self.deactivate() | |
| raise described from e | |
| def activate(self): | |
| try: | |
| import spidev | |
| except ImportError as e: | |
| _LOGGER.error("Unable to load spidev module. If you are on a raspberry pi, or another SPI capable linux device, " | |
| "you can install spidev with 'pip install spidev' inside the ledfx venv.") | |
| self.deactivate() | |
| raise ImportError("Unable to load spidev module.") from e | |
| self.spi = spidev.SpiDev() | |
| try: | |
| self.spi.open(self._config["spi_bus"], self.SPI_DEVICE) | |
| except OSError as e: | |
| described = OSError("Unable to open SPI device. If you are on a raspberry pi, " | |
| "you may need to enable SPI in 'sudo raspi-config'. Otherwise make sure the device is not used by another process.") | |
| _LOGGER.error(described) | |
| self.deactivate() | |
| raise described from e |
There was a problem hiding this comment.
The point of doing it as committed was to display the verbose error message also in the react frontend (which prints the argument of the exception).
There was a problem hiding this comment.
@bbbergh, thank you for clarifying the intention behind the current implementation of error handling. It's important that the frontend receives detailed error messages for better user feedback.
Considering your goal, we can still refactor the error handling to separate the concerns of logging and raising exceptions while ensuring that the verbose error messages are preserved for the frontend. Here's a suggested approach:
def activate(self):
try:
import spidev
except ImportError as e:
error_message = "Unable to load spidev module. If you are on a raspberry pi, or another SPI capable linux device, " \
"you can install spidev with 'pip install spidev' inside the ledfx venv."
_LOGGER.error(error_message)
self.deactivate()
raise ImportError(error_message) from e
self.spi = spidev.SpiDev()
try:
self.spi.open(self._config["spi_bus"], self.SPI_DEVICE)
except OSError as e:
error_message = "Unable to open SPI device. If you are on a raspberry pi, " \
"you may need to enable SPI in 'sudo raspi-config'. Otherwise make sure the device is not used by another process."
_LOGGER.error(error_message)
self.deactivate()
raise OSError(error_message) from eThis refactoring maintains the detailed error messages for the frontend and separates the logging from the exception raising, enhancing the maintainability of the code. Let me know if this aligns with your requirements!
New Learnings Added
User: bbbergh
PR: LedFx/LedFx#919
File: ledfx/devices/spi_ws281x.py:0-0
Timestamp: 2024-04-23T14:51:09.775Z
Learning: The frontend of the LedFx project displays the argument of exceptions, which is used for showing verbose error messages to the user.
Note: Learnings are effective only in the context of specific code segments. To apply general coding guidelines, please configure review instructions.
…spi_write if necessary)
|
Love it. Any thoughts as to creating a single device and having RGB or rgbw as an option for the device? And should we remove the ws281x device type at the same time as merging this you think? |
This is definitely possible, I just found splitting it into two device types a lot cleaner (theres different config options for white mode calculation and the color order selection, and the RGBW inherits from the RGB one, so theres no code duplication and the code paths are nicely separated). But if you prefer keeping the device type list short I can merge them together.
The ws281x device is currently completely broken (activate() never calls super().activate() and so the device never switches on), so I don't think anybody is actually using it. If we fix it, the only real reason someone might potentially want to use it is that it allows to use different pins, but I don't think thats enough of a reason to keep it around (it's also a lot slower, and some aspects of that are quite hard to change). Also, can you have a quick look if I'm doing anything wrong the the descriptions of the config options, because I really have no idea why they don't show up in the frontend. |
|
I think I'd prefer a single device with an option for RGB or RGBW just to remove duplication. I'll have a gander at the frontend, sorry I've been very busy. |
This adds two devices to control WS281x neopixel LED strips via the kernel SPI driver (through the spidev python package),
one for RGB strips and one for RGBW strips.
Highlights:
The spidev package is added trough a new "spi" extra in poetry.
Current issues:
Summary by CodeRabbit
spidevas an optional dependency to enhance SPI functionalities.