[APP][Pro] NEW: Dashboard Studio - A completely free-form dashboard designer

The current Dashboard Studio is very flexible and offers many options. To keep it readable and manageable without sacrificing too much flexibility, I have a few suggestions:

  • integrate color and opacity into the color settings screen
  • allow one font per object. If multiple fonts are required, use a separate Label/text widget
  • remove Case setup if the user can manually enter the value
  • enable “Tint with icon color” by default and remove the option
  • disable (do not hide) impossible combinations of options

If you are unsure, you could ask existing users on this forum. Or maybe they have great ideas after using your software.

Okay, so each dashboard contains a copy of the full menu, and you use the main menu to highlight the current page while also activating or deactivating the submenu. However, if a highlighted menu item (one where the state is set to ON) is pressed, it sends a false value to the submenu (the menu items is ON and turns OFF), causing it to collapse. If the submenu is already collapsed, nothing happens, which means you have to click twice to actually open the menu. Since there is no option to set individual icon colors for menu widgets, you cannot fake a highlight by changing the “off” color. At this point, it seems it is just not possible to have a main menu highlight an item while it remains connected to a submenu.

Is it possible to press a main menu icon so that, regardless of the status of an open submenu, all submenus are closed, only the selected submenu is opened, and the selected main menu icon gets the selected icon color?

I previously showed the image below (from my “old” dash), where the orange icon is the active main menu and the blue one is the clicked menu.
This way, you always know which main menu you are in.

Perhaps I should solve this by placing a main menu name above the main menu icons.

I actually want to add another color section in the defaults section. Every time I add a new widget, I need to update all templates with extra default colors, which is a pain to do. I want a default color section with “base color, highlight color… etc,” and all widget default settings will reference those by default. I will probably still keep the default color settings per widget so users can override them easily, for example, if someone wants a different color for all buttons. So the hierarchy would be: Main default colors => Widget colors override => Widget individual override :sweat_smile:

No, I think the way it is integrated in the menu and button widgets is the way to go, and I want it implemented in all other widgets too. Just a default typography setting overall, but if users want to set the bold, italic, font, size, or whatever else, they can do that in the typography slideout for each item. I do not want to add separate “bold” options or sizes aimed at specific sections of a widget. Instead, just a set of typography options that are the same everywhere leads to better expectations and less confusion. Since these sections are collapsed by default, it also does not clutter the editor with all these settings.

Just like the new typography, I want the icon slideout featured in the button and menu widgets implemented in all widgets. I want the same set of rules everywhere as much as possible. The “Tint with icon color” is only available when the user uses a custom icon, and this should be off by default. This option masks bitmaps and fills them with a single color. Otherwise, the left button would look like the right button.

I would rather just hide them like I did in the menu widget. It creates less clutter.

The problem is that you want to have two things at the same time. You want the menu item to be enabled to show which dashboard you are in, and you also want to enable or disable the button to open and close the submenu. The only solution I can think of is to “fake” the highlighted menu item by setting the “OFF” color to the same color as the “ON” color. However, setting individual icon colors is currently not possible for the menu widget. You could replace the mainmenu for just individual buttons. Then you can change the individual icon colors. And if you make all buttons a member of the same Selection Group ID you can enable only one sub menu.
(Also enable Allow empty selection and Send Off When Turned Off by Group)

Instead of easier it’s getting more complex for developer AND user (to understand).

I do read something contradictory here. By hiding (not disabling) irrelevant options, you get an inconsistent display, because options keep appearing or disappearing.

I will try this for my horizontal main menu.

Not for the developer :rofl: I do not have to adjust all 35 templates when I introduce a new widget.

Basically, the font setting already works with this hierarchy. I do not like the way it is now. It is a pain to create a custom template this way because you need trough go to each and every widget to change the colors. With the extra main color settings, you only have to adjust those colors. If you want a special color specifically for a button or something, then you have to go one step deeper and adjust the default button setting.

Don’t think so if it acts the same everywhere. For example, when you are in the icon settings of the menu widget you get a different set of options by selecting the “Icon source”. If every widget that uses icons, use the same slide out, it is not inconsistent at all.

I think you mean consistency within a certain type of widget.

I mean the example below. Turn off Background and Glow: many options then become irrelevant and hidden. The screen then looks different than when these options are enabled.

# New TEST version! V1.6.2

current page output topic

I thought about how to implement this and I think I have found a neat solution. In the “Dashboard Environment” settings you now can add a custom topic inside “current page output topic”. This publishes the active page on load, reconnect, and whenever the page changes (only in view mode).

No need for extra flow cards, you can just use the regular DS trigger card:

Button glow:

When the container background is turned off the glow now expands beyond the boundaries of the container.

Widget’s page(s) improvement

Widget Page(s) supports ranges (e.g. 1,2,5-8). Insert/delete page shifts all page numbers including range bounds.

Fixed :+1:

2 Likes

I have tested the new active page option and it works as expected. Thanks for that!
For some reason the new release is making my synology nas again unresponsive.
I have now disabled the live refresh to see if it will come back online, but it seems that something is hammering the nas again.

I was a bit worried I’d accidentally merged the old image widget, but I just tested it and everything seems to be working exactly as it should (when resizing). Could you right-click on your dashboard and select “Inspect”? Once that’s open, head over to the Network or Network Monitor tab. From there, you can track the actual network connections being made. It should be downloading images based on the interval you selected.

