I’ve got the blue FlightFeeder but I have some issues with it. The other day I came back from work to find that it had been offline for 4 hours. Apparently the WiFi was off.
I found out that my father had changed a wall socket so he cut off the electricity temporarily.
I thought that was the cause and that the feeder doesn’t turn on the WiFi automatically after a power cut. But I’ve tested again unplugging the feeder power supply and the WiFi power supply but when I plugged them back on again it automatically connected no problem.
So I am confused as to what happened. What caused the WiFi to turn off and not turning on again.
Again today it started being disconnected with the WiFi on.
As a flightfeeder is owned and remotley managed by Flightaware, probably best to email them directly regarding any issue.
I’ve emailed them but they replied only that everything look ok. Of course,because I had solved the issue. I just wanted to know what to do to avoid this from happening again in the future.
We can’t travel back in time and tell you what happened, you know. Since the FlightFeeder boxes are FlightAware’s property it’s up to them whether or not they want to spend time investigating log files etc. to tell you what happened in the recent past. Since you don’t have access to those logs no one in the discussion forum can really help you.
I just asked, maybe someone else had this issue…you know
Wild ass guess. If when he turned off the power if it also powered off the WiFi Access Point, when it got turned back on, the feeder booted faster than the WiFi, and couldn’t find it.
When you tested you just cycled the power to the feeder, and it was able to find the WiFi. Not knowing their software setup, it’s hard to say if it will going looking for the WiFi connection just when it boots up, or on some sort of a timed basis. Again only a guess, but the next time the power is off, see if it does it again.
Maybe the onboard WiFi simply did not start properly on the first restart after power was back.
I have a similar issue with my Jetvision Airsquitter. It is connected through WiFi to a repeater.
Once in a while the repeater restarts by itself, so WiFi is lost for a few minutes.
The Airsquitter is not capable to reconnect automatically.
For this i am using a simple monitoring which pings the repeater every five minutes. If it’s not reachable the Airsquitter performs a reboot.
As the Flightfeeder is owned by Flightaware, you can’t add this unfortunately.
Now it happened to unplug both because of the thunderstorm but this time on the website everything showed up as ok(green) except MLAT.
Came home and the status of the network and the system cycled between green and red. It kept connecting and disconnecting from the WiFi. Until I unplugged the feeder again and restarted it. Then it worked.
I really hate this because I may not be at home for long periods and the feeder won’t function properly without my intervention.
Either the FlightFeeder it’s buggy or the WiFi connectivity is a issue for it.
We can’t travel back in time and tell you what happened, you know. Since the FlightFeeder boxes are FlightAware’s property it’s up to them whether or not they want to spend time investigating log files etc.
I’ve just been troubleshooting exactly the same problem, my FlightFeeder randomly losing the connection, and not reconnecting unless both the FF and the router (MESH system) are rebooted. Fortunately I have an app which can monitor connections in real time.
The router gives out an internal network address to every device on the network. The router periodically ‘forgets’ each of these addresses (deliberately) and gives everything a new address every few hours. The addresses are in the form 192.168.1.xxx the xxx being the individual device. Last night my FF lost comms, it’s address was 192.168.1.160, but the app showed a smart switch with exactly the same address on the network, technically an 'IP Conflict", so the router had screwed up issuing a new IP to the FF, which duly stopped working.
The solution, for me, was to tell the router never to change the address for the FlightFeeder (a fixed IP), if you know your router’s admin passwords you can set this up internally and hopefully will sort your problem properly.
My router’s a TPLINK.
Sounds like you need to plug in your wifi source and your Flightaware hardware to UPS battery backup power supplies. I do that with any network and computer-based systems in the house that I don’t want losing power. I like the CyberPower EC850LCD.
Another thought is to lose the wifi config and use a hard wired network connection to the router or hub/switch if you are close enough or can co-locate the network and Flightaware. I designed my system to have them both live in the same room so I could hard wire the network and not play the silly wifi games.
I eliminated the wall wart power supplies and use power over Ethernet for every stationary device on my network. My POE provides a very stable 50v and up to 600 mA per port. Of course the switch is on my UPS system.
Well done. The best of both worlds since you are also getting switched ethernet connections included in the deal.
Very occasionally my PiAware will no longer be reachable on the local network by ping or by ssh and the webserver/SkyAware is not available – it appears to lose its local IP address. However it continues to feed FlightAware. I can reboot it using the site control on FlightAware.
After reboot it’s available on the local network once again. Checking the logs doesn’t show anything obvious that would explain it. It happened yesterday and there may have been a power fluctuation around the same time, so I’ll have to assume some kind of interaction between the router and the PiAware in relation to its handling of wireless radio at the physical layer.
I know it’s not a FlightFeeder but perhaps some similar mechanism taking place under the hood, so I thought worth mentioning for the record. As @CraigWoodThomas says ethernet makes these kind of problems vanish, worth doing if you can.
Right you are! Hard wired Ethernet and backup power UPS connections go a long way to minimizing interruptions in the communications stream.