OpenCPN data connections after standby/hibernate

[bradfordharley]

It appears that the data connections do not reset after recovery from standby or hibernate on windows 11. I've tested this on 5.8.4 and 5.8.2 and it consistently does not resume the data connection. This is true with signalk data or tcp to signalk or my vesper xb8000. It does resume and work fine with 5.6.2.
I have also tried this on two different windows 11 laptops and confirmed the same behavior with friends' systems.
This is makes it a requirement to restart either opencpn or disable/enable the connection to access the NMEA data stream.
Any thoughts?

[AedanC]

I have seen this with Linux, what OS are you using?

[bradfordharley]

Windows 11....

[Antipole]

Have a look at this issue.

[Hakan]

Or this discussion.
Windows standby when regarded to TCP is a small trouble for present O and not less for some network devices.

[bradfordharley]

Thank you for the responses. The referenced posts are interesting, but not a direct fix. There is still something going on with the modern OpenCPN and reconnecting. It is both TCP and the Signalk protocol.... I did implement the signalk UDP broadcast plugin and it recovers fine on 5.8.4, which I expect is to be expected with UDP being stateless. How does one file a bug here?

I'm happy to do any testing.

[barcoMeCasa]

that has been a bit annoying on my win10 laptop as well so had a google over coffee. As a workaround this seems to do the trick...
In task manager, created a task which runs when workstation unlocks with specific user (me of course..) and actions is "start a program", which points to a file called "test.bat".
Inside the test.bat file (plain text file) are 2 lines...
(WIfi 2 is usb wifi dongle connected to a raspberry pi running openplotter/ signalk)
"
netsh wlan disconnect interface="WiFi 2"

netsh wlan connect name=openplotter ssid=openplotter interface="WiFi 2"
"
So each time the laptop sleeps & I wake it & unlock, it turns off & on the network which supplies the data. Which i did before to get opencpn to see the data again.
Seems to work so far anyway.
Hope this might help for now.

[Hakan]

Seems a handy workaround until OCPN will take care of it itself.

There are, as you may have seen, discussions for a solution.