BoM camera id: 521 unavailable

[tomlut]

Home Assistant release with the issue:

0.92.0

Last working Home Assistant release (if known):
None

Operating environment (Hass.io/Docker/Windows/etc.):

Hassio NUC image

Component/platform:

https://www.home-assistant.io/components/bom/#camera

Description of problem:
I have one camera that shows the radar image and one that does not (id: '521'), it only shows a black window. I have double checked the ID, delta and frames.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
Working camera:

- platform: bom
  id: '763'
  name: "Rain Radar 128Km"
  delta: 360
  frames: 6

Camera that just shows black:

- platform: bom
  id: '521'
  name: "Rain Radar 512km"
  delta: 360
  frames: 6

Traceback (if applicable):

Additional information:
Web link for non working camera: http://www.bom.gov.au/products/IDR521.loop.shtml

[OkhammahkO]

I am experiencing the same issue. The 64, 128 and 256 loops are working well, but the 512 shows black (Melbourne Radar Loop).

[stale]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[tomlut]

This issue is still present in HA v0.96.4.

The camera fails with the error:

Got NO frames for ID 521 at 1564104960

[stale]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[tomlut]

This issue is still present in HA v0.100.3

[stale]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[tomlut]

This is still an issue 0.104.3

[maddenp]

I'm the author of the underlying bomradarloop component. Thanks to @kuchel77 for pointing out the source of this problem, and for a PR with a fix.

Looking at this more closely, though, it seems to be a pattern that the timestamps on images for the 512km loops are all offset vs those for the 256km, 128km, and 64km loops. For example, the Melbourne radar's images have a 6-minute delta and, for the higher-resolution loops, have minutes-past-the-hour values like 00, 06, 12, 18, etc.; while the 512km loop has corresponding values like 59, 05, 11, 17, etc. The Moree radar, with a 10-minute delta, has 00, 10, 20, etc. for higher-res loops, but 57, 07, 17, etc. for the 512km.

Now, I just realized (from tables like this) what some of you surely already knew: The IDs of the actual radars are 1- or 2-digit numbers, and the last digit of the radar loop ID indicates the resolution, i.e 1 => 512km, 2 => 256km, 3 => 128km, and 4 => 64km. So the Melbourne radar (ID 2) has radar-image IDs '021' for the 512km images, '022' for the 256km images, etc. Nifty. So it looks like I might be able to simply deduce the timestamp offsets for the 512km images from the delta value and the last digit of the radar-loop ID. Spot-checking a few delta=6min and delta=10min radars looks like this rule might hold generally. I'll try this as a fix and we can see how it goes.

Longer term, I wonder if it might be nice to have a resolution parameter for the named radars. I mean: I just used the radars displayed on the Radar Images map to populate the "easy" list of radars that can be specified by name, and those are all 128km-resolution loops by default. So if you say location: Sydney in your config, you get the 128km loop. But maybe an (optional?) resolution parameter would be helpful.

Lastly, does anybody know if there's a good way for me to get notified about issues pertaining to this component? There was an earlier one related to a memory leak that I got tagged on and was able to fix fairly quickly. I would have looked into this one some time ago if I'd known about it.

[tomlut]

does anybody know if there's a good way for me to get notified about issues pertaining to this
component?

I believe you can be added as the code owner.

[maddenp]

I opened PR #32660 to fix this issue.

Interested users might also look at https://github.com/maddenp/bomradarloop/blob/master/fetchall.py, an updated version of a script kindly provided by @kuchel77, which tests all known combinations of radars and their supported resolutions. Two radars that are currently out of service per BOM are noted, and a couple that previously provided every-10-minutes frames, and that now provide every-6-minutes frames, have been updated (also in the actual HA component).

I hope this helps, Australian friends. And here's hoping our upcoming summer here in Colorado lacks the kind of fires you suffered recently.