Grouping Automations on frontend for organization

I use a HA Yellow Box with some 15 integrations, about a 100 devices (ZWave, Zigbee, Wifi, Alexa, Google Home…) and my setup has been pretty stable. Over one year I have needed to power cycle my Yellow Box some 3 times to get Zwave back but other than that I am very satisfied with HA.

BTW, I’ve always imagined the navigation / organization would be simple drop down arrows, like this example I just threw together:

6 Likes

This is exactly what i would love to have aswell!

I want to group all my climate automations into one folder. They contain different entities in different areas so the currently existing filter option isn’t useful for that.

Well having now looked at this for the best part of 2 weeks, the only thing I can find in the logs is that the ADB service cannot see the boxes when they are powered off and just spams it. As previously mentioned this is because they all have smart plugs on, and after using debug to gracefully shut down the boxes, the power is killed. Each time one is powered on the ADB service is reloaded so it doesn’t error. This I can do in an automation. What I don’t seem to be able to do in an automation is something like:

If android box smart plug is off, then disable ABD for that box (then obviously as well, when plug on, turn ADB on). This would clear the errors from the logs. Else it just spams it.

 Logger: androidtv.adb_manager.adb_manager_async
Source: components/androidtv/__init__.py:123
First occurred: 26 November 2023 at 19:24:39 (9454 occurrences)
Last logged: 02:48:47

    Couldn't connect to 192.168.7.100:5555. OSError: Network unreachable
    Couldn't connect to 192.168.7.101:5555. TcpTimeoutException: Connecting to 192.168.7.101:5555 timed out (1.0 seconds)
    Couldn't connect to 192.168.7.100:5555. OSError: Connect call failed ('192.168.7.100', 5555)
    Couldn't connect to 192.168.7.102:5555. TcpTimeoutException: Connecting to 192.168.7.102:5555 timed out (1.0 seconds)
    Couldn't connect to 192.168.7.102:5555. OSError: Connect call failed ('192.168.7.102', 5555)

9454 unnecessary log warnings in a WEEK lol. So it’s retrying every minute? As far as I can tell, there is no way to disable/enable an integration via an automation. I would be very happy to be corrected. Apart from being unsightly, I was unaware this could cause an issue, but I won’t know until it goes away.

Spook can do that.

1 Like

Thanks, Spook looks amazing.

And it’s in… HACS … Stuff like this should be part of core IMO or at least the official add-on store. Especially if the author is a core dev.

I’ve avoided HACS, but I’ll have a read through the Spook docs and have a think about it.

I appreciate you replying, thx.

1 Like

Spook was made because it adds service calls that will never be added to core. It’s made by a core developer as well. Same with HACs. There should be no reason for you to avoid either.

1 Like

That’s reassuring. I’ll see what I can come up with. Thanks again, I mean it.

You can prevent the logger from showing these messages in the log in the first place.

In my system my balboa module goes offline regularly (designed to work that way, I dunno why) which means my log gets spammed with all kinds of crap when it’s offline. So I filter the errors. My entire logger config is here if you need an example.

2 Likes

Thanks, I’ll definitely take a look at that too. I’ve just thrown this crude thing together:

alias: ADB Service Test
description: >-
  Enables or Disables ADB integrations based on the smart plug state connected
  to the shield. Prevents the ADB service trying to connect and spam the logs
  when the plugs are off.
trigger:
  - platform: device
    type: changed_states
    device_id: livingroom_plug_device
    entity_id: livingroom_plug_entity
    domain: switch
    for:
      hours: 0
      minutes: 0
      seconds: 1
condition: []
action:
  - if:
      - condition: device
        type: is_off
        device_id: livingroom_plug_device
        entity_id: livingroom_plug_entity
        domain: switch
        for:
          hours: 0
          minutes: 0
          seconds: 1
    then:
      - service: homeassistant.disable_config_entry
        data:
          config_entry_id: adb_for_livingroom_shield
  - if:
      - condition: device
        type: is_on
        device_id: livingroom_plug_device
        entity_id: livingroom_plug_entity
        domain: switch
        for:
          hours: 0
          minutes: 0
          seconds: 1
    then:
      - delay:
          hours: 0
          minutes: 0
          seconds: 45
          milliseconds: 0
      - service: homeassistant.enable_config_entry
        data:
          config_entry_id: adb_for_livingroom_shield
mode: single

Obviously I’ve changed the IDs so it’s more readable. It’s really crude I know but lets see how this works. I’ll probably change in future so when it can see the Shield’s cast entity is available, it reloads instead of just a timer… idk. The trick will be getting it to reload as near to the point where it can, so if someone boots the box then kills it almost immediately, the service is still there.

+1. Here’s hoping for a 2024.1 update with folders.

2 Likes

Didn’t know about this until now.

This feature should be way higher and apply not only to automations but ALSO to all entities.

ESPECIALLY now that more and more is being ripped out of YAML so you can no longer use YAML packages to logically group your sensors and things.

What was previously a very logical and straightforward “these for LAN status, these for WAN failover status, these for esphome, these for WiFi APs” well organized PING sensors is now an absolute mess because sorting alphabetically doesn’t sort them in the logical way that they are used.

2 Likes

Reposting a screenshot I added back in Dec. of 2021 which showed my previous system, Homeseer, and how it groups “events” which are it’s automations.

Even something as simple as this would be super helpful in my mind, and I would think others would agree as well as a giant first step. The grouping would most likely either be a custom field or just simple the area.

.

2 Likes

UD’s Eisy has similar feature.

1 Like

You have my vote

2 Likes

What I did is to prefix.
In your case, could be

[LAN status] something
[LAN status] something else
[WAN failover] something
[WAN failover] something else

and so on

Yes, please!

This would be an amazing feature. I came here to vote but really need helpers organized. But it should apply to Helpers, scripts, entities, devices and even integrations.

1 Like

That is the same thing I do to organize them

Yes, you can do that (and probably most here asking for this feature do). But the point being made here is that it’s a workaround for a much demanded feature that’s being ignored.

@petro Spook has been great - it’s allowed me to solve the issue with the logs, and I’ve found other stuff it can do which I am very interested in. Thanks :+1: