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

All the reload.input_* services work except for input text.

Script:

reload_input_texts:
  alias: 'Reload Input Texts'
  sequence:
  - service: input_text.reload

Error log:

2020-01-16 21:59:43 ERROR (MainThread) [homeassistant.components.script] Error executing script script.reload_input_texts. Service not found for call_service at pos 1: Unable to find service input_text/reload
2020-01-16 21:59:43 ERROR (MainThread) [homeassistant.core] Error executing service <ServiceCall script.reload_input_texts (c:f01e52f596604783b884f3b0f18391cd)>
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/core.py", line 1234, in _safe_execute
    await self._execute_service(handler, service_call)
  File "/usr/src/homeassistant/homeassistant/core.py", line 1251, in _execute_service
    await handler.func(service_call)
  File "/usr/src/homeassistant/homeassistant/components/script/__init__.py", line 137, in service_handler
    await script.async_turn_on(variables=service.data, context=service.context)
  File "/usr/src/homeassistant/homeassistant/components/script/__init__.py", line 209, in async_turn_on
    raise err
  File "/usr/src/homeassistant/homeassistant/components/script/__init__.py", line 204, in async_turn_on
    await self.script.async_run(kwargs.get(ATTR_VARIABLES), context)
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 189, in async_run
    await self._handle_action(action, variables, context)
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 272, in _handle_action
    await self._actions[_determine_action(action)](action, variables, context)
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 354, in _async_call_service
    context=context,
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 96, in async_call_from_config
    domain, service_name, service_data, blocking=blocking, context=context
  File "/usr/src/homeassistant/homeassistant/core.py", line 1201, in async_call
    raise ServiceNotFound(domain, service) from None
homeassistant.exceptions.ServiceNotFound: Unable to find service input_text/reload

EDIT: never mind. I didn’t have input_text: in my configuration.yaml file!

same problem two tv, only one working … :frowning:

PSA: If you use zwave2mqtt for your locks, 0.104 is a breaking change for auto-discovery.

