-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
piaware MLAT Client with wrong configuration for Beast-format results connection and http feed tracker dosn´t show any airplanes #151
Comments
I you want to connect to a remote dump1090, you can do it like that:
If you do it like this, you don't have to change anything else. |
Ok that is weird. In my opinion the mlat client of piaware should also use the environment var PIAWARE_RECEIVER_DASH_HOST and maybe a additional env variable like PIAWARE_RECEIVER_DASH_BEAST_PORT for the port definition - like in the other feeder parts. I mean the same issue exist also in the ADS-B Exchange feeder. There both XXXX_RECEIVER_HOST and XXXX_RECEIVER_PORT variables are missing and the feeder also try´s 127.0.0.1 Everything is working fine if dump1090 is running in the same container, but if it runs outside - like on my side - some of the feeder will not work, which is a shame, because it is a relly nice deployment/package which you created. But back to your answer, it means that your dump1090 starts and takes the input from my dump1090 outside and forwards it to the mlat client, right? If so - not a nice setup . Is there not the possiblity to provide the external receiver var for host and port to all feeder´s and also to the "secondary" parts of the feeder - like the mlat client of piaware ? Anyway, I will try - but in my opinion not the best solution |
It might be possible to do it the way you want. |
But why then the environment var exist for XXXX_RECEIVER_HOST and XXXX_RECEIVER_PORT on other feeder´s section´s ? I mean, is it really a high risk to replace every 127.0.0.1 defintion with a environment var for every feeder section ? Yea it is work i know but one point more for your image ;) |
PR are welcome. 😄 |
So no chance that you will fix that point - that every 127.0.0.1 address for actually local dump1090 app / or feeder section, is more flexible to set via env var for a remote instance ? |
No chance right now sorry. It would involve some rework and documentation, I'm pretty sure people won't use it properly in the end. For me using local dump1090 connecting to a remote one it a solid workaround for now. It's how I've been using it for several years. |
Specifications
Expected Behavior
Beast-format results connection with dump1090:30104:
Actual Behavior
Beast-format results connection with 127.0.0.1:30104:
Steps to Reproduce the Problem
I run a rasp. v4 swarm cluster of 3 nodes. On the first node i have a running dump1090 container, which is not in the swam context because of missing device section in compose support :
My current stack configuration :
At that point everything is working fine - my feeder is shown in piaware - with 3 green status bars. But in the stack container i got several messages :
I expect that the mlat-client connect´s to my container dump1090:30104 and not to 127.0.0.1:30104 or missed i something ?
The text was updated successfully, but these errors were encountered: