Would be nice if it was possible to manage OTA updates through it as well (Y)
Managed to sort out the hold down dimmer buttons but on rare occasions it looks like deconz doesn’t get the event for release, so it keeps looping even though the button has been released physically. I think this may be deconz/rest api though, not necessarily an issue with the component. I leave this horrible extract here for anyone else, just in case.
automations.yaml:
- alias: 'Constantly increase brightness of lamp from dimmer until released'
initial_state: 'on'
trigger:
platform: event
event_type: deconz_event
event_data:
id: remote_control_1
event: 2001
action:
service: script.turn_on
entity_id: script.increase_lamp
- alias: 'Stop increasing brightness of lamp when dimmer is released'
initial_state: 'on'
trigger:
platform: event
event_type: deconz_event
event_data:
id: remote_control_1
event: 2003
action:
- service: script.turn_off
entity_id: script.increase_lamp
- service: script.turn_off
entity_id: script.increase_lamp_loop
- alias: 'Constantly increase brightness of lamp from dimmer until released'
initial_state: 'on'
trigger:
platform: event
event_type: deconz_event
event_data:
id: remote_control_1
event: 2001
action:
service: script.turn_on
entity_id: script.increase_lamp
- alias: 'Stop increasing brightness of lamp when dimmer is released'
initial_state: 'on'
trigger:
platform: event
event_type: deconz_event
event_data:
id: remote_control_1
event: 2003
action:
- service: script.turn_off
entity_id: script.increase_lamp
- service: script.turn_off
entity_id: script.increase_lamp_loop
scripts.yaml:
increase_lamp_loop:
alias: Start looping brightness increase
sequence:
- delay:
milliseconds: 650
- alias: Call increase brightness script
service: script.turn_on
data:
entity_id: script.increase_lamp
decrease_lamp_loop:
alias: Start looping brightness increase
sequence:
- delay:
milliseconds: 650
- alias: Call decrease brightness script
service: script.turn_on
data:
entity_id: script.decrease_lamp
increase_lamp:
alias: Increase Lamp
sequence:
- alias: Increase Lamp Brightness
service: light.turn_on
data_template:
entity_id: light.lamp_2
brightness: >
{% set bri = states.light.lamp_2.attributes.brightness | int %}
{{ [bri+30, 249] | min }}
- alias: Call loop script
service: script.turn_on
data:
entity_id: script.increase_lamp_loop
decrease_lamp:
alias: Decrease Lamp
sequence:
- alias: Decrease Lamp Brightness
service: light.turn_on
data_template:
entity_id: light.lamp_2
brightness: >
{% set bri = states.light.lamp_2.attributes.brightness | int %}
{{ [bri-30, 0] | max }}
- alias: Call loop script
service: script.turn_on
data:
entity_id: script.decrease_lamp_loop
Probably not the nicest way of doing it and i’m sure you can make it cleaner with templating, i’m just not too hot on that 
Yeah, it shouldn’t be the component. In this case at least
You can look at doing automations in the python support in HASS or by using Appdaemon if you want to. Way better than yaml automations if you want to do anything more than turning on or off a light
I’ve just removed the WIP status from the PR for both documentation and component. Let’s hope there aren’t too many additional comments. Thanks for the support so far! 
Based on a comment in the PR about certain motion detectors only sending an event when detecting movement. This will not work well with the current implementation.
Im considering managing that manually for the ZHAPresence class by keeping a timer of 5 or 10 seconds from presence=True and when timer has ended automatically set presence=false unless timer is restarted due to additional movement. What do you think about this?
Never mind… Manup solved it upstream in deCONZ instead 
Hi,
too bad that the PR was not merged in time. I had an improvised solution running based on a different component (that could not handle temperature sensors though) and hoped to be able to play with the new shiny component over the holidays.
So, I looked into somehow merging the component myself. Since I’m running HA in a docker container I could not replace the files manually. So I came up with a custom Dockerfile that is based on the official one and just adds files and prerequisites to it. Works fine so far. In case anyone is interested, the dockerfile looks like this:
FROM homeassistant/raspberrypi2-homeassistant:latest
RUN pip3 install pydeconz==21
COPY ./components /usr/lib/python3.6/site-packages/homeassistant/components
All source files related to the component (taken from PR) need to be in a subdirectory “components” of the directory where the Dockerfile is. The complete file list is:
./Dockerfile
./components/scene/deconz.py
./components/sensor/deconz.py
./components/deconz/services.yaml
./components/deconz/__init__.py
./components/light/deconz.py
./components/light/hue.py
./components/binary_sensor/deconz.py
./components/discovery.py
Now events, temperatures, motion is detected perfectly and available in HA.
Thanks for your work!
Happy holidays
Jochen
1 Like
One more thing: I noticed a typo in the documentation PR:
In one section it says:
+- **host** (*Optional*): The IP address to your deCONZ server.
+- **api-key** (*Optional*): The API key to your deCONZ server.
+- **port** (*Optional*): Configure port deCONZ web server is accessible from. Default is 80.
But in the example, the api-key becomes api_key. Only the latter one works though.
+# Example configuration.yaml entry
+deconz:
+ host: 127.0.0.1
+ api_key: 0123456789
+ port: 80
1 Like
Thanks! Good catch! Will fix that
Nice! I might do a docker image like that myself so I can start migrating my lights from hue to deconz.
BTW do abybody have docker for Deconz Server?
We’re working on it, but there isn’t an image that works correctly yet. If you google there are a few options that “work” but at the expense of being able to do firmware updates etc.
Hey,
I think I found another bug (or at least inconsistency) related to entity names.
I have several Aqara temperature sensors resulting in 3 entities in HA:
Today, I added a Xioami Mi Smart Temperature sensor that delivers temperature and humidity.
However, the entities are not named like above but merely numbered:
Jochen
This is a pure deCONZ behaviour. Best solution would be if deCONZ could solve this when
There have been some discussion about me adding type of sensor to the end of the name.
If you would, could you please see if you can rename your sensors to add the suffix.
Modify this to match your device and device type.
{ “field”: “/lights/1”, “data”: {“name”: “light2”} }
For more details check the documentation here: https://raw.githubusercontent.com/Kane610/home-assistant.github.io/a49c08adb98d5333c09b84d95312116b9dab3f22/source/_components/deconz.markdown
Okay, I’ll look into it… thanks!
Another thing is that all values in HA are displayed as unavailable when deconz is updated/restarted and has not received any messages from the sensors:
In the phoscon app it also shows up as unavailable:
However, shouldn’t these values be ignored in Home Assistant and the last available valid value be displayed?
Is there a way to debug why there are inconsistencies between deconz and HA?
(“nicht verfügbar” = unavailable, “offen”/“geöffnet” = open, “geschlossen” = closed)
I’m seeing this in HA:
whereas deconz has
Names are different, but the order is the same…
I have the suspicion that maybe the first events after the “unavailable” state are not pushed out maybe or mishandled in HA.
I think if the item is marked as unavailable in deconz the preferable choice is to have the HA component also mark the device as unavailable so that the true state of the device is known to the user in HA.
You should enable debug logging for the deconz component and watch to see what the websocket data for that sensor says - if it is marked available and sending values, but HA marks it unavailable, then there is a problem that @Robban should look into. If deconz still reports as unavailable over WS or hasn’t sent an updated value, you should raise this as an issue in the deconz rest API GitHub.
I did another reboot and see the same thing. When I trigger updates again then this is also reflected in HA.
So it seems to be just a bootstrapping thing…
Does the component pick up the current values from the deconz REST interface when it starts ? Or does it rely on websockets alone?
@marthocoo , What is the correct string to enable the logger for the component?
Is there maybe an issue with deconz regarding timestamps?
Edit:
I rebooted at around 5pm but there is a value in deconz that has timestamp of 2pm. Is this possible or did maybe the rpi not finish syncing the time when deconz received that value?
@jo-me sorry I didn’t see this message earlier; enable debug logging by adding the following to your configuration.yaml:
logger:
default: info
logs:
homeassistant.components.deconz: debug
pydeconz: debug
In other news, I took your docker image idea from above and built images that can be deployed from Docker Hub: https://hub.docker.com/r/marthoc/home-assistant-deconz/.
Just substitute marthoc/home-assistant-deconz for the normal image name in your docker run command. If on a raspberry pi, add the :rpi tag: marthoc/home-assistant-deconz:rpi.
@jo-me by enabling logger as @marthocoo we will be able to see if deconz get the information or not. I print everything in debug. So expect a lot of data.
Regarding unavailable, the logic between hass and deconz might differ in how certain data is presented. But hass only presents the information sent from deconz.
But of course there might be some dial-in to get stuff 100%. Suggestions are appreciated