0.104: Sentry, Signal Messenger, IntesisHome, Sure Petcare, KEF

Hi, after updating to 0.140.1 I’ve got this error initializing Hue:

Error setting up entry Philips hue for hue
Traceback (most recent call last):
File “/srv/homeassistant/lib/python3.7/site-packages/homeassistant/config_entries.py”, line 215, in async_setup
hass, self
File “/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/hue/init.py”, line 115, in async_setup_entry
allow_groups = config[CONF_ALLOW_HUE_GROUPS]
KeyError: ‘allow_hue_groups’

Thanks in advance.

My Philips Hue stopped working after the update. It was rediscovered, so I removed the existing one and readded it. But its empty now, no lights got discovered.
So i thought restarting after removal but before readding may do the trick. After rebooting it discovered 2 Philip Hues for the same device. I could add both, but they both still didn’t discover any lights.

Edit: still had a config entry in configuration.yaml. Removed that and rebooted, now it’s working.

Edit 2: in the process of re-adding (and probably a update on the hue bridge), all my lights have different names! In addition that the groups from the hue bridge also disappeared (except adding a config entry - I just removed that entry to get it discover any lights at all!).

This is a major breaking change and can cause quite some downtime. Please adjust the breaking change section accordingly.

Had the same thing on unraid docker image for homeassistant, downgrading to 0.104.0 and hue is working again.

I have maybe about 100 entities hidden/ignored by putting them under zwave: like this:

device_config_glob:
  "*_ignore":
    ignored: true
    polling_intensity: 0
  "sensor.*_axis":
    ignored: true
    polling_intensity: 0
  "sensor.*_energy*":
    ignored: true
    polling_intensity: 0
  "sensor.*_exporting":
    ignored: true
    polling_intensity: 0
  "sensor.*_heat*":
    ignored: true
    polling_intensity: 0
  "sensor.*_power_management":
    ignored: true
    polling_intensity: 0
  "sensor.*_seismic_intensity":
    ignored: true
    polling_intensity: 0
  "sensor.*_sourcenodeid":
    ignored: true
    polling_intensity: 0
  "sensor.*_system":
    ignored: true
    polling_intensity: 0
  "sensor.*sensor_general":
    ignored: true
    polling_intensity: 0

I do this because disabling them from the GUI generates a flood of errors in the log, saying it’s a fault with the integration. However now from 0.104, they all come back as unavailable. Is there another preferred way to get rid of them, or should i just start clicking remove entity one-by-one?

Same thing with Tradfri.

Darn. That is something I want to avoid.

Looks like allow_hue_groups is required now: https://github.com/home-assistant/home-assistant/issues/30876#issuecomment-575519760

Yes, I’ve added the variable in the Hue configuration section and It’s working again. I guess the doc should be changed.
Thanks.

group.all_devices was useful in appdaemon to set a listen state for when someone arrives home or everyone leaves.

What’s the preferred method now?

Group.all_lights, and group.all_switches was also useful in appdaemon to turn off a mixture of different platforms (eg lights and switches) and mixture of groups and individual entities specified in apps.yaml.

What is the preferred method now?

I’m not sure, but maybe you can use something like self.listen_state("device_tracker") to listen to all device_trackers. @ReneTode what is the preferred way to do this now?

That might work when “someones arrived” because just one device tracker needs to change state from not_home to home.

But in the case of “everyones left”, all device trackers that are home need to all change to not_home. So I dont think this will work :frowning:

Came across this post to get any desired group.all_* back.

Seems the best option for those needing group.all_lights, group.all_devices, etc

1 Like

I ran Check Configuration and I’m seeing:
“Platform error sensor.modem_callerid - No module named ‘serial’”

What does this mean and how to fix?
I’ve just started experimenting with this platform in 103 and would like to continue in 104.

After this update and after re-configuring Ring via the config flow, my Ring binary sensors for doorbell press and motion are not working. What’s strange is that the “last activity” sensors are correct, but the binary sensors don’t change state. Anyone else experiencing this?

EDIT: Looks like I’m not the only one, post #312 Ring integration setup fails

1 Like

Will try again later today. I reverted back to 103.6 yesterday.
Althou I don’t remeber seeing a delete button anywhere on the dead group.

For this that have not yet upgraded OR have reverted back to previous version.

Robban has explained that the issue is a side effect of a code change he did (side effect that he had missed - hey we are all only humans :wink: ) and he has described a manual hack of the core.device_registry that you can do BEFORE you upgrade.

In short - the issue is that from 0.104 the Deconz integration generates internal references to groups with a new method and if you already have groups defined you end up with duplicate groups. Robban’s workaround is to stop Home Assistant and hack the Deconz existing group reference to the new format (which is removal of 4 F’s in a hex number).

This only works before you upgrade Home Assistant!! See the link and also follow the next 10-15 comments. It is hacking of a JSON file but much less trouble than the clean-up I describe that you need to do AFTER the duplicate groups have been created.

3 Likes

yes you can listen to all device_trackers and then loop through the state from the devicetrackers and generate the group state.

with some simple apps you can even get the wanted groups back.

It’s a config error. What does the error look like in home-assistant.log? That message does not look like it came from the log files.

make use of the presence functions that AD has. (everyone_home(), noone_home(), anyone_home() )
and the presence constraint functions

with get_state you can get a dict with all lights or all switches, which then can be used to turn off.

2 Likes

Yes this was what I was going to do. Saw some methods using HA automation and python_script.

Do you know what the listener function in appdaemon is for when HA boots up?