The variants for boolean values are so nice that I would like them also in devices. 
You can do more in flows with a virtual switch then variable. Like a bypass switch.
So I like to make there also a Y/N button.
By lamp device is it nicer to have a yellow/black toggle instead of the red/grey one.
good point by the way … I also commonly use virtual switches to disable/enable some automations
I have not voted yet because I consider the consequences. I like to be able to editing with mobile but it is “nice to have”. But it would be a big drawback if I can not design a good mobile view, I use it many times a day. If I design a dashboard on computer I have to adjust the mobile view, size and position, so in that case mobile editing will be “must have”.
The same thing
It would be a draw back for me
Off course, he talks about editing, not viewing.
As Athom has done with Advanced Flows (doesn’t even support viewing). I think it makes perfectly sense. Even more when we talk about dashboards.
Fixed
And I’ve also noticed that my attempt at using topic-link click count as a makeshift poll… has failed 
It seems it doesn’t work with links to the same topic, only to other topics or external links. And if I try to add a poll in the native Discourse way, I get an error message about insufficient permissions. So lets try again, this time using your favorite search engines. If this doesn’t work, I give up 
Click the link representing your opinion:
I my opinoin building a dashboard would (I’d like to say should ) be done on a computer. The possibility to finetune it on mobile would be nice (f.e. if you spot a small error)
Did you get a chance to look into my problem (page not responding after first click, possibly caused by a missing device)?
My dashboard now looks like this and I’m not able to do anything (menu on the topleft doesn’t respond). The same on my phone, Chrome and Edge
Sorry for nagging about the same thing 
but I really want to understand if it’s a local “problem” or a general problem.
I have now bookmarked both the local URL and the remote URL, in order to compare the two (while being on the same network as my Homey).
Experience to date:
To summarize - it feels like a hit or miss when trying to access the dashboard, sometimes it works, sometimes it doesn’t work, sometimes you have to repeatedly hit the URL to have it loaded.
I mean, accessing the https://my.homey.app works 10 out of 10 times (independent of location), so I guess we’re not talking about a general access problem.
Maybe something you can have a look at, but of course, if you’re not experiencing it, it will be difficult. 
What is the need for “Local dashboard” (not the same as local URL). After loosing a local dashboard (reset of browser data) I only have Homey app dashboards and do not see the need for Local.
Concerning dashboard editing:
Guess no big issue on the browser e.g. in developer mode where you can change the view to any mobile device anyway.
Other option: make a toggle somewhere and support both modes 
Support both also nice idea indeed
For me is it a no go to edit on PC
This was the initial way to build dashboards, before the introduction of Homey app dashboards, but it’s legacy now I guess?
Maybe some of us made a huge dashboard with it, and wait for a way to import it into a Homey app dashboard?
Have you checked for error messages in the developer console (F12) ?
I’ve tried to reproduce it, but unable to sadly 
I can do the technical explanation if you like, but its more or less like comparing apples to pears here.
When you access the dashboard through the local or remote urls, you try to load all the html, javascript and css directly from your Homey sitting somewhere in your house.
Remote connection uses Athom Connect as a reverse proxy to access your Homey over the internet through any firewalls your router might have. Your Homey maintains a constant connection to Athom’s servers, even though little or no traffic flows through the connection. When you access the remote url, Athoms servers first has to find our which server holds that existing open connection to your Homey, and then route your request through that connection. This takes time, and is why you experience first connection to take a little while.
Local connection is a somewhat advanced beast in itself. When you access the local url, in my case: https://192-168-0-88.homey.homeylocal.com/, several network protocols work together. First off your browser query your ISP’s DNS server. It requests an A record for the domain name 192-168-0-88.homey.homeylocal.com. An A record is an IP address type record. It seems Athom has either pre-created A records for all local IP ranges, which seems excessive. Or they host some kind of custom DNS server that just respond with the IP from domain name. At least they host their own name servers at ns1.athom.nl.
Now, what’s so interesting about this? Well in order to create a secure connection, you need a verified encryption certificate. And even though it’s possible to create certificates for an IP address, it’s easier for a domain name. So Athom uses an automation protocol called ACME to obtain a wildcard certificate from Lets Encrypt for the domain *.homey.homeylocal.com. The private and public encryption-keys for this certificate is then distributed as a part of the Homey firmware.
So at this point your browser resolves the local IP address for your Homey, and responds with a valid certificate. And your Homey responds with the html, javascript and css files built by yours truely: me.
Now, over to the theory why the first request is slow: My guess is that it’s a combination of DNS query, certificate and web-server on the Homey that needs to warm up for some reason. Because when you use homeyboard.github.io or my.homey.app, both of them first try to access the local and remote url underneath the hood. Both access the urls, but only use the APIs of the Homey, and not the web-server itself. The API responds quickly, but the web-server is slow or times out the first time. It might be that the web-server has to resolve the certificate from somewhere before it can respond. The Homey web-server doesn’t serve compressed files. That means that you have to transfer 5-10 times more data compared to the online version at homeyboard.github.io.
I usually use the online version, so this is a problem I don’t experience this issue on a daily basis. And there’s nothing I can do with this, because it’s either network, DNS, TLS or Homey web-server or a combination.
NOTE: As a poll, everyone that knows how all these technologies actually works, like this post. Its just interesting to see how many in this forum knows their shit 
Thank you Marcus @skogsaas for your very detailed explanation - very appreciated Maybe I should try the online version then!
On the other hand, I guess that this issue, Reconnect on tab focus · Issue #109 · skogsaas/homey.dashboards · GitHub, will reduce/eliminate the need for page reloads though.
Keep up the GOOD job and have a really nice weekend!
I remembered that the local, unencrypted, address don’t seem to have this connectivity issue. Try using this local url, just with your own Homey-ID instead:
http://homey-1234567890abcdef.local/app/skogsaas.dashboards/assets/dashboard/
This is only for info because I use a shortcut to githob.io
Then I get both dashboards.
Local URL: 192-168-178-6.homey.homeylocal.com. : not found
If Wi-Fi is needed then that’s the reason. On my new Fritz!Box I have Homey not connected to Wi-Fi.
It’s so only on ether-net connection.
Remote URL: only the Homey Dashboard.
I have a whole lot of errors in my developer console (I’ll pm you)
Thanks, but it doesn’t work:
This works fine @ Pro 2019
http://Homey.IP.address/app/skogsaas.dashboards/assets/dashboard/
Like:
http://192.168.10.20/app/skogsaas.dashboards/assets/dashboard/
And, don’t use https
Hi
I think this dashboard looks great. 
And i like how fast it updates. I have 1 question. Is there any way to make the text and numbers any larger? I have a plan to have some power and temperature on a 7" screen. But i can’t make the text any bigger. And i want to see the outdoor temperature from my sofa.
