Option to prevent provider from rendering if entity is specified but `unavailable`

[felipecrs]

[REQUIRED] Card diagnostic information:

N/A

[REQUIRED] Description of problem:

When a camera entity is unavailable, the card renders the following:

Which is nice.

However, when go2rtc is set as the live provider for the camera, such screen is not triggered even when the camera entity is unavailable:

[OPTIONAL] Last working release (if known):

N/A

[OPTIONAL] Javascript errors shown in the web inspector:

N/A

[OPTIONAL] Additional information:

Example config:

type: custom:frigate-card
cameras:
  - camera_entity: camera.camera_03
    live_provider: go2rtc

I believe the easiest way to make the camera entity become unavailable is perhaps by forcing its state in the Home Assistant developer tools.

[dermotduffy]

The issue here is that I don't want providers to depend on entities unless absolutely necessary (e.g. using go2rtc without an entity is not uncommon).

Technically go2rtc does not really use a camera_entity at all, which is why this does not currently happen. The only usage is getting the real Frigate camera name from it on camera initialization, and then that is used to identify the go2rtc stream name later (none of which cares whether the entity to be available or not).

Lets imagine this case:

cameras:
  - camera_entity: camera.office
    frigate:
      camera_name: office
    go2rtc:
      stream: office_stream

Should the unavailable error be shown if the entity is unavailable? I would argue not as the live_provider does not actually care. One option could be to show it as unavailable if only the entity is specified, but that's harder than it looks since the live provider cannot currently tell the difference between the camera_name being manually set and being autodetected. I could implement this, but I'm not really sure it's worth it ...

[felipecrs]

Got it. I thought the "entity unavailable" would actually be called before the live provider loads, and that you perhaps had just skipped it for the go2rtc source.

I personally believe it makes sense to honor the entity unavailable state in order to provide a better user experience. For one, when the stream is unavailable in Frigate, it renders the black screen "No frames received, check logs" in my Frigate Card streaming with go2rtc, which I can absolutely comprehend, but I cannot say the same for my householders that do not speak English nor have any clue on what "frame" and "logs" mean. lol

But your reasoning makes total sense as well: if the stream URL/name is overridden from the entity, the entity state would be meaningless.

Except that I use substreams that share the same entity id, but have a stream name like garden_hd. In this case, it would make sense to also render the unavailable stream in case the entity is unavailable.

Maybe introducing a new option like stream_if_entity_unavailable that users can disable would be the best.

[dermotduffy]

Maybe introducing a new option like stream_if_entity_unavailable that users can disable would be the best.

i.e. stream_if_entity_unavailable would default to true, but if set to false then all live providers would fail with the card produced (translated!) error message if (i) an entity was specified, and (ii) it was unavailable. Otherwise, behavior would be as it is today. Is this what you mean?

[felipecrs]

That's correct.

(Or would it make sense to make this an option of the go2rtc live provider only? On the other hand, I can at least think of the webrtc-card provider, which could benefit of the same setting.)

BTW, you mentioned at some point that this would be somewhat hard to implement. My answer to that is: prioritize it accordingly. I admit this issue isn't anyhow major.

[dermotduffy]

(Or would it make sense to make this an option of the go2rtc live provider only? On the other hand, I can at least think of the webrtc-card provider, which could benefit of the same setting.)

Yeah. I think it'd be at the overall provider level, I can imagine new providers in future that don't care about the entity.

BTW, you mentioned at some point that this would be somewhat hard to implement. My answer to that is: prioritize it accordingly. I admit this issue isn't anyhow major.

As defined now, I don't think it would be hard.