Changed the network to host and that resolved it.
1 Like
That was painless, thanks for all your hard work! One thing I wanted to point out in DASHBOARD.md you still have a reference to dash_url = http://192.168.1.20:5050 with a ā=ā instead of a ā:ā Took me a few minutes to figure out why appdaemon was bombing 
Aha - thanks for pointing that out, fixed!
I would be great that whenever you post an announcement about a new release, there could be a pointer to the git repo or other next step on how to fetch and install the software. Iām new to appdaemon and canāt obviously find the āhow to get startedā post. Having a āsticky postā with this info would be great starting point.
1 Like
OK, I included a link in the top post.
1 Like
Thanks for the pointer; I didnāt think it would be within the HASS documentation pages since this was a āThird party integrationā 
Can AppDaemon expose a service to the rest of HASS? I have been thinking about an alternative to homeassistant.turn_on which could be used for timed and preemptable changes to devices.
Iām thinking of cases where some event happens (eā¦g, front door gets unlocked). Iād like to turn on the foyer light for 5 minutes, and then have it restored. I was thinking of trying to encapsulate this within a service that could maintain the previous state, perhaps in a stack with some priority/preference and restore the state of the light when the interval expires. This might be done as a stack, with some duration specified. So if I happened to āmanuallyā turn the light on, having the automation trigger wouldnāt turn it off after 5 minutes; it would be restored. And during that 5 minute interval, if some other automation wanted to flash the light, that would happen, and the state would restored to the 5-minute on state.
Iām thinking that implementing this as a service with extra parameters (duration, priority) would be easy to do, and since the event bus would be monitored, I could see other calls to homeassistant.turn_on and treat that as a high priority, indefinite duration state change and still play well with this other scheme.
Probably I could do this within HASS as a component, it might be easier to prototype/debug externally within AppDaemon.
Not exactly but you can do something very similar.
Both AppDaemon and HASS support custome events. An event can be whatever you want and can have an arbitary number of arguments - it is very similar to a service call and can be used in Automations both to listen for and explicitly fire, so you can easily integrate AppDaemon and Hass automations in this way.
Check out the docs for more info.
Thanks, thatās very helpful!
1 Like
I do something very similar in a couple of my automations. Actually with my front door, I do exactly that. I have a Ring doorbell. When the doorbell rings, I turn on the entryway light for 15 minutes. I do this by listening for the doorbell ring event. When I see that event I turn on the light and then setup a callback to turn it off in 15 minutes. You could easily pass the initial state of the light to the callback function in the kwargs parameter list, then in the callback, just set the light back to that state.
@turboc, Iām trying to think of a more generalized solution. I the light is already on (for some reason), I probably donāt want to turn it off. If after turning the light on, if some other action happens where thereās a deliberate action on behalf of the human that results in the light being turned on for 3 hours, I donāt want to turn it off after 15 minutes.
I need to think a bit more about the semantics and rules, but I know thereās a stack of previous state in there, influenced by some sort of preference or priority where deliberate actions override the effect of automated effects.
So stepping on the porch probably turns on the porch light for 5 minutes, but successfully unlocking the door would turn it off right awayā¦ except if the human pushed the turn on the porch light button where it should just stay onā¦ Rather than try to spread the logic of this all around a bunch of automations, I think the action of turning on the light could also carry an indication of what could preempt the (time) action.
Or I could just be barking up the wrong tree and trying to invent something too complicated. Wouldnāt be the first timeā¦
What Iāve found in my automations is to think of things from the perspective of the light (or the device being automated), when something touches it, let it look out at the things that might influence itās behavior and make the decision on what to do.
One of the issues though that we have run into, is that we donāt have a good way of knowing whether something turned on as a result of a person flipping a switch, or an automation or switch in HA turning the light on. Even if you move all your automations to AD, you still have the issue of not knowing if the light was turned on by someone in the HA UI, or physically turning on the light. That ambiguity makes it difficult to know whether you are dealing with a person that would override the automation or another automation that can be overridden.
Another thing I do is assign each of my devices that might impact a device I am automating a bit and then make a mask out of the current state, then I build a list of the associated states with either a turn on list, or a turn off list. If the current state mask is in the turn off list, then I turn off the light, if itās in the turn on list, then I turn on the light. It makes the code very simple, the hard part is when you have several devices that impact one light, the turn_on/turn_off lists get pretty long.
Again, thatās just what Iāve found that makes sense to me. But do whatever makes sense to you since you are the one thatās going to have to maintain it.
I do process automation for a living, in general you should apply KISS wherever/whenever possible. The more what ifs and random scenarios you come up with the more complicated it becomes and youāll never get to the end of the list. Bottom line is the operator will always screw it up if you let them. Either its all auto all the time or you train your house occupants on how to run your system. You can usually come up with a few scenarios that fit your household but as said there are infinite ways in and out of the situation you find yourself inā¦ Even as simple as if the light is on and why and now what do I want to do with it? That being saidā¦ I do the same damn thing because itās cool and I can, my wife is usually not amused though.
there is a way to find that out and take actions based on what did turn on the switch.
take a switch in HA called switch.livingroom for example
i can expose that switch directly to Alexa and let Alexa turn on that switch
i also can use a remote and based on some button turn on that switch
i can turn it on in HA or
i can turn it on on the wall.
4 ways to turn on 1 switch and if it is switched i want to know what switched it on.
to do that you need to create some general variables or some input booleans.
lets go with the input boolean option.
create input_boolean.alexa_livingroom and expose that to Alexa instead of exposing switch.livingroom.
create input_boolean.remote_livingroom and connect that to a remote code
create input_boolean,ha_livingroom and hide switch.livingroom.
listen to the 3 booleans and to the switch.
if Alexa boolean is turned on, turn on the switch. you now know that Alexa turned on the switch from that moment on.
if HA boolean is turned on the same, and also for the remote boolean.
if the hardware switch is turned on only the switch is turned on and no boolean.
in the different listen_state callbacks you can make different decisions based on how the switch was turned on.
you can also create a history for the switch, so you can make different action when the switch is turned on through Alexa after it was switched on through hardware then you would when its turned on through Alexa after it was turned on by HA.
i have tts message for some switches. it announces if Alexa, remote or automation turned on a switch.
Obvious its a lot off extra programming, but if you want different actions for different situation, they have to be programmed.
1 Like
Yes, thatās a way to do it. There was conversation at one time though about having HA trap whether it initiated the call to turn on/off a light, whether it found out about it and just updated itself to match reality, or whether it was turned on by a HA automation script, or external automation. In addition we would be able to do something from AD to flag that the light was turned on by AD automation and which one turned it on/off. We could do something like you said, but like you also said, it a lot of extra programming and configuration for each device. It would be nice if it was a part of AD/HA.
the biggest part from the programming is still the different responses for the different actions, but it would be more easy to make functions general.
another way to go is to adapt the components you want to use.
copy the switch component you use to custom components and catch where the action is coming from there and add it to the component as a attribute.
after doing that you can read and use the attribute in AD.
you only need to keep in the back of your mind that if the component is updated, that you need to make the update manually yourselve (if you wish that update)
you probably need to update a few components for it but it is possible.
Thanks for the hard work getting the official release out!
Iāve been messing around with HADashboard in Docker, running it behind my nginx reverse proxy. Last night I was able to set things up using the official release rather than my fork.
Docker command to launch appdaemon:
docker run --name=appdaemon -d -p 5050:80 \
--restart=always \
-e HA_URL="http://docker.noisufnoc.net:8123" \
-e HA_KEY="correcthorsebatterystaple" \
-e DASH_URL="http://hadashboard.noisufnoc.net" \
-v /dockervol/appdaemon:/conf \
acockburn/appdaemon:latest
Nginx config for vhost
server {
server_name hadashboard.noisufnoc.net;
listen 80;
location / {
proxy_pass http://docker.noisufnoc.net:5050;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
}
}
Iām still testing, but it seems to work well. All the calls on the dashboard are being proxied through nginx, which is fine for something like this IMHO.
2 Likes
I have also, after some thought, followed the principle of grouping logic that affects one (or several related) actuator together, such as lights or ventilation. This approach has worked very well for me. I also decided that the automation should back off as soon as it was manually overridden, whether it be from a physical switch or through an app, and automatically regain control after a period of inactivity. I implemented this on my Fibaro HC2 (LUA scripts) by checking if the actuatorās value has changed from the desired automatic value.
When re-implementing similar light control in Home Assistant, I faced an issue where the entityās state was not exactly what I set it to - possibly due to some rounding/scaling/resolution in the device. I also got āintermediateā values when changing - e.g. if I commanded a light from 0 to 70%, I would get a state change to e.g. 40% before it reached 70% (or maybe 71%). This made manual override detection harder.
Design patterns and high-level logic in automations are very interesting topics, maybe it should be split to a separate thread?
The intermediate levels is a problem with the design of the ālightā switches. Normal non-dimming āswitchesā donāt have that problem obviously. On some of the switches, there is an option you can reach through the zwave configuration of the node that lets you adjust the transition or ādimmingā rate. Speeding that up, has greatly reduced the issue with intermediate values I was encountering.
There are some situations where I found that grouping things like you said is a good idea. Iāve also had a good bit of success focusing on the individual light. For example, I have one app that monitors the ceiling fan and associated light kit in each of our rooms. It registers the triggering events that impact itās status. It either turns the light on/off/dim or simply ignores the event depending on itās status and the status of other sensors/devices.
upgraded everything tonight. I went to python 3.6, latest release of HA, latest release of AD. Everything is working (sortof). Iām getting a clock skew detected message with a delta of approximately 1 second every second. Then it will go off and do something, but then it comes back.
Did you pull from the dev branch? Iāve been working in that area recently.