I would like to achieve the following using a single button: a short press toggles the power (on/off), while a long press displays the device settings. I want a confirmation to appear only for the short press, not for the long press. Currently, confirmation is shown in both cases.
Or is there another creative solution?
New: Widget Deactivated Mode
Added a Deactivated toggle for all widgets. When active, all user interactions are disabled while the widget continues to receive and display live data updates in real-time.
Added an Opacity input (0% to 100%) for all widgets
When Require Confirmation is enabled and some outputs use Hold to Activate while others do not, a Confirm With dropdown in Confirmation Dialog Appearance lets you choose which press gesture opens the dialog: Hold to Activate, Tap to Activate, or Hold and Tap.
Resolved an issue where buttons configured with Hold to Activate could react on a quick tap or prematurely open confirmation dialogs.
Bound text, label, and peer widgets now update immediately when control widgets (switches, sliders, menus) share the same topic for both binding and output.
Still performance issues, I am aware of those. Working on improvements.
The “Reverse Flow Direction” feature is not working correctly in version 2.0.3. In my case, the topic value can be positive or negative. When positive, the arrow should point to the right and be red; when negative, it should point to the left and be green. Currently, the arrow points to the right in all cases. This worked correctly in version 1.11.7.
Some small questions:
| | tijd | bericht |
| :---: | :--- | :--- |
|  | 16:50 | Regen & open ramen |
|  | 14:19 | Afwasmachine klaar |
|  | 13:32 | Regen & open ramen |
|  | 12:58 | Regen & open ramen |
|  | 11:56 | Regen & open ramen |
|  | 07:06 | Screens achter OK |
|  | 15-09 | Regen & open ramen |
|  | 15-09 | Regen met open ramen |
|  | 14-09 | Regen met open ramen |
|  | 13-09 | Afwasmachine klaar |
|  | 13-09 | Wasdroger klaar |
|  | 13-09 | Wasdroger klaar |
|  | 13-09 | Regen met open ramen |
|  | 13-09 | Wasdroger klaar |
|  | 13-09 | Wasmachine klaar |
|  | 13-09 | Wasmachine klaar |
|  | 13-09 | Wasmachine klaar |
|  | 13-09 | Wasdroger klaar |
Same here. In my case I still use the ‘old’ way, in which a Homey Variable is switched between 1 & 0 depending of the value. The reverse flow value is linked to this variable.
==> Makes me think that the bug is situated in the ‘reverse flow’ part…
start-up performance is still worse than version 1.XX in my opinion, but already better than 2.0.0
This was mainly a performance update, got pretty complicated. I was basically trying to eliminate unnecessary steps, but the risk is that I might cut necessary ones as well. So I really appreciate you guys testing this out.
I also stumbled across an edge case that has a massive impact on performance. Certain password manager browser extensions can tank performance by five times, literally dropping DS from 60 fps down to 12 fps. The issue comes down to their autofill functionality. Because Dashboard Studio has so many configuration fields, the extension tries to run a check on every single change.
If you are running into performance issues, try disabling your password manager to see if that helps. You can also run Dashboard Studio in an incognito or private browsing window, which usually disables extensions by default. Please let me know if you run into this and which plugin is causing the slowdown. Sadly, there is not much I can reasonably do on my end to fix how those extensions behave, but you might be able to whitelist or disable the extension specifically for this site.
Just checked the demo dashboard, but that seems to work fine. Can you check 2.0.4?
Not really. I only needed it for the image widget but I implemented everywhere. I am testing a visual representation of a home, and smoothly switch from day to night mode based on the time of day. Also smoothly transform in to different weather profiles.
Not in the markdown, but in the editor:
Wel… it used to. Hooray for the performance improvements and for breaking things elsewhere. This is from V1. Wanted to make screenshot, but just discovered the column widths do not show up any more. I shall fix it.
I find SVG more a hack haha. Don’t know, let me first fix all the broken V2 stuff. That frosted glass effect gave me headaches for the editor, and weird shit like the flickering you discovered in the help file. 
Nope, also visibility linked to a variable doesn´t behave correctly anymore. Always visible.
Dashboard disappearing behind the editor on Android Chrome (i sent you this case via the support page) is also still present, but maybe you haven´t looked into this yet? Background also flickers in this case when touching the screen…
Learned today:
My Homey 2026 reboots every night at 1:00 AM. Updates are automatically installed immediately after the reboot; last night, this included updating Dashboard Studio to version 2.0.4.
The Dashboard Studio app was still taking too long to start up. Using Ctrl-F5 and manually clearing my Chrome browser cache (via settings) and deleting temporary files from the C:\Users directory did not improve the situation.
I noticed that while images and hard-coded text appeared relatively quickly upon launching the app, data requiring retrieval via MQTT took a long time to load. Interestingly, icons and text generated by deactivated flows were still displayed with outdated data (despite my earlier cleanup efforts).
Solution: I restarted the Dashboard Studio app, which significantly improved performance and ensured the data displayed as expected.
The takeaway: the app/MQTT retains a lot of data (some of it outdated), which can cause poor performance, an issue that is easily resolved by an app restart.
Bert, can you add a screenshot of the demo page with the arrows in your message?
I am trying to recreate the problem but it seems to be working on my end. What I did:
added a switch widget and a battery widget
In the output topic of the switch widget I set: local/visible (I also triend non local and just: visible)
Made the visibility of the battery widget dynamic and added the same topic(s)
Switching the switch made the battery widget dissapear and appear again.
Can you give me steps to recreate the visibility problem you are experiencing Bert?
I have seen the images, thanks. Sadly I don’t have an Android chrome tablet to test but I shall see what I can do. Do you also edit dashboards on that tablet? Doest the viewer has the same problem? (misaligned dashboard). The dashboard works fine on a regular desktop browser?
How many seconds are we talking about? Reinstalling DS (by the automatic update) should have the same effect as restarting the app. Re-sending all the cached values, even though it is a lot, should not significantly impact startup time. This slow start up time was not the case in V1?
Loading the dashboard now takes 7 seconds, which is fine on a fast Windows pc (~40 populated pages + 20 empty pages due to “teleporting” restructuring, ~10MB of images in total with preload on all pages, 1.2MB json dashboard export size). I estimate that it took 15 seconds before the app restart. This was not the case in v1.
Things that differ in v2 compared to v1 (this might be useful for performance optimization):
Is this what is meant? The image below is the Chrome browser in Windows.
Only working fine in v2.0.4 setting a manual true or false checkbox, not when using a variabele or Numeric payload formula.
Wow, that is long time. Does it open faster when you do not preload all those images?
If you did not put it in “Scale to fit screen” mode, then it does not scale the dashboard. I have no idea why the scrollbars appear compared to V1. There is an option to eliminate scrollbars:
Ah yes I see. Thanks. @Bert_Onraedt Screenshot won’t be necessary any more. I will fix it.
No, I’ve seen the screenshot (it was shared privately, so I can’t post it here publicly). It looks like the dashboard is shoved underneath, completely ignoring all the free real estate on the right.
Here is how it should behave: it should try to keep the dashboard in the unused screen space. If there is no room left to display it there, it should drop below the help file if that is open. If the right side is completely packed, it should drop below the editor also.
I tested it in version 2.0.4. Unfortunately, it doesn’t work in that version either.
Hi @Satoer , sorry, not much time right now. Just want to apologize for not making myseof more clear.
I was only talking abojt the ´flow’ in the arrow widget. Showing or not the flow and reversing the flow doesn´t seem to be affected by the value of the variable it is linked to.
Button/local topic/visibility-of-another-widget does indeed work perfectly.
No measurable or significant difference
In that case, the scrollbars have indeed disappeared, but they are also gone in Design mode.
Could you please respond to the comment above? Is this intended?
It is strange that, repeatedly, after I restart the app (clearing the cache), the response/startup time improves measurably (and the individual app’s memory usage decreases). Gemini AI says the following about this, though I cannot gauge its significance:
"Which value should you focus on?
For overall system impact (is Homey running out of RAM?):** Check **Settings → General → Memory. This reflects the actual effective RAM occupied on the physical system.
For app stability (does the app have a memory leak?): Check the app detail page. If both values continually climb over time without ever dropping (even after extended period of inactivity), the app likely has a memory leak. If the detail page value remains steady (for example, hovering around ~30–40 MB with ~15–20 MB actually in use), this is standard Node.js behavior."
/Gemini AI
Maybe for me the solutions for now is:
Hi @Satoer
Sorry for the late response. But thanks for adding the dynamic theme option.
And as requested hereby 2 pics from the Amazon Echo Show 5 as dashboard.
Hi @Satoer, if I check the “When topic has no value,…” box, the color and direction of the arrow change. The value of the topic has no effect on the direction and color of the arrow. Using a variable instead of the topic has no effect either.
This issue has been fixed 
The custom column width setting has been restored.
I made some improvements to startup loading times and overall performance.
I audited the Homey side of the app and could not find any real memory leaks. The main thing is that I never cleaned up old, unused topics. For instance, when a device gets renamed or a user creates a temporary topic in a flow, those topics stayed in memory until an app restart. Unless someone is dynamically generating changing topics in a flow (which is possible), the impact is negligible. I did implement a few tweaks, like purging topics from the cache if they sit unused for two weeks, along with a few other technical cleanups, but I doubt it will make a huge dent in memory consumption. Like I mentioned, I think Homey likes to cache heavily. It keeps data sitting in memory even after it has been flagged for the garbage collector just in case it needs it again. Unused memory is wasted memory.
Still, startup times between 7 and 15 seconds baffle me a bit, massive dashboard or not. I really do not think it comes down to raw data volume. Have you tried temporarily removing all images to see if that speeds things up significantly? Also, is your Homey connected via Wi-Fi or Ethernet?
When using a Dashboard Studio page as a browser homepage, the page used to fail to refresh after hitting the back button. Fixing that in V2 is likely what triggered this behavior. Is it necessarily a bad thing, though? Wouldn’t you want the latest data refreshed every time the dashboard wakes up? Or is it triggering so much data transfer that your Homey starts bogging down?
Thanks for sharing! Seeing how things render across different screens really helps with development. For example, the text on the graph Y-axis looks cut off here, so I will dig into that.
A bit of unsolicited design feedback: is that bottom-left widget a text widget? Did you set the padding in the Layout & Dimensions section to 0? It usually looks a lot cleaner when the text does not press directly against the border. You could drop the font size a touch, widen the container, or simply turn off the container border completely under Container Style. Another quick visual tweak would be matching up the gaps between all containers and aligning everything neatly to the top and bottom.
Here is what I would do:
I have rewritten parts how the dashboard centers on the screen. But I do not have a Galaxy fold device to check if this resolves the problem. Can you check 2.0.5? Is the problem resolved? Can you check the flickering as wel? If there are still flickers, can you be as detailed as possible what you do to recreate this problem? Is it anywhere on the screen, is it when the editor is open, is it also when just using the viewer? Or is it like on special locations (like buttons or sliders or something).
Some testing results:
I have reconverted a v1.7 dashboard to version 2.0.5. Displaying the dashboard’s opening screen (images and static text) takes 5 seconds, while fetching and displaying the data takes 7 seconds (total 12 secondes on a fast pc), even though I have deactivated all flows that provide additional data. On fast Android tablet these figures are 8 and 11 seconds (total 19 seconds).
Could the reference to “instant synchronization” above have anything to do with this?
If needed, you can take a look at my system via a private session.
I wonder: am I experiencing these performance issues because I have an extensive dashboard with 30-40 pages and a lot of logic?
What have other dashboard users experienced regarding performance with version 2.0.5?
Please feel free to share your experiences.
The mapping in Dashboard Studio? Dashboard studio does not know it is gone, it still has the topics pointed to it.
Ah, yes it needs to know how many columns there are in the markdown. (same as V1). You can put something like this:
||||||||||| --- | --- | --- | --- | --- | --- | --- | --- | --- |||||||||||
In the binding options default value. (empty table).
The data inside the topics are overwritten every time you are executing the flow again. I do not see the problem here. It is not unconnected and floating around. You want to keep this data right, to show it on the dashboard.
Can you send me your 1.7 dashboard, including all the used images using this service? (Put them all in a zip file) Maybe I can improve these performance issues based on your actual dashboard.
