Computed sensor does not become unavailable, when the underlying real sensor becomes unavailable.

[darrenfreeman]

I have some ZigBee temperature/humidity sensors that are on vehicles, and so they become unavailable fairly often. Unfortunately, when this happens, the heat index and the dew point continue to report valid states. (I assume the other computed values would behave similarly.)

This can be problematic when using the value in an automation, for example running an air-conditioner until a room becomes very cold.

[darrenfreeman]

Another downstream problem caused by this - when combining the values in e.g. max/min helpers, they completely screw up the behaviour of the helper, when some sensors are unavailable.

[rautesamtr]

Sure we could make them unavailable when the state of input sensors is unknown over unavailable. If we do this we probably should also show a notification in the UI so the user knows why this happens.

@dolezsa what do you think?

[darrenfreeman]

I don't think a notification is the correct behaviour, none of the core helpers do this.

Also, all sensors are unavailable during HA startup. If the user wanted a notification, they should be looking at the integration that provides the physical sensor, as Thermal Comfort can't tell the reason why the sensor is unavailable.

[dolezsa]

Of course, I agree with you, rautesamtr, this is more than logical. 👍

[dolezsa]

I was wondering that the notification might be reasonable in a way that the sensor value would indeed be 'unavailable,' but we would communicate the reason in an attribute, for example, that the temperature sensor is not accessible...

[darrenfreeman]

I'm looking forward to testing a fix, I have sensors coming and going all the time. The good news is I think it does go unavailable, if you fully restart HA.