PowerCalc for Home Assistant

Screenshot of the energy dashboard in Home Assistant with some data provided by PowerCalc

One of the features I like about Home Assistant is its Energy dashboard. It can analyse and display various data about power and energy usage in your home – provided that you have the correct sensors available. As we have solar panels, our inverter provides lots of live data via a local API that we can use.

We also have a number of energy monitoring smart plugs that track energy usage. We have a couple of Meross plugs, and a couple of cheap Tuya Zigbee plugs. Home Assistant can then display the power usage of these devices, and so you can see where your energy is going.

But we can’t fit these onto every device. For example, devices like our oven, hub and dishwasher are all built-in, and don’t use standard 3-pin plug sockets. We could have smart relays fitted, but that would be a paid job for an electrician. So, instead, there’s a potential software solution, in the form of PowerCalc.

PowerCalc is a custom integration that you can install from HACS. Once set up, you can use PowerCalc to estimate the power usage of your devices, or use its extensive library where other users have provided this data already. Indeed, when I installed PowerCalc, it automatically added entries for our various Google Home smart speakers. Once added, these appear as additional entities attached to your existing devices, which is nice – they don’t appear as separate devices.

You can then add these entities to your energy dashboard, to see where your electricity usage goes. Here’s a Sankey graph from last week from our house; it was quite a dull day with little solar generation. There’s a lot that we can’t track, but you can see that a significant amount of our energy usage was spent drying clothes.

PowerCalc gets regular updates, with new devices being added all the time. And, of course, you can add these yourself, if you have the means to record the energy usage. The energy usage data also updates in realtime, so you could add the data to a dashboard and see how changing the brightness of a bulb affects its calculated energy usage.

How to disable go2rtc in Home Assistant

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.

Home Assistant Green review

A photo of a plugged-in Home Assistant Green

Since I started using Home Assistant in October 2023, I’ve been running it on a Raspberry Pi 4, first in ‘Container’ mode and more recently in ‘Supervisor’ mode. I’ve now bought a Home Assistant Green, and I’m using this to run Home Assistant.

The Home Assistant Green is one of the two dedicated hardware platforms that come pre-installed with Home Assistant. The other, the Home Assistant Yellow, deserves its own section later on. By buying one of these devices, you’re also helping to financially support the Home Assistant project.

Why I bought a Home Assistant Green

As someone who has previously gone down the DIY route, it may seem surprising that I’ve decided to buy a Home Assistant Green. My decision came down to the following:

  • Price – the Home Assistant Green costs around £90 in the UK, which isn’t much more expensive than a bare bones Raspberry Pi 5. Once you’ve added a case, power supply and SSD to a Raspberry Pi, the Home Assistant Green is actually cheaper.
  • Cheap to run – I had considered some kind of mini PC, which would offer me more power, but with both a higher upfront cost and ongoing electricity cost. The Home Assistant Green runs on up to three watts; it comes with a 12 volt, one amp barrel plug power supply. As it’ll be on all the time, I don’t want a power-hungry device.
  • The need for a dedicated Home Assistant device. In May, it was announced that the ‘Supervised’ install method would be deprecated along with ‘Core’; only a tiny fraction of people use these methods. This dovetailed with me wanting a dedicated device for Home Assistant, rather than trying to run it on the same little Raspberry Pi as Plex and some other services. In other words, I was in the market for an additional device to run Home Assistant, and the Home Assistant Green fitted the bill. Meanwhile, my Raspberry Pi 4 can be dedicated to Plex.
  • No longer needing to worry about compatibility. According to Home Assistant Analytics, over a third of people install Home Assistant on a Raspberry Pi and so I don’t expect it to become unsupported. However, as the Home Assistant Green is the closest thing to ‘official’ hardware, I know it’ll be well-supported in future releases. As I’m coming to rely on Home Assistant more, I need it to run on a reliable platform.

What the Home Assistant Green can’t do

Coming from a Raspberry Pi, it’s worth noting what features the Home Assistant Green lacks. These include:

The Home Assistant Green does have two standard USB-A ports for you to plug in dongles and hubs, so I have my Thread and Zigbee dongles connected. Not having Wi-Fi or Bluetooth on board may reduce interference on the 2.4 GHz band, I suppose.

The box that the Home Assistant Green comes in

Home Assistant Green hardware

