Repository navigation
Adding non-WLED devices #83
Description
Hello Moustachauve & Greetings to Canada.
A fix was applied quite recently which actually introduced an unfortunate limitation, at least for me.
I have a bunch of WLED-based lights in my home and also some which are not WLED-based but still have a browser UI.
It used to be possible to basically enter any local IP adress and add it as a new device. Although it was shown as unreachable, the browser UI of the respective light came up when selected in the app. That was really convenient because I had just one app to control any lights with browser interface, WLED or not.
This "bug" was fixed, the app is now checking if new devices really are WLED devices and refuses adding any other addresses.
For me, that bug was a cool feature :-) and hence I would like to suggest making this an option; i.e. enable non-WLED devices as new devices.
Thanks & Regards, korkbaum
Activity
[-]Adding devices[/-][+]Adding non-WLED devices[/+]Moustachauve commentedon Apr 19, 2026
Hello! Thank you for the feature request. I can definitely understand how this would be useful. I could check in the future to find a way to allow non-WLED devices. I'll keep this issue open until then, but it might not be my #1 priority.
In the meantime, have you ever tried Home Assistant? It's great to regroup multiple devices in one interface.
korkbaum commentedon Apr 24, 2026
Thanks for getting back to me. Of course this in not #1 prio for you but I'm thankful you may consider this at some point. Home Assistant would certainly work but requires a dedicated always on-device and that would be over the top for the limited use case I would like to cover. BR korkbaum
smitty078 commentedon May 15, 2026
After working on #87 the thing that comes to mind for me is for when AddDeviceView validates through FirstContact, it throws an error that it was unable to connect - it would be easy enough to add an “add anyway” button - which I actually thought about being useful even for WLED devices, for a user that wants to set up even if their device list when devices are in fact offline (I ran into this myself during testing since my WLED devices are on a physical power switch that was off). Additionally, a toggle could be added to DeviceEditView to “ignore online status” which would simply list a device in DeviceListView as plain (not red or green) and allow it to be selected, thereby loading the web interface and remaining unobtrusive. The on/off switch and slider could also be hidden when WLED communication can’t be established. I can take a stab at this as I find it pretty useful to have this actually. The only problem with this is that this then opens the door to this app being a mini web-browser, where the device list can just have any old website added and that could bring a lot of support and other issues. In the well intentioned use cases, it can make sense, for a user that just adds any old website, it could be problematic. Up to @Moustachauve on if he wants to make that make sense for this project.
korkbaum commentedon May 15, 2026
Hi smitty078, thanks for chiming in. Indeed, users may have the idea to add e.g. cnn.com to their device list and I have no idea what that would look like in the app. While any support for that could be easily rejected, maybe any URLs with top-level-domain endings could simply be excluded from device additions? BR, korkbaum
smitty078 commentedon May 15, 2026
The issue with that is that I actually access my real WLED controllers from a TLD (it’s a reverse proxy serving through a TLD for valid https). There’s a huge range of use-cases it’s just a matter of figuring out what, if any, gating should be in place. I understand your use-case totally and it’s a nice convenience. That said, if it were my project I’d probably demand it stay to verifiable WLED only, and maybe consider expanding the scope to other verifiable web-based lighting controllers, which yeah, may be the way to go. What’s the other lights you’re controlling? The scope of API usage is small enough right now it would be fairly trivial to support a small subset of popular lights - maybe tasmota and esphome could be added easily enough, for example.
korkbaum commentedon May 15, 2026
The other lights I'm controlling are e.g. a staircase light (all steps illuminated) and a bedside light. Both have very, very simple HTML-Interfaces with just a toggle on/off button and a slider for dimming. However, it would be easy to add some simple API-response that could giva a value back to the app to 'authorize' app usage. I only have no clue what endpoint the app is expecting, what request is being sent and what the response would need to look like.