seems like you ran into a little bug.
Not a bug 
From the docs:
repeat
After the initial callback has occurred, another will occur every repeat seconds.
However, the example is incorrect, apologies.
You are supplying it with a timedelta object which is not what it is expecting - it is expecting a plain integer.
try:
self.run_every(self.event, timer, 15 * 60)
1 Like
Thanks! Working like a charm.
1 Like
My AppDaemon instance stopped sending notifications since yesterday night about 12:38:04 am. I noticed none of the state change listener was getting called. Below is the log and I didn’t see any error in the log. When I did Control+C on the terminal which was running AppDaemon it logged “2016-10-12 21:43:05.706579 WARNING Not connected to Home Assistant, retrying in 5 seconds” But I think it does every time when we do Control+C to stop it, actually to stop I do twice.
Once I did that it started working. It will be nice to have “event” (like what we have homeassistant_start, homeassistant_stop etc) in case of communication link breaks down (for whatever reason) with HA so we can send notification.
This has happened two times so far and as I have moved all automation to AppDaemon it makes really difficult and everything goes down. One thing still I can say that all my time based automation works perfect just not the state change callbacks.
By the way I was running one lower version of AppDaemon 1.3.4 and now I have upgraded to the latest 1.3.6 but I didn’t see anything got fix in this version regarding the issue I saw.
In the log last 3 items: 8:29:52, 16:56:39 and 17:56:40 are time based (sun based) callbacks not the state changes.
2016-10-12 00:00:06.589608 INFO EcobeeTracking: reset_values()-up-before: done
2016-10-12 00:00:07.791498 INFO EcobeeTracking: reset_values()-up-after: counter=0, run time=00:00:00, last cool=None, old state=idle, new state=idle at 00:00:07.791
2016-10-12 00:00:09.194133 INFO EcobeeTracking: notify_pb(): type=103, title=AppDaemon, msg=reset_values()-up-after: counter=0, run time=00:00:00, last cool=None, old state=idle, new state=idle at 00:00:07.791
2016-10-12 00:00:09.194856 INFO EcobeeTracking: reset_values()-up-after: done
2016-10-12 00:14:01.726289 INFO EcobeeTracking: notify_pb(): type=101, title=Home Assistant, msg=Ecobee upstairs thermostat is cool : 00:14:01.103
2016-10-12 00:14:02.659210 INFO EcobeeTracking: callback_up(): counter=1, run time=00:00:00, last cool=2016-10-12 00:14:02.362256, old state=idle, new state=cool, executitonPath=1 at 00:14:02.659
2016-10-12 00:14:03.304380 INFO EcobeeTracking: notify_pb(): type=103, title=AppDaemon, msg=callback_up(): counter=1, run time=00:00:00, last cool=2016-10-12 00:14:02.362256, old state=idle, new state=cool, executitonPath=1 at 00:14:02.659
2016-10-12 00:14:03.304775 INFO EcobeeTracking: callback_up(): done
2016-10-12 00:38:01.757808 INFO EcobeeTracking: callback_up(): counter=1, run time=00:23:59, last cool=2016-10-12 00:14:02.362256, old state=cool, new state=idle, executitonPath=3 at 00:38:01.757
2016-10-12 00:38:04.564657 INFO EcobeeTracking: notify_pb(): type=103, title=AppDaemon, msg=callback_up(): counter=1, run time=00:23:59, last cool=2016-10-12 00:14:02.362256, old state=cool, new state=idle, executitonPath=3 at 00:38:01.757
2016-10-12 00:38:04.565294 INFO EcobeeTracking: callback_up(): done
2016-10-12 08:29:52.214322 INFO PorchLight: notify_pb(): type=103, title=Home Assistant, msg=Turning porch light off : 08:29:50.356
2016-10-12 16:56:39.618232 INFO LivingroomLight: notify_pb(): type=101, title=Home Assistant, msg=It's almost dark out, turning on the living room light : 16:56:38.907
2016-10-12 17:56:40.331697 INFO PorchLight: notify_pb(): type=103, title=Home Assistant, msg=Turning porch light on : 17:56:39.238
Thanks
notify is a service and i also have the problem that after some restarts my service doesnt work.
i didnt say anything here because i am not sure where the problem is.
it could be that the service in HA isnt called or that HA doesnt send it to my serial port or that my serial gateway doesnt send it out.
all 3 parts are hard to check.
but this let me think that there is a hangup in appdaemon somewhere.
after 1 or more restarts the problem disappears again.
SOunds like the event stream from HA went down but AppDaemon didn’t notice - the code is in there to check and reconnect automatically but for some reason it isn;t getting called.
Couple of questions:
-
What platform are you running on?
-
Next time this happens can you check and see if the HA Front End is affected? Maybe trip a motion sensor or something and check if it shows up in the Web App.
rethinking about it, cant my problem be the same.
my eventstream stays up, only the service doesnt work.
i just cant pinpoint it, because all other sensors from mysensors keep updating.
i will see if i can get the HA log to give me more details about when and how the service is used. (without an overload of other information)
I can tell for sure that HA is up and running as usual no issue, see answer 2 for more details.
Here is one more thing I would like to mention to @ReneTode that I am not using notification service from HA to send notification but I use AppDaemon app which uses pushbullet.py https://pypi.python.org/pypi/pushbullet.py. Idea is to leave HA alone and don’t overload with notification service calls. I am sure this works great and not causing any issues to AppDaemon. I have proved that in some situational AppDaemon looses connectivity with HA and then no longer status change callback in AppDaemon until restarted.
As I mentioned earlier post it is nice if we can have event which gets fired when AppDaemon looses the connectivity with HA, not sure though how simple/easy it is? And not sure how AppDaemon gets connected to HA using sockets or something else?
Thanks all for the help and time.
thx for mentioning that you use another way to notify.
then you are not using a service and that means that my problem is for sure not related.
i guess i will find out at one time what it is causing, but right now my gut says its not appdaemon. (thats why i didnt mention it before)
Then I think if you do like what I do to send notification then your problem may go away, that’s good news.
I can share the details how to use pushbullet as an app for AppDaemon to send notifications if you wish.
Thanks
untill now i have no notify from any kind.
i did look around a little but havent found anything i really like.
at this moment is the only smartphone we have from my wife.
dont want to annoy her with messages for me 
i just checked out pushbullet, but i think i would need more then 100 msg pro month, so it would cost me to much.
i would prefer a notifysystem which is own network only, but i’m afraid that isnt out there.
Make sense about not to push unwanted notifications to your wife!
About pushbullet, here is little secret if you use channel push then there is no limits per month and it’s free
I am using it since long even after their policy changes pushes for channel are still free and no limits. May be in future it may change.
AppDaemon already has an AppDaemon restart event, but it would be interesting to add another loss of connectivity event to see if this gets fired. As far as I remember though, the scheduler stops as well when it loses contact with HA which is not happening here. I think the problem is though that AppDaemon doesn’t notice or you would be getting messages about retrying to connect in 5 seconds, which means it is unfortunately out of my control. I will take a look at the code and see if there is any additional debugging we can do, or if I missed something
@aimc, I was reading blog at Home Assistant about stream update and he mentioned that HA server sends heartbeat signal called “STREAM_PING_PAYLOAD” and client SSEClient can watch for it and if doesn’t receive in certain time reset the connection to HA and retry. Do you think this can help? I am not sure you may be already doing this but I couldn’t find in the file appdaemon.py
Thanks
FWIW, I am running on an almost identical platform, but I am not seeing this issue …
At the moment I am just ignoring the pings, but I am seeing them:
if msg.data == "ping":
return
The problem I have is that there is no way to cleanly terminate the connection that I know of due to the way the Python SSEClient library works, but I’ll have a look into it.
Oh ok, I missed that as I was searching the const/define term rather then data it self. So the method/function process_message() can reset the timer each time when it sees the “ping” and main loop will see if time reached certain threshold then reset the connection by reconnecting it.
Hope I am not sounding that this is easy fix/update as Python is new to me even though being c/c++ developer for more than 20 yrs.
Thanks
I just saw your another post about terminating and re-establishing the connection is not easy 
Yep - your suggestion above is exactly what I would have done except that the SSE client is a generator that blocks until the next message arrives. It should error out if the connection goes down and I handle that, but it seems like the stream is just stopping without causing any error I can react to. I am currently reviewing the SSEClient code looking for enlightenment …
1 Like
OK, I think I am going to pull the SSEClient code into AppDaemon so I can instrument it better and get some logging going. SSECLient itself has a retry mechanism but I don’t have visibility to what it is doing without some extra logging - I will probably remove the retry logic as it doesn’t seem to be working very cleanly (I have had other behavior which makes more sense now I see this).
It will take me a fwe days to find the time to do it, then I will send out a new version with some better logging and hopefully we can get to the bottom of this.