The Home Assistant Green is actually bigger and heavier than I expected it to be – certainly, it’s larger than a Raspberry Pi. It has a very sturdy base, which is designed to act as a heat sink – it’s passively cooled so there’s no fan noise. Inside, there’s a quad-core 1.8 GHz ARM processor, placing it between the Raspberry Pi 4 and 5 in terms of computing power. There’s 4 GB of RAM, and storage comes courtesy of a 32 GB eMMC (embedded multimedia card).

You’ll also get an AC adaptor with a variety of plugs (including a UK 3 pin plug) and an Ethernet cable.

Optionally, you can install a CR2032 battery inside. It doesn’t come with one, but if you add a CR2032 battery then the system clock will remember the time between reboots. It’s mostly only needed if you’re using it somewhere with poor or no internet access, as otherwise the clock synchronises with the internet on startup.

There’s also an HDMI port and a slot for a micro-SD card, but these are only for system recovery purposes and not for general use.

I would tell you more about how it is to use, but to be honest, it’s just like using Home Assistant on any other platform. All I had to do was restore a backup from my Raspberry Pi 4, and I was up and running.

Home Assistant Yellow

If the Home Assistant Green doesn’t meet your requirements, consider the Home Assistant Yellow. It’s more advanced and upgradeable, but also requires some assembly as it ships without a logic board. That’s provided by a Raspberry Pi Compute Module, the idea being that you can upgrade this incrementally over time without needed to buy a whole new device. It’s a nice idea, but it also adds to the cost – the base Home Assistant Yellow costs around £120 with the Compute Module adding £30-40 on top, and it arrives in kit form rather than pre-assembled. However, long term, it could be cheaper due to it being upgradeable.

There are other differences: The Home Assistant Yellow is available with Power over Ethernet (PoE), meaning that it doesn’t need a separate power supply. However, you’ll need a router or a switch which supports this. If you don’t, then you can buy a Home Assistant Yellow with an AC adaptor.

The Home Assistant Yellow also has an 802.16 radio, meaning that it can support Zigbee devices without an extra dongle. This can also be re-programmed to support Thread, but not both Thread and Zigbee at the same time. Additionally, there’s a 3.5mm audio port, and inside, there’s an expansion port for installing an SSD if you need one.

Whilst I have the technical knowledge to get a Home Assistant Yellow up and running, once you’ve factored in everything, it costs about double the price of a Home Assistant Green.

Zigbee PIR motion sensor

A photo of a Zigbee PIR motion sensor

Regular readers may be relieved to know that I’m done writing about my trip to Athens, and are back to the occasional series of ‘Neil reviews cheap Zigbee devices from AliExpress’.

Earlier this month, I reviewed Zigbee window sensors, and this time I’m reviewing a Zigbee PIR motion sensor. PIR stands for ‘passive infrared’, and senses changes in infrared light to detect motion. It’s used in most motion detectors for burglar alarm systems, but you can buy sensors such as these for home automation too. In my case, I’ve fitted one to the top of our cellar stairs, to turn on a light in the cellar when motion is detected.

It’s pretty small – about an inch across – and runs on a single CR2450 battery (provided). You also get a sticky pad to attach to surfaces, and a couple of tools for opening the battery flap and for resetting and pairing it. It’s compatible with Zigbee2MQTT.

In terms of configurability, you can adjust its sensitivity, and its keep time. The keep time means that it remains in the ‘occupied’ (i.e. motion detected) state for a given number of seconds after motion was last detected. If you have a motion activated light, this prevents the light constantly flashing on and off.

As with the window sensors, you can also buy these devices from Amazon (sponsored link) if you need them quickly, but again they’re significantly more expensive than AliExpress.

To make the light turn on and off, I have automations set up in Home Assistant. I also bought a Zigbee smart light bulb for the motion sensor. Ideally I would have just bought one that switches on and off, but the cheapest one I could find is a colour changing dimmable one. Which is overkill for a cellar light, but hey, it was cheap. Indeed, the motion sensor and light bulb collectively cost less than £9.

Which integrations are slowing down Home Assistant?

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)

How to use bindings in Zigbee

Screenshot of the Zigbee2MQTT interface showing a binding being set up

One advantage of the Zigbee smart home protocol that I didn’t mention in last summer’s comparison was Bindings. This is where you bind a function of one Zigbee device to another, allowing the first device to control the second device directly.

