Oh, I’m sorry, I should have mentioned if it actually fixed my problem lol Yes, it worked perfectly. Today alone I was able to replace 12 automations with only 4 appdaemon Apps!!
1 Like
Excellent! Glad to hear it is working it for you 
Oh, btw, I forgot to mention this. The appdaemon API Docs say to use the following format for calling a service:
self.call_service(“light.turn_on”, entity_id = “light.office_lamp”, color_name = “red”)
self.call_service(“notify.notify”, title = “Hello”, message = “Hello World”)
However, dot notation does not work for calling services, rather forward slash notation has to be used
self.call_service(“light/turn_on”, entity_id = “light.office_lamp”, color_name = “red”)
self.call_service(“notify/notify”, title = “Hello”, message = “Hello World”)
If I use dot notation, appdaemon will throw an error.
All of my apps are using forward slash notation, but I don’t know why I would have done that in the first place since the docs say otherwise.
I’m not sure if you wanted it as “service.servicename” or as “service/servicename”, however, the slash notation is in all my apps and works fine, but the API documentation still says to use dot notation, which does not work.
in yaml it is dotted, but in the frontend with slash
i guess thats what made andrew go the wrong way at first and he forgot to change the API.
Correct - I changed it from “.” to “/” before I released v1.0, and I thought I had fixed the docs but I guess not Thanks for spotting that, I’ll fix it.
1 Like
Andrew, you are more genius than you think!
you know what i was trying to accomplish.
and i had it working
i made 2 apps.
1 to listen to minutes or to state change.
1 for general functions, which saved the times in different files that could be compared.
i made an commandlinesensor for all the objects i wanted to checkup on.
and after all the little bugs i had (some difficult to find) removed, i was satisfied.
it worked and finally without strange updates.
then i thought: havent i seen somthing about creating battery sensors automaticly?
i looked that up and started trying to make a custom component.
that would make it easier then creating lots of commandline sensors, dont you think?
i made something like the hello_state and i tried to update that component with your set_state (you know the problems i had with input_slider and template sensor)
and it works like charm.
so that gave me confidence to go on.
but i struggled.
i took a look at how template sensors are setup and tried to simplefy that.
i didnt get it working.
and suddenly there it was:
you dont need any sensor in the YAML!!
your set_state creates 1 and you can give it any name and platform you like and update it anyway you want.
off course you can set attributes to!
off course it is to bad from all my work, which i now can flush down the drain.
all you need is some code like this:
import appdaemon.appapi as appapi
import datetime
class objectcontrole(appapi.AppDaemon):
def initialize(self):
self.listen_state(self.object_controle, "input_boolean")
def object_controle(self, entity, attribute, old, new, kwargs):
update_time = datetime.datetime.now().strftime("%H:%M:%S")
self.set_state("controle_" + entity, state = update_time)
off course i can use small part from my work to save the time and compare it, so i can see time gone by.
but for now i’m starting to downsize again, because off you! 
That’s really cool, but I give the credit to Home Assistant for being so open and extensible
That’s a really neat discovery you made!
I am unable to use set_state on non existent entities. When I try to set_state on an entity that does not exist in Home Assistant, I get the following error:
2016-09-01 19:38:03,700 WARNING set_state: Entity battery_level.media_room_window not found in Home Assistant
** UPDATE **
Nevermind, not an issue… it gives a warning, but it still allows it to go through, so thats not a problem 
Thanks!!!
now you say that i see the warnings also.
and they keep on coming, even though the object is created, so the warning should dissapear.
it can be that the object misses a part which lets it be there, but not really be there.
maybe we could examine the set_state to see if it can made a bit better.
atrributes are not set in this case.
I’ll look into this -
Based on how AppDaemon is working I would expect the warnings to stop after up to 10 minutes or so -0 can you confirm if that is the case? Either way I’ll look at a fix so that it warns you the first time but not after that.
youre code checks if the entity exists. and it doesnt, even after that HA it displays, it still doesnt exist.
actually we are working with ghost objects.
fits the daemon part (but i have no daemons 
1 Like
Andrew
in your configuration you have
ha_key should be set to your key if you have one, otherwise it can be removed.
when I removed that line I received the following error on startup
Traceback (most recent call last):
File “/usr/local/bin/appdaemon”, line 9, in
load_entry_point(‘appdaemon==1.3.1’, ‘console_scripts’, ‘appdaemon’)()
File “/usr/local/lib/python3.5/dist-packages/appdaemon/appdaemon.py”, line 844, in main
conf.ha_key = config[‘AppDaemon’][‘ha_key’]
File “/usr/lib/python3.5/configparser.py”, line 1230, in getitem
raise KeyError(key)
KeyError: ‘ha_key’
leaving it blank works, maybe update the doc’s to:
ha_key should be set to your key if you have one, otherwise it can be left empty.
Thanks - I’ll fix that in the next release
this morning suddenly 12 times in 15 minutes i get the skew detected warning.
OK, I’ll look into it - it could be a delay in access to your HA instance, but I’ll need to look at the code in detail. Again, it isn’t harmful worst case your automation triggers will be delayed by the delta but it is self correcting. Could you send me a sample of your logfile please?
sorry, i have it at STDOUT
and i cant copy paste from my commandline screen.
all i can give you is this:
Was anything particular going on at that time?
After reviewing the code the only conclusion I have is that something maxed out the CPU and your timer thread slowed down - there is nothing in my code that would cause delays that regular without seeing other warnings, worst case I would expect to see one once every 10 minutes or so if access to your HA instance was slow.
cant get it back, but sometimes my wife lets google open with some websites that eat my machine alive.
could be that that was the problem.
nothing to worry about, but i thought i just mention it.
by the way 1 question:
is there a way to view from 1 app all args from all other apps?
i have a run minutly at the moment, and i want to let that 1 update other ‘sensors’ based on the args from other apps.
for instance i want to show the time left from every sunset automation.
i probably can use an info_listen_state and use a new set of args in the list from the run_minutly args, but i wonder if it can be more easy.
You can add self.args to your self.global_vars dictionary, indexed by the Apps name. For instance, in each initialize() you could have:
self.global_vars[self.name] = self.args
Then in another App for instance called App1 you could access them with:
app1args = self.global["App1"]
oke so if i put the global_vars in every init i could find every offset through:
for arglist in self.global:
if "offset" in arglist:
#this is an sunset automation
off course only if i use the offset arg only in sunset automations