Will check as soon as my nas is working again. No response at all anymore. So perhaps it is nas related this time :wink:

Poor NAS

There seems to be a bug where every time the app is updated to a new version, one of my gauges stops working correctly. The label becomes “Gauge” and the value becomes “0”, both are linked to topics from different capabilities of the same device. If I restart the app, it starts working again. My other gauges do not have this problem, and the only thing that separates this one from the others that I can think of, is that its device name contains the non-standard ascii character “ø”, where this is replaced by dash-characters in the topic name.

This is how it looks after the recent version update:

Then after a forced restart of the Dashboard Studio app:

This has happened after every app update since I created the dashboard I think.

Wauw, best app ever :grinning_face:

Made these dashboards:

Only small thing, i want de wind direction shown like in a full 360 gauge or something.

Now its showing like 228gr, any tips?

When I use a gauge and use

  • a horizontal line
  • no label
  • no unit
  • no icon
  • use show labels
  • set rounding mode to smart interval
  • no background

Then one label is rendered outside the boundings of the gauge.

When I turn on background again it is “fixed” or it doesn’t show the 250 again.

I use version 1.6.2.

Hello @Satoer

Hello

Do you want to see the display conditions of a widget based on its status?

You will want to check the background color of a text widget based on the status.
Example electricalité jour jour rouge, le widget texte background met en rouge, si bleu alors le background met en bleu?

Do you have a weather widget?
thx for all :slight_smile:

Nice :grinning_face:
Couple of ecstatic suggestions : Try to to keep things consistent. For example, I noticed the gauge widgets are currently different sizes. You can actually control all of their sizes at once in the default settings. You’ll need to reset the custom settings on the widgets themselves first (just click the little arrow button above each setting). Also, the icons and values inside the gauges are looking a little large right now. Some of them are touching the edges of the containers, so scaling them down a bit will give it a much cleaner look. By the way, looking at your values… I think I might need to add an “m” (mega) alongside the “k” (kilos) option! Haha, I never expected users to have such huge numbers!

Yes, gauges do not go full circle. I also think they should have a clear start and end. There is only a single widget that can rotate, and that is the label widget. You could just type an arrow in it and rotate it :rofl: :

code snippet (you can import snippets at the top of the editor. Note: might not work if you are not in the test version):

{
  "snippetHeader": "Dashboard Studio Snippet",
  "snippetType": "widget-snippet",
  "snippetFormatVersion": 1,
  "version": "1.6.2",
  "source": {
    "dashboardName": "Wind example",
    "page": 1,
    "createdAt": "2026-04-04T13:57:03.019Z"
  },
  "master": {
    "currentPage": 1
  },
  "widgets": {
    "label_2214": {
      "type": "label",
      "overrides": {
        "x": 470,
        "y": 220,
        "width": 260,
        "height": 250,
        "zIndex": 10,
        "page": 1,
        "text": "🡱",
        "metaName": "New Label / Text",
        "fontSize": 200
      },
      "bindings": {
        "textRotation": "local/rotation"
      }
    },
    "slider_5686": {
      "type": "slider",
      "overrides": {
        "x": 440,
        "y": 500,
        "width": 360,
        "height": 110,
        "zIndex": 10,
        "page": 1,
        "value": 71,
        "min": 0,
        "max": 360,
        "sendValueMode": "movement",
        "showVal": true,
        "valOffX": 174,
        "valOffY": 0,
        "valAlign": "center",
        "outputTopic": "local/rotation",
        "label": "Degrees",
        "labelOffX": 0,
        "labelOffY": 0,
        "metaName": "New Slider",
        "bgVisible": false,
        "valFs": 25
      },
      "bindings": {}
    }
  }
}
1 Like

Dashboard Studio uses a cache system which is enabled by default. It keeps the latest data sent to your dashboards in memory, but since this memory is volatile, it gets cleared whenever Homey or Dashboard Studio restarts. The app also restarts when a new version is published if you have auto update turned on.

When the cache is empty and a dashboard starts up, it tries to fetch the latest values from the capabilities you have enabled in the settings. However, if you just rebooted your Homey, it’s possible the devices themselves haven’t properly started yet.

Also, it doesn’t send values that were sent from flow cards because that data isn’t actually retrievable. Since the data is generated in a flow and sent immediately, there is no way for the app to go back and grab it. You can get around this by sending the data into a Homey variable instead and then enabling that variable in the settings. Dashboard Studio can retrieve data directly from Homey variables in a read only format.

Are you sure the gauge that isn’t showing the right info is connected to a capability and not getting its data from a flow? I don’t think the device name should make a difference, but bugs can definitely manifest in weird ways :sweat_smile:

Il add it to the list to check :+1:

1 Like

Yes. I’m 100% sure the value comes from the device capability and not a flow. I’m also 100% sure that this is the case also for the other gauges on the same dashboard, but this one gauge is the only one where this happens. And it happens consistently with every app update, from what I can see. Also, I have not rebooted my Homey.

EDIT: Also, restarting the Dashboard Studio app fixes it, which I would not expect if it was caused by the volatile caching issue you mentioned.