Nog steeds dagelijks aan het checken of de update er is… Ik wil 3 kolommen! 
@Harwin is het een update via de app store of is hij in-app?
Sorry, auto-translate was on…
Still checking daily if there is a update… I want 3 columns!
@Harwin is it an update via the app store or is it in-app?
Ik check inmiddels ook ongeveer 30 keer per dag 
Een update voor wat betreft deze update zou fijn zijn!
I have now, I started the app before the transparency option and didn’t know it needed incrementing. However, even after updating the Android version still displays the border and background colour 
I’m not sure if everyone asking for the column width feature is aware of having the option to add multiple colums and scroll horizontally?
I totally support all requests of setting column width (1/4th, 1/3, 1/2 or 1/1) to increase custimizablity of the dashboard. However, adding a 3th column does provide me with options to at lease sort my widgets based on how often I use them (or which I want to see).
If you weren’t aware: open a dashboard, click the pencil icon and slide your screen to the left to get 2 new colums to use.
Is anyone able to help me with the following: I’m trying to have my widget use methods from the OAuth2Client but I’m failing so far.
I got to the point were I created an API route in the api.js that forwards the call from the widget to home.app.getDevices() within app.js. But… I’m lost where I take this next. It still needs to be forwarded from app.js to the method in the OAuth2Client.
Thanks in advance! 
You access the oAuthClient from your device. So the device should provide a method you can call from the API.
Widget → API → app.js function → get device → device function → oAuthClient
You already have methods in your device you can call:
nl.pendo.spotify/drivers/spotify/device.js at d52a8a83f1f3e9f1686269a0566b5519c6fea2e7 · PendoNL/nl.pendo.spotify · GitHub
There you access the oAuth instance which holds your auth token.
In my widget, I added a setting where you can select a device with an autocomplete field.
This way, the user selects the assigned device and the widget knows the device id.
Then you call the API providing the device id as parameter. In app.js, you can use the device id to search the device.
Example:
Widget:
homey.tesla/widgets/car_main/public/index.html at c0e2fe0cf620fa43ddf179e8d28a2eb6a9c64d10 · RonnyWinkler/homey.tesla · GitHub
App:
homey.tesla/app.js at c0e2fe0cf620fa43ddf179e8d28a2eb6a9c64d10 · RonnyWinkler/homey.tesla · GitHub
Thanks for the great example! Much appreciated. So basically my take at this isn’t going to work as I was hoping to leverage some API methods, that’t don’t rely on a device such as getDevices, before a device is even selected. But it all makes sense what I was seeing while testing after reading your example 
My idea was to create a general (not bound to a device) widget for Spotity where the API was called to get available players (devices from Spotify API not the Homey app) and the user could select the player straight from the widget without interference of a Homey device. Kind of a universal remote for Spotify speakers.
There probably will be a workaround for this, but it isn’t a big deal. I’ll just change my universal remote idea to a reguler remote for a single device then! However… I could just use the first found device from this.homey.drivers.getDriver('spotify').getDevices() to have it do the trick?
Thanks again!
You can add a dropdown to your widget to change the device from the widget. Then you can act on the selected device.
But the default media widget is also bound to a device, so that’s the default behaviour.
Check! Thanks for pointing out. I’ll dive back in tomorrow.
Have a great night!
I really hope that a web-based version of Homey Dashboards will be released sometime next year. As someone who uses Homarr (a great open-source dashboard app for HomeLab), I was looking forward to integrating my Smart Home setup into a web-based dashboard from Athom/Homey. I wanted to add custom widgets such as for an -Arr Stack (Sonarr, Radarr, etc.) to track movie releases.
I don’t have much use for a tablet or mobile-based dashboard, as I prefer a web-based solution that can replace my existing dashboard environment. Additionally, from a development perspective, I believe it would be much easier and more efficient to create and customize widgets using a web app or web developer tools.
A web version would offer significantly more flexibility and accessibility for users who prefer to manage their systems on a larger screen or as part of an existing multi-dashboard setup.
There is an official feature request here if you want to upvote it:
I like to mention something… What I see what is happening is that different widgets have different styles. Like, different fonts, colors and layouts. This makes it a bit uggly in my opinion. It looks just like an Android homescreen with all kind of different widgets, not making it one piece of software together. I think it will be better to let developers make use of an kind of format. So that everything will look nicely together. And later on, working with different themes to make it your own.
Maybe just something to think about…
Developers have access to some default styling options for widgets:
However, it’s ultimately up to them whether to use these options. I understand your point, and for widgets that closely match Homey’s own design, I would personally try to stick to the styling options provided by Athom. That said, I believe creative freedom is essential, as it allows for the creation of unique widgets that stand out.
For instance, I would never have made a sticky note widget if I couldn’t use a different font. To me, sticky notes with a non-handwritten font wouldn’t make sense.
I only made one widget yet and I use the default styles.
But even then it’s not easy to ensure the widget fits to all others in case of alignment, icons etc.
Perhaps we can make a new styleguide thead to discuss such things also with Athom developers.
I’m not a web developer and a hint from other devs and from user perspective would be a good feedback for me.
I made 2 widgets
One I used the default styling from the widget docs
For the other one I used DaisyUI combined with the design tokens from Homey
In my opinion daisyUI fits perfectly between the other official widgets.
So if you’re not really into css I would really recommend that 
Would be cool to see this worked out as wide as possible: keep styling apart from the development of the widgets and get “dashboard themes” as a separate customization option for your installation.
This basically “just” means that there is going to be a default Homey theme/style which can be extended/cloned and modified and essentially transforming all widgets on your dashboard to be styled the same way. Imagine having some options like monotone, energy friendly and matrix styled dashboard 
And I get that things like post-its would still be custom styled as they are now, that fits their “thing”. They are meant to stand out. But for most the sake of the dashboard and widget quality I agree it would be a wise choice to adapt to a default style that can be customized using themes rather than per-widget styles.
So here is an example where I’m not sure what icon/textsize would fit best. I think this is something, that’s up to the developer to decide. But the style guide doesn’t provide examples for such text/icon sizes in such text only value presentations.
Title is ok I think, based on the examples I use homey-text-bold and homey-text-small-light
For the content I can’t decide between
homey-text-small and --homey-icon-size-regularhomey-text-regular and --homey-icon-size-mediumAnd it depends on widgets next to another if can directly see a difference.
Using Homey CSS styles is like using the Homey theme. But this theme has a lot of text styles 
Styling | Homey Apps SDK
I mean… it does provide enough structure to have developers just develop what they want and it’s open enough for an extra themes layer to be layed upon it and perhaps have some creative mind utilize the setup and create some beautiful themes.
In your example it’s probably either gonna be what your feeling the best about or what feedback you get from users and you decide to adapt to? The theme would just replace the colors, borders and active states for example. Not so much the size. Widgets with a lot of content could benefit from smaller fonts and icons. Personally, I think I would try to stick as close as possible to the “font-size-default” for the most important content of a widget and work up for headings and down for less important things.
I have an Alexa Echo Show 15 on the wall. The only thing I can access from it is the Homey web interface. I created a new dashboard using my phone app. Is it true that dashboards are only accessible using the native phone / tablet apps?
When will you add the web interface support?
When will you add the homey app to Echo Show app store?
