interfaces.webSocket.connect() warning

Since installing I'm getting almost continuous warnings in the logs about

No route to host (Host unreachable)

every 13 seconds or so.

This is from Ramdev's PC Controller, which is polling to see whether a given PC is powered up.

Is there a way to turn this warning off? e.g. another parameter to interfaces.webSocket.connect()?

I was chatting with @es_ferret about this on the PC Controller topic...

My suspicion is some logging may have been added to the platform to indicate the host is unreachable, not an unreasonable change if that is what has happened, but I have not sought to confirm that. In @es_ferret 's case the host was indeed turned off, so it made sense for the log to appear. Is that true in your case as well?

There is also a setting in the PC Controller about the time between connection retries, which you could adjust if you wanted, to try and reduce some of the noise, but this would obviously have an impact on recovery time from a legitimate temporary drop in a connection.

1 Like

I agree with your suspicion.

And it's definitely true in my case - the device was off while I was asleep.

It's the pollution of the logs that's irritating for something that's entirely expected.

I've changed the time between retries now.

1 Like

If it is connectivity and/or testing of the host being turned on that you are trying to get out of this driver, then it may be worth looking at an alternative method for doing this. If you are also using the other features like I am, an alternative connectivity method may also being something worth incorporating into the PC Controller driver, so as to reduce the noise from the web socket, or even just an error count and stopping the connection retries... there would be a range of options to manage this I expect. I think the inclusion of the warning is fine, it's the repeated attempts to connect to an unreachable host that is more the issue that is causing the noise, IMHO.

I use it to send the PC to sleep under certain conditions, e.g. if I've forgotten to turn the computer off before going out.

I'll give it some thought.

1 Like

I still can't quite figure out why the driver needed to ping the host on any scheduled basis. Is it that without it a command might not go through? i.e. without the connection occasionally the send events just fail outright (the ping kind of opens the communication pathway)? Couldn't the connect be setup to happen right before the send event?

From all I can see the commands are in one direction, calling the EG add-on. So I can agree the need to keep the connection alive in order to receive external commands is not something the driver appears to need to handle. I would expect that it could re-stablish the connection if needed when issuing a command.

I feel I may have come across a little judgmental or just over-the-top in responding to @rob 's grievance over the chattiness in the logs. That said, I still feel it is best managed by the driver, but I probably should have made it clearer that the responsibility is better placed in those managing the driver, not those using the driver or their expectations. It's fair enough to want / expect relatively quiet logs and a better managed transition. I have hesitated in saying that I think the websocket is not technically a supported platform feature, but I am likely to be wrong about that...

I agree that the warning could be useful and that the platform development might not have anticipated this existing driver where it could be valid that there isn't a host online. Both can be true. I also agree that the adjustment belongs in the driver, but I don't get the impression Ramdev is actively participating to where I can ask for help on that. I might toy with just working without the reconnect schedule in the code for a bit to see how that affects things. I have no idea how GitHub works as far as taking over (nor do I have time to).


1 Like