NEW VERSION COMING SOON... but first...

[taburineagle]

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:

• Support for Neewer Infinity lights
• Support for lights that use 17 effect settings, but aren't Infinity lights (they use a kind of hybrid communication protocol)
• Running a global/snapshot preset will turn any previously-turned-off lights on before setting that preset's values
• The ability, from the CLI, to control multiple lights via MAC address, while previous versions could only work with one
• A new slider GUI that renders more accurately on MacOS (previous versions had a MacOS-specific bug that would make adjacent sliders appear to move even when they weren't)
• New versioning designation (not 0.15f or similar, but year-month-date, which runs more into the old style of versioning I used for other programs I've written)

But in order to do that, I also need to do the following things first:

• [ ] Test all kinds of Neewer lights with the normal settings, snapshot settings, HTTP server, etc.
• [x] 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)
• [ ] Fix animation preset loading with the CLI

And I'd like to do these things too, but not necessarily before the new version:

• [ ] Re-write the documentation to bring it up to spec with the latest versions and additions
• [ ] Take new screenshots to show the new slider layout
• [ ] Add toggle-abilty for setting new lights as Infinity lights from the GUI
• [x] Work more on the HTTP server, add a "busy" indicator (as per #45)

[fribse]

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.

[taburineagle]

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...

[taburineagle]

@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.

[taburineagle]

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 😅

[fribse]

That looks very clear, and unmistakable, great progress for me when using it through HTTP :-)

[taburineagle]

@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.

[marnovo]

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.

[taburineagle]

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.

[marnovo]

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?

[taburineagle]

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.

@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.

[marnovo]

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):

• The desktop Live 2.4G App is being phased out and Neewer Control Center is the future on desktop.
• They are upgrading the app (firmwares too?) and "all" bluetooth lights will be be controllable on desktop by June/2024.
• They plan to make the lights work with their future Bluetooth USB dongle (those which have Infinity/BT) and current USB 2.4G dongle (those which have 2.4G channel sync), and "Wifi" (I guess for some streaming lights that have it).

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!