Well thanks for doing my homework for me! That is exactly the behaviour I’d like to see in the UI. But I guess Mick said it best - you can’t always get what you want!
Well… that was a disaster!
I ended up with a BUNCH of switches and lights I DON’T want exposed… exposed…
That makes NO SENSE
This kind of reminds me of the BS I went through before… So I’m adding back the
exposed_domains:
- input_boolean
So it seems unless I have 1 exposed domain as per the above it will then add all sorts of other spurious shit to Google Assistant I don’t want. I think I might raise a new issue about this.
This is my ‘final’ google yaml
# Google Assistant
project_id: !secret ga_project
api_key: !secret api-ga
exposed_domains:
- input_boolean
entity_config:
light.lounge:
room: lounge room
expose: true
light.dining:
room: dining room
expose: true
light.office:
room: office
expose: true
light.desk:
room: office
expose: true
switch.sonoff12914:
room: kitchen
expose: true
switch.sonoff23110:
room: bathroom
expose: true
switch.sonoff51083:
room: house
expose: true
switch.sonoff63719:
room: house
expose: true
input_boolean.homeandawayauto:
room: house
expose: true
input_boolean.alarmgaragedoor:
room: house
expose: true
input_boolean.overtime:
room: kitchen
expose: true
input_boolean.holiday:
room: kitchen
expose: true
sensor.nodemcu_lounge_bme280_temperature:
room: lounge room
name: Lounge Temperature
expose: true
sensor.sonoff1_2914_si7021_temperature:
room: meals area
name: Meals Area Temperature
expose: true
sensor.bom_gosford_air_temp_c:
room: house
name: Outside Temperature
expose: true
script.bedtime:
room: bedroom
expose: true
script.diningdaylight:
room: dining room
expose: true
script.diningnormal:
room: dining room
expose: true
script.diningwarm:
room: dining room
expose: true
script.lounge100:
room: lounge room
expose: true
script.loungedaylight:
room: lounge room
expose: true
script.loungemovie:
room: lounge room
expose: true
script.loungenormal:
room: lounge room
expose: true
script.loungewarm:
room: lounge room
expose: true
script.officeall:
room: office
expose: true
script.officedaylight:
room: office
expose: true
script.officemain:
room: office
expose: true
script.officewarm:
room: office
expose: true
script.deskdaylight:
room: office
expose: true
script.desknormal:
room: office
expose: true
script.deskwarm:
room: office
expose: true
Check out the expose_by_default parameter. I think you need it!
expose_by_default (boolean)(Optional)
Expose devices in all supported domains by default. If
exposed_domainsdomains is set, only these domains are exposed by default. Ifexpose_by_defaultis set to false, devices have to be manually exposed inentity_config.Default value: true
Still doesn’t make sense.
If I don’t have an exposed_domains, expose_by_default should not matter…
maybe I should delete that exposed_domains again and set expose_by_default to false… lemme try that lol
OK that worked. Now I’m removing expose: true from everywhere as that is the default and I’m not exposing any domains by default anymore…
And that doesn’t work nothing is exposed…
Cloud config is indeed different then local config, you need to specific each entity first that you want to expose… I struggle with that too when I stepped over from local to nabu
not sure if this helps, but in my cloud config (I use Nabu Casa)
I explicitly include entities and 1 domain like this, exclude 2 other domains, (which probably isnt necessary because of the include, but just to be sure) and nothing else gets included:
cloud:
google_actions:
filter:
include_entities:
- script.aan_de_slag_direct
- script.gaming_direct
- script.gym_direct
- script.home_theater_direct
- script.mode_developer_direct
- script.mode_full_house_direct
- script.mode_kiosk_direct
- etc
include_domains:
# - switch
# - light
- media_player
# - scene
exclude_domains:
- script
- switch
Each included entity gets its own config like:
entity_config:
input_boolean.audio_system:
name: Audio system
aliases:
- Muziek
- Music
room: Woonkamer
Not only can one create useful aliases for normal speech, these entities are in their correct room immediately and that doesnt need configuring i the Google Home environment at all.
Must confess I have my Hue and Tradfri lights connected to Google directly, because every once in a while HA has issues (because an undocumented breaking change 
) and cant connect to the cloud in that case. Having Hue and Tradfri directly linked to Google Home certainly has its advantages then.
Long story short: nothing gets added unless I explicitly instruct it to.
I feel it is the best of both worlds like this.
My whole family can talk to the house and get things done.
for updating: whenever I change things in the HA environment a click in the cloud config on Sync entities to google is enough. Seems to all do the trick very nicely.
Really like the ease of things, and the fun of course. Very cool to be able to talk to home when not at home…
Very much the same here. I have a couple of lights and switches that are configured in Google directly so I don’t expose them via HA (even though they are integrated in HA as well). That way if something goes awry with HA I can still control a couple of lights…
I tired to expose the 2 scripts I really wanted to Alexa and they didn’t show. I exposed the entire script domain and still nothing is coming up in Alexa. All my switches and whatnot are there, and the Alexa GUI page shows the scripts are exposed as scenes, but they aren’t showing up in the Alexa app.
Edit:
Add YAML
alexa:
filter:
include_domains:
- switch
- light
- lock
- climate
- scene
- script
exclude_domains:
- automation
- remote
- device_tracker
include_entities:
- script.alexa_goodnight
- script.alexa_goodbye
It’s done until another update 
I understand why they changed scenes. I doubt they will be changing scripts.
HA… makes us adaptable lol…
In the release notes I read:
Voice for Home Assistant Cloud
Nabu Casa has introduced a new beta service providing speech-to-text and text-to-speech services to Home Assistant Cloud subscribers powered by Azure Cognitive Services.
I don’t have a nabu account for that long. Were do you find the beta services?
102.3 broke Solaredge component
2019-12-01 12:29:28 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up platform solaredge
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 150, in _async_setup_platform
await asyncio.wait_for(asyncio.shield(task), SLOW_SETUP_MAX_WAIT)
File "/usr/local/lib/python3.7/asyncio/tasks.py", line 442, in wait_for
return fut.result()
File "/usr/src/homeassistant/homeassistant/components/solaredge/sensor.py", line 35, in async_setup_entry
api.get_details, entry.data[CONF_SITE_ID]
File "/usr/src/homeassistant/homeassistant/core.py", line 343, in async_add_executor_job
task = self.loop.run_in_executor(None, target, *args)
File "uvloop/loop.pyx", line 2647, in uvloop.loop.Loop.run_in_executor
File "/usr/local/lib/python3.7/asyncio/coroutines.py", line 162, in iscoroutinefunction
return (inspect.iscoroutinefunction(func) or
File "/usr/local/lib/python3.7/inspect.py", line 185, in iscoroutinefunction
object.__code__.co_flags & CO_COROUTINE)
AttributeError: 'functools._lru_cache_wrapper' object has no attribute '__code__'
I have the impression that since 0.102.3 the config check, restart (auto config check before) and LL refresh (yaml mode) takes ages.
Can someone confirm?
Me too, same thing
Config check takes a little longer for me, but this is because of a bug in HACS, it used to take around 5 seconds to check config, but now it takes around 10 seconds to check config.
Thanks for your reply. I’m waiting 25 - 30 seconds for the config check.
Is there any link to the HACS issue?
I had this and one by one disabled my custom components. I found that if I remove the Samsung multi room custom component it went back to 5 seconds. As soon I put it back, it goes to near 30 seconds. Weird as it’s worked fine for a long time.
Same for me
I have a very similar issue. I am also running home assistant on an Intel NUC. I am running it on a Lubuntu with hass.io. After updating from 0.101.2 to 0.102.3, the CPU load went up to 100% after a couple of hours. I was barely able to connect to the host system over SSH. I figured out that the CPU load is caused by running out of memory (I have 8GB of RAM installed).
After a reboot, I figured out that there must be a memory leak in the main Home Assistant container. The memory usage of this container raises continuously about 150MB per hour. As soon as the system is running out of memory, the CPU gets to 100% and the system is unstable.
My solution was to go back to version 0.101.2. This version seems to work fine.
1 Like
Mine hasn’t been a constant issue but it does seem to spike higher than it ever did previously. I have 16Gb RAM in my NUC (I think…from memory) and it isn’t getting used up, it’s just the CPU that sits high for a while but then eventually comes back down to normal. I am however only on a Pentium NUC…maybe time to upgrade
While writing this the CPU has gone for another spike…
