Requesting support for device triggers https://www.home-assistant.io/integrations/deconz/#requesting-support-for-new-device-trigger
You can find the different remotes supported in code here: https://github.com/home-assistant/home-assistant/blob/61bb24c423d98e9183677c1bf7aa79690e14a9a5/homeassistant/components/deconz/device_trigger.py#L212
It is just sad that the device_triggers have been implemented using the cryptic user unfriendly IDs. It makes it a feature I will not touch or recommend. Why has it not been implemented with entity IDs which you can name something human? Then you could save the automation and move it to another automation file. As it is now you can only use it in the automation editor which is still early days and limited
Have you ever asked the Dev why its been implemented in the way it has?
It could well be there is a valid reason it’s been done that way, criticizing it’s implementation isn’t helpful without knowing the reasons
Also, what is the issue with the automation editor and moving to other files
I have one of these
single click turn the jukebox screen on/off
- alias: 'Garage JukeBox Screen Toggle'
initial_state: 'on'
trigger:
platform: event
event_type: deconz_event
event_data:
id: smartswitch2
event: 1002
action:
- data:
entity_id: switch.garagejukebox
service: switch.toggle
double click pause/play the jukebox
- alias: 'Garage JukeBox Screen Pause Play'
initial_state: 'on'
trigger:
platform: event
event_type: deconz_event
event_data:
id: smartswitch2
event: 1004
action:
- data:
entity_id: media_player.volumio
service_template: >
{%- if is_state("media_player.volumio","paused") -%}
media_player.media_play
{%- else -%}
media_player.media_pause
{%- endif -%}
Device triggers are as specified based on what features a device has. A device has many entities. Device triggers are specifically targeting the automation editor taking another step in usability and user friendliness. No-one is forcing you to use it.
I do understand the intension of the Automation Editor and I do not want to start a debate about that in this Deconz thread.
But specifically for Deconz what is difficult is the Events and finding out which 4 digits code means what and what the device name is reporting the events. You cannot look it up anywhere. You have to pair the device, rename it in Phoscon (unless you like pointless generic names), and restart HA. And then try all the key combinations and try to guess if there is something special about double press, long press etc.
The new feature in the Automation editor resolves the part of the problem finding the device and presenting the possible key modes. But it does not help me at all as an advanced user because the only way it works is by cryptic device IDs and imagine having 50 of those in your automations.
It would be so nice if I could create triggers in automations using a predictable name for the device instead of a device ID
For those that do not know what I am talking about this is how a simple automation looks like created by the Automation Editor
- id: '1574157146269'
alias: New Automation
description: ''
trigger:
- device_id: 33dabc73ecff426d88cf6e176085be36
domain: deconz
platform: device
subtype: turn_on
type: remote_button_short_press
condition: []
action:
- device_id: a807652383e9462986af02f7455fd4b1
domain: light
entity_id: light.kitchen_table
type: turn_on
It would be wonderful if I could refer to the devices with a name that I can define instead of 33dabc73ecff426d88cf6e176085be36 and a807652383e9462986af02f7455fd4b1 and then be able to use the very much more user friendly “remote_button_short_press”
In the Z-wave integration the developer creates entity IDs that are prefixed zwave. E.g. zwave.front_yard_multisensor
And an Aeotec Multisensor then consist of 10 individual sensor and binary_sensor entity IDs.
Maybe that could be one way to attack it.
We learned from the ZHA integration that defining binary sensors for remotes does not work. A remote switch is stateless and creates events. A push button remote is not ON after you press ON. It just sends an ON message. That is why ZHA and Deconz now both just sends events. That is correct to do. But the issue is that the sources for the events are invisible to the user and no entity IDs exist for them. And the 2nd problem for Deconz is those 4 digit codes.
Would it make sens that devices in Deconz could get entities like we know from zwave integration and that these could be used in device automations as an alternative to the device_id?
Just an idea to think about.
This is a bigger question that fits well to be formulated for the home assistant architecture project. Im not opposed to having some kind of visual reference to the remote (current work around is the event id in battery sensor attributes). But this won’t solve the different events a remote can emit.
I just installed the add-on, confirmed that Conbee II is found by hassio added the “/dev/serial/by-id/…” link in the configuration, but the UI won’t start. I’m getting a lot of “wait reconnect” posts in the logs and curiously it refers to “ttyACM1” all the time in the logs. Is this because “by-id” refers to “ACM1”? Anyway, I think I configured correctly but the problems remain. Is there any specific information I should be looking for? Below is a dump of the logs. Thx!
starting version 237
[20:41:38] INFO: Starting the deCONZ gateway...
[20:41:38] INFO: Running the deCONZ OTA updater...
[20:41:38] INFO: Running the IKEA OTA updater...
[20:41:38] INFO: Running Hass.io discovery task...
{"uuid":"798bc2ebe10141b78dc0e57d8ceb781b"}
[20:41:38] INFO: Success send discovery information to Home Assistant
[20:41:38] INFO: deCONZ is set up and running!
libpng warning: iCCP: known incorrect sRGB profile
20:41:38:895 HTTP Server listen on address 0.0.0.0, port: 40850, root: /usr/share/deCONZ/webapp/
20:41:38:920 CTRL. 3.22.020:41:38:964 COM: /dev/ttyACM1 / serialno: DE1962786
20:41:38:964 COM: --dev: /dev/ttyACM1 (ConBee II)
20:41:38:964 ZCLDB init file /data/.local/share/dresden-elektronik/deCONZ/zcldb.txt
20:41:39:017 parent process bash
20:41:39:017 gw run mode: docker/hassio
20:41:39:017 GW sd-card image version file does not exist: /data/.local/share/dresden-elektronik/deCONZ/gw-version
20:41:39:018 DB sqlite version 3.22.0
20:41:39:018 DB PRAGMA page_count: 30
20:41:39:018 DB PRAGMA page_size: 4096
20:41:39:018 DB PRAGMA freelist_count: 0
20:41:39:018 DB file size 122880 bytes, free pages 0
20:41:39:018 DB PRAGMA user_version: 6
20:41:39:018 DB cleanup
20:41:39:019 DB create temporary views
20:41:39:020 don't close database yet, keep open for 900 seconds
20:41:39:021 started websocket server at port 40860
20:41:39:022 GW firmware update not supported on x86 linux headless
20:41:39:023 found node plugin: libde_rest_plugin.so - REST API Plugin
20:41:39:024 found node plugin: libde_signal_plugin.so - Signal Monitor Plugin
20:41:39:593 found node plugin: libstd_otau_plugin.so - STD OTAU Plugin
20:41:39:618 COM: /dev/ttyACM1 / serialno: DE1962786
20:41:39:618 COM: --dev: /dev/ttyACM1 (ConBee II)
This plugin does not support propagateSizeHints()
This plugin does not support propagateSizeHints()
20:41:39:984 wait reconnect 15 seconds
20:41:40:014 COM: /dev/ttyACM1 / serialno: DE1962786
20:41:40:014 COM: --dev: /dev/ttyACM1 (ConBee II)
20:41:41:035 wait reconnect 14 seconds
20:41:42:085 wait reconnect 13 seconds
20:41:43:104 wait reconnect 12 seconds
20:41:44:104 wait reconnect 11 seconds
20:41:45:104 wait reconnect 10 seconds
20:41:46:103 wait reconnect 9 seconds
I see .71 to fix the .70 issues is out on Dresden’s site, any idea when the HASSIO addon will be updated ?
.71 was only released 4 hours, maybe a little while before its out
The Docker container is built. You can always create an issue with hassio addons that a new release is available.
Unrelated to the .70 issues, anyone know how to “reconnect” all those nodes via Deconz? (not resetting + reconnecting every single item if I can help it)
RPi4/HASSIO/RaspBee.
Suddenly everything zigbee was greyed out. Have tried resetting gateway, restored backup, removed addon+integration, lots of reboots, then restored a HASSIO snapshot, but still no go:
Are the devices actually not working, or is it just a visual issue on the deCONZ screen?
It can take some time for the lines to reappear after a reboot.
If the devices are actually not working, perhaps changing the frequency settings in the Phoscon app can help.
Thanks, I see the updated add on is available.
Are the devices actually not working, or is it just a visual issue on the deCONZ screen?
It can take some time for the lines to reappear after a reboot.
Not working. Nothing zigbee is working. This has never happened before, and the Pi have been rebooted countless times.
If the devices are actually not working, perhaps changing the frequency settings in the Phoscon app can help.
To a specific channel, or just to some other channel? I’ve set everything to channel 25 because of the condition on the 2.4 ghz bands where I live. I’ll try just changing to see what happens.
Just to some other channel to see if it works.
This has never happened before, and the Pi have been rebooted countless times.
Have you recently purchased any new devices? I suddenly experienced issues with Conbee that I later tracked down to a new USB-C hub that I purchased.
It seems that some USB-C hubs generate interference in the 2.4GHz band.
Anyone got a guide how to get the battery levels on my three Fyrtur blinds reported to HA? (non-hassio install in a container and Deconz / Conbee 2 running on a seperate windows vm).
Well, i believe i just added my precious button
ooooh! @kurniawan77 for real?
I’ve got a bunch of those WXKG11LM’s lying around for ages, not getting them to work.
Does this mean after next release of deconz it will be piece of cake to add support for this button?
