i just installed noob on the PI and installed HA.
and i installed the dashboard and appdaemon which was way more easy by the way.
1 Like
would you also be if someone called a project, where you are working on for hundreds of hours and with a great amount of pleased users, a nightmare.
Would you prefer that I lied and said it’s fantastic and then go and moan somewhere else behind your back?
no but you should be realistic.
you didnt get it installed because of the platform you chose.
installing the dashboard is nothing more then
pip install appdaemon.
and configuring it is just as difficult.
i could try to install it on a iphone, but if that wouldnt work i couldnt blame the program.
Must be my fault for following the instructions for installing it on hassio because there were instructions for installing in on hassio then.
hassio is quite new.
and if i see the amount of topics about it on the forum, its not perfect yet 
In my defence, coming here as a new user from Openhab using Openhabian which works well, the landing page that tells you how to install it on a PI is promoting hassio as the best and recommended way. It’s clear to me now that if you want a fully functional system this is very much not the case.
I get it that HADashboard is a labour of love but to be honest, a home automation system that doesn’t have a simple user panel interface is as much use as a chocolate teapot in my house hence my annoyance at the wasted hours.
I’m going to persevere and go down the route of not using hassio as I really like the automation in HA as I’ve got more working in HA within a few hours than I ever got working well on Openhab in weeks. The Openhab rules system is a nightmare
Thanks to all for the pointers.
1 Like
The very reason I built HADashboard. The native HASS interface works well on hand help mobile devices but a wall mounted dash has a different set of design goals.
At some point, hopefully soon, HADashboard will be fully integrated with AD and the installation piece will be a no brainer.
1 Like
Yes, using HASS.IO is indeed the problem here, and I know HADashboard works well because I had it up in running before I made the switch to hass.io. (thanks @aimc for all your hard work on this, it is much appreciated) I decided to move to hass.io as I had to too many issues updating stuff on hassbian, I had to reinstall several times, etc. Hass.io just seems to work, I’ve been through several upgrades without issue…which it great
That said, I just need to figure out how to get HADashboard to look for homeassistant on port 3030 instead of port 80, OR obviously better yet, forward all port 80 requests to port 3030. Supposedly NGIX can do this… I just can’t get configured correctly. If anyone knows how to get HASS.IO to forward requests on port 80 to 3030 I’ll be golden!
I will be taking a look at this when I get back from my business trip - it seems to be tripping a lot of people up - If I can make it easier with some simple changes and writing some docs I will 
4 Likes
awesome! Looking forward to it. I’d be willing to test anything you have if needed.
Thanks @aimc. I assure you it certainly WILL make the life of many much much easier…
Ps: I’m another one who’s scratching his head to get it working
Does anyone know if there has been any progress on this?
I made the jump from a manual install over to HASS.io. I’ve really liked it so far but am starting to have regrets as HADashboard is such an integral component of my setup.
i heard of no change.
still regularly people with hassio problems and outdated AD version not working.
I got it working by changing port in appdaemon setup and domain to hassios ip.
also changed dash_url to hassios ip adresse.
and set dash_force_compile to 1
3 Likes
cool not bad for a carpenter (me) that dont kow muich coding
1 Like
I’ve been hit by the this problem as well and have done some research.
The “error getting state, check java console for details” occur when you are using SSL proxying, and is caused by mixed content (both https and http). I.e. the states (sensors, devices etc.) are loaded as "http://<host>:<port>/state/..."and the javascripts are loaded as "src=javascript/...."
This will expand them to urls starting with “http://…” and that will fail when proxied through a SSL proxy.
I’ve tried to hardcode this to https, changing the conf.base_url in appdash.py to:
conf.base_url = "https://{}".format(conf.dash_host)
and changing all javascript in dashboard.jinja2 to:
src="https:<host>/javascript/....
And then it works when connecting through an SLL proxy. Unfortunately hardcoding this will break normal http access so it is not a permanent solution, more like a proof of concept.
What needs to be done is to change both the appdash.py conf.base_url logic and the javascript loading to something that will dynamically appear as https:// or http:// depending on how you connect. This should be fairly easy for those who know what they are doing (I do not : )
Thanks for the investigation - i’ll add this to the list - the relative javascript paths might be a problem though.