[APP][Pro] Virtual Radar App

Apps
,
61

Hi Tom. Actually there is (I’ve checked my Flightrader24 app on my phone at the same time I get the Homey notifications).

But I can see, that you also don’t have any content (N/A) in the tags To and Operator. The very same tags I use in my flow/push notification.

62

@Kasper_Kvist correct Unfortunately, not always on the website either.

63

Bug: radar latitude/longitude are rounded to whole degrees when saving device settings (v3.4.2)

Hi Bretislav, thanks for keeping this app alive — the OpenSky API-client support works great.

I ran into a bug that makes the Radar device unusable after any settings change, and I think I’ve narrowed down the cause.

Symptom

Saving the Radar device settings rounds lat and lon to whole degrees. 52.53306289 / 4.71264712 becomes 53 / 5 — a location 55 km away, so the radar silently finds nothing.

It happens on every save, including saves where I don’t touch the coordinates at all. Changing only the scan interval is enough to move the radar 55 km.

Steps to reproduce

  1. Pair a Radar (ADS-B) device. The app writes the correct coordinates itself, with 8 decimals — this part is fine.
  2. Open device settings, change nothing but the scan interval, press Save.
  3. Reopen the settings: latitude and longitude are now whole numbers.

Extra clue

The settings field itself rejects its own valid value. Typing 4.71264712 makes the browser flag the last digit as invalid (“please enter a valid value”), and on save it becomes 5.

Not a UI-only problem

I tested every route — all of them round:

Route Result
Settings screen (web app) rounded
Settings screen (mobile app) rounded
Cloud API PUT /api/manager/devices/device/:id/settings rounded
Local API (same call, direct to Homey) rounded

And every precision rounds the same way:

Value sent Value stored
52.5 53
52.53 53
52.533 53
52.5330629 53
52.53306289 53

Pairing is the only path that stores decimals correctly, which fits: onPair writes the settings from inside the app and bypasses Homey’s settings validation.

Likely cause

The lat and lon settings appear to declare a step attribute. The rendered input carries step="1e-8", and Homey’s validator seems to snap the value to a multiple of that step — but ends up treating the step as 1, giving whole degrees. The dstsetting has no step and renders as step="any", and it keeps its decimals without any problem (5.6 saves fine).

Suggested fix

In drivers/radar/driver.settings.compose.json, drop the step from both coordinate fields so they behave like dst:

json

{
  "id": "lat",
  "type": "number",
  "label": { "en": "Latitude", "nl": "Breedtegraad" },
  "hint": {
    "en": "The distance of aircraft will be based on the radar location.",
    "nl": "De afstand van toestellen wordt bepaald op basis van de radar locatie."
  },
  "attr": { "min": -90, "max": 90 },
  "value": 52.228936
},
{
  "id": "lon",
  "type": "number",
  "label": { "en": "Longitude", "nl": "Lengtegraad" },
  "hint": {
    "en": "The distance of aircraft will be based on the radar location.",
    "nl": "De afstand van toestellen wordt bepaald op basis van de radar locatie."
  },
  "attr": { "min": -180, "max": 180 },
  "value": 5.321492
}

If the step has to stay for the UI spinner, writing it as a plain decimal instead of exponential notation may also do it:

json

"attr": { "min": -90, "max": 90, "step": 0.00000001 }

I couldn’t verify the exact manifest because the 3.4.x source isn’t on GitHub (the repo is still at 3.2.0), so the snippet above is my best reconstruction from the rendered input attributes — worth a look at your end.

Workaround for anyone else hitting this

Don’t open the device settings. Delete and re-pair the device instead; pairing takes the coordinates straight from your Homey location and stores them correctly. The trade-off is that you’re stuck with the pairing defaults (5 km range, 20 s scan interval).

One small request

Would you consider pushing the 3.4.x source to GitHub? The repo still sits at 3.2.0, so there’s no way to check or contribute a fix from the outside.

Thanks!

64

Let me have a look on that…

It is always up to date - GitHub - shaarkys/com.gruijter.virtualradar: Virtual Radar app for Homey based on ADS-B data · GitHub

Maybe you are looking on previous/old repo ?

65

Fixed in Virtual Radar | Homey, can you please test and report back ?

66

Tested and works, perfect! Thanks for the swift reply, and I missed the GitHub on my part. Sorry for that :wink:

Have a great evening! Kind regards