NEW VERSION COMING SOON... but first... #84
Comments
Fixed "Fix HTTP server coding that doesn't turn all lights on when running snapshot preset (GUI works fine for this, but HTTP server doesn't yet)" - I wasn't running the loop over the correct number of lights, so the result was always one less than it should have been...
|
That sounds great, thankyou for the great work, I hope the webserver will get a proper you update as well, a 'busy' indicator will help a lot. |
|
You're welcome! I definitely want to add that in, I need to figure out the best way to implement it. Maybe change the color of the page when a request is going through... |
|
@fribse - I think I have a way to go about adding the busy indicator. All of the HTTP requests are threaded, so I can check that thread state and report that back when it comes time to re-render the HTML page during a refresh. |
|
OK @fribse - I haven't commited it yet, but I have a working busy display for the HTTP server. When you request anything from it while another request is pending, it shows this message and hides all hyperlinks on the page until the server is ready to listen to commands again:
Eventually down the road, I'd like to replicate the GUI functionality in the HTTP server with working sliders for CCT, Temp, etc., but that's going to be a "down the road" project. EDIT: Just realized I said "down the road" twice... hmm...... keeping it 😅 |
|
That looks very clear, and unmistakable, great progress for me when using it through HTTP :-) |
OK, this commit affects the following issues: #45, #83 and #84 - this commit adds: - A busy indicator (including current status message, if the action takes more than a few seconds) to the HTTP server - this has been a request for a little while... - Adds the FX functionality of the Infinity lights to the HTTP server (and it should also take care of the CLI, but I haven't tested the CLI extensively yet) - Rewrote the JavaScript re-loading mechanic to use .replace instead of .assign, so there isn't a new history entry in your browser every time a page reloads - Adds a "pause delay" if you click out of the HTTP server webpage, like clicking on the URL: bar of your browser - this will make typing light parameters in easier - Adds the following parameters to the HTTP and CLI interfaces - bright_min, bright_max, temp_min, temp_max, hue_min, hue_max, speed, sparks, specialOptions - Reworked the getLightSpecs() function to return light parameters with less work (re-alphabetized the list of lights, refined the procedure for finding the current light, etc.)
|
@fribse - I've implemented it in the WIP-HTTP-Server-Mods branch! It shows that error message above when processing a request, and if the request takes longer than a few seconds (such as the initial "finding and connecting to lights" step), it shows the current status of what the program is doing. |
|
Let me know if you need help testing it. I have a Mac + 2.4G USB dongle + MS60C RBG COB light + TL60 RGB tube. Just FYI as of now both are found via "list", but only the TL60 responds to the commands. |
|
Sounds good! Sorry for the late reply @marnovo, the last few weeks have been kind of hectic 😅 The 2.4G USB dongle won't work with NeewerLite-Python though, as NL-P is only able to (at the moment anyway) control Bluetooth-controllable Neewer lights. Also, some lights use different commandsets - there's the "old" style, the "Infinity" style, and the "Infinity-style-but-not-actually-an-Infinity-light" style of controlling the lights, so the MS60C might not be properly configured in my default settings list. Looking on Amazon, it looks that model is an Infinity light, and looking at my codebase, I don't have an entry for that one (which means the program sees it and configures it as an "old" style light by default, which isn't correct), so I'll add that in on the next commit. |
|
Hey @taburineagle, thanks for the thorough reply! No reason to be sorry, take your time. Yes, learned about the USB dongle not working for these lights (I assumed—wrongly—that their "2.4G connectivity" of lights meant through the "2.4G USB dongle, but it's not. Also learned that Neewer plans to release a "Bluetooth" dongle in the next 1-2 months, that would work with these "Infinity" lights—I wonder if anything special about it (the "Infinity" bit) or just a regular Bluetooth 5.X dongle. In any case, despite the Neewer mobile app working fine with lights like MS60C or TL60 via normal mobile/laptop bluetooth, this BT dongle is apparently required to connect to lights like to the TL60 to their "Neewer Control Center" desktop app. If you want I can test this, just point me where in the code I should add and test them and I can make a PR. One thing I noticed with the TL60 (which works) is that sometimes when setting CCT mode, even with GM=0, it goes -50 green tint. Maybe related to the different protocols, or some of the math to normalize [0, 100] and [-50, 50] ranges? |
- Added TL60 to the list of lights to have specific parameters (2500-10000 CCT range, Infinity light) - this addresses #84.
|
@marnovo - You could do that - although I just did 😊 It's in the getLightSpecs() function. Try the latest commit out and see if that fixes it. The reason why the GM gets all wonky (or did, this latest commit should fix that) is the old style lights don't have a value for GM, and "0" is actually -50 when it sends the command, as "0" = -50, "50" = 0, "100" = +50. |
|
Hi @taburineagle! It seems to have fixed the GM shift in the TL60, or at least I didn't bump into the issue anymore as it was not consistently an issue. It hasn't changed the MS60C being recognized/listed but unresponsive to the commands. One thing I've done in parallel is to contact Neewer about it, and this is what I got from them (they're quite responsive on their Neewer reddit and user NeewerOfficial):
I was thinking in telling them they could open source their desktop app, that there's a growing OSS community around this, and they could get help and differentiate from others like Godox/Aputure/Zhiyun/Smallrig being the only open platform for light control. And then point them at this repo and keefo's (and others if you know), is you think that makes sense. Let me know! |
|
That sounds great @marnovo - sorry for the looooooooong delay! |
|
They really need to get their act together, and streamline this. If I were to buy today, I would not buy neewerlites when they use 3 different connections, then it would be the more expensive but sleeker Elgato |
|
@fribse - Yeah, I remember various reports coming in from people over the course of writing this program that "this light doesn't work with...", and I found CCT-only lights use a completely different command set than the RGB ones. Then Infinity lights came and reinvented the wheel again... I'm not really sure why Neewer keeps changing their systems just a wee bit differently than the last set... |
New version update: I have been working on an update (or various updates) to NeewerLite-Python for... well, since October-November of last year, when I've had a spare moment here and there, and I've been working at releasing an official new version, but I want to make sure all of my I's are dotted and T's are crossed before officially releasing the newest version, hence the delay. The new version (hopefully released in the next few weeks) will have:
But in order to do that, I also need to do the following things first:
And I'd like to do these things too, but not necessarily before the new version:
The text was updated successfully, but these errors were encountered: