Open flo-wer opened 1 year ago
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 has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
This is still an issue for 2023.12
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 has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
This is still an issue for 2024.3
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 has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
I tested this with 2024.6.0 and it is still there. Based on some debug tracing and code inspection, I believe the cause is as follows.
In class ManualTriggerEntity
the method _process_manual_data
calls async_write_ha_state
and later calls method_render_templates
in superclass TriggerBaseEntity
, which populates _rendered
. But the ValueError
exception is raised during _stringify_state
as called indirectly from async_write_ha_state
so the call to _render_templates
never happens. The value of _rendered[CONF_AVAILABILITY]
is initially None
and it stays that way.
The available
property of class ManualTriggerEntity
treats None as True:
@property
def available(self) -> bool:
"""Return availability of the entity."""
return (
self._rendered is not self._static_rendered
and
# Check against False so `None` is ok
self._rendered.get(CONF_AVAILABILITY) is not False
)
So, the availability template never gets rendered and the availability continues to be judged on the basis of the original None, which means True and the exception keeps getting raised each time there is new data.
Someone with more knowledge of this or other integrations may be able to comment on the preferred way of ensuring that availability is rendered before it is tested as a precondition to populating the state (or even on whether basing availability templates on the value data is supposed to be supported).
I'm having this exact problem and it is significantly impacting the usefulness of HA for me. I use a large array of REST sensors that report the values of devices that aren't always fully reliable. I used to be able to return "null" or some other error value for numeric sensors for which a value wasn't available. Now, AFAICT, it is basically impossible to handle any kind of error with a numeric sensor. Worse, it silently maintains the original value in the UI and in the graphing of the value. This is just wrong. If there's no value, there's no value, and I want that reflected in the UI and in the history of the sensor. Even worse, the way the exception is raised means that if any single sensor in a rest integration fails, none of the values get updated for any of the sensors.
So far, I haven't even found a credible way to work around this. Are there any HA devs watching these issues? It seems like this issue is just being ignored, which is quite upsetting as it has a pretty serious impact for me.
Same issue here: https://community.home-assistant.io/t/rest-sensor-ignores-the-availability-line-in-the-yaml/753237/4
The rest sensor is not respecting its availability ...
So far, I haven't even found a credible way to work around this. Are there any HA devs watching these issues? It seems like this issue is just being ignored, which is quite upsetting as it has a pretty serious impact for me.
Hi @symposion,
One reason it may not be getting attention is because it is not just about RESTful sensors: evaluating the state before evaluating the availability template is common to other integrations (see my comment above).
Not sure what counts as "credible", but one workaround would be to have a template sensor for each of your numeric sensors so that the RESTful sensors are always strings and the template sensors would assess availability and avoid invalid numeric values.
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 has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
This is still an issue for 2024.10
The problem
The rest sensor is still raising the
non-numeric value: 'None' (<class 'str'>)
error despite using theavailability
config to filter any non-numeric values (see theis_number
condition). I included example API responses for both cases. In the not available case, theavailability
condition evaluates to false and the value_template equalsnull
/None
. This produces the below exception.What version of Home Assistant Core has the issue?
core-2024.10
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant Core
Integration causing the issue
rest
Link to integration documentation on our website
https://www.home-assistant.io/integrations/sensor.rest/
Diagnostics information
No response
Example YAML snippet
Anything in the logs that might be useful for us?
Additional information
REST API response available:
not available: