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.
__init__.py instead of manifest.json. It silently worked as expected without any notifications. I suppose because of false written lowercase. It should be uppercase.
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.
I agree with both your recent posts while read together.
To be fair, the times I’ve seen changes made to the default config it’s always been mentioned in the release notes.
If you read this it’ll be clear I don’t like having software that provides me with no benefit being injected into my instance of HA. It’s fine that they mention things in the release notes, but as a user of the system I shouldn’t have to take all features the developers decide to include. If you scan the forum you’ll see people looking for ways to disable auto included features all over the place.
I’ve had shelly devices since I started. At that point shelly didn’t have a good integration. The best way to integrate the devices was via MQTT. I tried the shelly integration that was under development at the time and it didn’t work on my network. MQTT worked so I went with it. At some point the developers decided the shelly integration was ready to be integrated with the auto discovery stuff. So all of my switches showed up with notification and individual integrations on the integrations page. Since this was now part of the main system I figured I’d give the integration a try. Sadly it still doesn’t work on my network, but MQTT still works. The shelly integration tells me about the switches even though they are already working and configured. I don’t need these notifications and integrations, fortunately you can tell the system to ignore the devices. This just hides them, the shelly code still runs. So if the shelly code ends up having and issue I might then have an issue with my system. I don’t need the integration, it doesn’t work for me. Don’t force me to run it on my system. If the developers want to include it then it should be easy me to disable. This doesn’t seem like too much to ask.
The ssdm integration started causing issues on my system just after the first of the year. It’s taken me since then to figure out it was the ssdm integration. My system crashes about ever 3 days with this integration running, as it has a memory leak. This integration is included just like the shelly integration to do discovery. I don’t need it, I don’t want it and forcing me to have it just causes my system to crash. I spend well over 60 hours (one of the reasons for the rant) trying to figure out this issue. An issue caused by a feature I don’t need. If an end user doesn’t need it why force it on them.
I don’t understand why auto discovery is viewed a something that has to be run all the time. Some might see it as a nice feature for a new system you’re trying to set up. However once you get your system set up and working the way you like it you don’t really need full on auto discovery. You know when you add items to your network. A button to do a scan would be better than making the system run scans all the time. Auto discovery provides very little value to the average user with the system up and running. Why does it have to run all the time? The ssdm issue I mentioned above it part of auto discovery. If auto discovery didn’t run all the time it wouldn’t have been an issue.
Got that new energy panel a few versions back. Doesn’t provide any features on my network, but it’s on the my interface why? They could have just mentioned it in the release notes and told me how to enable it if I like. Or better yet when I clicked on the “tell me what’s new on my network” button, the system could have said “You have features on your network that can be integrated with our energy component, do you want to add them?”.
Enough of a rant. I love HA. I’m thankful for all the great work done by all the software developers. I’m just hopeful someone that has the potential to change what is included in the minimal viable product reads this and is influenced.
I understood very well what you meant. I don’t categorically disagree with what you’re saying, but things are more nuanced, in my view.
My previous message was specifically addressing your previous message, in particular the bit quoted above (and for good measure, the quote above that from your message before that). To rephrase my previous remark as a question: Did you check the release notes at the time, because every time I’ve seen changes made to default_config I’ve seen it announced?
I’m amazed every time I see a comment like this on the forum as part of a justification. To be brutally honest, if you have that much experience you would realise there can be different views, none of them necessarily wrong, because it depends on what you want to optimise for.
Here’s the thing: You don’t have to. For as long as I’ve been a user of HA (~3 years) it’s been the case that you can remove default_config and specify what you want. Why haven’t you done that, given your views and experience (I’m not being sarcastic; you pointed out the difference between new and experienced users and put yourself in the latter category)?
Also, it’s not like the selection for the default config is somehow ridiculously stupid. You may not like it, but it’s not stupid. Why not lower the barrier to entry, especially if you already have the power to change it later on?
Are you the average user (or an experienced one) and/or can you speak for the average user? Do you have any data to support this? Experience and convenience isn’t mutually exclusive.
And if the devices you want to scan for are asleep? I’m just pointing out it may not exactly be that simple.
From what I remember from the time it was announced, it seemed like a major new development direction for HA. From that point of view it would make sense to then include it as a default.
Exactly my case.
For users who have a few devices it might be not an issue. If you have more devices (close to 100 like me) it’s really annoying to click 200 times on each integration. See the screenshot
Even after you do all this clicking, it will clutter the list of ignored integrations. And in worst case you will have to repeat in case you build your HA from scratch (not mentioning you have to ignore every single new device you are adding).
I reported it to github but after some shuffling between developers it has been abandoned. Some time after this reporting ‘disabling integration’ feature had been announced. Unfortunately it doesn’t apply to this case, since every Shelly device is treated like single integration. So ignoring or disabling requires the same rolling effort.
I don’t like to use such an argument. But sometimes it’s required to notify your interlocutor that you really know what you are talking about (in contrary mass of unqualified opinions over there)
Some of them just wrong patterns. And the best developer can to is to avoid bad patterns.
Maintaining default_config on your own just because you want to disable single integration is obviously wrong pattern.
Because once you change default_config you are effectively obliqued to check it with every release.
So instead of making the usage easier, you opting-in for additional, continuous work. As I said: bad pattern.
Mentioned support for PowerManagement is another good example. Particularily I don’t measure a power usage. Don’t have solar panels. It’s not going to change in near future. I don’t need it in main menu. I know I can remove it from the menu… From EACH device SEPARATELY (incl. all users from my house). Are you kidding if you think it’s efficient.
Removing default config fixes all those problems and the only thing you would have missed out on in the last 2 years was the energy panel, which you are complaining about. Remove default config and give up this stupid 3 year argument. I don’t run default config and I have none of these problems the both of you have and the management of default config required me to add energy about 4 months ago. Give it a rest man. It’s not asking a lot and it gives you exactly what you’re looking for. I’m in awe over the stubbornness here.
For reference, you can find the integrations enabled by “default_config” at
e.g. nobody needs “cloud” unless they are using NabuCasa.
But for instance disabling zero-conf is far more than disabling unwanted Shelly integration
No, it doesn’t. Please stop insist what is my original need.
You also forgot about input button added recently.
I’m not going to accept any solution which in turn requires additional awareness/actions. We need those feature to save the time, not opoosite.
Disabling zeroconf, ssdp, … prevents HA from auto-discovering stuff, which is the issue at hand, isn’t it?
It doesn’t prevent you to manually configure, e.g., Shelly.
BTW, nowadays, you can ignore auto-discovery per integration via the UI (only for those configured via the UI, iirc, but Shelly is) , which makes this thread a bit moot…
Look at my screenshot in few posts above. Each shelly device is represented as separate integration. You cannot disable whole shelly integration with single click. you have go through every device and each new device you are adding to the system. which renders it pointelss.
