The Great Thread of Fate - Formerly Cannot Resolve or Find Documentation

[Geefbird]

Searching for lights through HTTP Daemon not returning any lights present. Not sure where to go from here. WiFi is on, Lights should be discoverable and yet nothing shows up it just keeps refreshing.

[taburineagle]

Hi @Geefbird! Interesting... looking through the old versions of your post, it looks like you're using Windows. Can you see any of the unpaired Neewer lights in Windows' Bluetooth and Other devices control panel? If Windows can't see the lights, then NeewerLite-Python isn't going to be able to either.

[Geefbird]

Ok, editing this comment as well to just keep things short and not have 15 things to be read through. I have tried to see them in windows under bluetooth but they aren't coming up. They are BH30S lights which are both bluetooth capable and in the list of supported lights in your documentation. I don't know what is preventing them from being seen and I can't find any help with it on NEEWER or anywhere else for that matter. Appreciate any and all help that can be given.

[taburineagle]

Got you - although those other 15 comments help me to understand the problem better 🤣 Yeah, Neewer lights (except for a few of them that have a proprietary remote) don't use WiFi, the ones that communicate with the official Neewer app all use Bluetooth in one way or another, and those are the ones that NeewerLite-Python are written to work with. Your PC also needs to be able to use BLE (Bluetooth Low-Energy) devices, which most computers should be able to, although that's down to the Bluetooth chip on your motherboard or the Bluetooth dongle you use. How do you have Bluetooth set up on your PC?

Also, there is documentation for NeewerLite-Python, although I do admit, I need to update it badly

[Geefbird]

I just use the bluetooth chip in the MoBo but maybe that doesn't handle BLE so I might have to order one of these Neewer dongles for 20 dollars and give that a shot.

All personal issues aside thank you so much for writing this and putting together/out there for everyone I have wanted to do this for a really long time and have just never been able to sit down and give it an honest effortf. Plus my coding skills in general let alone in python are not great lol so something of this extent would take me months. Sincerely appreciative.

[taburineagle]

You're welcome, thanks for saying so! I've written several programs in other languages, but this project is actually my first grand-scale Python project actually, so I know what you mean 😊 This is the Bluetooth dongle I use, which is around $9 at Amazon and works pretty decently with the Neewer lights - or at least I've found it to work pretty well!

[Geefbird]

Wish I would have seen that before I ordered mine directly from NEEWER lol. It will be here tomorrow and then I will let you know how everything worked out and whether or not I was able to see my lights and get them set up. I really hope it works. This will be a total game changer for my lighting and stream immersion.

[taburineagle]

Ah, ha, timing is everything 😅 I hope it works too! I don't know if the Neewer dongles work with Bluetooth in general, or just a proprietary app that they use, but if it doesn't, I can definitely vouch for the TP-Link one.

[Geefbird]

the level of sadness that will be had if this one doesn't work is indescribeable lol

[taburineagle]