You can update the discovery payload in the zwave2mqtt web gui to include the following:

  "discovery_payload": {
    "state_locked": true,
    "state_unlocked": false,
    ...

I’ve opened this issue to have zwave2mqtt updated.

Cant edit home screen in app anomore.
Visual editor for cards crashes and if saved the entire tab is blank. Same in ui.

Example iframe card: Expected a value of type string | undefined for aspect_ratio but received 0.

For me, I have the deconz all lights group and it is duplicated, but then I also have “lightgroup” light groups. I do use deconz, but I also have some light groups made up of both zigbee lights from deconz, and zwave lights fro ZWA, and I am getting duplicates of those lightgroups too. Group - Home Assistant

1 Like

Note

I cannot comment on duplicated input_booleans.

It was noted in the release notes the breaking change of old dormant ghost entities that could show up. For things that are related to that I would just bite the bullet and fix it once and for all.

The Deconz issue is different because it is not old dormant entities that suddenly show up.

It is at device level all groups from Deconz get duplicated.

It has nothing to do with the Deconz Addon changes that Frenck did recently. I run with a Deconz outside the Home Assistant realm where it is a pure API connected from Deconz to Home Assistant. Deconz was not even restarted in connection with the 0.104 upgrade.

The issue seems to be that in 0.104 something changed that make Home Assistant re-discover all Deconz groups as if they were new groups and in that action it leaves all the existing groups orphan. But since there are already entities associated with the old groups all the new groups get associated with new _2 entities and then the whole system breaks down because all automations and front end refers to the old now broken entities.

To fix the deconz specific issue do this in this exact order.

Go to the Integrations page and open the Deconz Integration. You now see all your deconz devices listed. You can easily see the duplicate light groups.

Walk through each duplicated group and click on the first.
Verify that it has an entity associated with it not ending with _2
Delete this entity
Give this old group Device (not entity - device!!) to a name that we can later find. I called mine the old group name appended by crap (that was my mood in the situation). Use a string that is unique
One step back and open the other new group device
Rename the associated entity to same name but remove the _2

Note that you have to delete the old entity first before you can rename the new _2 because you cannot rename to an existing name.

Do this with all the groups.

In principle all works now. But you still have some old “cruft” devices in the core.device_registry that you cannot delete from any user interface. I am sure that will haunt you again in future and can cause more duplication to occur. The only way to delete deconz devices is to hack the JSON file

So next steps are…

Stop Home Assistant to avoid hacking live data.

Go to .storage and save a backup of core.device_registry

Now open the core.device_registry in a text editor and search for that name you appended to the old devices (crap in my case).

Now carefully delete the entire JSON object that contains this crap device. Be careful with the commas. Especially if it is the last member you delete. There can be no trailing comma in the list. That is why we saved a backup in case we goof up. Hacing JSON is horrible but it is the only way because Home Assistant still has no user interface for deleting devices. It is only entities we can delete in the user interface (which also means that each time a light bulb fails and I buy a replacement, I have to hack JSON files to get rid of the old).

Since 104 I’m getting the following error:

“The ‘api_key’ option (with value ‘blablabla’) is deprecated, please remove it from your configuration. This option will become invalid in version 0.105”

I’ve looked at the PR discussion here: https://github.com/home-assistant/home-assistant/pull/30402

…but am still unclear as to what effect removing the api_key is going to have on my setup. Do I need a ‘service’ account? What is a ‘service’ account? Will removing my API key remove my access to the request_sync service?

The config is supposed to be stored in .storage now and not need unique filenames like prior releases.

I have 2 WebOS TV’s working…

Do you see the files in config - those should not exist any more. Mine do not.

Playstation Integration is still broken - it says it couldn’t be found on the network even when it’s clearly discovered by autodiscovery, is switched on and has no issues to be accessed from LAN and WAN. Previously added PS4 continue to kind of work but very unreliably.

@jwelter The webostv.conf file is recreated just like it always has been, but with only the details of the last paired tv. There’s no mention anywhere of it using .storage that I can see (and having looked I can’t see anything in the files there).

However the following link (and the link within in it) seems to suggest that use of the .conf file is still expected and likely fixed in 104.1 when released:-

So I guess a few days should see me fixed - thanks for the reply.

When creating Zigbee groups, I’m getting the details for the last group I created (with the devices I added to the new group added to the previous group) without a new group created. There are no errors in the log and I’ve cleared cookies/browser.

These are the groups I’ve been able to create.

Creating a new group:

After clicking on “Create Group”, I get this with lights I added to my Carport Lights group (and no group created):

Stats:
image

My update from 0.103.6 failed and I had to power off the Rpi. Is there some update log etc where I could try to find the reason?

I was able to get this working by copying the token created by the pairing request, then putting them together manually in the webos.conf file like this: {“192.168.1.xxx”: “a1007cea8ad4be8axxxxxxxxx”, “192.168.1.xxx”: “8011c444f8376143xxxxxxxxxxxx”}

I’m not sure if this is actually doing anything, it may be totally wrong, but it seems to be working for now, as I no longer get the pairing request notification on startup, and the TVs work fine in hass.

Mine is running and no webostv.conf in the configuration folder… So it is somewhere else.

Question:

  • What to do with the “newly discovered” Philips Hue bridges? Note they are already discovered…

Almost a flawless upgrade! :ok_hand:

1 Like

This works for me too…and I’d even tried putting commas at the end of each line - I just hadn’t removed the {} around each line individually.

Thanks!

@Vasco @WhistleMaster @KennethLavrsen I think this issue is the result of me normalising bridge id, which groups unique id are based on. I didn’t reflect on this affecting entity unique ids, this should have been a breaking change or done in a different way. I haven’t verified this though

3 Likes

Same here, two new hue bridges discovered. But only one already discovered one is active in my network. Any advices or workarounds? Should I just press “IGNORE” then? :smiley:

Read the google assistant docs for how to setup the service account. It also talks about what services it provides.

I have a few https://www.home-assistant.io/integrations/light.group/ type light groups also. And mixed with non-Deconz lights. I did not get any duplications of those.