Light does not react to actions after losing link with the HTTP server

adriportela95 commented 2 years ago

Hi! I was testing with two 660-PROs and I noticed that one of them lost the connection after a few minutes but quickly reconnected (I have its panels always visible). The problem is that after relinking and checking on the web that both appeared linked, that light does not receive any action that I send to it. Without closing the HTTP server, I have tested the GUI and if it has linked and reacted to the actions. When I closed the GUI and returned to the HTTP server I did a ...doAction?link="mac", and it was linked again but I still didn't receive anything. I have tried several times because that light has been losing linking very frequently and always the same result. The only solution has been to close the HTTP server with Control+C several times until it responded with "unlinking device", launch it again and perform a &discovery to start again.

Notes: I have version 0.12b, Windows 11 and I always launch the HTTP server with the --force_instance command. Also, I have 3 BT devices (the two 660-PRO and a keyboard) connected with the TP-Link UB500 dongle (BT 5.0).

And this is the message that comes out after sending the action (http://localhost:8080/NeewerLite-Python/doAction?light=mac&mode=scene&animation=5&bri=40) and it doesn't react:

127.0.0.1 - - [Oct/01/2022 17:57:15] "GET /NeewerLite-Python/doAction?light=mac&mode=scene&animation=5&bri=40 HTTP/1.1" 200 - [17:57:15] - Processing HTTP arguments [17:57:15] - Going into send mode

I have a .ps1 file with 2 URLs with different actions for each light and the other light reacts successfuly (well, both react successfuly until link is lost)

I am doing something wrong? Thanks.

taburineagle commented 2 years ago

Hi @adriportela95! Let me do some checking into that - just curious, what is the signal level you're usually getting from that light?

adriportela95 commented 2 years ago

Hi @adriportela95! Let me do some checking into that - just curious, what is the signal level you're usually getting from that light?

I would say between -76dbM and -82dbM. The other light had similar values, but I would also say that it always had a better signal than this one (for example, one 80 and the other 82, or one 76 and the other 78).

For this reason, yesterday I exchanged them. The one farthest from the PC was the one that was disconnected most frecuently. I also changed the port of the BT usb dongle and put it closer to the lights. The new result was approximately -64 dbM to -68 dbM. Even being closer, that light still gave me a worse signal (+2dbM), but in this way, both lights were connected for 2-3 hours without losing the link.

I should have tried to manually turn off one of them with the button and try that when linking again (either automatically or by doing a &discover or a &link), it gave the problem that I mentioned. I'll try it later.

taburineagle commented 2 years ago

Nice, I'm glad you're having a bit more luck with it! I had a feeling the initial disconnection was due to a lower signal level. I tried the same thing here (HTTP server, an SL-80 and MacOS, just because that's the system I currently have), not with the RGB660 PRO (I have one of those, but not with me at the moment) and I turned it off, then back on, waited for the HTTP server to show that the light was no longer linked, then clicked on the "No" link to re-connect it, and after re-linking, the light did respond to requests, but my test bench here is a lot closer together (the light's signal is -59dBM), so the program has less of an issue connecting to the light. I'm curious though if the signal level is too low, and the light does have issues re-linking, does the HTTP server still show that it's linked. It shouldn't, but I need to look more into that.

adriportela95 commented 2 years ago

I have more satisfactory tests. I think I have something, a pattern:

I turn off the light on the switch and turn it on again, the BT icon on the light flashes until it is re-linked (2-3 seconds). This doesn't show console messages and when doing a &list, browser says Linked = YES. But it does not react to new actions. As soon as it receives the new action, the BT icon flashes again and does not reconnect. Now yes, doing a &list, the browser says Linked = NO.

From here I have 2 behaviors:

I send a &link=mac or click on Linked = NO from the browser. This action binds the device again (I see the Successful in the console) but does NOT react to new actions.
I send a &discover or hit Scan in the browser. This action binds the device again (I see the Successful) and if it reacts to new actions. This case works perfect.

If just turned on and "linked" (first paragraph) I decide to send a &discover instead of launching a new action, the same thing happens as in case 1, the light does not react.

More useful data:

After carrying out the successful case (number 2) this message has been printed on the console: Light found! [NEEWER-RGB660 PRO] MAC Address: MAC but it's already in the list. It may have disconnected, so relinking might be necessary.

After that message is when the Successful appears and everything works correctly. This message does not appear in case 1 and it may be useful to find something. Perhaps in case 1, isConnected = true is already true and it ignores it in some way. I don't know. Hope this can help you!

taburineagle commented 2 years ago

Hmm, interesting, I didn't notice this behavior when I was testing, but now I have access to my Windows PC and my 660PRO - I'll check this out a little bit more in the next few days to see what I find out. It sounds like the light gets taken out of the list when it disconnects (which shouldn't be the case, but I'll definitely check into it!)

taburineagle commented 2 years ago

I also wonder if it's because it's two of the same kind of light - that also shouldn't be the case, but I'll check that out too - I don't have 2 660PROs myself, but I can see if I can trick the detection function to think I do.

adriportela95 commented 2 years ago

Hmm, interesting, I didn't notice this behavior when I was testing, but now I have access to my Windows PC and my 660PRO - I'll check this out a little bit more in the next few days to see what I find out. It sounds like the light gets taken out of the list when it disconnects (which shouldn't be the case, but I'll definitely check into it!)

Yes, I added more debugging messages and I saw that when I turn the light off and on, the BT blinks for about 5 seconds and reconnects without reacting to requests, as I told you. Well, if I do a &discover at that point, "devices" in the findDevices() method is empty.

On the other hand, if I do the same thing but instead of sending a &devices, I send a color change request, the BT blinks again as if it was completely unlinked and no longer automatically reconnects. After that, when doing &discover, "devices" contains that light. If I do this with two lights, I have to wait an additional 5-6 seconds for the second light to unlink.

For example, if after sending the color change request to the 2 lights, I send a &discover without waiting those 10-12 seconds, in "devices" only the first light appears. If I wait all that time, the 2 appear in "devices". The problem is that if I don't wait and it only finds one light, that light reconnects fine, displaying the "Light found!" and then the "Successful", but with the other it prints the "Successful" directly but still does not react (and of course, the BT continues like "connected" because there was no time to the completely unlink that I said before after the color change request).

It's like in the writeToLight() method, when it gets a request and the light is not okay, it unlinks it completely after a few seconds.

I'll try later or tomorrow with a single light, but I think I did it and had the same result.

taburineagle commented 2 years ago

OK, I've finally had time to test this out myself with Windows 10 and the RGB660 PRO, and I was able to recreate the situation. It looks like I'm not clearing the Bleak connection object when the light goes away (which the GUI does automatically every few seconds, but the HTTP server only checks to see if the light is connected when the page loads), which gives a false re-connect when re-linking to it. Running "Scan for New Lights" deletes this object by default, so when re-linking, the correct Bleak object is in control of the light, and everything works like it should. To fix this, I'm going to automatically delete this object and create a new one on a re-link request (it originally only re-created it if it didn't already exist), so regardless if there's a Bleak object there from a previous connection, it gets a new one assigned to it when re-linking - and that works!

