So I’ve made a small AppDaemon script that emulates a simple light and has enable and disable functions. Now how do I call it from a home assistant automation?
The easiest way is to have your yaml send an event that your appdaemon code is listening for.
Why do you want to call it from a home assistant automation?
How else would I turn my new light on and off?
In all likelihood, whatever you’re trying to accomplish with the YAML automation can be done directly within AD. What are your YAML automation triggers/conditions?
I don’t understand what you are trying to accomplish. You would turn on/off the light with an appdaemon app, otherwise I don’t see a reason to use appdaemon at all.
It can, but I would like to separate the light implementation from functions that control it. Currently all my automations are done in automations.yaml and I see no good reason to separate a single automation to a completely new place.
It would probably be better to implement this light as a new light platform in hass, but it requires like 5x more code and a lot of reading, didn’t have time to do that.
Could you please explain what you are trying to achieve? What exactly are you doing in appdaemon?
The AppDaemon part is a light implementation that sends http rest commands every 0.5 seconds when the light is turned on. I have a light that will turn off if you don’t send it wake up command within 1 second (led lights on home mini, I use them as a night light for bathroom)
I can’t do that with scripts because they don’t support tight loops, and can’t do that with python_script because I can’t import http requests there, so the only options I see are AppDaemon and implementing a new hass component
Can you please post you appdaemon code?
If I understand correctly you listen for the state of the light and as soon as it turns on, you send continuously a command to keep the light awake. And how do you determine when to stop the sending of the http commands? Timer based?
In current implementation I’ve introduced a new hass variable and listen for its changes
import appdaemon.plugins.hass.hassapi as hass
import requests
import time
class BathroomNightLight(hass.Hass):
def initialize(self):
self.enabled = False
self.log("Initializing bathroom night light")
self.listen_state(self.update, "variable.night_light")
self.loop(None)
def update(self, entity, attribute, old, new, kwargs):
self.log("Switching bathroom night light to %s" % new)
self.enabled = new == 'on'
def request(self):
url = 'http://172.16.x.x:8008/setup/assistant/set_night_mode_params'
data = {"enabled": False, "demo_to_user": True}
headers = {"content-type": "application/json"}
requests.post(url, headers=headers, json=data)
def loop(self, kwargs):
if self.enabled:
self.request()
time.sleep(0.4)
self.request()
self.run_in(self.loop, 1)
I still don’t get what you are trying to achieve. Your current code looks like an endless loop, but it would be better if you only trigger the loop once the light turns on and stop the loop once it should be turned off.
Does the variable.night_light tell when the light should be turned on/off? What is the logic for this variable?
And what kind of light is this, for me it doesn’t make any sense to have a light only staying on when you repeatedly send a command, what is the advantage of this? Am I missing something?
Indeed this loop can be optimized, but I will do it later. Variable is set to on when the light is on and to off when the light is off by an automation. It works, but for the future projects I want to know if there is a better way.
Constant requests to the light in order for it to stay on is the limitation of hardware, there is no way around it except flashing Google Home Mini with a custom firmware.
Ah now I think I understand, you use the led lights of the google home mini itself not some led strip controlled by the google home mini. Sorry for the confusion.
How is this variable set to on or off? Depending on time of day?
I don’t understand how your loop can work. You said that you need to constantly send a request every 0.5 s for the light to stay on. The loop sends a request then sleeps (by the way sleep should be avoided whenever possible) for 0.4 s then sends another request and then the loop will only start again 1 s later so according to your description the light would have turned off by then.
Technically home mini doesn’t allow to use its lights but I found that I can repeatedly set DnD mode with demo_to_user argument as a workaround.
Variable is set to on if motion is detected in the bathroom, sun is down, and the light in other rooms is off.
This loop has me wondering too. At first it sent only one request with run_in set to 0.5, but it appears that it can’t wait less than 1 second. Then I’ve set it to 1 sec, added a sleep and second request as a quick fix and verified that it worked correctly, but then I looked closer and was like “wtf, this shouldn’t work, the run_in should be moved to function start”. But it works for some unknown reason, so I left it as is. Voodoo magic right here.
I’ll rewrite the loop anyway so that it runs only when the light is enabled, I just need to learn how to do that in a thread safe way in python.
Why don’t you switch to appdaemon? 
Going forward it might be a better option, because it allows for more complex automations and in the future you possibly have more situations like the current one, in which you will not be able to do certain things with hass automations.
Can you add a log in the loop after each request? This way you can see in which frequency the requests get sent. I’d like to find out why this works, because it shouldn’t haha.
Oh I already did log the timings before when verified that it works:
appdaemon_1 | 2019-04-08 21:35:59.008756 INFO bathroom_night_light: Sending request
appdaemon_1 | 2019-04-08 21:35:59.442709 INFO bathroom_night_light: Sending request
appdaemon_1 | 2019-04-08 21:36:00.010552 INFO bathroom_night_light: Sending request
appdaemon_1 | 2019-04-08 21:36:00.439713 INFO bathroom_night_light: Sending request
appdaemon_1 | 2019-04-08 21:36:01.010400 INFO bathroom_night_light: Sending request
appdaemon_1 | 2019-04-08 21:36:01.437807 INFO bathroom_night_light: Sending request
appdaemon_1 | 2019-04-08 21:36:02.010392 INFO bathroom_night_light: Sending request
appdaemon_1 | 2019-04-08 21:36:02.439797 INFO bathroom_night_light: Sending request
appdaemon_1 | 2019-04-08 21:36:03.009539 INFO bathroom_night_light: Sending request
appdaemon_1 | 2019-04-08 21:36:03.435724 INFO bathroom_night_light: Sending request
appdaemon_1 | 2019-04-08 21:36:04.009891 INFO bathroom_night_light: Sending request
appdaemon_1 | 2019-04-08 21:36:04.437787 INFO bathroom_night_light: Sending request
appdaemon_1 | 2019-04-08 21:36:05.011371 INFO bathroom_night_light: Sending request
appdaemon_1 | 2019-04-08 21:36:05.447699 INFO bathroom_night_light: Sending request
appdaemon_1 | 2019-04-08 21:36:06.011438 INFO bathroom_night_light: Sending request
appdaemon_1 | 2019-04-08 21:36:06.439178 INFO bathroom_night_light: Sending request
appdaemon_1 | 2019-04-08 21:36:07.011844 INFO bathroom_night_light: Sending request
appdaemon_1 | 2019-04-08 21:36:07.441849 INFO bathroom_night_light: Sending request
appdaemon_1 | 2019-04-08 21:36:08.008938 INFO bathroom_night_light: Sending request
appdaemon_1 | 2019-04-08 21:36:08.437783 INFO bathroom_night_light: Sending request
I have no clue why though
What do you mean by switch to AppDaemon? Like write all my configs and automations there instead of yaml?
Hmmm, unless python_script starts supporting imports, this is exactly what will happen to HA (people will switch to appdaemon). I am in the same boat, I need to write a python script and export it as a service in HA. Apparently the only option is appdaemon (or maybe a script, but … that is really ugly). Now if I write my script in python/appdaemon, I can’t apparently easily export it as a service in HA, thus I cannot use the UI in HA (lovelace). Such a shame. Hopefully, someone can tell me I’m wrong here… 
HA is nice, but once you start writing complex automations, it is simply not enough, and w/o a viable python interface I doubt it will succeed…
No, it won’t because mostbpeople don’t have really complex automations and most of the time its solvable through HA automations but the people don’t know how or their logic is flawed. With the recent addition of features to automations/scripts it will also get easier to write complex automations/scripts in HA.
Sorry I don’t understand what you are trying to achieve. Can you explain a bit more please?