So if I was using switch instead, would I say the entity is the input_select and use the state_map? The scripts do handle the input_select (in fact, that’s how all the actions trigger, by the input_select changing, since in the HASS UI that’s the behavior).
Cool to hear we can do the overrides in the dashboard!
Exactly - as I said you need to explicitly specify which script to use for off and on for each widget, and the state map will map the value of the input select to display any value you like although it won’t affect the switching on and off in any way. Also don;t forget the part about toggling the input select in the scripts themselves.
I think you might also need to use the active map to make sure the switch understands what is on vs off.
I was playing more with the dashboard and include files the other day and discovered something nice. I have a footer with all of my rooms in it to use for navigation between room dashboards. It’s composed of two rows of 6 widgets each with a spacer in front of each row to center them nicely. I put this in there simply by including the footer.yaml file. my footer.yaml file has the widgets and layout in it. In the case of one of my son’s rooms, this covered up part of the background that is nice to see (background is a picture of bush stadium and the footer covered the infield). So I wanted to split the footer 50/50 leaving a gap of two spaces in the center. This meant that for that room I would have to not use the standard footer and include the widgets and layout in the file directly and I didn’t like that idea. Here is how I solved it.
I moved the footer into two files (footer_widgets.yaml and footer_layout.yaml) In his file, I included footer_widgets.yaml but not footer_layout.yaml. This way if I need to change the link for one of my dashboards in the footer, I can still just change it one place and everyone gets the updated widgets. Then I just added the layout lines to the appropriate .dash file and was able to customize that footer the way I wanted.
Learning : the widgets and layout don’t have to be in the same file.
Ok I think I have it. Actually if I use state_active, I dont really need to do the mapping. I guess it’s an either/or but I like the state_active better here
I can’t test at the moment as everyone’s home and the TV is being monopolized 
But the Apple TV is lit up and the others arent
tv_atv:
widget_type: switch
entity: input_select.living_room_tv
state_active: Watch Apple TV
post_service_active:
service: script/turn_on
entity_id: script.lrtv_watchappletv
post_service_inactive:
service: script/turn_on
entity_id: script.lrtv_watchappletv
title: "Watch Apple TV"
icon_on: fa-apple
icon_off: fa-apple
Another thought, since I would now have intelligence in the dashboard and don’t really need a script that’s smart enough to toggle, maybe I could call input_select.select_option directly from the post_service blocks and stop having the scripts at all?
Yep, I don;t see any reason that would not work - I was assuming you were doing other stuff in the scripts but if you are firing automations based off the input select changes it should work just fine
Well I first cloned the beta v1 from github, then did a pip3 install . in the appdaemon directory, then did a pip3 uninstall appdeamon, then did a git pull origin and then a pip3 install . again.
yeah. It runs fine from the comand line.
OK, What happens if you invoke the INIT script form the command line:
$ sudo /etc/init.d/appdaemon start
thats what I do…
“ps ax | grep appd” gives me appdaemon running, but “netstat -tupan|grep 5050” gives nothing, and there is the former error in the appdaemon log file. But the error log is empty.
the difference is that when I start it with the init script I am running /usr/local/bin/appdaemon, and from the command line I am running python3 -m appdaemon.appdaemon. And that the init script is not started from the cloned directory, but from /etc/init.d
That shouldn’t matter if you have done the pip install.
Errno 22 implies something weird in one of your parameters, I presume you are using the same config file in both cases? I Pass elements form DASH URL into the call that is failing, could you try deleting and recreating that line in the cfg file?
Also, what happens if you sudo to root:
$ sudo su - root
Then run appdaemon directly:
$ appdaemon -s <path_to_config_dir>
ok so this is the “new” appdaemon.conf
[AppDaemon]
ha_url = http://192.168.112.254:2012
logfile = /var/opt/homeassistant/appdaemon/appd_log.log
#logfile = STDOUT
#errorfile = STDERR
errorfile = /var/opt/homeassistant/appdaemon/appd_err.log
threads = 10
#app_dir = /var/opt/homeassistant/appdaemon/conf/apps
#dash_url = http://192.168.112.254:5050
dash_dir = /var/opt/homeassistant/appdaemon/conf/dashboards
disable_apps = 1
# Apps
#[hello_world]
#module = hello
#class = HelloWorld
with this I don not get any errors in the log file, but nothing listening on the 5050 port naturally.
2017-03-14 19:18:26.316046 INFO AppDaemon Version 2.0.0beta2 starting
2017-03-14 19:18:26.316531 INFO Apps are disabled
2017-03-14 19:18:31.478001 INFO Got initial state
2017-03-14 19:18:31.486010 INFO Connected to Home Assistant 0.37.1You have the dash_url commented out so it won’t attempt to start the dash piece.
Yeah, I thought that 
If I take the comment out the error comes back…
Forgot to write that I always run everything as root for the first time to eliminate permission problems… (I know, i know, security and everything, but it is a bad habit that stuck with me)
Tried to write “/usr/bin/python3 -m appdaemon.appdaemon -d -p /var/opt/homeassistant/appdaemon/appdaemon.pid -c /var/opt/homeassistant/appdaemon/conf” to the init file, but getting various errors from no pidfile to “can’t chdir to -c no such file or directory”
Maybe I will just put the line that run form the command line into rc.local
Thank you.
Okay this seems weird.
Running appdaemon -s /var/opt/homeassistant/appdaemon/conf gives the following error
Traceback (most recent call last):
File "/usr/local/bin/appdaemon", line 11, in <module>
load_entry_point('appdaemon==2.0.0b2', 'console_scripts', 'appdaemon')()
File "/var/opt/homeassistant/appdaemon/appdaemon/appdaemon.py", line 1556, in main
args.starttime, "%Y-%m-%d %H:%M:%S"
File "/usr/lib/python3.4/_strptime.py", line 500, in _strptime_datetime
tt, fraction = _strptime(data_string, format)
File "/usr/lib/python3.4/_strptime.py", line 337, in _strptime
(data_string, format))
ValueError: time data '/var/opt/homeassistant/appdaemon/conf' does not match format '%Y-%m-%d %H:%M:%S'
How should a directory match a time format?
That would be caused if you specified a -s in the command line, which is the “starttime” argument.
EDIT: It should be -c not -s
Okay no error this way (with -c) , and it seem to be working fine.
2017-03-14 19:59:54.262753 INFO AppDaemon Version 2.0.0beta2 starting
2017-03-14 19:59:54.276656 INFO Apps are disabled
2017-03-14 19:59:59.467904 INFO Got initial state
2017-03-14 19:59:59.468468 INFO Starting dashboard
2017-03-14 19:59:59.487970 INFO HADashboard Started
2017-03-14 19:59:59.488506 INFO Listening on ('192.168.112.254', 5050)
2017-03-14 19:59:59.491491 INFO Connected to Home Assistant 0.37.1
Even more puzzling, or?
If I remove the “-d” from the daemon_opts then everything is fine, except that the process does not get daemonized, of course. If I put the “-d” back (does not matter if it is first, second or third option) the error is back.
OK, so we are down to an environmental issue then.
Still sudoed to root can you run:
# pip3 show aiohttp
my new skin in this post: