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

[Roman]

Hi Satoer,

I found a reproducible performance issue in Dashboard Studio V2.0.11 when returning to the Viewer after the browser/window has been minimized or hidden.

Symptoms:

• First load: about 15–18 seconds

• After that the dashboard is fast

• Minimize the browser/window and restore it

• The Viewer freezes again for about 14–15 seconds

• Same behaviour in Chrome and Edge

• Browser cache on/off makes no difference

I captured both a Chrome Performance Trace and a HAR.

The trace shows two dominant main-thread blocks:

• 17.984 s during initial state processing

• 14.642 s immediately after visibility changes back to visible

The second block starts about 199 ms after the page becomes visible again.

The dominant call path is:

Socket.IO

→ drivers/homey.js
→ _applyStateSnapshot
→ applyLocalTopicPayloadBatch
→ dispatchForMap
→ _widgetIdsForTopic
→ TextWidget.get config
→ WidgetBase.get config
→ typography/config processing

In the trace, _widgetIdsForTopic accounts for roughly 32.79 seconds of the 36 second profile.

The main issue seems to be dynamic Text widgets. During the state snapshot, Dashboard Studio repeatedly checks dynamic topic interests and ends up resolving this.config over and over again for every topic × dynamic Text widget.

In my dashboard there are:

• 702 widgets total

• 323 widgets with bindings

• 125 Text widgets with a dynamic text binding

• 142 different binding topics

The hot path appears to include:

_markdownTemplateSources(this.config)

inside the Text widget topic-interest lookup.

This causes a very large number of temporary allocations as well; the trace contains 8,633 MinorGC events.

I prepared a small patch that keeps the current behaviour but caches the dynamic topic interests for the duration of one state-snapshot batch, so each Text widget resolves its topic interests once instead of once per incoming topic.

The dashboard itself does not need to be simplified and the Homey Flows are not involved in the freeze.

I can provide:

• Chrome Performance Trace

• HAR

• the small proposed patch for V2.0.11

The important reproducer is simply:
open Viewer → wait until loaded → minimize/hide browser → restore browser → ~14–15 s main-thread freeze.

Would you like me to attach the trace/HAR and patch here?

[Satoer]

Hi Roman,

I haven’t run into any minimize / maximize freeze issues on my end, but 702 widgets sounds massive dashboard . I’d be happy to take a look at what you found.

Could you upload everything here?

Support & File Upload | Dashboard Studio | Free-Form Dashboards for Homey

It would also help if you could share the dashboard itself. I won’t share anything from it, but if it has too much personal stuff on it, I completely understand if you’d rather not. If you are open to sharing it, could you also include a “baked” version? You can do that by clicking the Tool (hammer) button at the top of the editor and choosing “Make All Dynamic Values Fixed.”

Thanks.

[Robin_Schuurman]

I also have some performance issues on my side.
Perhaps because of the same issue. The app on Homey is showing that it crashes due to memory issues. During auto restart the cards are not available for 10-30 seconds or so.
I am busy at the moment with creating a new dashboard from scratch via my laptop, so a lot of switching between the viewer, editor, my old dashboardboard and Homey advanced flows. Think only this evening I already had 4 crashes that I was aware of.

Can’t remember that I have seen this behavior before, but perhaps I was also not really aware

I just opened/closed the editor 20 or 30 times or so on my laptop and that seemed to trigger the memory crash

[Satoer]

Thanks for reporting this. Hmmm… I don’t see any crashes for 2.0.11 in the developer tools. Could you generate that diagnostic report for me?

Also, can you tell me what you are sending to the dashboard? For example are you reading calendar data using Dashboard Studio Flow cards? If so, can you disable that flow and try to trigger that crash again?

[Robin_Schuurman]

sure, hereby the diag id: f51a4df8-943c-466f-b8d1-58474221030e

[Satoer]

Thanks, received it, I will take a look. Can you also look at my last question. You might have missed it, because I edited my post.

[Robin_Schuurman]

yes, I am sending 2 calendars to page 1 and preload 2 on page2.
On page 2 I have 4 buttons for 4 different types of calendars (weekly/monthly)
So there are 2 textboxes on both pages that each have a single calendar. But with a button/switch I can change from weekly to monthly.

I have now disabled the flow and that does seem to help. Memory stays stable now. (But I do would like to enable the calendars again of course)

[Satoer]

Ah yes, my suspicion was right, and your report also confirms it. It is not really a bug in the code (Allthough I maybe need to make the code a bit more protective against this). Dashboard Studio simply ran out of memory because massive amounts of iCal data are being pulled every single time you reload the page, and Homey killed the process. Did you hook this up to a “dashboard loaded” flow card?

One thing about these universal calendar files is that they are stupidly clumsy. You cannot filter them by date range on the server side, so they basically dump the entire calendar history with all past appointments, sometimes going back fifteen years. I built in memory friendly routines so the app does not pull the whole file into RAM at once before parsing. Instead, it streams the data, checks whether an event falls inside the needed date window, and only places relevant data into the final output. Recurring appointments make things trickier since the app has to calculate repeat rules. Apparently Homey is still getting hit with high peak usage, which points to multiple calendars being processed at the exact same moment. You need to fetch this information in a way that is much friendlier to Homey memory.

First off, do not fetch all that iCal data every single time you reload the dashboard. Downloading it on every reload is completely unnecessary. Set up a timer flow so it only downloads once an hour or so. If you have an new appointment within an hour you will probably remember it . Google and Apple also dislike having their download servers hammered repeatedly, and you risk getting hit with a temporary rate limit.

I also suspect you are fetching multiple calendars in parallel. That causes a huge memory spike. It is much better to fetch them in series, one after the other.

So do not do this:

Do this:

Also, only process what you actually need. Do not import a whole year of events when your widget only displays a single week.

Finally, if you want a button to switch between something like a week view and a month view, never download the iCal file again upon clicking. Just fetch it once an hour like mentioned earlier, store the result in a Homey variable, and convert that variable into markdown when the button gets pressed. That will also make your dashboard way faster because you never have to wait for calendar downloads.

There is also iCal documentation
Hope this info can solve your problem. if not let me know. Just be careful adding flow screenshots. The personal iCal url’s are visible in the flowcards.

[Jos_Stultjens]

Hi Satoer,

I’m still very happy with your dashboard and still mainly using it on my old iPad air.
I noticed that when I enable “Viewer mode only” it indeed loads the viewer by default.
But when I access the dashboard using http://IPADDRESS:5050/editor.html?dashboard=dashboard it still loads in viewer mode.

[Satoer]

Yes… That’s exactly why the option is called “Viewer mode ONLY” . It’s intentionally designed to completely remove editing capabilities. It’s meant for situations where people display the dashboard in public spaces or Airbnbs where guests shouldn’t be messing with the settings, like on a Wi-Fi landing page or a wall display. Even if someone manages to tweak the URL or connects to the local Wi-Fi, they still won’t be able to change anything on the dashboard.

[Jos_Stultjens]

ok, I now understand, I just misinterpreted the info.

I thought when I enable this and just access the URL without /viewer.html, that it still will load in viewer mode and not in edit mode. I thought that I have to use /edit.html to be able to edit when this mode is enabled. Maybe good to mention that /edit then also is disabled.
But how can someone edit the dashboard and still wants the active dashboards not to load in edit mode if they are restarted while modifying the dashboard?

[Satoer]

@Jos_Stultjens

Ah yes, good catch. I changed how this setting works a few times before (previously it just hid the edit mode button) and forgot to update the text. I’ll will clarify the text in this setting.

@Jos_Stultjens

But how can someone edit the dashboard and still wants the active dashboards not to load in edit mode if they are restarted while modifying the dashboard?

I am not quite following what the issue is. Why not just leave that “Viewer mode only” setting turned off and make this URL the default on the iPad?
http://[IP]:5050/viewer.html?dashboard=[dashboard name]

You could save it as a web app bookmark on the iPad home screen. You can still easily edit the dashboard from a desktop browser using edit.html.

[Jos_Stultjens]

Yes, I know one can use the /viewer to load the dashboards in viewer mode.
Bu the reason for the “Viewer mode only” setting is to load the dashboards in viewer mode even if they do not have the /viewer in the URL.
So if someone is maintaining the dashboard and does not know if there are dashboards being used without /viewer.html, then (s)he can enable this feature, but they cannot edit without knowing for sure no dashboard will load in edit mode while he is editing.

But maybe this is a use-case that will never happen. I am just thinking of a possible use-case.
For me the current behavior now is clear and I personally do not have a problem with this.