Zigbee, as you may be aware, is a mesh network protocol. That means that every Zigbee device will connect to every other Zigbee device in range. Now, every Zigbee network also has a Controller, which is a device that issues commands to the network. In my case, this is my Raspberry Pi running Home Assistant, with a Sonoff ZBDongle-E plugged into it.

The advantages of bindings

However, when you bind two devices together, they can issue commands directly, without needing to go via the Controller. This is useful, because it means that devices can still work, even if your Controller is offline.

For example, let’s say you have a Zigbee motion sensor in your bathroom. You can set up a binding so that, when the sensor detects motion, it’ll turn on the bathroom lights. Once the binding is saved, this will work regardless of whether your Zigbee controller is online.

The other key advantage of bindings is that they should be faster. We’re probably only talking micro-seconds here, but as commands can be sent directly from one device to another without a round-trip to the Controller, they should be a little more responsive.

If you’ve ever bought Ikea TrÃ¥dfri bulbs, these usually come with a remote that has already had a binding set up. That way, the remote will work with the bulb out of the box without an Ikea Dirigera hub (or other Zigbee controller). But both can also be paired with a Zigbee controller if you have one.

Setting up Zigbee bindings

If you use an off-the-shelf Zigbee controller like the aforementioned Ikea Dirigera hub, or a Philips Hue Bridge, then you may be able to set up bindings using these. I don’t, so I can’t advise, but bindings can be set up using Zigbee2MQTT (which I use) and Zigbee Home Automation in Home Assistant (which I don’t).

In Zigbee2MQTT, you need to select your device, and then go to the ‘Bind’ tab. It’ll then expose a list of ‘endpoints’ that can be bound. In my experience, these are just numbers, so you may need to experiment to see what, for example, ‘endpoint 242’ controls. You can then bind this to the endpoint of any other Zigbee device to control it.

It’s worth noting some key points here:

  1. Not all Zigbee devices support bindings
  2. Those that do may only allow expose limited endpoints for binding, so you won’t be able to control all aspects using bindings.

For example, I have some Zigbee colour lights (which I used in my grouping example). I can bind them to another Zigbee device to turn them on or off, but not to change the colour. That still requires communication from the Zigbee controller.

Other protocols

If you have more than one Z-Wave device, then you can set up ‘Associations‘ between devices which work in a similar way to Bindings in Zigbee. Home Assistant users can set these up using the Z-Wave JS UI addon. I’m not aware that Matter offers anything similar.

The new Areas dashboard in Home Assistant

Last week saw the release of Home Assistant 2025.4, and with it, a new type of dashboard called Areas. This is an automatic dashboard, managed by Home Assistant itself, which displays your devices sorted by room, or ‘area’. At present, it’s ‘experimental’, but I wouldn’t be surprised if it becomes the default in future.

The default dashboard in Home Assistant is also automatically managed, but if you have more than a few devices and integrations, it can quickly become overwhelming. Therefore, my default dashboard is one that I manage myself. I can decide what to show, and in what order. However, it’s taken me quite some time to build and tweak that dashboard, and at one point I had almost 30 different cards showing. I’ve reduced that somewhat, and now use badges to highlight information that I need to know, but it still represents a significant investment of my time.

The new Areas dashboard therefore sits somewhere in the middle. The first tab shows an overview of your home, with sections for each ‘area’ that you have defined in Home Assistant. Most people will make each room an area, but it’s up to you – you may define parts of a room as a distinct area, for example. Personally, I’ve gone down the room = area paradigm, but I also have areas for ‘roof’ (where the solar panels are) and ‘outside’.

Setting up your home’s areas

You can set up your home’s Areas in the Settings pane in Home Assistant. When you do so, you can also specify any entities that represent the temperature and humidity in that room. This is useful, as these entities will then show up on your Areas dashboard.

Once you have defined your areas, you’ll need to add your devices to these areas. Again, in Settings, navigate to the Devices section. You can sort your devices by Area, so you’ll be able to see which ones are not allocated. Some of these ‘devices’ will represent virtual things, like HACS integrations or web services, so you don’t necessarily need to allocate these to a room.

A screenshot of the Home Assistant interface showing the options when adding a dashboard, including the new Areas dashboard

Adding the Areas dashboard

Again in Settings, you’ll need to open the Dashboards pane. Here you’ll typically see three dashboards there already. These will include your current default dashboard, the built-in energy dashboard and the built-in Map dashboard. At the bottom right, click ‘Add Dashboard’, and choose ‘Areas (experimental)’. Give it a title and an icon, and then enable to show in your sidebar. Once done, you’ll be able to access it at any time from the side bar.

