Piaware lost the TCP connection to my Radarcape during a Radarcape firmware update. It was not able to reestablish the connection itself. I had to reboot Piaware via the SSH console.
Can this be made easier? I.e. try to reconnect to Port 10003 several times before final timeout or have a reboot button on the Piaware main page?
Also I have lost track of the web page that explained the meaning of the aircraft.json output (this was not on github). Could a help button on the Piaware main page lead to that page?
Other than that, it works very well and MLAT tracks are of super quality.
It should try to reconnect to port 10003 automatically. The journal will have gone since you rebooted but if you look in /var/log/syslog for beast-splitter entries there might be something interesting. (when receiver-type is radarcape, it is beast-splitter that actually connects to the radarcape).
Possibly the problem is that the radarcape went away without shutting down the TCP connection properly and beast-splitter didn’t notice? (As it’s not sending data, if the remote host just abruptly reboots then the connection can hang forever)
(edit: I expect that, if left alone, piaware would have eventually noticed the lack of traffic and tried restarting beast-splitter. But that takes over an hour before it kicks in)
(edit2: you can remotely reboot a piaware device via the FA website stats page)
I’ll look at making beast-splitter detect this a bit better. In radarcape mode there should be a status message about once a second, so if it doesn’t see that for a while it can assume the connection is hosed and try to reconnect.
As a workaround here is a small python script (as a systemd service) that tries to restart beast-splitter when a radio malfunction is detected. It seems it works though I am not sure about the permissions when issuing the os.system call.