I know what you mean 😐 It wasn't this one, was it? That one doesn't do Bluetooth (it's for specific lights that use 2.5G control, but not Bluetooth... I think, I've not used one myself, so I'm not 100% sure on that one...)

[Geefbird]

Yea I think that is the one and now I am confused... and probably going to be very upset. That was the only dongle I found on NEEWER's site. I have been waiting 8 days for this stupid thing. Now I just want to cancel it

[Geefbird]

Well just to be safe I ordered the one you linked as well and it will be here today so if the one I got from NEEWER doesn't work then I have this one.

[taburineagle]

That's good, hopefully all works out with both of them honestly - yeah, sorry about the Neewer one, like I said, it might work, but I think it's working on a different standard than Bluetooth, so I'm doubting it.

[Geefbird]

I am trying to install the driver for the TP-Link dongle and it says it fails and asks if I have access to a Sys32 En-Us folder... which I am currently in right now but I keep hitting retry and it just keeps failing How did you get this driver installed lol

[Geefbird]

Ok so I got the driver to install, the dongle is set up my lights are turned on, I know they support bluetooth because they have infinity mode and are in infinity mode (which is NEEWER's Bluetooth) but it isn't finding my lights in the app, in the http server, or on the PC through the dongle. They are BH-30S lights so they should work. I can control them through bluetooth with my phone.

Appreciate any and all help, I am so worn out and frustrated lol

[Geefbird]

and when I run script I get OSError: WinError -2147020577 The device is not ready for use

[Geefbird]

and then to top off all of the annoying, frustrating, time wasting bits of the day as it turns out my motherboard does in fact support bluetooth low energy. So now I am extremely confused as to why I can't find these lights on my PC.

[taburineagle]

Hmm, so am I - I actually didn't need to install any drivers to get the dongle to work, it just showed up on my system. I'm not sure which version of Windows you're using, but it did auto-install on Windows 10. I'm curious why nothing is showing the light though, at the bare minimum, Windows itself should be seeing it - if you go to the Windows Bluetooth control panel (in Windows 10, it's Settings > Devices > Bluetooth & other devices > Add Bluetooth or other device > Bluetooth), does the light show up there? My lights do show up in that list (as well as a printer and a TV that isn't mine...)

NW-20220057&FFFFFFFF is a Neewer CL124, which is also an Infinity light.

[taburineagle]

Also, are you using the last released version (0.12d) of NeewerLite-Python, or the one that's currently the main commit? If Windows can see the light, but NeewerLite-Python can't, the older version (0.12) didn't have Infinity support - the new version I will be releasing soon (as well as the current main commit) do have Infinity support.

If you're not using the latest commit (last updated this morning), download the NeewerLite-Python.py file here and the ui_NeewerLightUI.py file here and see if that works any better.

[taburineagle]

Also (ha, multiple posts), you might already know this, but if the light is still connected to your phone's Neewer app (even if the program isn't currently the program running at the moment, but the light is still linked to it), nothing else will be able to access it, so that could also be an issue. You'd need to quit the Neewer app for the light to show up and be pairable on other devices.

[Geefbird]

Ok, so if the NW-2022 blah blah blah (lol) is a NEEWER light, then yes my computer is and has been seeing the lights, but the Python has never. I am going to replace the Python code with the codes in those two links. They don't actually go to a downloed but rather a text file so I will just copy and paste them and then run it. Maybe it was the lack of infinity support... I am hoping because I really want this to work lol. So so bad.

[Geefbird]

OMG OMG OMG OMG OMG!!! The change in the Python code to support Infinity totally fixed it! It found my lights immediately and linked them without issue! I am going to geek out now and try to get all of this stuff set up to work with StreamerBot and StreamDeck controlling them. Thank you so much! I don't even care that I wasted 30 dollars on dongles now lol. I am sure I can return them, or at least the one to Amazon.

[Geefbird]

Sooooooo lol, I feel terrible asking so many questions and feel like a huge pain in the ass... but I am trying to trigger the lights using the HTTP server Daemon, and it worked for the first request to turn on the light, but now when I try to trigger a second action to turn off the light or turn on the other light it says that the "Server requested an action, but we are already working on one. Please wait" and no matter how long I wait it just keeps saying that. Not sure what is going wrong or how to fix it. Even after turning off the HTTP server and switching back to the UI it says "Waiting to Send" when I try to do anything with the lights. Not sure what the deal with that is either. But hey! I Have them linked now lol. It is a great start.

[taburineagle]

Ahh! I'm glad you got it to work - I assumed you had the latest commit already, that's why I was confused why the lights weren't detecting. Yeah, I am very close to releasing a new version with all of that support baked in to it, but I have to test and troubleshoot all of the functionality to make sure it works perfectly before then, and the HTTP server is one that I admit I haven't fully put through its paces yet with all of the Infinity changes - I tend to focus on the GUI first, and then the HTTP server, and lastly the CLI. Apologies for the growing pains, I will try to check into that ASAP, because I'm getting the same result here. I might not have a chance to really get into it though until the weekend, but I will let you know how it's going when I have a moment to!

[Geefbird]

Yea no rush I can't imagine how long it takes to fully go through all of it and make sure all of the parts function properly. Looking forward to it with great excitement lol. I can try to figure out why it is breaking when an HTTP request is sent. I feel like it is continuing the request infinitely even once it is completed, processing it over and over without realizing it was successful or even if it fails, but I don't know for sure. I am just thankful for the code, the support, and as soon as it is working I am going to go nuts with this lol. Might even have to make a YouTube video about how amazing it is. Being able to have my wireless lights set up and turn them off from the UI is amazing as is, but when I can do all of the other stuff I have planned like triggering color changes, brightness, on/off, FX etc. with stream events, my heart rate and viewer interactions... yea, it's going to be a great day lol.

Thanks again for everything and best wishes on all of the checks and balances, I hope it doesn't take too much effort or cause nearly as much frustration as just trying to see the lights caused me lol.

[taburineagle]

You're welcome! I'm hoping you can get all of those things set up, it sounds like you have an awesome set up in mind! I actually might already have sorted the problem. I fixed one small error in the command processor for the HTTP server (I used the wrong variable name in one small section), and that should help the "The HTTP Server requested an action, but we're already working on one. Please wait..." error. Check the latest commit out and see if that resolves that - right click and choose to save the file for the NeewerLite-Python.py file. The ui_NeewerLightUI.py file hasn't changed, so you don't need to re-download that one.

[Geefbird]

Awesome!!

But this happened when I tried to run it lol

"Exception has occurred: ModuleNotFoundError No module named 'winrt' File "G:\Programs\NeewerLite-Python\NeewerLite-Python.py", line 51, in from winrt import _winrt ModuleNotFoundError: No module named 'winrt'"

[Geefbird]

I resolved that error but then there was another regarding python.lock, and then I ran the HTTP server and upon request it triggered the first, then said entering send mode or something and wouldn't let me send anymore requests.

[taburineagle]

Hmm - well, the winrt part of the program is only to solve a very old Windows error that would show up when launching the program on older versions of Windows that used _winrt as a Python library (Windows 7 basically), and the way I wrote the program, should not show that error (basically, what happens is - if the module exists, it does something that tells Windows that it's fine, and if it doesn't exist, it just goes past that part), so I'm not really sure why that showed up... because I didn't change anything with that section in that last edit, and honestly can just cut that section out completely on later Windows versions.

The python.lock error is usually when the program quits out, but when you go to start it up again, a lock file exists, as it didn't close properly the time before (I did this so that you could only run one instance of the program at a time, as only one instance can link to the lights at a time) - the best way to get around that is to use --force_instance on the command-line when launching the HTTP server.

python3 NeewerLite-Python.py --http --force_instance

Ha, still getting to the finish line... still getting there 🤣 The last version (the 0.12d one you were using before) is more or less rock-solid, although as you know, it's not Infinity-ready, so the latest commit is the best way to go at the moment.

[Geefbird]

Yea I just worked around it by changing it to winsdk since that works with more recent Python, and I am using 3.10 I no longer get that error as the library is current and working. I still get the another instance error but have just been deleting the file from appdata to move along with checking errors rather than forcing the instance and ignoring them. Once past the instance lock error I recieve

no running event loop File "G:\Programs\NeewerLite-Python\NeewerLite-Python.py", line 1787, in setUpAsyncio asyncioEventLoop = asyncio.get_running_loop() File "G:\Programs\NeewerLite-Python\NeewerLite-Python.py", line 3791, in setUpAsyncio() # set up the asyncio loop RuntimeError: no running event loop

I did take a screenshot of the terminal in a forced instance and what it is outputting when I send a command and then try to send another. The first "On" command works and then nothing after that, but it is no longer telling me it is already trying to process a command and to please wait.

[taburineagle]

Hmmmm! That's even more interesting - setUpAsyncio() is supposed to check for the running loop, and if it's not there, it creates it. So technically the RuntimeError is correct, but it's because of that exception that that function creates the loop directly afterwards. Also, NeewerLite-Python doesn't really need winrt or winsdk, that library is only imported for one very specific error with old versions of Windows (it used to complain something along the lines of "apartment was not disconnected", but everything would work completely fine), and I could probably just remove that entire section at this point with no issues at all, as that's literally its only function in my program.

How exactly are you running NeewerLite-Python, if you don't mind me asking? It sounds like you have it going through an IDE - or have a more stringent exception checker running (which is fine, I'm just curious where the errors are coming from, as both the _winrt and RuntimeError during setUpAsyncio() are correct, but in standard runtime, they're both handled in the script after those exceptions are thrown, so the Python interpreter is just saying "something's happening here, let's hope we have it handled"...) My usual runtime is Visual Studio Code, but I don't have as stringent an exception catcher running.

In your Terminal screenshot above, I see the last 2 URLs have %0A at the end of the address, which might also be adding to the issue of it not sending... It looks like you sent FA:06:FE:66:87:41 an on command, then CA:6F:17:4F:01:61 an off command twice, then sent FA:06:FE:66:87:41 another on command (but with that extra %0A at the end of the URL).

[Geefbird]

I am using VSC to run the scripts. Only program I like and am familiar with. Also realized I had raised exceptions ticked after you said that bit about you not having an exception catcher running so that is my fault lol, I am no longer getting the Asyncio error. Stupid me lol, I didn't even realize I had that on... I don't think I did originally and must have ticked it by accident or on purpose for some reason and forgot to turn it off.

Also I am seeing that when I use the UI to send commands after eash command it enters Send Mode, and then instantly leaves Send Mode allowing for another command. Where as when using the HTTP it never leaves send mode after entering it.

[taburineagle]

Ahhhh, got you - that makes a lot more sense 😅 I was going to say "why are they getting so many errors?", but then noticed what the errors were and went "ah, they must have 'Raised Exceptions' turned on" - VSC should be fine for running it, I usually do use that for debugging it, but try to use the normal Windows/Mac OS/Linux console to run it for normal testing. Try using the Windows console with the HTTP daemon if you get a chance, and see if running it that way changes anything. Shift-Right Click on the window you have NeewerLite-Python in, choose "Open PowerShell window here", then when that opens, type "cmd" and enter, and then either

python NeewerLite-Python.py --http or python3 NeewerLite-Python.py --http

If you are using VSC, how are you triggering HTTP daemon mode then? "Python File With Arguments"?

Interesting on the GUI and HTTP difference on send mode - the Terminal window you shared above does show it entering and exiting send mode several times, but you're saying that it doesn't actually exit send mode through the HTTP daemon. I'll have to check into that a bit more on my end - when I did that one tweak yesterday morning and tested it out, the HTTP server was exiting send mode correctly after every command.

[taburineagle]

OK, I just tested it here with a CL124 (which is not an Infinity light) and a SL90 Pro (which is an Infinity light) and the HTTP server turned the SL-90 off, on, off and then on again without issues here -

[Geefbird]

I am using VSC with arguments to launch HTTP. I am going to try using the regular console right now though and see if I can get better results. I just got off of work so I don't know how long I will be aawake, but if it works I might be up all night lol. Here is to hoping for great results.

[Geefbird]

Ok running with PowerShell still has the same issue. I guess what I was seeing with the UI is that it actually says "Going into send mode" and "Leaving send mode" while using HTTP does not say "Leaving send mode" so I assumed that it was not. If that is not the issue I don't know what it might be, and if it is working for you I am even more lost because nothing I do after the first request works.

[taburineagle]

Got you, got you - and I definitely got you in the tired department! I see, in the end of writeToLight(), which is the function that communicates with the lights, I wrote the return back to the main thread to say the phrase "Leaving send mode and returning to background thread" is only written to display when using the GUI, so that's why you're not seeing it in HTTP mode. I can change this.

OK, let's start from the beginning here - try deleting the light_prefs and __pycache__ folders in the NeewerLite-Python folder if they exist, re-download the .py files from the latest commit and let me know the order of operations of exactly what you're trying to accomplish, maybe there's some odd combination of things I'm not seeing on my end because I'm not aware of what to look for. I wonder if the issue could be that I've not tried it out with 2 Infinity lights at once in HTTP mode (it looks like in your Terminal window you have 2 BH-30s?) But you do say the GUI acts as it should, but the HTTP server is being finicky... One other thing to be aware of, if you try to send a command to one light, but are trying to still link to 2 lights, there might be an issue there too.

[taburineagle]

If needed, I can definitely write a version of the program to display a lot more debugging text which might indicate what is happening at every step in the pipeline too... I'm curious on why the GUI seems to be fine, but the HTTP server seems to not be...

[Geefbird]

Ok I deleted the two folders, re-downloaded the files, run the NeewerLite-Python.py using PowerShell instead of VSC, wait for it to say that both lights are linked, turn off the first light and then attempt to turn off the second light a few seconds later but nothing happens. I also tried to trigger both lights to turn on or off at the same time and that didn't work, it only turned off one. I did not take a screenshot of the terminal on that one as it presented no different information than this screenshot.

[taburineagle]

Got you - OK, let me do a breakpoint trace on my end and see what I can find out. I'm wondering if the reason I can't see it is I'm not testing with 2 Infinity lights, and something is sticking somewhere where it shouldn't. I'll change one of my other ones into an Infinity light and see how NL-P acts then.

Also, a few more questions - (ha, all the questions!)

• Just to make 100% sure, if you run the GUI and do the same steps, it works there, correct? So the message is getting muddled somewhere in the HTTP code and not the writeToLight() code
• If you run these commands in the HTTP server (changing the color temperature and not turning on/off), do they all send correctly, or do these ones also only let you send one command and then it stops?

http://127.0.0.1:8080/NeewerLite-Python/doAction?light=1&mode=CCT&temp=52&bri=50 http://127.0.0.1:8080/NeewerLite-Python/doAction?light=1&mode=CCT&temp=38&bri=100 http://127.0.0.1:8080/NeewerLite-Python/doAction?light=1&mode=CCT&temp=70&bri=40

[Geefbird]

Ok so I finally had a moment to try those out and I am not sure why but using light =1 and light =2 executes every request with no hang up. So for some reason using the lights actual mac address is what is causing the problem. I have successfully executed 6 requests using their numerical value instead of mac address with no issue. I am going to keep testing and see if I run into any other issue but I have to say I think you figured out my issue or at least a way around it.

[taburineagle]

Ah, excellent! That gives me something to check on, as Infinity lights use the MAC address in their commands to actually communicate with the light, so maybe something is getting jumbled there. Semicolons are how you do multiple lights at once - so it'd be something like:

http://127.0.0.1:8080/NeewerLite-Python/doAction?light=0;1&off

[Geefbird]

yea I got the multiples thing from the documentation. I had missed it the first time looking through it but read through it all again and got everything working. SO! It all works now, I have run a battery of tests and as long as I am using their numerical assignments versus their MAC addresses everything is flawless. Working with multiple applications, requests, and functions. Amazing. Thank you so much for going down this rabbit hole with me and getting it all sorted out. If you need any future testing on anything just let me know and I would be happy to return the favors. Appreciate all of the effort a great deal.

[Geefbird]

Ok I am back with another edition of I suck lol. I cannot for the life of me figure out how to get scenes to work. I have tried using SCENE and ANM and it for some reason is just changing my lights to about 5000K and 50% brightness. If you have any thoughts or an example of something that you have used and works I would appreciate it a lot because I have been at this for an hour almost trying different things.

[Geefbird]

and now the webserver won't even find my lights lol, but the UI still sees them. I am too tired to keep messing with this right now, and I need to go to work in an hour. Hopefully I can get this figured out.

EDIT: Now it sees them again lol... not sure what just happened but for like 20 minutes after trying to activate a scene it just stopped working so I restarted everything and then it wouldn't even see the lights. It is fine now though. Sorry for the constant barrage of messages.

[taburineagle]

Ha, it's cool @Geefbird - I'm glad that the light ID #s work with the HTTP server! I need to take a look at the MAC address system, as specifying a MAC address is just supposed to return a light ID# in the first place... but apparently something's not happy with that at the moment.

As far as the SCENES... ha, no, that edition of suck belongs to me - like I mentioned in the past, I do the GUI stuff first, and then the CLI and HTTP stuff - and Infinity FX are drastically different than the normal light FX, so that section needed a complete re-write. The FX work with the GUI, but I need to work on the CLI/HTTP subsystem to bring it in line with the GUI system. As the backbone of that system is in place, it shouldn't take a lot of extra work to bring all of that to the CLI/HTTP part of the program -- but it's not there yet... that's one of the reasons I haven't released the next version yet 😶

[Geefbird]

lol that edition of suck, I would like to steal that saying. That is too good. As much as I am sorry that it isn't there yet I am glad to know that it wasn't me just making mistakes and being dumb. I am sure you will reach your target soon enough, you've gotten a lot done and though I know there is a lot more to do it might just flow out of you effortlessly and you will be surprised how fast you got it all done. Maybe... lol

As for the scenes/animations Infinity light situation I found a temporary solution for me. Since everything else works I don't need my presets for anything and can set all of those up for the FX scenes and just use the http server to trigger those. Is it a perfect solution? No. It is however good enough and works just fine. Best of luck with all of the work ahead, I am sure I will be back with more questions at some point, and again, feel free to reach out with any testing requests if you need to since I have 2 infinity lights and that is something you are currently working on.

[taburineagle]

Hehe, I should just make that "edition of suck" thing my tagline 😁 I'm glad you have a method sorted out for the FX, even though it's not 100% ideal! I will definitely take a look at that ASAP - there are a lot of changes currently underway at work, so I might be in and out the next few weeks, but I will keep forging ahead as I can - I know what needs to be done with that at least, so I have a good starting point to get it implemented.

[Geefbird]

I am trying to help a member of my Twitch community set this up and he has a Gl1C and when he tries to control anything other than HSI through either the GUI or HTTP it doesn't work. GUI doesn't push any information on it to the console, and through HTTP it pushes this error, but when trying to trigger a preset it says "going into send mode" and then nothing after that.

[taburineagle]

2 things for this one -

• The Infinity protocol is a new one, and I need to add lights to the list of available Infinity lights as they pop up, so that might be one of those - I'm going to have to check a bit later on, I just got up (3rd shift woes)
• They're using an old version (2024-02-15-RC) - the latest commit (which I should have changed the date of when I commited it, but I - ugh - forgot) is 2024-03-02-RC That "list index out of range" issue was fixed in this commit a few days ago -

[Geefbird]

OOF 3rd shift.. I actually work overnights too lol

And yeaaaaa.... we just noticed that he wasa using old code and I came to tell you that when I saw your response lol