Not necessarily. I also want to check how it works with 2 website TVs. As far as I understood there is a multiline file to store the keys for each IP. Webos docs says that keys are up address sensitive
Yeah, i’ve also got 2 LG TVs, how should i do the configuration.yaml now? Like this?
webostv:
- host: 192.168.1.11
name: 'Livingroom TV'
- host: 192.168.1.12
name: 'Bedroom TV'
I can’t figure out how to actually fix the link and submit a pull request …
In two spots for the change related to the new local_ip integration the link needs to be updated.
The current link is: (note the missing _ )
https://www.home-assistant.io/integrations/localip/
The correct link is:
https://www.home-assistant.io/integrations/local_ip/
With removal of default groups, what is the recommended replacement for group.all_lights.default usage in light_profiles.csv?
Just updated, no new errors in my log, restarting seems quicker also, thanks. 
Only had to remove 114 entities…
Also I had zero interest in Elgato Keylights before this update, but now I’m slightly intrigued.
1 reply
My upgrade to 0.104 was messy
There is a bug that triggers when you upgrade.
All my deconz light groups were suddenly duplicated in the Deconz Integration
And this resulted in all those light groups to be duplicated entities also all with suffix _2
And the result was that no light automations and no dimmer switches worked any more.
To clean it up I had to delete all the original entities which you can do from the UI.
Then I had to rename all the _2 to the old names
And finally I had all the duplicate Deconz groups that I had to delete. And again - the only way you can delete them is to stop Home Assistant and hack the JSON file core.device_registry in a text editor.
We really need a feature so you can delete not only entities but also devices.
Why were all the Deconz light groups duplicated? And will it happen again?
Edit. I checked the last backup of core.device_registry from just before the upgrade and there was only one instance of each Deconz groups. No old cruft. This happened during the upgrade
4 replies
I had the same issue with deconz groups.
On the Integrations page, there’s a new action menu (3 dots) in the top right corner. That’s how you can show or hide ignored integrations.
A bunch of old entities/sensors/devices that hadn’t been showing up in HA or were registered under different names
I have three WebOS TV’s - How do I now configure these?
I have swapped the config over, but I am getting error messages about duplicates like this:
2020-01-16 02:25:07 WARNING (SyncWorker_0) [homeassistant.util.yaml.loader] YAML file /config/webostv.yaml contains duplicate key “host”. Check lines 1 and 17.
2020-01-16 02:25:07 WARNING (SyncWorker_0) [homeassistant.util.yaml.loader] YAML file /config/webostv.yaml contains duplicate key “name”. Check lines 2 and 18.
2020-01-16 02:25:07 WARNING (SyncWorker_0) [homeassistant.util.yaml.loader] YAML file /config/webostv.yaml contains duplicate key “turn_on_action”. Check lines 5 and 21.
Rik
1 reply
This works for me:
webostv:
- host: 192.168.10.xxx
name: "Family Room TV"
turn_on_action:
service: wake_on_lan.send_magic_packet
data:
mac: C8:08:E9:xx:xx:xx
- host: 192.168.10.xxx
name: "Master Bedroom TV"
turn_on_action:
service: wake_on_lan.send_magic_packet
data:
mac: 38:8c:50:xx:xx:xx
Note the first TV which used the default filename for the auth was automatically ported over. The second which had a custom file name needed to be re-added.
3 replies
Not all integrations are config entries but they still register entities to the registry so in some cases you need to do both.
I had a bulk renaming problem to solve unrelated to doing a Home Assistant upgrade, and found that using hass-cli in a shell script a good solution to bulk entity renaming. See the thread over here: What is the preferred way to rename z-wave entities? - #173 by lmamakos for some info that technique.
i threw myself over a “ctrl + f” yet again to be disappointed 
there is still a bug affecting everyone using more than one philips hue bridge wanting to apply hue scenes. so close but still no cigar
This update creates a mes with my deconz groups, hue platform did not work and a lot of my input_boolean got renamed to _2.
So stay away if you dont want a lot of work…
Painless update for me. Well done folks.
Is there any plan to add the new input_*.reload services to the Configuration/Server Controls menu?
I get these errors after update:
2020-01-16 09:22:05 ERROR (MainThread) [aiounifi.api] Couldn't find key: 'None'
2020-01-16 09:22:05 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 284, in async_update_ha_state
self._async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 320, in _async_write_ha_state
state = self.state
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 588, in state
return STATE_ON if self.is_on else STATE_OFF
File "/usr/src/homeassistant/homeassistant/components/unifi/switch.py", line 219, in is_on
return self.port.poe_mode != "off"
File "/usr/src/homeassistant/homeassistant/components/unifi/switch.py", line 264, in port
return self.device.ports[self.client.sw_port]
AttributeError: 'NoneType' object has no attribute 'ports'
Hi,
after update, my MPD media player is failing to init.
I’ve got this error:
mpd: Error on device update!
Traceback (most recent call last):
File “/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity_platform.py”, line 299, in _async_add_entity
await entity.async_device_update(warning=False)
File “/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity.py”, line 461, in async_device_update
await self.hass.async_add_executor_job(self.update)
File “/usr/lib/python3.7/concurrent/futures/thread.py”, line 57, in run
result = self.fn(*self.args, **self.kwargs)
File “/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/mpd/media_player.py”, line 154, in update
self._fetch_status()
File “/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/mpd/media_player.py”, line 136, in _fetch_status
position = self._status[“time”]
KeyError: ‘time’
Any idea? I guess it’s related to @ndonegan changes.
1 reply
Hi, QNAP NAS after update, failing to start. I’ve got this error:
Failed to fetch QNAP stats from the NAS
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/qnap/sensor.py", line 191, in update
self.data["system_stats"] = self._api.get_system_stats()
File "/usr/local/lib/python3.7/site-packages/qnapstats/qnap_stats.py", line 207, in get_system_stats
force_list=("DNS_LIST")
File "/usr/local/lib/python3.7/site-packages/qnapstats/qnap_stats.py", line 67, in _get_url
self._init_session()
File "/usr/local/lib/python3.7/site-packages/qnapstats/qnap_stats.py", line 49, in _init_session
if self._login() is False:
File "/usr/local/lib/python3.7/site-packages/qnapstats/qnap_stats.py", line 57, in _login
result = self._execute_post_url("authLogin.cgi", data, False)
File "/usr/local/lib/python3.7/site-packages/qnapstats/qnap_stats.py", line 98, in _execute_post_url
return self._handle_response(resp, **kwargs)
File "/usr/local/lib/python3.7/site-packages/qnapstats/qnap_stats.py", line 110, in _handle_response
data = xmltodict.parse(resp.content, force_list=force_list)['QDocRoot']
File "/usr/local/lib/python3.7/site-packages/xmltodict.py", line 173, in parse
handler = _DictSAXHandler(*args, **kwargs)
TypeError: __init__() got an unexpected keyword argument 'force_list'
Checked config, restarted couple of times, even rebooted hassio. Nothing helped.
Is there a way to get the all_lights group back ? I use it in node-red (together with some function node) to turn off all lights EXCEPT a couple …
Also the locks group was quite handy to lock all my doors at night, or to check if all the doors were locked. How should this be done now ? Do I have to create (and maintain …) these groups manually now ?
Removing all these groups is quite a big change. Is there a way to get them back ?
1 reply
Seems like the new “light buttons” do not respect defined groups in groups.yaml?
I have the generated lovelace view. Instead of my previously organised groups with light switches, I now have a bunch of unorganised big buttons 
, any way to go back to switches without customizing the lovelace view?
This is way too cumbersome. Do I need to create a new binary_sensor too to check if all doors are locked ?
But disappointed by this drop without a simple replacement or way to turn it back on.
1 reply
Praise the lord for fixing the RFXtrx covers! Up to now, “up” was “down” and vice versa!
Yes, and then I have to maintain them too. Point is, this was all done automatically. Add a lock to the system, the UI was immediately up to date thanks to the all_locks group.
I’ve done the prerequisite work of removing existing ring config but when I go to integrations and click ‘Ring’ it goes back to the choose integration pop up.
Log shows
Error occurred loading config flow for integration ring: cannot import name 'Auth' from 'ring_doorbell' (/config/ring_doorbell/__init__.py)
I did previously do the Ring workaround, could this be affecting it?
Edit - Deleted the folder ring_doorbell from config and it’s working.
That still doesn’t allow you to link to a button or switch showing status of all lights.
Hopefully a custom integration will be created, creating such groups automatically.
Yes, i saw it. I agree for turning on/off lights, or lock/unlock doors, this is ok.
But now there is no built-in solution to check if all door are locked, all lights are turned off, …
I guess I’m not to only one who thinks this is an issue ?
1 reply
“Note the first TV which used the default filename for the auth was automatically ported over. The second which had a custom file name needed to be re-added.”
I have four webos tv’s - when I go through the process each one overwrites the default file with it’s own config and so only the last one ever works after a restart of HASS. So what exactly do you mean with your statement, since individual conf files no longer seem to be supported ? Or have you just not restarted HASS since getting it working ? i.e. you re-added ‘what’ to ‘what’ ?
1 reply
Same issue wit Deconz. Had to revert back to 0.103.6, with a lot of work to clean the duplicated input_booleans, groups, etc.
1 reply
did you see this comment at the bottom the arch issue on how to create your own dynamic group
while it applies to lights it should be easy for others
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 …
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 reply
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).
1 reply
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?
1 reply
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.
2 replies
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:
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.
1 reply
Mine is running and no webostv.conf in the configuration folder… So it is somewhere else.
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
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? 
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.
That section was there for a few releases actually. Ever since report state was added It is just easy to miss as it is part of the install steps.
The HEOS integration doesn’t work anymore. My devices were unavailable → I removed the integration and wanted to re-add it via Lovelace, but HEOS is not available as an option…
Hi, i have the same problem since the update
How would you do the delete? There is no delete button for single entities in the integrations page.
1 reply
After updating from 103.5 to 104.0 Home assistant entities cannot connect to mqtt service. It is starting and therefore clients are able to connect that are external clients to HASSIO. Am using HassOS 3.8 with the Mosquitto broker addon.
I get the following in the logs
Mosquitto log:
1579204435: New client connected XXX.XXX.XXX.XXX
HA log:
2020-01-16 19:42:20 ERROR (MainThread) [homeassistant.components.mqtt] Failed to connect due to exception: [Errno 110] Operation timed out
2020-01-16 19:42:20 DEBUG (MainThread) [homeassistant.components.mqtt] Subscribing to owntracks/#
2020-01-16 19:42:20 ERROR (MainThread) [homeassistant.setup] Error handling when_setup callback for mqtt
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/setup.py", line 307, in when_setup
await when_setup_cb(hass, component)
File "/usr/src/homeassistant/homeassistant/components/owntracks/__init__.py", line 144, in async_connect_mqtt
context.mqtt_topic, async_handle_mqtt_message, 1
File "/usr/src/homeassistant/homeassistant/components/mqtt/__init__.py", line 442, in async_subscribe
encoding,
File "/usr/src/homeassistant/homeassistant/components/mqtt/__init__.py", line 842, in async_subscribe
await self._async_perform_subscription(topic, qos)
File "/usr/src/homeassistant/homeassistant/components/mqtt/__init__.py", line 878, in _async_perform_subscription
_raise_on_error(result)
File "/usr/src/homeassistant/homeassistant/components/mqtt/__init__.py", line 985, in _raise_on_error
"Error talking to MQTT: {}".format(mqtt.error_string(result_code))
homeassistant.exceptions.HomeAssistantError: Error talking to MQTT: The client is not currently connected.
I get the same in the logs after commenting out:
configuration.yaml
#owntracks:
# max_gps_accuracy: 200
# waypoints: true
# mqtt_topic: "owntracks/#"
# events_only: false
# waypoint_whitelist:
# region_mapping:
# shed: home
# office: work
In Developer tools > MQTT I try to publish a topic but get the following
unable to call service mqtt/publish. Service not found
was working before upgrade.
Thanks!
1 reply
All my deconz connected devices are dead. Their entities are showing as unavailable.
They have not been duplicated; they are just not seen by HA, although they are functioning perfectly in Phoscon. What can I do? Should I delete the entities from HA? Will they then be rediscovered?
When you see the list of devices - click on the one that you believe is the old one (normally the first of the two). Then you see the page that lists all entities that are associated with the device. For a deconz group there is only one.
Then clock on the gearwheel icon. The pop-up should show a delete link in the lower left corner. It will only available if the entity is in status unavailable which the old group will be.
And it is the same for renaming the _2 entity. Instead of delete you update the entity name by removing the _2 and hit update in the lower right corner
I with there was a similar delete function for the device but we can only rename devices which is the gearwheel in the top right of the screen when you have opened a deconz device
1 reply
This is what worked for me:
MQTT: <IP Address> in Configuration > Integrations. At some point maybe after I restarted HASSIO I went back to Configuration > Integrations, and “Mosquitto: configure” appeared near the top. Clicked on configure, confirmed Enable discovery (not sure if this is the exact wording) and clicked through rest of wizard.It is now working, try step 2) first as step 1) didn’t make any initial difference in fixing issue. If step 2) doesn’t work then try step 1) & 2).
After updating to 0.104.1 I’m seeing the following error which wasn’t in 0.104.0:
Log Details (ERROR)
Thu Jan 16 2020 23:16:19 GMT+0000 (GMT)
extra keys not allowed @ data['0']
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 134, in handle_call_service
connection.context(msg),
File "/usr/src/homeassistant/homeassistant/core.py", line 1204, in async_call
processed_data = handler.schema(service_data)
File "/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py", line 272, in __call__
return self._compiled([], data)
File "/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py", line 594, in validate_dict
return base_validate(path, iteritems(data), out)
File "/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py", line 432, in validate_mapping
raise er.MultipleInvalid(errors)
voluptuous.error.MultipleInvalid: extra keys not allowed @ data['0']
It doesn’t look like a config error but has anyone else come across this? I’m not sure what extra keys its referring to.
1 reply
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.
1 reply
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.
1 reply
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?
2 replies
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
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
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 
) 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.
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.
listen_event and then the special HA event. please check the docs
i would however use an input_boolean.
set it to off on default in HA, and to on when the groups are made.
when HA restarts, the boolean changes state to off, so the callback gets triggered ands sets it to on again.