Hey all. This is going to sound like a really stupid question. But I’ve been over the documentation many times and just still don’t get how this actually ties into Home Assistant. I’m sure I’m missing something stupid, but I just don’t get how events from Home Assistant trigger functions in AppDeamon. Or how AppDeamon see events. Or whatever. Is there some post somewhere that has a complete step-by-step guide to setting up something simple to wrap my head around the interaction?
There are some tutorials to get started here at the “Appdaemon” category.
Here is one example.
2 Likes
In addition, just to explain the how part, AD polls the HA server on a regular basis for updated states. That’s how HA triggers functions on AD.
AD has a setting in the options for your HA URL and Password. It uses these to talk to the HA via HA’s API.
I don’t think this is technically correct. HA receives all the events from the HA event bus from the websocket api. No polling is involved.
3 Likes
Actually, I believe you are correct. I must have been thinking back a few versions. Thanks!
1 Like
@danichispa - Yeah I get Python, and I code in it regularly, but I still don’t get the tie into HA. So I write this automation to make the lights come on 60 minutes before sundown - and it works without issue:
- id: turn_on_living_room_when_sun_sets
alias: Turn on living room light when sun sets
trigger:
platform: sun
event: sunset
offset: "-00:60:00"
action:
service: switch.turn_on
entity_id: switch.living_room_37
So I re-create this in AppDeamon with a Python class. And it just what, works like magic? How do I get sundown? How do I get 60 minutes before sundown? How do I turn the light on? How does AppDeamon interact with HA?
@gpbenton - That still doesn’t help me understand WTF I’m actually supposed to be doing to trigger things and make AppDeamon work. Or how things get called from HA to AppDeamon, or the other way around.
I just don’t understand the interaction here, and how I deal with that in my automations.
Ugh I just don’t get how I make things flow from HA to AppDaemon? Do I call it some way? How does it know when its 60 minutes before sundown? How does it interact?
Appdaemon connects to HA, when you configure it via appdaemon.conf, with your HA url, api pass, etc. Then you can use all info in HA to make appdaemon work.
Based on your example, if HA knows when sunset or sunshine is, AD knows too, so you can use AD’s run_at_sunset to trigger an action on sunset, e.g.
Take a look at API.md on AD github to see all avaliable functions.
Also you can read the tutorial on AD github too.
I think you need to read the appdaemon API
https://github.com/home-assistant/appdaemon/blob/master/API.md
Perhaps this is the part I’m not getting. So you connect AD to HA, I got that. Then what do you do in HA to trigger AD to fire events? What config is needed from the HA side? And how does AD manipulate things in HA (like lights)?
You don’t need to do anything special in HA. Just “use” it normally.
Then in the AD apps is when “magic” happens.
Just a very basic example. When our family group (group.familia) goes to not_home in HA, AD gets that info and turns on the motion detector on a Foscam cam (switch.foscam_motion), and back to off when we came home.
This controls a switch, but it can be a light, or set a scene, etc.
import appdaemon.appapi as appapi
class DetectorFoscam(appapi.AppDaemon):
def initialize(self):
self.listen_state(self.foscam_motion, "group.familia") #here you tell AD to listen group.familia states on HA
def foscam_motion(self, entity, attribute, old, new, kwargs):
if new == "home": #if we came home (new state of group = home)
self.turn_off("switch.foscam_motion") #AD turns off foscam motion detector
elif new == "not_home": #else if we go outside (new state = not home)
self.turn_on("switch.foscam_motion") #AD turns on foscam motion detector
Yes, this can be done easily with HA automations, but there’s a moment when you need more complex automations and HA can’t reach where AD does.
2 Likes
Ok this helps a ton. So once AD is connected to HA there is NOTHING that needs done from the HA side? I think this is where I was getting confused, I kept thinking something needed to happen on the HA side to trigger things in AD.
In most situations, you’ll do everything on the AD side.
There are some cases, like some of @turboc’s apps, where I’ve had to create a specifically named sensor or a grouping may need to be made on the HA side, but that will be in very few cases. For the most part, AD is just sucking in data from HA and processing it.
1 Like
From what I understand (and this may not be technically correct (wrong verbiage), but the right spirit I think) When something happens in HA, it places an event in a “event buss” or queue of sometype. HA uses this to allow other components and automations to decide if they need to know about that event and to act on them. AD just ties into that buss and uses it to trigger callbacks in AD. Those callbacks, are your “business logic”. When they decide something needs to be done, they effectively through helper functions in AD, put other events on the event buss in HA for other HA components to act on.
So
The Den light switch gets manually turned on.
HA Realizes this, and places an event on the buss saying the den light turned on.
As a result other HA automations trigger and AD sees the event on the buss.
If an AD app, has registered a callback against that light, the callback gets called.
The call back goes through it’s “business” logic and decides that the kitchen light should be turned on too.
AD calls a turn_on(entity) function that in turn essentially calls the HA service to turn on a light, which in turn places the Kitchen light turned on, onto the buss for other apps and automations to trigger against.
There are tons of helper functions in the appdaemon api, that shield the nuts and bolts of interfacing with HA from us.
As for what Rpitera was talking about with my apps. If I’m doing something that acts against multiple objects, instead of hard coding them into a config file, I tend to build a non-view HA group and just read the group membership. That way I don’t have to restart anything when I add a new items to the list.
For example:
I have a roomba that runs at 11:30 every night. Well Roomba needs light to see to run, so at 11:30 every night I have certain lights in the house turn on. I could have put that list of lights into a config file, or hard coded them into the app. But instead, I put them into a non-view group in HA and just have the app read the objects in the group. That way, If I decide we want roomba to start cleaning the dining room, I can add the light to the roomba_group in HA, and those lights will now turn on at 11:30, and turn off again at 1:00 with the rest of the roomba lights. It’s just an app design feature and really doesn’t have anything to do with how HA and AD work, it just takes advantage of the visibility into HA that AD gives us.
4 Likes