[Robin_Schuurman]

Thanks,
I am requesting in parallel, but based on an adjusted range. After that I load the data in a variable and only reload once an hour. I will check if running them serial will help. Is there also a way to free up the allocated memory?

[Bert_Onraedt]

You can clearly see when the calendar is loaded. I only load it once per day at 2:15 in the morning. People are not welcome to change my planning with less than 24h notice
I remember similar crash-issues when you were developping the calendar integration. For me it works without crashes since then. I load them (3 icals) in series, not parallell.

[Satoer]

@Robin_Schuurman

Is there also a way to free up the allocated memory?

The app already frees up all allocated memory automatically

The card downloads the calendar data as a stream and filters out unwanted events on the fly, keeping the temporary memory footprint as low as possible.
Once the card finishes, all temporary data is immediately released and cleaned up by the system’s garbage collector.
The generated JSON is just a flow tag (token). It only lives during the execution of that specific flow run so subsequent cards can use it. As soon as the flow finishes, Homey automatically discards it.
Because the data isn’t saved anywhere by the app, there is nothing you need to clear manually (unless you chose to store the tag in a Homey Logic variable yourself).

If you see a temporary bump in memory usage right after the flow runs, that is completely normal in Homey/Node.js — the system probably waits until it actually needs to run a garbage collection sweep before reclaiming that memory.

[Robin_Schuurman]

@Satoer

dy frees up all allocated memory automatically

The card downloads the calendar data as a stream and filters out unwanted events on the fly, keeping the temporary memory footprint as low as possible.
Once the card finishes, all temporary data is immediately released and cleaned u

hmm,
not seeing any memory cleanup, unless I restart the app.
I have 2 calendars. For both I want this week, next week, this month, next month.
So I am doing loading and filtering 8 times the calendars based on 7 days up to 1 month time ranges.

Looking at the picture below I did the following tests, every time starting with a restart:
1: Parallel
2: serial per 2
3: serial per 2 without sending the data to the dashboard
4: serial per 2 without converting data to week or month
5: Parallel again

So, not much of a difference.
Is there perhaps a way to load and filter the both calendars just once and filter the dates for different dates afterwards?

[Robin_Schuurman]

I rewrote it now to collecting last month up to next month in 1 call and then use homey script to split it to this week/next week/this month/next month.

[Satoer]

@Robin_Schuurman

not seeing any memory cleanup, unless I restart the app.

I dug a bit deeper how Homey’s garbage collection works, but AI could explain it a bit better then me so this is an AI snippet:

What you are seeing in the Homey Developer graph is completely normal behavior for Node.js / V8 on Linux:

1. How Node.js memory works:
   When an app processes data (like downloading, streaming, and parsing calendar data), the Node.js engine requests memory pages from the operating system (which is what the RSS/PSS graphs measure).
   When the flow card finishes, the app immediately releases all variables and data internally so they can be garbage-collected. However, Node.js does not release those memory pages back to the Linux OS. Instead, it keeps that memory pool reserved so it can instantly reuse it for future runs without needing expensive system calls.
2. Why it stays flat:
   Notice how after reaching ~75–80 MB PSS, the line stays completely flat. If there were an actual memory leak, memory would keep growing higher every time the flow runs until Homey terminates the app. Here, it simply stays at the allocated memory pool ceiling.
3. 8 cards = 8 full downloads & parses:
   Currently, running 8 cards for 2 calendars means Homey is downloading and parsing the full calendar feeds 8 times (either all at once in parallel, or back-to-back in serial). Because calendar feeds from Google/Apple/Outlook often contain thousands of events across many years, running 8 downloads at once will naturally cause a high working-memory peak.

@Robin_Schuurman

Is there perhaps a way to load and filter the both calendars just once and filter the dates for different dates afterwards?

In hindsight, it would be better to filter a range to JSON (this already works) and then use that to pick and convert multiple ranges out of it. I really have to think about this one. It is so hard to be as versatile as possible without overcomplicating things. And of course, it shouldn’t break any of the existing user flows. Anyway, did you manage to optimize the iCal flows? Does the app still crash?

[Robin_Schuurman]

it is better now and no more crashes, but memory is relatively high. Think it is about 20-30MB lower, but still 136MB RSS/80MB PSS.