adriportela95 commented 2 years ago

Great! I will check the repository to test as soon as the changes are uploaded. Thanks for everything!

taburineagle commented 2 years ago

You're welcome! Just pushed the commit - let me know if you have any issues! If not, I'll push a new version with those changes.

adriportela95 commented 2 years ago

I have already done some tests:

If I turn the light off and on, the behavior is the same. It does a fake re-link and upon receiving a color request, the light doesn't react and unlinks by displaying NO on the HTTP page. But effectively, if instead of sending a color, I send a &link or a &discover, now it unlinks it and relinks it successfuly.

The process is the same with two lights at a time. It takes 5 seconds longer to unlink the second light but meanwhile it keeps making links attempts until it succeeds. And now, it always does (previously I had to wait 10 seconds until the BT icon blinked on both to launch &discover).

So now both &discover and &link successfully relink the lights. Although I have noticed a curiosity. Waiting for the lights to make that "false" re-linking when they are turned on again (when both have stopped flashing), from the HTTP page when clicking on "List", both lights come out Linked = YES (although they do not react to requests ), but if I press "Scan", both lights come out as Linked = NO.

Well, the only problem now might be that I lose that first request since it doesn't try to reconnect when it fails and resend the request, but instead unlinks the light and waits for the &discover or &link to be sent. But everything else with reconnection works fine now!

