i think that if there is an option to change names from other parties, or use other ways to avoid double names, there is no reason to create breaking changes.
there will always be third parties that use the same names, for sure when it gets to things like “events, entities, new, old, attributes, etc” in an automation development.
it could very well be that if Andrew changes it to “event_name” then some other components will get a problem, because they use event_name in stead of event.
Absolutely. It’s a mine field. And this is my own fault not thinking of it since I do use appdaemon. Just never tried events before.
I guess it might be more appropriate for me to rename the event to button_event or press or something similar
i didnt get that you are the third party 
isnt that event also in the attributes?
or could you add it there?
then there wouldnt be a need for listen_event at all and noone would have to have breaking changes.
Unfortunately no. The remotes are only exposed as events so someone have to make a change
This is the way to go I think - the filtering function of listen_event() is optional - you will still get the callback, and you simply need to use an if statement in your callback to check the id and event entries in the data parameter that AppDaemon supplies to you.
It’s a couple of lines more code, but no one has to make any breaking changes 
Excellent!
There is no performance penalty in this?
Not really - the filtering is just a convenience function - either way there is an if/then evaluation either implicitly in the appdaemon code if you specify the additional arguments and they match fields in the event data, or in the app where you are handed a complete set of the event data anyway.
@Try2Fly would you be willing to post a full AD example of this? Either here or as an PR for the component documentation. Would be really nice to have an AD example in the documentation.
Yeah sure, this is a AD example that works, loosely based on this script, or do you mean a more basic version?
import appdaemon.appapi as appapi
import time
class dimming(appapi.AppDaemon):
def initialize(self):
self.listen_event(self.button_pressed, "deconz_event", id = "lumisensor_switch" )
self.table_hold = False
self.table_dim = False
def button_pressed(self, event_name, data, kwargs):
self.click_type=data["event"]
if self.click_type == 1000:
if self.table_hold == False or self.get_state("light.table") == "off":
self.table_pressed = False
self.toggle("light.table")
self.table_hold = False
if self.click_type == 1002:
self.table_pressed = True
time.sleep(0.3)
self.table_hold = True
if self.table_pressed:
self.long_press()
self.table_dim = not self.table_dim
def long_press(self):
if self.table_dim == False and self.table_hold == True and self.get_state("light.table") == "on":
while self.table_hold:
self.new_brightness = self.get_state("light.table", "brightness") + 25
if self.new_brightness >= 255:
self.new_brightness = 255
self.turn_on("light.table", brightness = self.new_brightness)
self.table_hold = False
elif self.table_dim == True and self.table_hold == True and self.get_state("light.table") == "on":
while self.table_hold:
self.new_brightness = self.get_state("light.table", "brightness") - 25
if self.new_brightness <= 0:
self.new_brightness = 6
self.turn_on("light.table", brightness = self.new_brightness)
self.table_hold = FalseThat works! Thanks! Do you have a config example to go with that?
what do you mean? config of the lights or button? Those are just loaded from the deconz component.
I used to toggle the light with this automation, but I couldn’t get the dimming working within yaml in a correct way.
- alias: toggle table light
trigger:
platform: event
event_type: deconz_event
event_data:
id: lumisensor_switch
event: 1000
action:
- service: light.toggle
entity_id: light.tablebtw chances are that the event codes 1000 and 1002 for pressed and released will be swapped in the next version of the deconz rest api, as this is now a pull request.
I will correct that for the example so it is default behavior for all devices.
Regarding config I mean the app daemon config for the app
ah thats nothing special as this is the only script I’m running with appdaemon (so far)
appdaemon config:
AppDaemon:
logfile: STDOUT
errorfile: STDERR
threads: 10
app_dir: /config/appdaemon/apps
HASS:
ha_url: HASS url
ha_key: "password"
apps.yaml:
dim_app:
module: dim
class: dimming
where the name of the file with the dimming script is dim.py
Aah, I expected that you define the remotes name in the config.
No, only use it for one light and one button. In my present setup if have no need for multiple dimmers (yet).
I’m just finding out and learing programming in python as I go.
Hi @Try2Fly i’m new to AppDaemon, to use your script i need something like automation? I installed and configured Appdaemon, changed the light name but it doesn’t work
to use apps with appdaemon you need to configure every app.
to understand how appdaemon works you can read this:
when you read and understand what is written there, the you will understand how to implement apps and change settings.