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.
@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
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:
only two left, which I will probably leave there, to be sure the script is running alright
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.
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
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:
click dev mode:
revealing group.developer and some, click Catch! and show Ungrouped Items:
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.
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.
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…?