One question. You are not capable of knowing when the light has lost connection and reconnected on its own, right? Because that's where the problem starts.

taburineagle commented 2 years ago

Right, right - that makes sense, as the HTTP server only pushes that information when the information is first sent to the browser (a request or a refresh for instance), so the page will still act as if they're linked until you give a command to refresh the information, at which point they'll say "No" in the linked column - it might make sense for me to implement an auto-refresh feature, like forcing the page to refresh every few seconds to update that info. I'd like to make a more interactively updated version of the page (@fribse also requested this, and I've been thinking of the best way to implement this), but I have to look into that a bit further 😊

adriportela95 commented 2 years ago

I have something. I know almost nothing about Python, I'm a Java programmer, but I discovered through printDebugString() that when I send that request after turning the light off and on, the writeToLight() method is calling the Exception (line 2516). Specifically to the else of the if UpdateGUI == True. There if I do a print(e) the result is NOT_CONNECTED.

What I have done is put a returnValue = False there and in the processHTMLComands() method, do this:

            if len(selectedLights) > 0:
                isConnected = asyncioEventLoop.run_until_complete(writeToLight(selectedLights, False))
                if isConnected != True:
                    asyncioEventLoop.run_until_complete(findDevices()) # find the lights available to control

                    # try to connect to each light
                    if autoConnectToLights == True:
                        asyncioEventLoop.run_until_complete(parallelAction("connect", [-1], False))

                else:
                    printDebugString("Already connected!")

With this I get that when the request fails, the lights automatically try to reconnect and stay ready for the next request.

taburineagle commented 2 years ago

@adriportela95 - I'd have to take a look at that and see if it breaks anything in the CLI (because it also uses writeToLight() and also uses updateGUI = False) - as far as I remember - ha, I've been writing a JavaScript method all day, so my mind's a bit foggy at the moment 😁 That might be a good way to add a "reconnect if light not found" method... although re-scanning for lights globally would take quite a while if you have a lot of lights to go through - with just two though and just the HTTP server, that could work...

taburineagle commented 2 years ago

@adriportela95 - With this addition, the list page (doAction?list) automatically refreshes every 8 seconds, unless you click on an "Edit" button to rename a light, in which case it will pause the refreshing timer. This will update the list of available lights automatically (instead of needing to click on "List Currently Available Lights and Custom Presets" or refreshing the page manually), their statuses (Linked/"No"), etc.

@fribse - Also with this, the info updates more fluidly... still need to work on a method to show what's going on in the background, but this is a little bit closer to that.

fribse commented 2 years ago

@taburineagle oh, and make the http gui 'perdy' as well :-D Well, joke aside, it would be treat to have the http gui move closer to the 'real' gui.

taburineagle commented 2 years ago

Hehe, but perdy-fication takes finessing @fribse! 😁 I've always kind of treated the HTTP GUI more like just a status page where the actual usability lies in sending commands to the URLs with external devices like Stream Deck and the like (it's just kind of there to show there's something going on under the hood) - but that would be cool to have a more interactive setup - buttons that don't take up 95% of the screen (like the custom presets on the HTTP pages do now) and draggable dials - not sure if how I'd manage that though using Python's HTTP server, they'd have to constantly send URLs back to the main system to affect things.

fribse commented 2 years ago

Well the perdyfying isn't a factor :-D But it would be great as you also say, to have it more interactive, so that one could see what is going on on the different lights, ie. it's currently trying to connect etc. That would be a major improvement, but I'm hijacking the thread, so ignore me for now :-D

taburineagle commented 2 years ago

Ha, that's cool @fribse - I definitely do want to improve it... sometime down the road 😊

@adriportela95 - Do you need anything else from this issue? I'll close it tomorrow if I don't hear back, and push the HTTP refresh changes in a day or two.

adriportela95 commented 2 years ago

Ha, that's cool @fribse - I definitely do want to improve it... sometime down the road 😊

@adriportela95 - Do you need anything else from this issue? I'll close it tomorrow if I don't hear back, and push the HTTP refresh changes in a day or two.

Oops, sorry, I forgot to reply. Everything is fine now. Issue closed! Thank you very much for your help!

taburineagle commented 2 years ago

Excellent! You're welcome @adriportela95 😊

taburineagle / NeewerLite-Python

Light does not react to actions after losing link with the HTTP server #56