Script to find all ungrouped items

that might be very useful, though, does this override the settings in the logger.yaml, or put differently, how does this interfere with logger.yaml? Wouldn’t want to set the log settings system wide on all components. Maybe set the data_template to homeassistant.components.python_script ?

thing to note: this line ignore = data.get("domains_to_ignore","zone,automation,script,zwave,scene") doesn’t allow spaces after a comma, or else it ignores the domain.

also, setting the view: True, fixes it in the tab bar (might be very dangerous depending on whats found…) so making that dynamic, based on a dev-mode setting seems preferable. As per i’ve describe above. I can confirm this works just as fine with your newest version, which is able to ignore ‘hidden’ entities, thanks for that.
Cool, a really useful tool you’ve made here. :+1:

@finity you probably want to set the view parameter to false based on Marius’ most recent comment.

@Mariusthvdb
The logger script I posted was what I use, and probably needs to be modified for anyone who is using it. It would be better if I could programmatically build a list of items we might want to set a log level for, but I haven’t looked at that yet.

The modification to allow spaces after commas will only take me a couple of minutes after work, so that will be up later today (my time)

If you don’t want the group set as a view, then I would suggest either passing a parameter to disable it, or changing the default value. Most people don’t have the Dev - mode, so I can’t code this around that

If I do that it doesn’t show at all, even if there are ungrouped items.

However, in poking around I found something interesting that might explain why it’s still showing in the tabs even if it’s empty:

Here is a screen grab showing that an entity still exists in the group but the tab is empty:

It’s the ‘script.scan_for_new_devices’ entity_id at the bottom.

of course you have to set it to be visible and show as view, if you desire to do so. after finishing whatever you need to do, you can close it again. I dont run the python on homeassistant.start but per manually started script in my tools:

had a nice cleanup!:

13

only two left, which I will probably leave there, to be sure the script is running alright :wink:

ive found this btw:

hass.states.set("group.catchall", "new", attrs) as also depicted in @finity 's screenshot. Is ‘new’ a special group state? havent seen that before, and not sure what is does.

check this:

ive set both view and visible to false, and the group is still showing. Might need a reload after having changed the python script on both settings to False (and let my automation take care of it), but maybe this ‘new’ interferes somehow? Why not have it set to 'On/ Off ’ depending on the state?

This is a half-lazy/half-lost post from half-lazily scanning the thread and getting half-lost trying to follow which replies are to which posts…

Can we have a consolidated post with the latest version of the python-script, and a working automation that creates/shows/hides the view on demand please? Save me working it out for myself when it appears all the work has already been done :smile:

this is the way I do it:

have an automation call these scripts for dev/normal mode:

scene_normal:
  alias: Call Normal scene
  sequence:
    - service: homeassistant.turn_off
      entity_id: group.philips_motion_sensor_switches
    - service: frontend.set_theme
      data_template:
        name: >
          {{ states.sensor.sun_based_theme.state }}
    - service: group.set
      data:
        object_id: developer
        view: false
        visible: false

scene_developer:
  alias: Call Developer scene
  sequence:
    - service: homeassistant.turn_off
      entity_id: group.philips_motion_sensor_switches
    - service: input_select.select_option
      data:
        entity_id: input_select.theme
        option: 'matrix'
    - service: group.set
      data:
        object_id: developer
        view: true
        visible: true

have a group.developer with entity script.catchall:

script.catchall:
  action_name: 'Catch!'
  icon: mdi:baseball
  show_last_changed: true

##########################################################################################
## Groups
##########################################################################################

group:
  developer:
name: Developer
icon: mdi:developer-board
#    view: true
entities:
  - switch.mode_developer
  - script.reload_frontend
  - script.reload_python
  - script.catchall
  - script.restart_ha
  - script.rc_reboot_iungo
  - script.sc_reboot_iungo
  - input_select.log_level # package hassio_pi3_system
  - group.catchall # if made on the fly by python_script

