thanks so much! would it be possible to post your dependencies from /local/custom-lovelace/ as a downloadable .zip? might take some time to fetch them all individually for the people who wanna try this out
Hey @hefal, I can include the custom cards code in my repo. My recommendation would be to get them all straight from the source, but I’ll update the readme with that information as well. I can get that all updated tonight.
Just updated my readme file on GitHub. Tonight I finished moving most of my resources to use HACS (Home Assistant Community Store - I included a link to the setup instructions in the readme), so you can set that up so they will automatically download and update. There are a few custom files that are not set up in HACS that I haven’t uploaded yet, but I will be doing that soon.
My Home Automation blog is up and running! https://alex-p.com/blog
The first few posts are going to be an introductory series on the smart home/home automation, but as I move along, it should be a good mix of topics to appeal to people of all skill levels: tutorials, frontend examples, automation examples, product reviews, and more. I’m also open to ideas for posts!
I’ve also got three AppDaemon scripts that I converted for use with HACS. Those apps are available in HACS by default, if you include AppDaemon in your HACS configuration. I’ll have more added soon as well!
What do you use for presence detection?
I use the Android app Automate, which is similar to Tasker. Based on Wi-Fi connection state and then GPS location, I can reliably detect that I’m away within just a few blocks of leaving my home, and then generally as soon as I’m back in the garage when returning. Automate just sends HTTP requests to the Home Assistant REST API to call the device_tracker.see
service, which I’ve posted about previously here. I’ve got plans to share all of the details of my presence setup in a future blog post.
oh i was hoping for room presence detection, similar to xandem
Gotcha. I do have plans to consider that in the future . I considered using my Google Home devices to do it since I already have them in most of the main rooms we use, but I’ve heard the functionality is somewhat flaky. If I do it in the future, it’ll probably be with ESP8266 devices.
Config Check (AppDaemon)
I’m excited to announce the initial release of my Config Check AppDaemon app!
I’ve seen a few people around here asking for functionality to streamline the process of checking their configuration files and restarting Home Assistant, especially after some of the new additions to the Configuration menu pushed down the Check Config and Restart options on that page. This app will allow you to initiate a check of your configuration directly in Lovelace, and it creates a sensor that will tell you whether the configuration is valid (and why it failed if it’s invalid). Furthermore, the app will restart HASS automatically if your configuration is valid.
This has been tested successfully on my setup, so I’m ready to release it into the wild. Please check it out, put it through its paces, and log any issues on the GitHub repo! Full instructions can be found over there.
The app is also set up to work with HACS, though I’m not going to submit it to be in HACS as a default until I move it out of pre-release. For now, you can add the repository manually on the settings page. If you’ve never used AppDaemon before, and you’re hesitant to try this app because of it, don’t let that scare you off! Now that AppDaemon apps can be distributed by HACS, it’s pretty easy to set this up, especially on Hassio. Just install the AppDaemon add-on, and follow the steps in the HACS docs to enable AppDaemon support there. Then, add my repo and install the Config Check app, and all you have to do from there is add the three lines of App Config YAML to /config/appdaemon/apps/apps.yaml and complete the other steps in the readme.
Let me know if you have any questions, and happy config checking!
I was just about to write a long post about how I couldn’t get things working until i looked once more and had an AHA! moment.
I’ll post here to help any others who might get stuck where I was…
I use a non-hassio HA installed in Docker on a NUC running Debian (ie. not a RPi). I never had Appdaemon installed so I had to start from scratch.
Here are the instructions I followed to install Appdaemon in Docker:
https://appdaemon.readthedocs.io/en/stable/DOCKER_TUTORIAL.html
Everything went great with the test run and I moved on to creating a permanent install of Appdaemon.
After I got AD running I followed the install & config docs at @apop’s repo but for some reason I couldn’t get it to work.
I then realized that HACS was adding the check-config.py app files into it’s own appdaemon folder in the HA config directory and I had set up a completely different appdaemon docker config directory that I bound the “conf” directory to.
So to solve the issue and allow appdaemon to run HACS installed files in HA you need to bind the correct folder to the “conf” folder for AD. My HA config directory is found at “/home/finity/docker/hass-config” so you will modify the -v binding to “<your_HA_config_directory>/appdaemon:/conf”
Here is my docker run command that is working but you need to make sure you rename your path to the correct HA config directory:
sudo docker run -d --name="appdaemon" --restart=unless-stopped -p 5050:5050 -e HA_URL="http://<your_HA_IP:PORT>" -v <your_HA_config_directory>/appdaemon:/conf -v /etc/localtime:/etc/localtime:ro -e TOKEN="<your_HA_AD_Token>" -e DASH_URL="http://$HOSTNAME:5050" acockburn/appdaemon:latest
Make sure you change the permissions on the appdaemon conf directory in the HA config directory to allow HACS to write that folder.
Thanks for this, I’ve created a picture elements card with this and the other “reload” buttons.
@finity That’s great stuff! Do you think you could submit that a PR with that information to the HACS documentation? Otherwise, I can put something together.~ I’ll put together a PR to add it to the documentation as I think it needs to go on a brand-new page and not an existing one, and there’s some other things I’d like to include.
@Holdestmade That card looks awesome! Do you mind if I add a screenshot of it to the README to show another example of the app in action?
Also, could you post the config you used?
While I’m not against oohing and aahing over a pretty card I think I’d find it more useful to actually add it to my config too.
Thanks!
I’ve been playing around a bit and forcing some errors to see the response.
It looks like the sensor will only show one error at a time. Is that true or am I missing something?
EDIT to add:
Also, in regards to the post above about putting the reload buttons for the different items (automations, scripts, etc) in a card got me thinking that there is a loss of advantage to those buttons/services because the app automatically restarts HA on every valid config check as opposed to the operator simply choosing to reload just the domains supported by a “reload” instead of a full restart.
Is there a way to have any kind of “are you sure?” step to acknowledge that a full restart is desired instead of a reload? That way if you say “no” then the process stops and you can just do the reload at your leisure instead of the immediate auto restart.
Or maybe button for check and then stop. Could easily add a restart button calling the restart service to Lovelace same way I’ve added the reloads.
Yes no probs
I commented out line 35 of checkconfig.py and changed my card to this. Now checks only and have a button for restarting
type: custom:vertical-stack-in-card
cards:
- type: picture-elements
image: /local/images/BG_blank_slim.png
elements:
- type: image
image: /local/images/icons8-administrative-tools-80.png
tap_action:
action: call-service
service: script.check_config
style:
top: 50%
left: 10%
width: 10%
- type: image
image: /local/images/icons8-restart-80.png
tap_action:
action: call-service
service: homeassistant.restart
style:
top: 50%
left: 26%
width: 10%
- type: image
image: /local/images/icons8-source-code-80.png
tap_action:
action: call-service
service: homeassistant.reload_core_config
style:
top: 50%
left: 42%
width: 10%
- type: image
image: /local/images/icons8-variation-80.png
tap_action:
action: call-service
service: group.reload
style:
top: 50%
left: 58%
width: 10%
- type: image
image: /local/images/icons8-automation-80.png
tap_action:
action: call-service
service: automation.reload
style:
top: 50%
left: 74%
width: 10%
- type: image
image: /local/images/icons8-note-80.png
tap_action:
action: call-service
service: script.reload
style:
top: 50%
left: 90%
width: 10%
- type: entities
show_header_toggle: false
entities:
- sensor.config_result
The sensor is outputting everything it gets back from the check_config
API endpoint. I believe once it hits a failure it stops there, so you’d have to correct that error and then run the check again.
That’s coming in 0.2.0. Wanted to get an MVP out there for testing, but yes, I intend to make auto-restart optional. Should be pushing that update today.
Yeah, I’m not really sure how the check_config service differs from the “Check Config” button since I never use the service, only the button.
But I’m almost positive that the “Check Config” button will give you all of the errors that it finds not just the first one.
That’s not a deal breaker tho. I guess it prevents user overload from trying to figure out why 10 things have errors instead of just one.
I’ll be waiting on v0.2.0. I’m no MVP but hopefully my testing will count too.