Not sure what is going on here - looks like an issue with the daemonization, I’ll have to dust of a Pi and try it myself - I’ll need a few days as I am travelling on business this week. For now you will have to run it from the command line when you reboot.,
Hi Andrew. I just started using this awesome app. It really like what I have seen with it!
I believe I have run into a minor bug with regards to constrain_days in the configuration and use of Time Travel.
I specified a start time for early tomorrow morning / Monday (-s “2016-09-19 03:50:00”) but the apps with constrain_days = mon, etc. would not execute unless I added today’s day (sun) to the list.
It is easy enough to work around but want to let you know about it.
Thanks again for the great tool!
Ok, np. Take your time. I’m also traveling for work and I’ve learned not to mess with the system while I’m gone. Had my share of calls from the wife when she could not get the heat on or the lights kept going out…
p.s. from the file that is placed in init.d folder;
I have “DAEMON=/usr/local/bin/appdaemon” this was the only reference I was not 100% sure of as there are multiple locations ‘appdaemon’ is present. Is there a way to validate this or is it impossible that this is causing my issues?
Can you post your App please? Some care is needed when using :“Time Travel” …
As far as I can tell the init script is doing what it should, but AppDaemon is not correctly starting …
It’s a pretty simple app and I don’t think that is the cause.
Like I said I could influence the behavior by adding today’s day of the week to the constrained_days list in the configuration and it would work.
Looking at the today_is_constrained function in appdaemon.py, I see:
def today_is_constrained(days):
day = datetime.datetime.today().weekday()
daylist = [ha.day_of_week(day) for day in days.split(",")]
if day in daylist:
return False
return True
This code is not taking the Time Travel value into consideration when determining the day.
Please let me know if I misunderstand this. Thanks!
Yep, looks like a bug, you are right. I’ll take a look at a fix as soon as I can - which may be a few days.
Just about to push a new version with a fix for this - let me know if it is working for you.
Hi aimc,
Well done on your efforts, looks like it will serve the community well.
As a non programmer, how do you think us will fare with the task of using AppDaemon?
How much Python do you think is needed to migrate to this approach?
I’m all for learning something new, but often dont know how much I am getting myself into 
If it helps, I once did C++ programming… but it was around 15 years ago so probably no relevance anymore!
I think the answer to that is a community of Apps - there are already quite a few simple examples as well as the Occupancy Simulator which I am treating as a project in its own right as it is a little more complex. It is my hope that over time we can build up enough Apps that they cover what anyone would want to do - at least the common usecases.
The programming itself is not that demanding - if you understand the basic framework of registrations, callbacks and constraints, you dont usually need more than a few lines of code to achieve what you need.
Oh yes I read about your occupancy sim, in fact, it is how I got reading about AppDaemon. I am only about 5 days in on setting up my HA server so I got along way to go before I need more power AD will bring.
1 Like
I pulled down the change and retested. It looks good / works great. Thanks for the fix!
Excellent - thanks for reporting back
FWIW. I have seen the issue that Tyfoon is reporting a couple of times now.
I am using Ubuntu (16.04.1) / systemd startup
I only get the first line logged: “INFO AppDaemon Version 1.3.3 starting”
I have to do a: sudo systemctl restart appdaemon.service
…after the reboot to get AppDaemon to instantiate the apps.
Here is the contents of my /etc/systemd/system/appdaemon.service file:
#
# Sample unit file for systemd
#
# Edit top suit your environment, then copy to /etc/systemd/system
#
# run "systemd enable appdaemon" to make it start at boottime
#
[Unit]
Description=AppDaemon service for Home Assistant
[Service]
# ExecStart=/usr/local/bin/appdaemon
#
# If you are not using a default path for the config file use this:
#
ExecStart=/srv/hass/bin/appdaemon -c /home/hass/appdaemon/conf/appdaemon.cfg
#
[Install]
WantedBy=multi-user.targetThanks for the additional date - I’ll tak a look at this over the weekend when I have time to build a fresh PI install and check it out.
I am having issue of not getting called my state listener everytime, looks like it works for few times initially and then never gets called. Below is the details
.
- I have AppDaemon running on Windows 10 under Bash shell
- My HA is running on same network but on different computer which is running latest Ubuntu.
- What issue I am noticing is the status change for HA entity are not reflected here in my app which has listener set to receive the status updates.
a. It does call my callback for initial few times when status gets updated and then stops and no other status changes causes to call my callback.
b. There is no error in log (console)
c. I have added logging to prove my callback got called as well it sends PushBullet notification, and I don’t see any log or PushBullet notification.
d. My HA runs securely and I have ha_url set to use https but I have not provider cert_path in config file as you see in the code
e. I have automation trigger set in HA which occurs and sends me PushBullet notification which proves there was change in status but not from my AppDaemon app
f. I have set many listeners on different entities and none of them works after few times
g. While development I was just keep saving the python app file and AppDeamon was keep loading to get latest changes and I thought dynamic loading may be an issue and I tried stopping the AppDaemon and running again still same issue.
h. I have most of the sensor where I have listener set are templated sensor, what I mean is I have some kind of device which gives sensor data but that sensor has attributes that I want to monitor so I have set template sensor to pull that specific attribute and that works great in HA to trigger automation. - I have another app which is purely time based (every two hours) which calls my callback without any fail and works flawlessly.
- I have attached config and app file to review the code if I missed anything.
Config file:
[AppDaemon]
ha_url = https://myha.duckdns.org
ha_key = ******
logfile = STDOUT
errorfile = STDERR
app_dir = conf/apps
threads = 10
latitude = xxxxx
longitude = -xxxxx
elevation = xxxx
time_zone = America/Chicago
# Apps
[TestPushBullet]
module = test_pushbullet
class = TestPushBullet
[EcobeeAutomation]
module = ecobee_automation
class = EcobeeAutomation
App code:
import appdaemon.appapi as appapi
import datetime
class EcobeeAutomation(appapi.AppDaemon):
def initialize(self):
self.log("Starting EcobeeAutomation App")
self.listen_state(self.cb_dn_status, "sensor.thermostat_downstairs_current_status")
self.listen_state(self.cb_dn_fan, "sensor.thermostat_downstairs_current_status_fan")
self.listen_state(self.cb_dn_away, "sensor.thermostat_downstairs_away_mode")
self.listen_state(self.cb_dn_temp, "sensor.thermostat_downstairs_set_temp_ac")
def cb_dn_status(self, entity, attribute, old, new, kwargs):
msgStr = "cb_dn_status: old=" + old + ", new=" + new + " at " + datetime.datetime.now().strftime('%H:%M:%S.%f')[:-3]
self.log(msgStr)
self.call_service("notify/pushbullet", title = "AppDaemon", message = msgStr, target = "channel/somechannel")
def cb_dn_fan(self, entity, attribute, old, new, kwargs):
msgStr = "cb_dn_fan: old=" + old + ", new=" + new + " at " + datetime.datetime.now().strftime('%H:%M:%S.%f')[:-3]
self.log(msgStr)
self.call_service("notify/pushbullet", title = "AppDaemon", message = msgStr, target = "channel/somechannel")
def cb_dn_away(self, entity, attribute, old, new, kwargs):
msgStr = "cb_dn_away: old=" + old + ", new=" + new + " at " + datetime.datetime.now().strftime('%H:%M:%S.%f')[:-3]
self.log(msgStr)
self.call_service("notify/pushbullet", title = "AppDaemon", message = msgStr, target = "channel/somechannel")
def cb_dn_temp(self, entity, attribute, old, new, kwargs):
msgStr = "cb_dn_temp: old=" + old + ", new=" + new + " at " + datetime.datetime.now().strftime('%H:%M:%S.%f')[:-3]
self.log(msgStr)
self.call_service("notify/pushbullet", title = "AppDaemon", message = msgStr, target = "channel/somechannel")
Home Assistant sensor definition
- platform: template
sensors:
thermostat_downstairs_current_status:
value_template: '{% if states.climate.downstairs %}{{ states.climate.downstairs.attributes.operation }}{% else %}??{% endif %}'
thermostat_downstairs_current_status_fan:
value_template: '{% if states.climate.downstairs %}{{ states.climate.downstairs.attributes.fan }}{% else %}??{% endif %}'
thermostat_downstairs_away_mode:
value_template: '{% if states.climate.downstairs %}{{ states.climate.downstairs.attributes.away_mode }}{% else %}??{% endif %}'
thermostat_downstairs_hvac_mode:
value_template: '{% if states.climate.downstairs %}{{ states.climate.downstairs.attributes.operation_mode }}{% else %}??{% endif %}'
thermostat_downstairs_set_temp_ac:
value_template: '{% if states.climate.downstairs %}{{ states.climate.downstairs.attributes.target_temp_high }}{% else %}??{% endif %}'
thermostat_downstairs_set_temp_heat:
value_template: '{% if states.climate.downstairs %}{{ states.climate.downstairs.attributes.target_temp_low }}{% else %}??{% endif %}'it didnt even come up to me that it is possible to use appdaemon on another computer.
can you tell me why you chose to install it on another computer?
without appdaemon my HA only functions partly, so the 2 are 2 part from 1 working programm in my eyes.
i wouldnt want that to be dependent on 2 computers functioning.
My guess would be thread exhaustion from the pshbullet call not returning. Can you add a line to log a message after the pushbullet call in each callback and let me know if you see it? If my theory is correct, after each thread is used up, you have 10, the requests will start queuing up waiting for a free thread.eventually you should start getting log messages about thread starvation.
First thing first. Thanks a lot for the suggestion/question.
Here is my answer. I was trying to minimize the impact on production computer of Home Assistant as I wanted to explore the options. Once proven what I wanted to do I will move it to the same box. As I am not using python virtual environment on my HA computer and I already experienced the issue of from home user to root user force move due to system updates changing python/folders.
I can definitely try installing AppDaemon to HA computer and see. I think (being positive) it will work as I have noticed another AppDaemon app works which has only time based callback. Which kind of hints there may be network interruption causing the connection between HA and AppDaemon getting closed? Not sure though this is my theory. May be Andrew can tell more on this as it has active connection to HA server or not?
Let me try to move AppDaemon to same computer and see the results, I will come back and post the finding so it can help everyone here.
Thanks again