Hi, thanks for replying!
Answers:
- Google Chrome (seems it doesn’t support Kiosk mode on Android)
- Just a cheap Chinese Android 15 tablet
- Yes, it is. 800x1280
Possible solution:
Fully Kiosk is not a mode but a genuine, standalone Android app available at https://play.google.com/store/search?q=fully%20kiosk&c=apps&hl=nl. The free version offers sufficient features to display a dashboard without tabs or a URL bar, and allows the entire dashboard to be shown by adjusting the zoom level.
Fully Kiosk: Settings → Web Zoom and Scaling → Initial scale: set this to 100% (the option above Initial scale, “Use Wide Viewport”, must be disabled).
The Chrome browser on Android does not appear to have a built-in option to hide tabs and the URL bar, leaving only the zoom option. On my tablet, this option does not go below 50%, which still fails to display the entire dashboard. Alternative (not the best): define your dashboard in a lower resolution.
My guess is that a Display Scaling / DPR (Device Pixel Ratio) has been adjusted inside your tablet. Even though the tablet’s physical panel is 800 x 1280, mobile browsers can apply a display scaling factor (often 1.25×, 1.5×, or higher)
Simple fix would be to change the “Layout Mode” (in the Dashboard Environment) to “Scale to Fit Screen”
Or change the Display Scaling / DPR inside Android. (I have no idea how, probably somewhere in the display settings or accessibility options.
I shall take a look at it.
Perfect, that works! Thanks a million! Now, I’m off to design a nice dashboard for my 100% Homey environment.
Thanks for the screenshot! Looking at it, I just noticed you’re using a security token. My guess is that the iPad or iPhone is trying to fetch the icon image without the token and gets denied access.
Please don’t try testing it without the security token, though. I’ll get (try) this edge case fixed in the next version so you can give it another go. I tested it on my end with a security token, but it’s likely just loading the image from cache from an earlier session where I didn’t use one, which is why it seemed to work fine for me.
And one other question: I’m using a vertical gauge to display the power output of my home car charger. It does display the correct power when charging but the colored bar goes all the way up to 11KW (max. power of the charger), where the actual output is just 3.7kW. So, the bar doesn’t scale to reflect the power value. Any idea?
You need version 2.x for that option. That version is stable (officially still in testing phase), so if needed, you could update to that version.
My guess is that the value that is being send is in Watt, not in kilo
Watt. So the “Max” should be 11000 instead of 11
You can see the actual data that comes in, in the Data Stream Explorer in the main settings (click an empty space on the canvas to see these):
(Note: this is a V2 screenshot, but it is also available in V1)
Hello,
I’ve run into an issue. In my dashboard, I created switches to turn lights on and off using the Light Grid widget, and these work exactly as expected.
I also added a floor plan of my house as an image in the dashboard, with a layer of light icons positioned on top of it. These icons should turn on/off or change color when I operate the corresponding light switch. I created this using the Switch widget.
When I press the button on the Switch widget (configured as a Toggle Switch), the corresponding control in the Light Grid widget also turns on and off correctly. However, when I switch the light on or off using the Light Grid widget, the Switch widget does not update its state accordingly.
Both widgets are configured to use the same .../light_state_json data source.
Could you help me understand how to get this working so that both widgets stay synchronized and always reflect the actual state of the light?
Hi Gunther,
I am a bit surprised you can switch the light on and off using the “light_state_json”. That should really only work when you send a “light_state_json” to it. Did you add the JSON objects { "state": "ON" } and { "state": "OFF" }
into the ON / OFF values to make this work?
Anyway, to toggle the switch and have it reflect the state of the light as well, you should enable the “turn on” capability of the light:
Hit “Copy Topic” and use that topic in the switch widget’s Output Topic and State (On/Off) fields (you will need to make this dynamic first). (On Value should be True, Off Value should be False)
Does this solve the problem?
Thanks for the replay, i will try tomorrow.
And yes, i added yhe json objects, forgot to tell!
Feature Request: Page-specific Inactivity Timeout
I apologize if this already exists and I simply haven’t found it in the documentation or forum discussions.
I use Dashboard Studio on a wall-mounted touchscreen and would like pages to automatically return to another page after a period of inactivity.
Suggested page settings:
- Enable Inactivity Timeout: Yes / No
- Return to Page: [page selector]
- After Inactivity: [seconds]
Example configuration:
Home Page:
- Inactivity Timeout: Disabled
Lights Page:
- Return to: Home Page
- After: 60 seconds
Heating Page:
- Return to: Home Page
- After: 120 seconds
Settings Page:
- Return to: Home Page
- After: 600 seconds
Important:
The inactivity timer should be reset by any user interaction, not only page navigation.
Examples of interactions that should reset the timer:
- Button presses
- Slider movements
- Menu selections
- Text input
- Page navigation
- Any touch/click on the page
Reason:
A timer that only starts when entering a page is not sufficient. If a user stays on a page and continues interacting with controls, they can still be forced back to another page while actively using the dashboard.
For example, imagine a lighting page with a 60-second timeout. A user may spend several minutes adjusting dimmers and colours without changing pages. In that situation, the timeout should continue to reset with every interaction and never trigger while the user is actively using the page.
Timeout Behaviour:
When a page is changed automatically because of an inactivity timeout, the destination page should become the active page and manage its own inactivity timer.
Example:
Advanced Settings:
- Return to: Room Settings
- After: 60 seconds
Room Settings:
- Return to: Lights
- After: 60 seconds
Lights:
- Return to: Home Page
- After: 60 seconds
In this example, if the user leaves the dashboard untouched while on Advanced Settings, navigation would occur automatically as follows:
Advanced Settings → Room Settings → Lights → Home Page
with each page applying its own inactivity timeout.
This creates a natural cascading behaviour for multi-level navigation structures, allowing a dashboard to gradually return to its home screen when no one is using it.
For wall-mounted dashboards this would be especially useful because it allows detail and configuration pages to be accessed when needed while ensuring the display eventually returns to the primary dashboard view, clock view or information screen without requiring a browser refresh or dashboard reload.
Alternative implementation:
As an alternative or addition, Dashboard Studio could expose an “Inactivity Timeout” event. This would allow users to create custom behaviour using Flows, including page navigation, screen changes, notifications or other actions.
Nice request! Right now, that is not really possible to do.
It also feels a bit overcomplicated. Why not just three settings in the dashboard environment, something like:
Enable Inactivity Page, Page [1], timeout [60]s
I get how you want it to work, but I do not quite understand why every page needs its own timeout setting. Why does it need to step back from Advanced Settings → Room Settings → Lights → Home Page and wait on each page for 60 seconds? Why not just jump straight from Advanced Settings → Home Page? What is the benefit of slowly stepping back through the hierarchy? If someone needed to change an advanced setting, they likely navigated through all those intermediate pages just to reach that goal. Wouldn’t it make more sense for someone returning to the dashboard after a few minutes to simply see the home page again instead of an intermediate sub-page?
A single global return-to-home setting is also so much easier to set up. That is probably what most people want anyway: just jump back home. If it is done on a page-by-page basis, you would have to configure it across every single page. Some people have more than 30 pages 
Anyway, I really like the idea and would love to implement it the way I suggested with a single home-page fallback, but I am curious to hear your reasoning for wanting page-by-page configuration.
TL;DR: I got carried away 
As usual, this started very simple in my mind. I just wanted to get back to my homepage from my three settings pages in case I forgot to press «back».
All I needed for each page was a «go to page 1 on idle» and a timeout. Then I thought - what if … and then that «what if» led to another and so on…
If I’m two or more levels down, I would prefer to go back to my homepage, but smarter people than me might have other needs so i thought, let’s suggest a feature with full flexibility to unleash the full power of the human mind…
Forgot to thank you as this helped. Must say that I’m really, really thrilled about Dashboard Studio. I’ve been tinkering around with Homey Dashboards on my tablet for too long but that’s really limited and for some reason didn’t have a clue that Dashboard Studio even existed. But, now…the sky is the limit! Thank you so much for building this, highly appreciated!
Haha, that is how whole Dashboard Studio is developed. “I got carried away”. 
Even now, I really want to get V2 stable, so I shouldn’t add any new features until every current bug is squashed. Yet with every update, I keep tossing in new functionality that also ends up needing its own test period. 
Thanks 
NEW TEST Release: Dashboard Studio V2.0.11
2026-10-03
- New: Text Scroll - A Text widget can move its markdown as one block, horizontally or vertically. Choose Loop, Bounce, or Reset, then set speed, reverse, Loop gap, and hold or fade. Only When Text Overflows moves the text only when it does not fit the widget. Auto-Fit, Scroll Overflow Content, and the content-change Animation stay off while Text Scroll is on.
- New: Markdown Blink - Wrap a phrase, table, or callout with [blink]…[/blink] so it fades on and off. Use [blink 1.5] for a slower cycle, or pick a speed from the Blink control in the Full editor.
- Improved: General Interface improvements.
- Fixed: Arrow Direction - A reversed arrow with Head Size 0 now meets the end point.
- Fixed: Smaller Issues - A handful of smaller unreported issues are resolved.
New: Text Scroll
A Text widget can move its markdown as one block, horizontally or vertically.
Choose Loop, Bounce, or Reset, then set speed, reverse, Loop gap, and hold or fade. Only When Text Overflows moves the text only when it does not fit the widget. Auto-Fit, Scroll Overflow Content, and the content-change.
Note: It is not possible to use text scroll and transition animations at the same time. I tried to implement it, but transitioning from scrolling text into a different scrolling text gave me a coding headache
See the demo for scrolling text
Blinking text
Markdown now supports blinking text if you put it between [blink]…[/blink] tags. Or use [blink 3]…[/blink] to set a custom blinking time of 3 seconds.
Examples are on the markdown demo page and if you want to make dynamic blinking: on the Formulas demo page
Hi,
for long time I did an update of Dashboard Studio form 1.7 to 2.0.11 and Safari at my iPAd running on iOS 12.5.8 Dashboard Studio now constantly crashes. Not a chance to start Dashbaord Studio at all. Updated the page at a PC, but it didn’t help. Even basic editor and Demo page are causing Safari to crash. Is it expected not to work with iOS 12 anymore?
Thanks