Initially, every area that you have defined will have a section and a tab along the top. If you click the Pencil icon at the top right to edit, you can re-order the areas, and also make any invisible. You may want to do this if the dashboard doesn’t show anything useful for that particular area. If you click into each area, you can also hide any devices that you don’t want to see on the dashboard. For example, in my screenshot, each programme on my Bosch dishwasher shows as an individual entity; I can therefore hide all of those apart from the dishwasher’s power status if I want to.

The areas dashboard is still experimental

We’re only a week on from this feature having been made available in Home Assistant, and so it’s still ‘experimental’. In particular, you’ll only see a handful of devices on this dashboard. In my case, this includes lights, sockets, my dishwasher, my TV, media players, and thermostats.

But it’s a lot easier to set up and manage than it would to create a new dashboard from scratch. And it’s less overwhelming than the other default managed dashboard, which shows a huge amount of data. As time goes on, I hope that the Areas dashboard is developed further and becomes the new default. It’ll make Home Assistant feel more like other smart home apps like Google Home, and make it easier for new users to manage.

Dashboard Badges in Home Assistant

A screenshot of the Home Assistant Lovelace dashboard showing several badges at the top of the home screen

One feature of Home Assistant that I’ve only recently started using is Dashboard Badges. These are small widgets that appear at the top of your dashboard, and allow you to view information at a glance. There’s a screenshot above which shows the widgets that I currently have set up.

Badges have been part of Home Assistant for a long time, but they received a major overhaul last August in version 2024.8. In the (approximately) 18 months that I’ve been using Home Assistant, I’ve been gradually adding more and more data to my dashboard, to the point where I had to scroll through several screens worth of data to see what I needed. Which isn’t ideal. Badges are a potential solution, showing basic information at the top, where it’s most accessible.

Each badge widget can usually display the state of one entity. In the screenshot above, I’ve included:

  • The temperature in our dining room, as recorded by our Nest thermostat
  • The current weather (it was, in fact, not raining when I took this screenshot)
  • The current power output of our solar panels
  • How much charge our solar battery currently has
  • The current status of our dishwasher
  • The current status of the TV in the living room
  • The current status of the sun
  • The latest version of Home Assistant

There’s a moderate amount of customisation available. For example, as well as the status of the entity, you can include its name, and this text is also customisable to save space if needed. You can also tweak the colours and the icons.

Controlling visibility of badges

One great feature that badges have in Home Assistant is controlling when they’re visible. I actually have more badges than the eight mentioned above, but they’re not showing as I don’t currently need the information offered. For example, I have a badge that displays whether an update to Home Assistant is available. But I only want to see this when an update is available – if I’m running the latest version, I want the badge to be hidden. Here’s how I configured it:

A screenshot of the Entity Badge configuration in Home Assistant

Having selected the widget, I’ve gone to the ‘Visibility’ tab, selected the entity, and told Home Assistant to only display it when the ‘State is equal to’ and ‘Update available’.

I use this on some other badges too. For example, if there’s no power coming from the solar panels, that badge disappears. Similarly, if my solar battery is at 20% or below, which is its idle state, that’s hidden too. You can also control the visibility based on which user is currently logged in, or anything really – the state of one entity can control the visibility of the badge for another.

A useful badge is one that makes use of the custom Octopus Energy integration from HACS, and will display if I haven’t used my Octopus Wheel of Fortune spins that month. Last month, I won 800 Octopoints, which was nice, and it’s helpful to have a reminder to use them.

By using badges, and setting their visibility, I’ve reduced the number of cards on my dashboard significantly. It makes the dashboard less overwhelming, and prioritises the most important information that I need to see quickly.

A tale of two dongles

A photo of two dongles, both Sonoff ZBDongle E devices, labelled 'Zigbee' and 'Thread'.

I now have two dongles – both Sonoff ZBDongle E devices – connected to the Raspberry Pi which runs my Home Assistant instance. One is for Zigbee, and the other one is for Thread.

Last January, I wrote about how I was using both Zigbee and Thread on the same dongle. This uses ‘multi-protocol’ mode, and requires a Home Assistant addon which can differentiate between Zigbee and Thread data packets. However, this is no longer recommended:

During the further development and testing of the multiprotocol firmware, we have concluded that while Silicon Labs’ multiprotocol works, it comes with technical limitations. These limitations mean users will not have the best experience compared to using dedicated Zigbee and Thread radios. That is why we do not recommend using this firmware, and it will remain an experimental feature of Home Assistant Yellow and Home Assistant SkyConnect. If you currently have the multiprotocol firmware installed but don’t actively use it to connect to Thread devices, we recommend that you disable multiprotocol.

For the time being, I have been operating a single ZBDongle E just with Zigbee firmware. However, now that I have some Thread devices, I decided to buy a second dongle and flash that with Thread firmware, using this web flasher.

Now, my Thread smart plugs can be reached by Home Assistant without its own Thread dongle – I have a Google Nest Wi-Fi system which also acts as Thread Border Routers. Therefore, having a Thread dongle isn’t necessary – Home Assistant can see and interact with the devices using Google Nest Wi-Fi. But having a dedicated Thread dongle for Home Assistant does offer some advantages:

  • Thread is a mesh network, so adding another Thread device extends the mesh and should improve resilience.
  • It gives Home Assistant direct access to the Thread network.
  • It enables another Thread Border Router, offering an additional exit node.
  • The Home Assistant Thread Border Router addon includes a web interface, allowing you to view your network’s topology and get a visual representation of how the devices connect to each other.

You may also notice that I’ve labelled the two dongles so that I know which one is which, using my trusty Bluetooth label printer.

If you’re looking to buy your own Sonoff ZBDongle E, you can, of course, buy one from Amazon (sponsored link), but (whispers: they’re cheaper on AliExpress).

Just a note: I was unable to flash any updated firmware on the newer dongle that I bought this month, using the Web flasher, so that’s now the Zigbee dongle. Apparently it may be an issue with the Windows drivers, as I was able to use Home Assistant’s Silabs Firmware Flasher addon to update it instead. If you specify this custom URL in the addon settings, it’ll use the latest (as of November 2024) Zigbee firmware. It’s also worth noting that, if you use Zigbee2MQTT, once you’re running the latest Zigbee firmware, you’ll need to tell Zigbee2MQTT to use the new ’ember’ driver rather than ‘ezsp’.

The older dongle seemed to happy to accept different firmware using the web flasher, having done so in the past. So, that’s the one with the Thread firmware.

Grouping devices together in Home Assistant

A screenshot of a Home Assistant dashboard showing a light group set to 50% brightness and a green colour

If you have several devices of the same type, and want to be able to control them all together, then it’s possible to group them together in Home Assistant. The integration is simply called ‘Group‘, and once configured, it creates a helper entity that will perform the same action on all grouped devices.

Last year, I picked up two Zigbee colour-changing LED strips from AliExpress. One was to go in our nine-year-old’s bedroom and the other in the living room – the idea being that we could set the colours depending on the time of year. Rather than having Christmas lights that we put up in December, and took down in January, these lights could stay up all year round. For example, they could be pink around Valentines Day, or green at Halloween.

That was the theory. However, despite ordering 3 metre long strips, they were too short. Our house is about 100 years old with tall ceilings, and consequently, tall windows. In the end, two LED strips together, totalling 6 metres, were long enough just for one window and so they’re both in our nine-year-old’s bedroom. Because they’re two separate strips, they appear and work as separate Zigbee devices.

Creating a group in Home Assistant

You can start the process of creating a group either on the Integrations or Helper screens of Home Assistant’s settings. First of all, Home Assistant will ask you what type of devices you are grouping – all the devices must be of the same type, so you can’t group a switch and a light together.

Well, actually you can – but first you need to create a ‘Change Device Type of a Switch’ helper. Say you have a smart plug controlling a light; you can then create a Helper that appears as a Light, and then that can be grouped with other lights.

Anyway, in my example, I selected Light, gave it a name, and then selected the entities that needed to belong to the group – i.e. the individual lights. There’s also a ‘Hide Members’ option, which will hide the devices you’ve selected from the list of entities in Home Assistant. If you’ll only ever want to interact with the lights as a group, then tick this. However, if you still want to be able to manage individual lights as well, then keep it unticked.

On my Home Assistant dashboard, the icon shows that the new group helper is for multiple lights. The good news is that, even with colour changing lights, all the lights in the group will respond the same way together once grouped.

I also make these lights available in Apple Home and Google Home, and again, I make sure that Home Assistant is exposing the group, rather than the individual lights. As such, when I use Google Assistant to turn them on and change the colour, both lights change simultaneously.