First of all thank you for creating such a great app!
I am playing around with it at the moment and it looks like almost everything I now have on my other dashhoards can be done here as well, but only more flexible. Really nice!
The only thing I am really missing is a RTSP or ONVIF support. I have a couple of camera’s that don’t support snapshots, only rtsp/onvif. Any idea if and when this will be supported?
Thanks
I have tried to create a solution for this, but without specialized plugins, it is extremely hard to show an RTSP/ONVIF stream in a web browser. The funny thing is, just recently Homey developed a solution by transcoding camera streams in real time to the WebRTC format. This makes it possible to view a web stream inside a browser window. But I have not had the time to look into that yet. And I am afraid it is only available in the Homey environment and not for app developers. But like I said, I have to look into it (though the list of things above it is long).
Okay, big update. I have added the “local” topic, an edit box widget, and updated the list widget with user interaction control. I also improved several other things.
It is a bit of an advanced update, but I think I managed to create this with zero advanced Homeyscript backend code.
The problem I faced was that a setup like this needs attached buttons to control things. A button to send an edit field. A button to select all or delete list items. But I do not want to add extra configurable buttons to every widget. So version 1.3.0 introduces “local topics”. When you add “local/” in front of your topic, the topic is handled locally and inside Dashboard Studio. This way it can send information directly to other widgets. This allows you to use normal widget buttons to interact with an edit box widget or a list box widget.
Edit box widget
This edit box sends text data. It can be configured for single line and multiline text. It features a new “Trigger topic”. When a topic is fired on this setting, the edit box widget sends its data to the output topic. So if you connect the output topic from a button to this trigger topic, the edit box sends its data. Remember you can use a local topic for this. Using local topics also prevents other browser windows with the same dashboard from sending their data.
List box widget
This widget is heavily modified to be interactive. Instead of only receiving data, it can now also send its content to save in a Homey variable. You can add interactive checkboxes in front of the items, and you can connect buttons to select or deselect all and delete selected items. It now also accepts line breaks in text.
If you connect the “output topic” of the edit box to the “Data (String/JSON)” input topic in the Content source section, the data is added to the list. But you can also store all the contents of this list in a Homey Variable:
Create a Homey text variable. In this case I created “testListbox”.

