I have one or two integrations that I would like to toggle disabled/enabled on occasion (one is unnecessarily “chatty” and I don’t seem to have control over it’s polling period). I can see how to do this on thee integrations page, but is there a way to disable/enable integrations programmatically? Thanks!
If you inspect the dropdown list in Developer Tools > Services you will see all the available service calls. Based on that list’s contents, there are no service calls to enable/disable an integration.
Would changing the scan_interval/polling rate work for you? See the blog on 2021.6
Cool, I missed this! I’ll see if I can make this work for my case (myq integration)
Speaking about disabling integrations. If I remember correctly 2021.2 version brought a disable integration feature. I found no documentation for this. Especially if is it possible in core integrations.
If so, how to disable Shelly integration?
In the frontpage, under configuration → integrations, if you click the 3 dots there is a menu ‘disable integration’.
So, the integration must be added first to be disabled, right?
But for Shelly. every connected device is represented with separate integration instance. Curious if is it enough to disable it for one instance to disable whole integration (?)
Since for Shellies I use mqtt, I’m not interested to be nagged by Shelly core integration every time I add new device. It even turned into extreme situation when I was migrating my HA. I had to click “ignore” for almost 100 devices (actually those are 2 clicks every time).
So literally I want to disable the Shelly integration at all, before it is used for some device. I know I can do that using zeroconf but as discussed elsewhere it’s not smart way (then how can be advised?) since it requires to list all other components which have to stay in zeroconf.
I had opened git issue for that which has been marked as resolved at the end of February’21 (without giving any information). I was understanding that it’s resolved by giving the option to disable the Shelly integration. But from what I’m seeing - it’s not.
create a folder in your config directory named custom_components\shelly, add an empty __init__.py with a manifest.json with the following contents:
{
"domain": "shelly",
"name": "Shelly",
"config_flow": false,
"documentation": "https://www.home-assistant.io/integrations/shelly",
"iot_class": "local_push",
"version": "1.0"
}
That should wipe out everything shelly forever, unless requirements for custom_components (integrations) change.
Also fwiw, the reason that got closed is described by the developers. You’d have to create an issue against the shelly/core not against the frontend. Each integration controls the UI, not the front end. This is how config_flow works. The integration creates a config flow in python and that tells the frontend how to display the information. They told you to create an issue against the shelly/core integration to allow for 1 integration with multiple cards. It can be done, as seen by many other integrations. The config_flow section for the shelly integration just needs to be changed.
TDLR: Integrations ui are handled by the integration not the frontend, i.e. create your issues against the integration.
At first thank you for a way how to disable core integration. I’m going to try it asap. It annoys me for long time.
Regarding a proper repository. Initially this issue I had created in ha/core (not sure why you mentioned shelly/core, a typo?) because I wanted to depict a need, leaving solution up to developers (it could have been resolved several ways). It was balloob who has moved it to ha/frontend.
Not a typo, I meant shelly/core as in the shelly integration inside ha/core.
I see that now, however bram is correct stating that it should be against shelly in core.
Either way, if the above works for shelly, maybe I’ll make a No Shelly custom integration and push it to HACS. Not sure if that would conform to HACS rules though.
I’ve tested it with one of my never turned on Shelly devices. And it seems it works! Thank you.
There are other users who voted for disabling Shelly zeroconf behavior. I’m sure HACS custom integration would help many of them. (While I still think it should be integral feature of HA itself)
Again thank you
with regards
I agree. It should work like ESPHome. However, I don’t think that will help for discovery. You might need to click ignore 100 times based on the current implementation of config flow. I don’t know enough to say for sure.
Can you try this out in hacs using the custom integration?
If it works, I’ll add it to hacs.
Heh… I made several mistakes. One is also in your initial code… I try to describe all of them to help you find final solution.
- Initially I put proposed by you content into file
__init__.pyinstead ofmanifest.json. It silently worked as expected without any notifications. I suppose because offalsewritten lowercase. It should be uppercase. - Your hacs code seems to work but it raises notification and related records in ha log:
2021-07-18 15:40:54 INFO (MainThread) [homeassistant.setup] Setting up shelly
2021-07-18 15:40:54 ERROR (MainThread) [homeassistant.setup] Setup failed for shelly: No setup function defined.
Otherwise log contain a line:
2021-07-18 15:40:49 WARNING (MainThread) [homeassistant.loader] You are using a custom integration for shelly which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant.
which somehow confirms running custom component
Also I found following error:
2021-07-18 15:42:36 ERROR (MainThread) [homeassistant.config_entries] Error occurred loading configuration flow for integration shelly: No module named 'custom_components.shelly.config_flow'
2021-07-18 15:42:36 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 535, in async_create_flow
integration.get_platform("config_flow")
File "/usr/src/homeassistant/homeassistant/loader.py", line 424, in get_platform
cache[full_name] = self._import_platform(platform_name)
File "/usr/src/homeassistant/homeassistant/loader.py", line 429, in _import_platform
return importlib.import_module(f"{self.pkg_path}.{platform_name}")
File "/usr/local/lib/python3.8/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 1014, in _gcd_import
File "<frozen importlib._bootstrap>", line 991, in _find_and_load
File "<frozen importlib._bootstrap>", line 973, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'custom_components.shelly.config_flow'
And likely for all my shelly devices which I clicked “Ignore”:
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 119, in async_init
flow = await self.async_create_flow(handler, context=context, data=data)
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 542, in async_create_flow
raise data_entry_flow.UnknownHandler
homeassistant.data_entry_flow.UnknownHandler
2021-07-18 15:42:36 ERROR (MainThread) [homeassistant.config_entries] Error occurred loading configuration flow for integration shelly: No module named 'custom_components.shelly.config_flow'
2021-07-18 15:42:36 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 535, in async_create_flow
integration.get_platform("config_flow")
File "/usr/src/homeassistant/homeassistant/loader.py", line 424, in get_platform
cache[full_name] = self._import_platform(platform_name)
File "/usr/src/homeassistant/homeassistant/loader.py", line 429, in _import_platform
return importlib.import_module(f"{self.pkg_path}.{platform_name}")
File "/usr/local/lib/python3.8/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 1014, in _gcd_import
File "<frozen importlib._bootstrap>", line 991, in _find_and_load
File "<frozen importlib._bootstrap>", line 973, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'custom_components.shelly.config_flow'
....
Trying to do the same thing, programmatically enable/disable integrations. I really don’t understand how this is possible from the UI, but there is no API to do so. On any product I’ve ever seen, the UI rides on the underlying backend APIs. Apparently not in HA. Did you happen to find any programatic solution?
This link speaks to disabling zeroconf so you can control what gets configured. The default_config: line at the top of your configuration.yaml is what automatically brings everything into play.
yes… and should be considered the worst practice ever since it opens real possibility to miss crucial to the system integrations added later on. TBH I’m surprised that developers supports such an approach
I’ve developed software for over 40 years. Having items added into a production system that you didn’t expect to be turned on is what is considered to be a terrible from a devops perspective. After running for over a year without issue I spend a week trying to find a memory leak only to find out it was associated with new stuff being turned on automatically. If you’re not concerned about your home automation security system going down then I guess having things automatically added is a good thing.
Just to follow up. I agree a user should not be able to turn off any software required to provide a minimum viable product. default_config includes some items that seem to fall into this category. However things like energy, usb, ssdm, zeroconf and others aren’t part of a minimal viable product. The ssdm integation enables discovery of upnp items on your network. It probes every 30 seconds. I really have little interest in HA trying to find stuff on my network at this point as my system is up and running. A better capability would be a discovery button where HA could then do a probe and tell me what new is available. The button would give the user the control instead of random stuff, like energy popping up on your system. Anyway as I’ve said I’ve spent over a week trying to find a memory leak and at it appears since I’ve disabled ssdm (upnp) my system is functional again. So default_config as it stands had introduced a potential memory leak in every HA user’s system. This is software that provides little to no value on a system that is already configured. This really shouldn’t be part of the HA deployment model.