Actually, you’re using the instructions for installing hass-apps together with a fresh copy of AppDaemon into a dedicated virtualenv, as also stated by the docs page you referenced. However, you already installed AppDaemon using some other mechanism before and now have two different copies. If you want to stick with the AppDaemon you already had before, remove everything related to hass-apps and reinstall it system-wide, as you seem to also have done with AppDaemon. This is an approach that’s highly discouraged due to various reasons, but since you already did it that way…
sudo pip3 install --upgrade hass-apps
Since you not seem to be particularly familiar with these things, maybe you’d be best off switching over to hass.io and not deal with managing a GNU/Linux system yourself.
Will see if I have time to switch back to hass.io again. I did try that before because of the very attractive looking add-on store but I did not like the fact that I could not install programs to the side like Influxdb, Grafana etc. I know that they also can be installed through the add-on store but at some point (with merging of influx databases if I remember correctly) I was missing some functionality (or know how ).
Just as an extra question: with hass.io it is NOT possible to install software outside the hass.io environment correct? (bit off-topic).
Last couple of week I have been switching from openHAB to Hass.io, Home Assistant and back again to see what is working for me. Any way will read the instruction again and see if I manage to get it working if I install the hass-apps system wide. Just out of curiosity
highly discouraged due to various reasons
What kind of reason might that be? At the moment I see myself only using Schedy and maybe trying a bit with the HADashboard, will these reasons be applicable to me?
between step 4 and step 5 you need to install appdaemon in the venv (pip install appdaemon)
because now you got hass-apps inside the venv and appdaemon not.
you can install appdaemon also in the venv right now.
first activate the venv
source /home/pi/appdaemon/venv/bin/activate
the install appdaemon
pip install appdaemon
from that moment on you need to activate the venv before you start appdaemon (with a service or manual)
the command to start appdaemon would stay the same, because your conf is still on the same place.
venv is a virtual environment.
when you create a new venv you create a new python environment. in which you then can install libs and packages. the reason to use venv is because different programs (HASS and appdaemon) can both need the same libs, but different versions. when you install them in 1 python environment they can bite each other.
so its wise to create 1 venv for HASS, and 1 venv for appdaemon.
Just as an extra question: with hass.io it is NOT possible to install software outside the hassio environment correct?
that depends on how you install it. there is also a docker version for hassio if i am correct, and then you can install other programs aside that docker.
will experiment with both in the future. Maybe Docker is the way to go but I do not have much experience with Docker (even less than with what we are doing now but I keep on learning).
graag gedaan Piet.
and when you have more questions about using or installing appdaemon or hadashboard then please feel free to visit our discord server: https://discord.gg/pHsjADY
we also have a dutch channel there. (taking a wild guess here )
between step 4 and step 5 you need to install appdaemon in the venv (pip install appdaemon)
because now you got hass-apps inside the venv and appdaemon not.
@ReneTode That’s not correct actually. Hass-apps pulls AppDaemon as a dependency, so he had everything he needed in the virtualenv. I was just noticing that he previously installed AD system-wide including a systemd service unit, probably by following some other tutorial out there.
@poeterdebier If you want to stay with hassbian in the long run, it’s actually best to use a virtualenv as @ReneTode suggested. That way, every Python software you use can pull the exact versions of dependencies it needs. If you install everything system-wide, you’ll soon reach a point where two of the projects you use require conflicting dependencies and hence won’t work properly or at all. If you want to follow that route, you can just use the Manual Installation instructions you followed before, but then also switch the command from appdaemon to /path/to/venv/bin/appdaemon. That is the cleanest solution. You need to change the path in the systemd service file you created for running AppDaemon at system startup time.
ah thx, i didnt know that.
in that case he has AD and hassapps in a venv like needed. all he needs to realise is that he needs to activate the venv before starting AD.
in that case he has AD and hassapps in a venv like needed. all he needs to realise is that he needs to activate the venv before starting AD.
He not even has to activate it explicitly. Just using the full path to the appdaemon script for launching AD is enough, since the fact that it is part of a virtualenv is baked into the Python interpreter itself.
I’m still progressing converting my automation to schedy.
Schedy is really awsome, really powerfull and yet simple. I love it.
I really like the allow_manual_change_function thing: forcing light to restore the scheduled state after wifi reconnexion when my kid plays with light switch (not the smartswitches but the main switches that are still functional but only meant as a backup in case of home assistant is down).
Anyway, if my schedule for individual bulbs is fine, I’d like to clean my template light (executing scenes before), and I’d like to use schedule_snippets for repeating triggers and conditions, please check an extract of my code below:
sejour_min:
actors:
light.sejour_min:
allow_manual_changes: true
rescheduling_delay: 0
schedule:
# Conditions
- x: "Break() if is_off('input_boolean.lampes_sejour_auto') else Next()"
- x: "Break() if is_off('binary_sensor.presence') else Next()"
- x: "Break() if float(state('sensor.luminosite_sejour')) > float(state('input_number.seuil_luminosite')) else Next()"
- x: "Break() if is_off('input_boolean.matin_soir') else Next()"
# Trigger
- x: "'on' if is_on('binary_sensor.presence') else Next()"
- x: "'on' if state('media_player.tv_ue55ju6510_salon') == 'on' else Next()"
- x: "'on' if is_on('binary_sensor.sejour_mouvement') else Next()"
- x: "'on' if is_on('binary_sensor.mezzanine_mouvement') else Next()"
sejour_max:
actors:
light.sejour_max:
allow_manual_changes: true
rescheduling_delay: 0
schedule:
# Conditions
- x: "Break() if is_off('input_boolean.lampes_sejour_auto') else Next()"
- x: "Break() if is_off('binary_sensor.presence') else Next()"
- x: "Break() if float(state('sensor.luminosite_sejour')) > float(state('input_number.seuil_luminosite')) else Next()"
- x: "Break() if is_off('input_boolean.jour') else Next()"
# Trigger
# - x: "'on' if is_on('binary_sensor.presence') else Next()"
- x: "'on' if state('media_player.tv_ue55ju6510_salon') == 'on' else Next()"
- x: "'on' if is_on('binary_sensor.sejour_mouvement') else Next()"
- x: "'on' if is_on('binary_sensor.mezzanine_mouvement') else Next()"
As you can see, 3 out of 4 conditions are common, and 3oo3 triggers are.
That’s easy to put triggers in a snipet, but the conditions, the way I wrote them, it’s difficult.
Did you understand the difference between Break() and Abort()? I just want to make sure you did, because your Break() will only break out of the sub-schedule it’s used in, not the whole scheduling. In your case, schedule_append will still be considered after one of the breaks catched, don’t know whether that’s what you want or not.
).
but I keep on learning).
