performance

How to disable go2rtc in Home Assistant

by

Home Assistant includes support for go2rtc, a streaming video application, which can be used to monitor and store footage from CCTV cameras. Since the November 2024 (2024.11) release of Home Assistant, go2rtc has been included in Home Assistant’s Default Config, which means that integration is loaded automatically on startup. If you don’t have any cameras to monitor in Home Assistant, this can mean some warnings appearing in your logs, and potentially slow Home Assistant down.

There are two ways to disable go2rtc if you don’t need it – a hard way and an easy way.

Hard way: Disable Home Assistant’s Default Config

You can tell Home Assistant not to load the Default Config. This gives you more control over which built-in integrations are loaded when you boot Home Assistant up, however, it means editing your configuration.yaml file. You’ll need to delete the ‘default_config:‘ line, and then create new entries for all the parts of the default configuration that you want to keep. This may be fine for simple installations, but for most users, this will add more complexity. I wouldn’t recommend this personally.

Easy way: Using HACS integrations

There are two HACS integrations that you need to install:

  1. Early Loader
  2. Default Config Exclude

These are not in the standard HACS repository, so you’ll need to open HACS, click on the three dots in the top right, select ‘Custom Repositories’ and then add the Github URLs in turn. You’ll need to install Early Loader first, restart Home Assistant, and then install Default Config Exclude next.

Once installed, you’ll still need to edit your configuration.yaml file, but instead you’ll only have to add a small block. Here’s mine:

default_config_exclude:
  - go2rtc
  - stream
  - cloud
  - my

What you’ll notice is that I’ve added some other integrations – stream, Home Assistant Cloud, and My Home Assistant. If you don’t have any cameras, then not only do you not need go2rtc, you probably don’t also need stream either. I don’t use Home Assistant Cloud or My Home Assistant, so I’ve disabled these too. As well as starting up a little quicker, Home Assistant also now uses slightly less RAM than before.

Which integrations are slowing down Home Assistant?

by
A screenshot of the Home Assistant integration startup times panel

I’m a little over 18 months into my Home Assistant journey, and now have 54 integrations set up. This includes standard integrations set up in the Home Assistant interface, some added using YAML, and custom integrations added via HACS.

When I first set Home Assistant, I went out of my way to set up as many integrations as possible, regardless of whether I needed them. Home Assistant scales quite well, but some integrations take longer to load than others. If you’ve ever logged in whilst Home Assistant is restarting to see a dashboard with many missing entities, you’ll know what I mean.

There’s a panel hidden away in Home Assistant’s Lovelace interface that tells you how long each integration takes to load. Open Settings, scroll down to System, and select Repairs. Then, click on the three vertical dots at the top right, and choose ‘Integration Startup Times’.

The list will be sorted with those taking the longest at the top. The vast majority of mine take less than a second to load, but there are some outliers. My worst offenders are:

  • Google Nest (24 seconds). Taking three seconds longer than a famous So Solid Crew song, this is the integration for my Nest Thermostat. I use this quite a bit in Home Assistant, so I’m stuck with it.
  • Wyoming Protocol (21.5 seconds). This is the bridge between Home Assistant’s Assist chat bot, and Homeway Sage. To be honest, I don’t use this, so this is an easy one to turn off. It’s an auto-discovered integration.
  • Meross LAN (21 seconds). This is a custom integration from HACS for my Meross smart plugs, and I need this for energy monitoring. Whilst the smart plugs also support Matter, the energy monitoring is only available via this integration. Theoretically, I can convince the smart plugs to use MQTT and that might negate the need for this integration, but I haven’t fully investigated it.
  • DLNA Digital Media Server (17 seconds). Another auto-discovered integration, courtesy of my router. I’m not using this, so this is another good candidate to disable.
  • Spotify (15 seconds). This allows me to control Spotify playback in Home Assistant. In reality, I don’t really use it, but it is on my dashboard.
  • Home Connect (14 seconds). This is for my smart Bosch dishwasher. I use this for a dashboard badge to see if the dishwasher is on at a glance. Our dishwasher is built-in and almost silent so this is useful.
  • Fitbit (14 seconds). Another dashboard badge to see how much charge is left in my Fitbit Versa 3.

