Dashboard Groups, can one control their collapsed state

Can one set groups to initially be displayed collapsed and/or directly be controlled ?


The initial state is always expanded - but you can use the ui_control node to both detect when a new browser connects and then immediately send them a hide command.

Really interesting. Do you have any examples on how this is done ?


Give it a go. The info panel should help.

I know, but I couldn't get it to work and I just can't figure out how to solve the problem.

Messages like {"group": {"hide": [ and {"group": {"show": [ works fine but apparently "close" and "open" can't be used in the same manor. Help in the info panel do not go into detail about this, and one could expect {"group": {"close": [ was the answer to the problem, but it's not.

I'm new to using the ui-control node and have not found any other information about this topic.

Post a screenshot of a debug node showing the message you are sending that doesn't work.

show/hide works fine, open/close does not.

The iu-group settings are:

This works for me:


I had another ui_control command with a close in the same structure, which also worked.

@Boja if it still isn't working, what versions of node-red, node-red-dashboard, the led node and nodejs are you using?
In fact if you post the startup log from node-red that will tell us all that except the led node. It may provide other useful information too.

Very strange. I'l have to dig into this problem to really figure out what exactly is happening in my flow. But at least I now know that's it's not the msg sent that's wrong.


Something is terrible wrong here. No matter what I do, the group will not close/open. I send open and close commands but nothing is happening.

But if I manually close and open the group just once, everything start working. Wt.

I think I'm on to figure out what's happening though.

Did you see my post asking for the startup log? That may give us a clue.

@Colin, regarding your "led node" question you must have mixed that with another recent thread, where somebody had indeed problems with the led node.

Yes I saw your post. The log unfortunately showed nothing interesting:

3 Oct 21:11:07 - [info] Stopping flows
3 Oct 21:11:07 - [info] [server:Home Assistant] Closing connection to http://supervisor/core
3 Oct 21:11:07 - [info] Stopped flows
3 Oct 21:11:07 - [info] Starting flows
3 Oct 21:11:08 - [info] Started flows
[03/Oct/2020:21:11:08 +0000] 200, POST /flows HTTP/1.1 (Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0)
3 Oct 21:11:12 - [info] [server:Home Assistant] Connecting to http://supervisor/core
3 Oct 21:11:13 - [info] [server:Home Assistant] Connected to http://supervisor/core
[03/Oct/2020:21:11:15 +0000] 200, POST /inject/9adc514d.3ec57 HTTP/1.1 (Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0)
[03/Oct/2020:21:11:22 +0000] 200, POST /inject/9adc514d.3ec57 HTTP/1.1 (Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0)

But I found out what the problem was.

I'm not quite there yet, but I'm certain that a group naming error I corrected early this morning is the culprit. The group name had a time specification included, 10:11:10 which is not allowed. Why the error have persisted all day, through a number of group renaming sessions and through countless full deployments is beyond me. A single manual close/open of the group, apparently cleaned it all up.

But anyways, everything now work as expected. But what a struggle.

Thanks to all.

1 Like

Oops, yes, I was getting the threads mixed up. Sorry for the noise.

Perhaps it was a browser caching issue. That can give some very odd results that can magically disappear.

God point. Yesterday I tried to trace back through what I had done, to figure out exactly what triggered the event, but sadly enough the exact same issue did not really materialize again.

But what the heck, it now works.