Disabling/Enabling an Integration automatically

This is not a new problem. It has popped up in the past with now clear resolution.

One of my Integrations is Shark IQ. Every 24 hours, it goes unavailable. The only solution I have to restore it currently is to DISABLE the integration, then ENABLE it again. If this happened only a few times a year, I would deal with it, but… every morning? NOPE, thus I would like to find a simple programmatic solution to disable and enable the integration automatically. I wouldn’t mind doing it in Node-Red if that option existed, but it’s not there either. So, anyone have a solution that doesn’t open another can of worms?

I was going to say you should report it as a bug but it appears to be a long-standing issue:

SharkIQ Integration loses connection frequently; integration must be reloaded daily. · Issue #44775 · home-assistant/core · GitHub

As an experiment, you might want to try the service call suggested here:

Unfortunately the process you linked does not work.
As I mentioned previously, “reloading” does not work. The only way I have found that works every time is to manually DISABLE the Integration, then ENABLE the integration again. That is why I am looking for a way to do these steps programmatically.

1 Like

Hi,

The spooky integration (GitHub - frenck/spook: Spook 👻 Not your homie) is really handy. I see a major use case to make the service “disable an integration” (homeassistant.disable_config_entry) officaly part of home assistant: energy saving.

Let me explain my use-case, since i think my use-case is generalizable.
-When going asleep / away from home, many devices are automatically disconnected from mains power via Shelly switches to save energy. Devices like my tv, my av receiver, and my logitech harmony hub. Total power consumption is impacted a lot by doing this: a reduction of 10-15 watts.
-Until i discovered Spook, there was no way to gracefully cover this scenario in Home Assistant. You either accept warnings in the logs, or you choose not to implement energy savings (in my case, i choose to accept those warnings).

The “disable an integration” service prevents warnings and handles this situation gracefully: some devices are really not available, and this is reflected by disabling the related integration. I’ve implemented the disable/enable service as part of my asleep-awake automation and come-home-go-away automation. It’s valuable. And i think it should be valuable to many others.

By integrating this feature into Home Assistant, it would encourage more people to implement energy savings. Thereby making a positive impact on the environment. Especially when giving this some attention in the release notes/release party as well, this could encourage others to further embrace energy savings.

Submit a pr.

I wish i had the skills to do so.

I thought the code was written already by frenck?

Correct. But i have never submitted anything via github. I would need to take a course first.

Help would be appreciated :slight_smile:

Frenck is a member of the Core development team and an employee of Nabu Casa. My assumption is that if he thought service calls for disabling/enabling integrations should be included in Home Assistant, he would have done that. However, he didn’t and chose to include it as part of a custom integration (Spook).

Unless you can convince Frenck to change his mind, my guess is that anyone’s Pull Request (to add the feature) will not be approved by the Core development team.

I like to believe that usecases that show added value, will be looked at with a positive critical mindset.

1 Like

Yeah I guess with comments like this

You should not use this custom integration, nor should you expect it to work. The integration will break a lot, and will probably not survive the next Home Assistant upgrade. Heck, it will most likely not even survive its own next release.

it’s possibly not fit fore core. However you can continue to use it yourself.

The feature request should imho be judged on its inner value, not on its presence in Spook.

Just set your logging level to “critical” before turning everything off. Set it back to warning after turning everything back on.

There are services for this.

The fact it’s already available in the Spook integration is why it’s unlikely a volunteer software developer will spend time attempting to implement it in Core.

If they do, their PR is likely to be rejected because this feature has already been judged to be (by Frenck, a member of the development team) unworthy of inclusion.

I’m not attempting to discourage anyone from voting for this FR, just sharing my opinion that the only way this gets into Core is if Frenck changes his mind about it

Thank you for the suggestion. This would alleviate the problem.

There is another factor at hand: when the device is disconnected from power, and you reflect this by disabling the integration, the device is displayed as “greyed out” in the user interface. Thereby reflecting its actual state. This is clearer to the end-user.

All in all, i would consider “disabling logs” as a work-around. It will not fix the root cause. There is currently no way to truly disable a device in Home Assistant until it comes back to power.

I understand your point. It would help if more people could chip in with their thoughts. In the end, the wisdom of the group would show us the optimal way forward.

I thought this was pretty clear,

The key forward is imho in open communication. If there were obstacles or reasons to not implement this in the past, it would be great if those reasons would be shared. In this way, we all can participate and chip in on those concerns.