I have an issue with the way triggers are initialised.
* Error initializing 'Lane Gate Battery Monitor' trigger: In 'numeric_state' condition: state of sensor.laneway_gate_battery is unavailable
* Error initializing 'Mailbox Battery Monitor' trigger: In 'numeric_state' condition: state of sensor.mailbox_battery is unavailable
These devices spend 99% of their time asleep. Do I have to run out into the back yard and wake them up every time I want to restart home assistant or reload automations?
Yes, but then it is still not clear if the migration has happened successfully, etc. etc. Why always having arguments “it’s all fine, the problem is always in front of the keyboard” and not hearing other ideas.
But yes, killer argument to leave everything always and forever as it is (even when this is not an optimal approach) is always possible.
I’m seeing similar errors. I guess this goes for this, mentioned in breaking changes for Automations:
Scripts and automations are now more careful about reporting problems with conditions. For example, a state condition that references an unavailable entity will log a message warning about the problem. Depending on the circumstances when such errors happen, the flow of the automation (i.e., stop/continue) might end up different from before.
I’m also not quite sure, what that means. I guess the automation will still get triggered, as soon as the sensor updates its state.
Because it has been discussed a thousand times already, and your “other ideas” have been brought up before.
It’s quite difficult to implement something like “comment out YAML config” as there are so many different possibilities of configs. I rather have the devs implement new features, fix bugs and other this than spending time on something that can be resolved by the user in a few mins if he reads the release notes.
I still think you have hundrets of users with a mess of integration here and there (after such braking changes( and the project should avoid such situation, e.g. as in Shelly for hass:
I’ve lost count of the number of times I’ve selected the entity id from there copied it and pasted it elsewhere only to find it has included a space in front of the entity id and now my indentation is messed up.
It’s a simple thing but one that will make my life easier.
I have the same problem (as I guess everyone will have).
I suspect it has to do with the ACE editor upgrade…
I used to do some work on different CMSes and the motto concerning WYSIWYG editors was always: “If it works and isn’t a security risk, never update it”
Unfortunately I don’t know ACE editor well enough to try and fix this…
Yes the lights were groups. I enabled the “Allow Hue groups” checkbox In the Philips Hue integration and the “group lights” were re-enabled.
I forgot they were groups because in my UI the lights are referred to as “light”.
I read in the breaking changes Hue groups are now disabled by default because they do not have a unique ID. Existing configurations that have previously saved Hue options are not affected.
Since I already had a Hue config running I thought this breaking change was not applicable to my setup.
In a way, that is exactly what won’t happen … hence the warning. The numeric_state will no longer trigger when going from unavailable to within range, it must have a valid reading outside the range before it will trigger.
We are prepared to tone down the warnings when we understand how they cause false alarms so please create GitHub issues to make us understand the use cases.
Been trying to find the result of this error since the updated, I don’t have any conditions that use state or this entity…it’s frustrating, any ideas? thanks
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/generic_thermostat/climate.py", line 398, in _async_sensor_changed
await self._async_control_heating()
File "/usr/src/homeassistant/homeassistant/components/generic_thermostat/climate.py", line 442, in _async_control_heating
long_enough = condition.state(
File "/usr/src/homeassistant/homeassistant/helpers/condition.py", line 387, in state
raise ConditionErrorMessage("state", f"unknown entity {entity_id}")
homeassistant.exceptions.ConditionErrorMessage: In 'state' condition: unknown entity switch.aircon_bedroom
Just updated to this new release, seems it breaks the modbus integration:
Logger: homeassistant.components.sensor
Source: components/modbus/sensor.py:134
Integration: Sensore (documentation, issues)
First occurred: 12:54:47 (1 occurrences)
Last logged: 12:54:47
Error while setting up modbus platform for sensor
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 200, in _async_setup_platform
await asyncio.shield(task)
File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/src/homeassistant/homeassistant/components/modbus/sensor.py", line 134, in setup_platform
hub = hass.data[MODBUS_DOMAIN][hub_name]
KeyError: 'modbus_hub'
If I roll back to the previous snapshot all works perfectly again
