Makes sense. I am only running it local and that is fine for me in the beginning. But someone just mentioned that the error I get when accessing the dashbord could be because of NGINX. But it seems from your answer that that is not the case. btw, the error that i get is a pop-up saying “error getting state, check Java Console for details” . And the light switch etc. that I added are not working. They just show a percentage that cannot be changed, and they are not able to turn the light on/off.
I am not a programmer, so please forgive the not exact terminology.
Appdaemon is linking into HA and communicating with it vica versa. So first you have to make sure that anything you try works in HA. Access your install with http://IP:8123, and see if the button, switch, sensor, etc. is there (you can see it). Then try to flip it manually, and see if it does what it is meant to do.
After that you can start creating your own dashboards, according to the readme on github
you can use nginx to see your dashboards outside your own network, with certs and you can password protect your dashboards.
This is probably hijacking, but
I have asked that question from Andrew (I know not baloob ) just about a week ago, and he told me that it is not possible yet.
am I missing something?
i dont know what is not possible and what you actually want.
but these things are possible:
- setting certs in AD or in NGINX
- going from outside your network to AD for AD API or Dashboards
- setting paswords for dashboards
those things are also in the docs and around for longer then a week.
http://appdaemon.readthedocs.io/en/latest/DASHBOARD_INSTALL.html
I have just ran through the link you’ve posted, but I can’t see where is nginx envolved there. It is only taking about appdaemon over ssl and password protecting it. (I haven’t found anything about proxying from port 443 to 5050.)
I thought that bagger was looking for something like this:
there is nothing about NGINX there because the docs are about AD.
i dont know if its possible to go from 433 to 5050 (i thought that was also possible)
setting up AD through nginx is off course completely different then setting up HA though nginx.
Sorry. Looks like today I am not that good with names It is bager of course not bagger. Sorry again!
No worries about the name @towme
I’m getting a bit confused about the nginx part. I have no need to acces the dashboard outside my own network at the moment, so if nginx is not required for jut normal local setup, then my bad. I might have gotten it confused. What I still can’t get to work though is, that in my normal HA panel (ie http://IP:8123) I can easily control all my components (lights, locks etc.) but when I add them on the HADashboard, they wont work. Then the system says the following error as I load the dashboard.
“error getting state, check Java Console for details”
I can see the components (ie. the lamps and locks etc), but nothing happens when I press them:
Hello
I had the same problem so appdaemon.yaml i added
AppDaemon:
cert_verify: False
disable_apps: 1
logfile: STDOUT
errorfile: STDERR
threads: 10
app_dir: /config/hadaemon/apps
HASS:
ha_url: http://192.168.1.100:8123
ha_key: ****************
HADashboard:
dash_url: http://192.168.1.100
dash_dir: /config/hadaemon/dashboards
I noticed if you look into compiled/javascript/default and edit one of your _init port number was wrong so i edited the appdaemon.yaml and corrected it that way with mine it just uses port 80 and that seems to work for me
I hope this helps
hey @aimwarlock . Not quite sure whats the difference is between the appdaemon.yaml configuration that you are showing there, and the one I have:
Furthermore, I’m not sure what you mean by the last part you mention. The part with the port numbers etc.
from the docs:
dash_url - the url you want the dashboard service to listen on
For instance:AppDaemon:
ha_url: <some_url>
…
HADashboard:
dash_url: http://192.168.1.20:5050
so i would add the port in your dash url.
But the thing is. I can easily get access to the dashboards. But it just won’t do anything with the components that I add. And I don’t know what the error means.
a) you could try it. (it wont hurt you)
b) for logfile and errorfile give a file name like /home/pi/error.log
c) start appdaemon new
d) acces the dashboard again
e) find the errorlog and show it here
a few other problems that you could have created while trying to get it right:
a) the browser could have cashed the page with the error when you tried it with the wrong config (so clean your cash)
b) the files that are created by appdaemon could be wrong so clear the subdirs from the dir named compiled
Oh I found something. Thanks to your guidance into the compiled dir, I can see that the .js files of the dashboards are looking at the port 80 of the IP. That shouldn’t be so I guess?
I think that is a result of you leaving the port off - it defaults to 80, which is why you need to specify it. That would explain the popup errors.
@aimc that makes sense. But I think that I have them specified. This is my .yaml file. And also how it looks in the “options” part in HA. Can you see if anything looks wrong?
Did you take Rene’s advice of clearing out your compiled directories? If you have a precompiled dashboard with the wrong port from earlier, it won’t be picked up because a change in port is not noticed by the compilation algorithm. Alternatively, set:
always_compile: 1
In the dashboard section of your config - at least until you have things working.
Tried adding that. And also “dash_compile_on_start: 1” as from the docs.
Now nothing will shoe (ie. nothing will load on the IP). And also after I deleted the files from the compiled folder, they are not coming back now
OK, I have some idea what is going on I think. Problem is I’m not a docker or hass.io expert, but I think this is why NGINX is required for this config.
The 5050 port is mapped to 80 by HASS.IO and you get the initial page, but since the code thinks you are coming in on port 80 (because of the mapping), the code sent to the browser to call back into the dashboard to get infor about the widgets state fails because they saw the request coming in on 80 the generated JavaScript references port 80 when it should be port 5050.
NGINX can be used to do the mapping somehow but I have never used this setup and I’m not sure of the specifics.