Multiple light control/different settings

[shootyourshotTV]

Is there a way to send different settings to different lights in one commands or to have python run commands faster? I use the HTTP Server Daemon

I have three Neewer 530 lights for streaming as my lighting and I currently am making due with operating all my lights with the same settings. I tried to run back to back commands with settings directed at specific lights but it was unreliable because some programs wont allow a delay between commands and Im getting "The HTTP Server requested an action, but we're already working on one. Please wait..." response.

I would like to have different settings with different lights but its proven really difficult to get it done.

[fribse]

I do that by having a preset for my lights, and I then just set that preset is http. I have one preset to turn them on, and one to turn them off

[shootyourshotTV]

So I've made some presets which operate fine through the GUI but when I try and do it through CLI via steamdeck, one or more of the lights dont change. I also get this too

[shootyourshotTV]

it just locks up if i try to run an animation preset

[taburineagle]

Interesting - I'll have to look into those... it looks like the second issue is the HTTP server is expecting something other than an animation preset... the first one is a new version of Bleak changing how it reports the signal level. Give me a few days to check into that and I'll report back when I've had a chance to check those out!

[shootyourshotTV]

thanks for looking into it! Im sure you noticed but I accidentally said CLI when I meant HTTP. Just a little more information incase its useful. Ive changed versions of python (3.7 to 3.9) and redownloaded/upgraded (0.12d to 0.13) and those didnt solve the issue of not all the lights changing when a preset is used.

My rssi isnt the best but the furthest one from the antenna is only 4 feet away (id 3) and the other two lights are within 2 feet. Ive put the antenna right next to them and it doesnt seem like theres much difference in strength. All the lights have seem to of had issues transitioning from one preset to another via http.

[taburineagle]

OK, @shootyourshotTV - I figured out what the problem was with the HTTP server and loading animation presets. I'm not sure why, but I had the argument being passed along wrong for the parameter that sends the command. I've fixed that, now all should work well when using animation global/snapshot presets in both the GUI and HTTP server.

[shootyourshotTV]

thank you so much for the work youve done @taburineagle. I replaced the NeewerLite-Python.py file in my folder and tested it out. Im happy to report that animations work but I'm sad to report that I'm still having the same issue with lights not changing via http. Most of the time the 530 (not pro) is the one to stick.

Some problems I've noticed consistently and are replicable when triggering http via the streamdeck:

• After a successful change, follow up consecutive triggers made after ~1 second but triggered around ~2 seconds, will consistently succeed without issue
• the 530 consistently will fail to be triggered ~3 seconds after the last successful trigger
• Custom Global presets seem to more consistently trigger the 530
• 3+ retries of a desired preset seems to get through but I've had 7+ retries before it would change

[taburineagle]

Got you - definitely glad to hear that the animations are good now, but that sucks about the issues triggering the 530. I'm not sure if I can really fix much of that though, if it is indeed a signal issue. According to the screenshot you posted before, the RSSI for the 530 is around -76dBm, which is low... usable, but iffy, almost like it's just barely connected to the Bluetooth antenna on the PC that connects to the Streamdeck. The Bluetooth in the light itself might not be as strong as the 530PROs, but I'm not sure about that one. It would be nice if Neewer had a hardwired control scheme as well as the Bluetooth for more reliable control, but that would also most likely increase the price as well 😑.

Also, just double checking, do you have the same issue with the GUI and the 530, or is it only the HTTP server that has that issue? I saw you mentioned the presets work in the GUI before, but do they have the same issue as consistently as the HTTP server does?

[shootyourshotTV]

I did some arranging with the antenna placement and got the best signal I could. You may be right that the 530 bluetooth might be weaker than the pros cuz I can put my anntennas right next to it and it can still read -80.

I do not have the same problems with the GUI at all, it works 100% of the time.

[taburineagle]

@shootyourshotTV - got you, got you - sorry for the long response time, I've been extremely busy this week. I'll have to check to see how I have the routine set up to talk to the lights for the GUI vs the HTTP server.

[taburineagle]

@shootyourshotTV - Ha, again sorry for the long response times... it's been one wicked month, sorry to say! 😑 I hope to check more into this during the weekend!

[shootyourshotTV]

No worries! I understand that this is a hobby project and not your job so I'm patient! thank you for taking the time!

I am running into a new problem that has completely halted my use of the http server and GUI, not really sure whats happen but this is what I get

[taburineagle]

Thanks @shootyourshotTV - I appreciate the understanding! I've been away for the last week too, so that's an even longer delay... 😅 Hmm, that looks like a Blink issue, I really need to install a VM to see how the new Blink/Python versions work with NeewerLite-Python, because it appears that they've changed some things under the hood (the RSSI warning is one of them, but they may have made other changes I'm not aware of yet)...

[taburineagle]

OK @shootyourshotTV - still not 100% there, but I have added a new commit that should solve the BLEDevice.rssi and AdvertisementData.rssi deprecation warnings. Bleak changed a few things in version 0.19, so I had to query the device information a bit differently to compensate for those. But at least that specific issue should be sorted out.

[shootyourshotTV]

Thank you so much for looking into it and figuring out a way to fix it! I look forward to the eventual update and getting back to using lights for stream!

[taburineagle]