Enable this variable in the Dashboard Studio Configuration.
Connect this topic to the Data (String/JSON) topic in the List box widget.
Set the “Output mode” of the list box widget to “On any change” (this will send all list items directly to the output topic on any change).
Set the “Output format” of the list box widget to “JSON Array (Objects)” (this will send the full list).
Set the output topic of the list box widget to “ListboxData” (So this is a custom global topic, not a local topic!).
Set the output topic of the edit box widget to the same “ListboxData” topic.
Now create this flow:
This will copy the data inside the “testListbox” variable we created earlier.
So it is a bit of a mindfuck, but this is what is going to happen:
- The user types data in the edit box.
- The user presses the send button.
- The button triggers the edit box to send its text data to the ListboxData global topic.
- The Homey flow puts this text data in the “testListbox” Homey variable.
- The Listbox receives this Homey variable, sees only a single line of text and adds this to the list box.
- Because of this change it directly sends the full list in json format to “ListboxData”.
- Now it arrives again to the Homey flow and puts this full list in json format into the Homey variable “testlistbox” again.
- The listbox receives this full list data but compares it to what it already has, and ignores it completely (this prevents infinite loops).
The beauty: All the data is stored. When the page refreshes (and “State Caching” is enabled in the DS settings) it will directly load the latest list data.
Another option that the List widget has:
Trigger Topic: Select All
Trigger Topic: Deselect All
Trigger Topic: Delete Selected
When you connect a button to these topics it will execute these features. This way you can create a separate dashboard just for viewing the list, and a special management dashboard with the attached buttons that can manage this list.
Please check the demo over here
Please check the updated help file over here
Bug is fixed in 1.3.0 (TEST version)
- NEW! Edit Box Widget: A new interactive input field that allows users to type and send custom text values.
- Added Topic Auto-Echo feature to automatically synchronize state changes across multiple open dashboard windows.
- Introduced Local Topics: A new way to define and manage internal dashboard variables without broadcasting them externally.
- Added multi-line text (linebreak) support to the List/Log widget.
- Added various UI improvements and styling refinements to the dashboard templates.
- Added a new ‘Vertical Alignment’ setting to the Label & Text widget.
- Introduced visual Read/Write data access level tags, local tags and Flow tags across the configuration interface.
- Updated the Arrow widget to automatically synchronize the arrowhead direction with the flow animation state.
- Alphabetically sorted the widget selection dropdown for easier navigation.
- Improved the Lightgrid UI with better visual consistency and an option to hide the white/color light indicators.
- Added X/Y icon offset settings to the Switch/Button widget.
- Fixed an issue where the Arrow widget bounded box blocked interaction with underlying widgets.
- Fixed an issue where the Graph widget would crash the dashboard when receiving a flatline of identical values.
Is there a way to connect the autoscale function of both graphs when you stack two graph?
No, the widget is not able to send that value. You need to connect the manual values to the same topic. And then inside a homey flow create a comparison of the highest values and send it to the graph. Or just take a logical default highest value?
Thanks. I was indeed about to try to send the value to Homey and send back the highest (or lowest) one. Having it as fixed value does not have my preference for this graph. It will show electric consumption (or return) and when the electric car is charging the consumption is much higher than the other 95% of the time ![]()
Just noticed the image widgets accepts SVG images in the url just fine:
Or do you mean something else?
@Satoer Based on my initial experiences in defining new Dashboards, I have some suggestions (in random order). I would appreciate a brief response to the points below so I can better understand your design philosophy.
Suggestions:
- Example of a menu pulldown: icon, menu text, highlighted color active menu option, reference to dashboard and page. Definition like plus button in arrow shape points.
- Gauges have a start and end color. Could a third color be added to better visualize high, medium, and low colors (red, green, blue for temperature)?
- Also show values for gauges, similar to the y-axis of a graph, but curved around the gauge. Possibly adjustable with min. and max. values and intermediate values. (Humidity has a value from 0 to 100, but solar panels, for example, have a value from 0 to 7000) and outside temperature -20 to +50°C. Indoor temp. example 14-26 °C:
How to handle electricity? With positive values the scale goes in my example from 0 to 7k Watt and negative values go from -7k to 0 with a green (solar) color scale:
- What is the difference between “Glow” and “Enable core glow”? If I turn one on/off, the other also turns on/off.
- Would it be possible to use the “Rich formatting syntax” not only for Label widgets, but in all widgets with a Label & Text component, and then also add a normal (non-bold) font (as default)? Various texts are now bold by default (e.g. graph titles and button text), which looks flashy and takes up more screen space.
- Display the dashboard name below the version number in the top left corner in developer mode (useful when defining multiple dashboards).
- Set a multiplier on the slider value text. For Homey, a value is often 0-1, and for a user, it’s often 0-100.
- Font not adjustable for slider label; alternatively, choose one font type per widget to limit the number of settings (why using different fonts for one component?).
- Add an option to write directly to a Homey variable; currently, a virtual device is required for this.
- Sort the variables alphabetically in the Dashboard Studio configuration of syncable components and capabilities.
- Make the app multilingual to reach more people with this flexible dashboard app.
Yes, I have something like this in mind for the new “pul down” widget. It will be more like a stationary menu but with a “pul down” trigger. So you can attach a button to it that can optionally activate it.
I have to think about that one.
Yes, there will be an update that allows negative values aswell
Nothing, It was a copy and paste mistake when I renamed all the properties to incorporate more clear and better naming. Are you still on version 1.2.5? Because it is already removed in 1.3.0
Changing default values breaks excising dashboards. There is a migration module that can handle this, but I try to overcome this as much as possible.
Adding features is not a problem. I shall look if I can can add a “bold” option to those text option (so you can disable it. Just like the gauge.
Good idea
Good idea
Ill take a look at it
Yes, this is something I would like also. I have tried this, but failed. I need some example code how an app (not a homeyscript) can change these variables. But it is on my wish list.
That’s a good idea
This is also on the wish list… but totally at the end. It would be too much of a hassle for every change or addition I need to edit a list for all languages. Besides, Dashboard Studio is just a webpage. Users who would like it in their own language can easily change it using language tools build in the browser:
Thanks, really appreciate it.
Perhaps GitHub - AlexxIT/go2rtc: Ultimate camera streaming application · GitHub helps. Was actually already investigating it for another project
I looked into it, but there are a few hurdles. First, it requires go2rtc running on a backend server. Since it isn’t written in JavaScript/Node.js, getting it to run natively on a Homey would be a major challenge. But I’m also concerned about performance, I don’t want to be responsible for crashing a Homey because a user tried to transcode a high bitrate 4K stream on such limited hardware. ![]()
I think the best bet is for the Homey team to open up the WebRTC API to third-party developers. They may have already started, it’s a very recent feature, but I haven’t had the chance to dive into the latest documentation yet.
Hi @Satoer I tried this url, but it doesn’t show anything in the image widget:
https://www.yr.no/en/content/2-2748000/meteogram.svg
Weird, seems to work fine over here. Tried in Firefox and Chrome:
Do you see some errors in the console terminal (right click, inspect => console) when you try to load that image?
I deleted the image widget and created a new one. Put the URL in and….well it just works.
Thanks for checking!
Don’t know if it ahs been discussed yet, but I like to show Ring snapshots in my dashboard. Homey RIng app can take snapshots, but the only action I’ve been able to identify is a card that send a snapshot image in a push message to my phone.
Would be great if I could use the snapshot image tag to send that to the dashboard and use it as the contents of an image widget.
I can only send messages from Homey to Dashboard Studio, not images. I do not plan to support image formats within topics because it would break compatibility with Node-Red and MQTT, which are message-based.
Additionally, Dashboard Studio cannot access Homey gallery files where screenshots are likely stored. A potential solution could be a “Then” card that exports images directly to the Dashboard Studio image library. This would allow the image widget to display them properly.
I don’t know if this image gets automatically updated. But if you want it to update it your dashboard you can do the “streaming a live camera feed” trick in the help file tips & Tricks section
Thanks @Satoer Your idea of exporting Homey images to the Dashboard Studio image library sound good! Any new image with the same name could overwrite the previous one. Then, with the mentioned update trick the image would be refreshed.
Please read my remarks about the Ring image and Homey reboot here.
As far as I know that trick won’'t work with Ring doorbell.
New TEST version! V1.3.1
I have implemented these requests. The gauge widget now has a “base value” setting; when enabled, the gauge moves negatively or positively around that value. Default 0, but can be another value like 50 in below example. I also added optional labels and ticks.
Additionally, I added a third gradient color in the middle. Actually did not want to do it, because this extra power can make visually such horrible graphs
This middle color also acts as the base color when enabled, allowing the gauge to turn red for negative values and green for positive ones. By default it is the average between start and end color. So if you change the start or end color, this “middle” color changes also (unless you change it) use the reset button to set it to default.
Well, I added more text options to the widgets
. I included a “bold” option in all text settings so you can disable bold text on any widget. The list of adjustments continues to grow thanks to demanding users
I agree that users should stick to one font, but I can imagine someone wanting a monospace font for a specific value. An extra font selection box won’t hurt. Once the settings are stabilized, I plan to overhaul the interface and reorder everything logically, perhaps by grouping font settings into a single panel. Also, I fixed the font adjustability for slider labels.
Done
Added it over here next to “Dashboard file” with status indicator:
Another great update, thanks!

