Of these, there were two obvious candidates to remove – Wyoming and DLNA, saving a combined 30 seconds of startup time.

Ignored integrations

As they’re both integrations which are auto-discovered, I have had to tell Home Assistant to ignore them. On the Integrations Settings page, if you click the filter icon on the top right, you can then show the integrations that are ignored. I’ve added Wyoming Protocol there; it joins Philips Hue (since I’m using Bifrost) and ZHA (since I’m using Zigbee2MQTT)

Firefox, Performance, and You

by

I’ve been blogging quite a bit about the beta versions of Firefox 3, which can be downloaded here, and how much better it is than Firefox 2. If anything, I’m as excited about this version as I was when version 1 came out, as it feels like the browser I have been using for 5 years has now grown up and many of the issues it has had in the past have been ironed out.

In this entry, I am going to go through the various changes that have been made in Firefox which improve the performance of the browser – the startup times, the time it takes to render web pages, and the general responsiveness of the program. Improving performance has been a major focus of the Firefox developers for this release, and the changes are notable.

Memory usage

Do a search for ‘firefox bloated‘ and you’ll get over 500 000 results, many of which complaining that Firefox is big and slow. Many put this down to the amount of memory it uses, which, in Firefox 2, appears to be more than its main competitors – Opera, Internet Explorer and Safari. (Note that, unless you’re using Windows Vista, it is difficult to measure memory usage of individual programs on Windows successfully)

For Firefox 3, reduces Firefox’s ‘memory footprint’ (the amount of memory it needs to run) was one of the main priorities. Improvements have been made both in reducing ‘memory leaks‘ – memory taken by Firefox that isn’t released back to the operating system when it is no longer needed – and memory fragmentation, which means that the memory it does have allocated is used more efficiently. The culmination of this is that, on Windows, Firefox 3 uses less memory while running than any other current web browser. It also released more memory back to the operating system after a period of inactivity, meaning that it’s no longer needed to close and restart the browser because it’s eaten half of your RAM.

How does this improve performance? If you have 16 GB of RAM, then, not much really. But if like most computers your machine has just enough RAM to perform, then it means more of Firefox can fit into RAM and less of it has to use ‘virtual memory’ – essentially a big file on your hard disk which acts as an overflow when all of your RAM is used up, but that is much slower than RAM. It will also allow more space for other programs in RAM, so you’ll be able to run more programs at the same time as your web browser.

Code optimisation

Several parts of Firefox have been re-written to fix bugs and simplify code, and in some cases, improve performance. There have been performance improvements in:

  • Page rendering – a marked performance increase that also means that Firefox 3 will pass the Acid2 test
  • Image drawing – a bug fix sorted out problems with image caching and a new JPEG decoding routine also means that images will render faster

Mac-specific improvements

Firefox 3 finally moves away from the really old QuickDraw API to the newer Cocoa API. As well as giving nicer widgets (scrollbars, buttons etc) on web pages, this also means the whole program should feel more snappy. This, combined with the new theme, means that Firefox 3 is the most Mac-friendly version to date.

Profile guided optimisation

Firefox is now, essentially, compiled twice – the first compile runs as usual, and then the compiler runs a series of tests which optimises the code by looking at what parts of the browser will be most used in a working environment. This has lead to performance improvements of at least 10%.

Because we’re now approaching the ‘release candidate’ stage, ahead of a final release probably some time in June, most of the performance changes have now been made, so if you want to see if it is an improvement for you, now is as good a time as any to try; any further changes will be to fix any major bugs and stability issues. All in all, the massive strides made in performance make Firefox a much bigger competitor in the web browser arena and may win back some of its earlier detractors.