-
Notifications
You must be signed in to change notification settings - Fork 365
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
Add support for LED strips using UDP (e.g. WLED) #2145
base: dev
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems to work great on my end and others have had success with it so far. As user nzbr said this would be much better with direct integration through the JSON-API
Hey, sorry i'm taking so long to get to the PR's. This needs updating to the new IDevice interface, should be very simple to do: just change the GetSomething() methods to properties instead. Visual Studio's refactoring should do this correctly. Also manually adding the device in DeviceManager is not needed anymore. As for the http json api, would this be implemented on top of the current code or would it be another Device? |
The WLED API would be another device because it would only work with WLED whereas the UDP device is much more generic I have converted all the getters to properties. It should still work, but I can not test it, as Aurora crashes when I try to set a keyboard model (In |
weird, I didn't experience any keyboard layout issues. I can't test this properly as i don't have the required hardware but it runs fine otherwise. I don't know why the nzxtsharp submodule keeps coming back, but that's what's causing the CI build to fail. I can remove it if you'd like. Otherwise looks good. |
d5c02a6
to
a820c2c
Compare
Ok something must have gone wrong with my repo because I just cloned a fresh version, put |
I noticed this device always shows up as Initialized. Should it be disabled by default? is the initialization code supposed to work like that? |
This still shows up as initialized always. I think disabling it by default makes sense. |
Could we revisit this and instead of UDP consider e1.31 that would give the flexability of ANY rgb pixel device. strips strings bulbs whatever. |
I have now changed the initialization behavior so that the device only initializes if at least one IP is specified. Also, ports are now set by writing Having E1.31 support (as an addition) sounds like a good idea to me, though I have no idea how that protocol works tbh. I had started working on a WLED-API device integration with auto-discovery of WLED devices on the local network some time ago, but I have lost the code for that. I may start working on that again soon, but I can't promise anything |
hey guys. any updates on this? is this actually working? would love to integrate my multiple wled's with aurora. |
The project seems to have been moved to https://github.com/Aurora-RGB/Aurora I have not really touched this since my last comment, however it still seems to work on the latest version. If you want to give it a try, i packaged a version of Aurora that includes the UDP device: https://s3.eu-central-1.wasabisys.com/nzbr/Aurora-setup-v2-nzbr.exe EDIT: Aurora will try to update to the latest official release, you have to click cancel in the updater to keep the patched version |
thank you ! @nzbr |
List any issues that this PR fixes: fixes # , etc...
This pull request proposes the following changes:
Support is added for devices that receive color information via colors sent as raw bytes over UDP.
This protocol (which is called rawudp by Hyperion) is supported by WLED, a software for controlling led strips (#2027).
Known issues/To do:
The ESP platform (on which WLED runs) only supports up to 490 LEDs using this protocol (see Aircoookie/WLED#1019). To get around this, direct support for WLED using their JSON-API over HTTP would be a solution