Retry Timer on wifi plug

[Wob76]

Hi,

First off, thanks for your work.

I am using your node for the wifi socket, it works great, but I am getting constant "retrytimer started" in my logs and this seems to have a negative effect on the socket, it will go offline (even shows offline in the Mi Home App) a couple of times a day and the only way I can get it back online is to turn it off\on.

It also seems to be causing nodered to crash after a few days.

If I stop the flow the socket behaves fine.

I have loaded up a development instance of nodered to further test, I can enable debug logging if that will help diagnose.

Thanks, Wob

[Wob76]

Hi,

I did some further testing, I waited for my socket to go offline and then stopped my flow, my socket then recovered in a few hours and was online again in the Mi Home App. Without the flow active my socket is stable.

I then did a quick fix, changing the watchdog timer from 10 seconds to 10 min, the socket is still online after 24 hours, still early, but before it was lucky to last 12.

Is the node meant to be maintaining a constant connection with the socket? If so what are the advantages of doing that over just sending a command when it is received?

Thanks, Beau

[Wob76]

Hi again,

The above fix has made the socket much more stable, but it still seems to go offline every few days, restarting nodered brings it all back up pretty quickly.

I have this installed on a "dev" nodered install, and I noticed it is causing x5 to x10 the amount of network traffic as my production nodered, and that has a flow that is polling a web page every 5 mins.

Considering I am lucky to turn this switch on\off more than a couple of times a day it seems a bit excessive.

Is it possible to have the node "destroy" it's connection after a successfully on\off and only reconnect as needed? Or does this introduce to much delay? I did try added a few extra "node.plug.destroy();" in but I just get a error (above my skill set).

Thanks, Wob

[hrietman]

Hi, sorry for not responding earlier. Yes I also noticed this behaviour. It is something I need to fix but did not get around to make time to investigate. Your findings are a great help. At the moment I am using a setInterval to check the state of the socket (you can turn it on/off via different devices, app, physical etc.., hence the constant checking) but I read it is not the best way to do this; a setTimeout is recommended in such cases which should prevent to start multiple threads if the device is not responding. Hopefully I will find time to fix it in the nearby future.

[hrietman]

@Wob76 version .14 should fix the retry timer; if you can please give it a try and let me know.

[Wob76]

Will do, thanks for the effort