Enhancement request: Busy signal on HTTP server

[fribse]

Hi @taburineagle
I hope you still work on this from time to time, it's a much appreciated project, and I promote is in my videos :-)
It would be great if you could get a 'busy' signal implemented on the webinterface, so that when it is searching for lights, it tells somebody about it, so you wouldn't just click away on all the buttons when being impatient :-)

[taburineagle]

Ah, awesome - thanks for the promotion @fribse! I'm definitely still working on it, just taking some time to work on some other projects at the moment - I'm trying to fine-tune my motion-sensor camera system (ha, which is the reason I wanted to write NL-P in the first place), which is a a little Pi-hat board I designed using an ATTiny85 chip, running on a Pi Zero (both the AT chip and Pi run code that I wrote) - kind of a badge of honor that I designed all of that, although I also have to work the kinks out when they don't quite work 100% the way they should 😁 Ha, duly noted - the log does give a kind of "we're doing something at the moment, so we're ignoring this!" kind of response when it's busy searching, although if you're running it headless, the web interface admittedly doesn't - so that's a good idea for the next one!

[fribse]

Hi again
So I tried once more with the new version where it's merged together.

1. When I do a 'scan' it never exits the 'The HTTP Server is busy with a request'.
2. I can't seem to import the old presets, and I can't remember the trick for it.
3. If I restart the daemon, it fails to start again

Sep 04 11:12:24 neewerlitepi systemd[1]: Started Run NeewerLite-Python HTTP Daemon as a service.
Sep 04 11:12:26 neewerlitepi systemd[1]: neewerlite-python.service: Main process exited, code=exited, status=1/FAILURE
Sep 04 11:12:26 neewerlitepi systemd[1]: neewerlite-python.service: Failed with result 'exit-code'.
Sep 04 11:12:26 neewerlitepi systemd[1]: neewerlite-python.service: Consumed 2.235s CPU time.

[taburineagle]

Hmm... interesting... The 3rd one makes sense, because when you restart NL-P, it's probably reporting the other copy is still running (the lock file exists), so it won't launch a new copy without --force_instance being called on startup. Do you have the --force_instance flag set in your neewerlite-python.service file?

1 - I'm curious... if you launch NeewerLite-Python as a normal program (not a daemon, just python3 NeewerLite-Python.py --http --force_instance), and you check what's coming out of the console, does it get past the scan there, or does it freeze there as well? I haven't tested the new version as a daemon yet on my own, just the command line, and it seems fine here, but that doesn't mean there isn't something wonky somewhere between the two that I'm not seeing.

One other change I made to the HTTP page in the new update, if you scroll away from the page (click on the address bar for example, or browse away from the page), the JavaScript timer that refreshes the page freezes until you click back on the page. I did this for anyone that wanted to enter a URL in the address bar after lights were detected to test setting params on a light without the page refreshing and kicking them out of entering an address, but that also might be holding things up here, so I can take that out.

2 - this one is a bit confusing (to me) because I wrote a conversion procedure to convert the old presets to new presets internally, and it doesn't seem to be working... could you send me the old presets again that you had saved from before? This is the list you sent me earlier:

customPreset0=DF:88:56:D0:72:A8|8|80|44;CE:D9:49:A3:1F:F7|8|40|44;C0:50:A7:8C:95:BA|5|0|44;CB:72:58:58:26:64|8|4|44;DB:64:76:35:00:A5|5|0|44
customPreset1=CE:D9:49:A3:1F:F7|5|50|44;C0:50:A7:8C:95:BA|5|60|44;DF:88:56:D0:72:A8|5|100|44;CB:72:58:58:26:64|5|5|44;DB:64:76:35:00:A5|5|60|44
customPreset2=C0:50:A7:8C:95:BA|5|74|44;DF:88:56:D0:72:A8|5|48|44;CE:D9:49:A3:1F:F7|5|49|44;CB:72:58:58:26:64|5|4|44;DB:6

[taburineagle]

This is what should be showing up for the list of presets, based on what you sent me before:
#81 (comment)

[taburineagle]

Also, one other possibility (just spitballing here), there could be a permissions issue with the file in the light_prefs folder where NL-P can't read the old list.

[fribse]

Hi Zach

I finally got some time, I just fetched the latest (4 months old) to test again.
This is the result when run from the command line:
root@neewerlitepi:/home/pi/NeewerLite# python3 NeewerLite-Python.py --http --force_instance

---------------------------------------------------------
             NeewerLite-Python ver. [2024-04-20-BETA]
                 by Zach Glenwright
  > https://github.com/taburineagle/NeewerLite-Python <
---------------------------------------------------------
Traceback (most recent call last):
  File "/opt/NeewerLite-Python/NeewerLite-Python.py", line 3897, in <module>
    loadCustomPresets() # if there's a custom mapping for presets, then load that into memory
  File "/opt/NeewerLite-Python/NeewerLite-Python.py", line 1976, in loadCustomPresets
    if currentParams[1] == 120: # we have a new-style list of parameters, so copy them as-is
IndexError: list index out of range

At first it complained about the Bleak missing, so that might have been an issue as well, don't know how the old version would work without it though?
I changed the rights on the lightprefs folder to 777, and filerights to 666, just to make sure that everything would be accessible.
The files are owned by root, and the daemon should run as root as well as far as I can tell.
I've added the prefs file, just to be sure...
light_prefs.zip

Oh, btw. if I remove the light prefs file, the webserver starts up, responds, finds the light and all...

[taburineagle]

Hmm, that's definitely odd @fribse - I'll have to check into why the prefs folder might be screwing things up.