Misunderstanding how retries work? #125
Replies: 5 comments
-
|
The timeout is per retry, so if you have 10 max retries with 1000 ms retry timeout, you should get a final failure after 10 seconds of failed retries. |
Beta Was this translation helpful? Give feedback.
-
|
OK, I deleted all the posting i did the last couple of days, because I realized a couple of things, and had to write a bit of code to illustrate what I think powerOnAndConnect is doing versus should be doing. How the retries and retryTimeout logic was confusing me a bit at first, this was because I was getting errors that seemed misleading. In short, I started ignoring the errors reported and just coded to what I knew had to be the right results. When my TV is on or off, but has not been off for more than 2 minutes, everything, connect() and powerOnAndConnect() included work as expected. It only when I called powerOnAndConnect() and post WOL sent, things got a bit nuts. Of course connect() cannot work once TV is off the network, so the issue I am seeing is specific to powerOnAndConnect(). The issue is, I keep seeing 'maximum retries of 90 reached' when I am (I believe) explicitly setting the retryTimeout to 1000. No way is powerOnAndConnect() taking 90 seconds to generate WOL, and the TV takes about 10 seconds to start to be pingable. That does not mean that getIpControlState is returning true, that takes a few more seconds, as we know in past discussion and why powerOnAndConnect was created (at least in part). So... when TV is on or off and only off for less than 2 minutes... In this case, I set retries to 120 and timeout 1000... So far so good, about 1 second to connect and return that the TV responder/listener is full available. Now I turn off the TV and wait at least 2 minutes, per ping result below... Pings stopped... So now to execute the script... Note... At about 10 seconds in the count down, the WOL sent, TV responded, powered up, sequence is done. Then, I believe misleading errors start showing up. These will continue until I get notification that getIpControlState() and getCurrentApp() return valid results, and my script loop breaks out, and script exit done. My TV takes about a full minute to become fully functional, in reference to getIpControlState() and getCurrentApp() state to return valid results. If I watched just the errors, the loop would expire and my code would believe the TV never powered up and/or never came online. Reminds me, I should be able to call the new method, getPowerState() (if I recall the name right) to do the same thing. My original script logic was waiting for no errors or exceptions to be reported before attempt to issue any commands to the TV, but clearly that can't work given what is happening above. Errors such as -113 connection refused make sense between TV power up and when getIpControlState() returns true, but this 'maximum retries reached' scenario just does not seem right, or am I missing something? Just as a sanity check... Run the same script how that my TV is fully up... As expected, connected, TV has good control state. The other error message I find a bit confusing is 'should be connected' error, No sure why that is not a warning versus and error... it only happens when I attempt to call connec() when TV is not fully online after power up, that i can tell, versus connection refused? |
Beta Was this translation helpful? Give feedback.
-
|
Wes? You disappear? |
Beta Was this translation helpful? Give feedback.
-
|
@Jibun-no-Kage Can you share the contents of Test.mjs? It's hard to draw conclusions from the output without seeing the code. |
Beta Was this translation helpful? Give feedback.
-
|
Sure, just need to dig up the test script. Even in Node Red flows, I never seemed to get the retries/timeout parameters to work the way I thought or expected. Might be an issue with how Node Red implements something? It always seemed like if I set the retries to 90 and timeout to 1 second, the routine never actually waits 90 seconds, and would return retries exhausted way too soon. I finally use the WOL node in Node Red, if the management interface did not respond, and just wait for 90-120 seconds (various by TV model) pinging approximately every second, until:
Then...
Only after all 5 of the above passed evaluation (counting the WOL state), I could consider the TV actually on the network and fully responsive, i.e. would accept commands. Of course, the TV does not drop off the network for about 2-4 minutes even after turned off. But if longer than 2-4 minutes, you have to repeat the entire process again as noted above, before you can even query the TV for its state, i.e. mute, volume level, etc. |
Beta Was this translation helpful? Give feedback.
-
Misunderstanding how retires work? If I set retries to X value, the total timeout is X*750 milliseconds by default? Or is the 750 millisecond the total timeout duration, I am referring to the TinySocket code of course where I see the 750 millisecond default. The powerOnAndConnect function works... but I keep getting maximum retries exceeded even when I set it to 60, 90, etc. So thinking it has no implied time per retry?
Beta Was this translation helpful? Give feedback.
All reactions