set view and visible in the python_script to False , and let these automation and script hide/show the group catchall as part of the group.developer on demand.

run script.catchall manually if eand when desired.

screenshot:

normal mode:
54

click dev mode:
16

09
revealing group.developer and some, click Catch! and show Ungrouped Items:

flip developer mode switch back off:

31

using the last python_script here: Script to find all ungrouped items - #52 by NigelL

as a side note: the view setting can’t be templated, hence the hardcoding in the automation. I have several groups with visible: {{ true/false}} that can be templated based on the state of a mode switch.

  - alias: 'Dev Mode selection'
    id: 'Dev Mode selection'
    initial_state: 'on'
    trigger:
      platform: state
      entity_id: input_select.mode
    action:
      - service: group.set_visibility
        entity_id:
          - group.developer_links
        data_template:
          visible: "{{ is_state('input_select.mode', 'Developer') }}"

Unfortunately not an option (yet ) for view:

Filed a request for that. don’t expect too much of that ;-(

2 Likes

Thanks, I’ll adapt that slightly so it works from my maintenance mode switch and get it running tomorrow :+1:

Ok…so now I have everything that I need. Defined a switch and group like:

group:
  developer:
    name: Developer
    view: false
    icon: mdi:developer-board
    entities:
      - group.catchall

switch:
  - platform: template
      developer_mode:
        # icon: mdi:auto-fix
        friendly_name: Developer Mode
        value_template: "{{(states.group.developer.attributes|default({})).view|default('False') == True}}"
        turn_on:
          - service: python_script.populate_catchall_group
          - service: group.set
            data:
              object_id: developer
              view: true
              visible: true
        turn_off:
          - service: group.set
            data:
              object_id: developer
              view: false
              visible: false

Turning the switch on/off enables/disables the group.

1 Like

Updated everything to my repo.

I tried to use the following, but keep getting the error that remove:Group 'catchall' doesn't exist! (even though it is there)

      developer_mode:
        friendly_name: Developer Mode
        value_template: "{{(states.group.developer.attributes|default({})).view|default('False') == True}}"
        turn_on:
          - service: python_script.populate_catchall_group
          - service: group.set
            data:
              object_id: developer
              view: true
              visible: true
        turn_off:
          - service: group.set
            data:
              object_id: developer
              view: false
              visible: false
          - service: group.remove
            data:
              object_id: catchall

Would have been nice to delete the group when not required.

yes, cant get that to happen.
What is nice though is that the group is dynamically changed according to the python settings in the line:

ignore = data.get("domains_to_ignore","zone,automation,script,zwave,scene")

maybe this can be adapted to ignore all, and make the group empty, ad hence disappear from view… bit of a hack, but is should work. experimented with the domains before and that seemed to work nicely.

btw, what exactly is happening here:

"{{(states.group.developer.attributes|default({})).view|default('False') == True}}" ?

That is to set the switch.developer_mode status. It turns on when group.developer is visible.

Can be simplified to "{{states.group.developer.attributes.view == True}}"

lol, thats easier…

still, in human language, are you stating that : if group.developer is visible, you turn on switch.developer. Shouldn’t it be the other way round: if you turn on switch.developer, is should make group.developer visible…?

{{ is_state_attr('group.developer' , 'view' , true) }}

Yes, so when you turn on the switch, it runs the python script and shows the group.developer and that is reflected in the switch status.

Still don’t understand why group.remove won’t work.

ok thanks, and @anon43302295, nice indeed.

btw, i can confirm that adding sensor to the line in the script (2 last items ungrouped were sensors) made the group disappear from view.

It still is there in the dev-tools though, albeit being empty except for the script itself.

might need a reload groups? or reboot even.

It actually does the check for the number of items before it adds the script.

If you don’t set the group to be a view, it won’t show, unless you add the group to another view (otherwise, it becomes an uncaught item itself :smile:)

I don’t actually know if the on/off values for the status for a group actually have meaning. I forget why I was using new last night