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 getting mixed signals about the Z-Wave JS server version I need:
The blog post says 1.10:
But further down in the breaking changes it talks about minimum 1.0.0
I can’t find any version newer than 1.1.0, so is that new enough or not?
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
statecondition 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.
What’s that?
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:
Copy the entity id.
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.
Thanks for the tip!
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.
As my numeric sensors are via MQTT I can fix my issue by setting the retained flag. I think. I’m about to test it.
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
Same here, must be a bug, but seems not a lot users are affected…
Thank you for all the work to make this better every time!
Two things that I’ve noticed about right away, but nothing that worries me:
1 - My snapshots can’t get a name anymore. They are just randomly named
2 - CPU-Load average in Synology DSM has a typo I think: “averarge”.
That seems to refer to the heater entity of a generic_thermostat not existing.
The log noise is a bug, I will fix that for the next update.
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
Great update, thanks.
But mysensors integration gives following error :
Unable to find service notify.mysensors
I tried with or without these lines in the configuration file :
mysensors:
gateways:
- device: '/dev/ttyUSB0'
version: '2.3'
persistence: true
Any idea ?