You're welcome! I still need to delve into the HTTP server to see why it's sticking.

[PoizenJam]

Revisiting this issue, specifically the point mentioned in the OP: Is it indeed not possible to send simultaneous, independent commands via the HTTP daemon? something like-

doAction?light=MAC1;MAC2&SOME_SETTING&MAC3;MAC4&SOME_OTHER_SETTING

I have tried without much luck, but could be the formatting my command incorrectly. If not possible, could this feasibly be implemented? Or, alternatively, allow for the addition of an arbitrary number of presets to the preset config file (even if they are not visible in the 8 button GUI)?

Like OP, I really enjoy using this program for streaming- and I even started having it react to events like 'Follows' and 'Cheers' by launching HTTP commands with Streamer.Bot. But I believe I need to rely on presets if I want to send independent commands to different lights, which can be limiting.

Suffice to say, thanks for all the work you have done so far.

[taburineagle]

Hi @PoizenJam - you're welcome! Yeah, at the moment, you can only send one command at a time via the HTTP server, because I'm limiting the length of the URL that's sent to the server to less than 159 characters at once for security reasons (so you can't send a URL that's ridiculously long and cause buffer issues with the HTTP server) - presets will do it, but I could look into sending multiple commands in a future version.

[PoizenJam]

Good stuff! In the meantime, I’m gonna fork it and take a crack at a mod to allow an arbitrary number of presets in the preset file (even if they don’t have associated buttons in the GUI). That would be a hacky workaround in the meantime.

I do have a tangential question, and you might know this. I can only send a successful command once every ~250ms. Any faster and it usually fails. Is this a limit of the lights themselves or the program? It occurred to me that custom animations would be possible if the script could be configured to accommodate rapid changes; I.e. <83ms, the equivalent of >12fps).

Could be a bandwidth limitation?

[shootyourshotTV]

im glad to see someone else is as passionate about rapidly changing light colors with presets as I am. Im here for updates

[shootyourshotTV]

@PoizenJam with the 530 lights, if you use the neewer app to control the lights, theres no delay. you can click and drag through the color wheel and the lights change along with it

[taburineagle]

The NeewerLite-Python GUI is equally responsive when dragging through the hue values @shootyourshotTV 😄 The thing with the HTTP server is I wrote it as a Stream Deck-esque controller that wasn't intended to be used in a real-time kind of way like the GUI (or even the Neewer app) is. Turn the lights on during a livestream at the start of the show, maybe dim them for a specific scene change, off at the end of the show, etc., etc., but not long continuous changes over an extended period of time (like going from hue 0 to 360 in a period of a few seconds in HSI mode), which is one of the reasons I wrote snapshot/global presets, to do multiple settings for multiple lights at the same time. The HTTP server probably could be engineered to do things like that, but not as I currently have it set up - it would need a better interface to the program itself that I would need a whole new set of logistics for (like CSS sliders sending data continuously to a thread, which is similar to how the GUI works) that would send commands in a different way than simple one-time HTTP PUSH/GET requests.

Multiple extra presets theoretically should work @PoizenJam - I mainly just made 8 as it was a good point to start from.

[taburineagle]

Mainly what I'm saying is, all in due time - I'm one person trying to do 12 things on 24 projects with about 30 minutes a day to do them all... and that's excluding the day job 😄

[taburineagle]

One thing I could theoretically do (and this is in a much later revision) is get a version of the HTTP server to the point where it has parity with the control the GUI has, and then make NeewerLite-Python work as only the HTTP server interface and no longer need PySide2. Looking extremely forward, that would be a game changer in a lot of ways...

[PoizenJam]

Thanks for the response! To be honest, I wasn’t sure where the bottleneck was for the rate of change, but I did have a feeling it was the HTTP Server.

Parity with the GUI controls would absolutely be game changing. One of the biggest limitations of the Neewer lights are the scenes; limited in both number and use case. The ability to send a continuous stream of values in a programmatic way basically enables the user to create custom scenes using simple scripts. I attempted a crude version of this with streamer.bot using sequences of [http command] + [delays], but of course limited to about 250ms / 4fps. Shorten the delay window enough or allow continuous change formulas for CCT/HSI modes, and the possibilities are endless! Neewer’s own app can’t even do that.

To be sure, this project is already game changing. There wasn’t previously a good way to control Neewer lights on Windows whatsoever, after all! So this is all gravy now :) I can appreciate having way too many concurrent projects and not enough time!

[taburineagle]

Thanks! Ha, I think that's pretty common with projects, there's either too much going on at once, or nothing at all 😅 I've wanted to do something similar to animations for a while, where you can theoretically keyframe a setting over a period of time, it would be amazing if the lights supported such things natively, but it would take a constant stream of Bluetooth commands to do it. Technically doable (the GUI can kind of do this, in the "kind of" that's limited to slowly dragging a slider from left to right), but it would be so much more smooth if the lights just had some sort of native animation protocol.

I did do a little research this morning on possible solutions for the parity issue - basically, I need a JavaScript/AJAX front-end (like a slider or series of sliders) that talk continuously to a POST callback in the Python script itself... doable, but I'm not as well versed with JavaScript/AJAX yet to pull that off... yet. Although NeewerLite-Python was one of my first large-scale Python projects also, so everything has to start somewhere...