Hue Tap Dial rotation not registered by Home Assistant
Closed this issue · 21 comments
Does the issue really belong here?
- I definitively want to report a bug within deCONZ or its REST-API
Is there already an existing issue for this?
- I have searched the existing issues and there is none for the bug at hand
Describe the bug
Note: I am unsure if this is a Home Assistant or a Deconz issue. I'm trying to pinpoint where the issue lies and how to fix it.
I recently bought a Hue Tap Dial switch which I integrated into Deconz without issue. I integrated it into Home Assistant. All buttons work perfectly, but rotation is not detected by the events listener. When I open the Phoscon app to check if the rotations are registered, I find that they are. When I then go back to Home Assistant and listen for events, I do suddenly see 5001 and 6001 events indicating rotation. When I reload the Home Assistant integration, these events are no longer detected.
Steps to reproduce the behavior
- Reload Home Assistant Deconz integration
- Listen to deconz_event in the events listener. Rotations are not detected
- Open Phoscon app
- Listen to deconz_event in the events listener. Rotations are again detected.
Note: restarting the add-on without reload of the integration does not cause the issue to appear.
Expected behavior
Rotation events should always be detected.
Screenshots
No response
Environment
- Host system: Intel NUC running Debian
- Running method: Home Assistent deCONZ Add-on
- Firmware version: 26720700
- deCONZ version (not Home assistant Addon version!): 2.25.3
- Device: ConBee II
- Do you use an USB extension cable: yes
- Is there any other USB or serial devices connected to the host system? Yes, P1 port reader.
deCONZ Logs
I'm having problems trying to find the actual debug logs. I can't copy from the vnc interface. I do see INFO_L2 entries along the lines of:
No button map for: RDM002, unicast to 0x0000 endpoint: 0x01, cluster 0xFC00, command: 0x00 payload: 1400013001291E00216400291E00216400291E00219001, zlSeq: 197.
Additional context
No response
If the events are always registered in phoscon: it's a home assistant issue as phoscon and home assistant both use the same websocket deconz provides.
Is the above the case?
If what you say is true, then it makes sense. The only thing we can't check is if the Phoscon page actually receives the signals when it is not open. However, I find that slightly unlikely.
One thing I do wonder is why I only see this problem for the hue tap dial switch and not for any other switch, sensor or light. So I'm not completely sure where to start with troubleshooting at the Home Assistant side. But I'll give that a shot.
I have the same problem but with OpenHab. My debugging indicates it is on deCONZ side.
In deCONZ UI: -> Help -> API information -> Then selecting the specific device (and clicking refresh button sometimes)
{
"config": {
"battery": 100,
"on": true,
"reachable": true
},
"etag": "-----------",
"lastannounced": "2024-06-14T17:42:39Z",
"lastseen": "2024-06-14T17:45Z",
"manufacturername": "Signify Netherlands B.V.",
"mode": 1,
"modelid": "RDM002",
"name": "My Hue Tap",
"productname": "Hue tap dial switch",
"state": {
"buttonevent": 4002, <----------------------------------------HERE
"eventduration": 1,
"lastupdated": "2024-06-14T17:44:19.381"
},
"swversion": "2.59.19",
"type": "ZHASwitch",
"uniqueid": "-----------"
}
Normal button events (1xxx-4xxx) change all the time after pressing.
Rotation events (5xxx-6xxx) barely - almost never - occur. Multiple "Hue Tab Dial Switches" tested.
A fix would be great :)
Host system: Raspberry Pi 4B
Firmware version: 26720700
deCONZ version (not Home assistant Addon version!): 2.26.3
Device: ConBee II
Do you use an USB extension cable: yes
deCONZ reports the rotations as rotaryevent values on the ZHARelativeRotary resource, not as buttonevent values 5xxx and 6xxx on the ZHASwitch resource. This is similar to how the Hue bridge reports these (see #6160). This has been the case since the initial support of the Hue tap dial switch back in 2022 (see #6164).
Thanks for the response! I appreciate the help! :)
But these also don't show up to me. I'm viewing this page:
I then subsequently pressed all the buttons on the switch, rotated clockwise, rotated counter clockwise. I repeated the rotation events again, couple of times clockwise, couple of times counter clockwise. Below is the result. I only see buttonevents here. No rotaryevents.
{
"20:55:28:414": {
"attr": {
"id": "100",
"lastannounced": "2024-06-14T18:50:30Z",
"lastseen": "2024-06-14T18:55Z",
"manufacturername": "Signify Netherlands B.V.",
"mode": 1,
"modelid": "RDM002",
"name": "Babyroom Tap Dial",
"productname": "Hue tap dial switch",
"swversion": "2.59.19",
"type": "ZHASwitch",
"uniqueid": "00:17:88:01:0d:d0:26:e0-01-fc00"
},
"e": "changed",
"id": "100",
"r": "sensors",
"t": "event",
"uniqueid": "00:17:88:01:0d:d0:26:e0-01-fc00"
},
"20:55:48:42": {
"e": "changed",
"id": "100",
"r": "sensors",
"state": {
"buttonevent": 1000,
"eventduration": 0,
"lastupdated": "2024-06-14T18:55:46.598"
},
"t": "event",
"uniqueid": "00:17:88:01:0d:d0:26:e0-01-fc00"
},
"20:55:48:207": {
"e": "changed",
"id": "100",
"r": "sensors",
"state": {
"buttonevent": 1002,
"eventduration": 1,
"lastupdated": "2024-06-14T18:55:46.773"
},
"t": "event",
"uniqueid": "00:17:88:01:0d:d0:26:e0-01-fc00"
},
"20:55:48:778": {
"e": "changed",
"id": "100",
"r": "sensors",
"state": {
"buttonevent": 2000,
"eventduration": 0,
"lastupdated": "2024-06-14T18:55:47.346"
},
"t": "event",
"uniqueid": "00:17:88:01:0d:d0:26:e0-01-fc00"
},
"20:55:48:860": {
"e": "changed",
"id": "100",
"r": "sensors",
"state": {
"buttonevent": 2002,
"eventduration": 1,
"lastupdated": "2024-06-14T18:55:47.429"
},
"t": "event",
"uniqueid": "00:17:88:01:0d:d0:26:e0-01-fc00"
},
"20:55:49:485": {
"e": "changed",
"id": "100",
"r": "sensors",
"state": {
"buttonevent": 3000,
"eventduration": 0,
"lastupdated": "2024-06-14T18:55:48.058"
},
"t": "event",
"uniqueid": "00:17:88:01:0d:d0:26:e0-01-fc00"
},
"20:55:49:659": {
"e": "changed",
"id": "100",
"r": "sensors",
"state": {
"buttonevent": 3002,
"eventduration": 1,
"lastupdated": "2024-06-14T18:55:48.226"
},
"t": "event",
"uniqueid": "00:17:88:01:0d:d0:26:e0-01-fc00"
},
"20:55:50:222": {
"e": "changed",
"id": "100",
"r": "sensors",
"state": {
"buttonevent": 4000,
"eventduration": 0,
"lastupdated": "2024-06-14T18:55:48.789"
},
"t": "event",
"uniqueid": "00:17:88:01:0d:d0:26:e0-01-fc00"
},
"20:55:50:372": {
"e": "changed",
"id": "100",
"r": "sensors",
"state": {
"buttonevent": 4002,
"eventduration": 1,
"lastupdated": "2024-06-14T18:55:48.940"
},
"t": "event",
"uniqueid": "00:17:88:01:0d:d0:26:e0-01-fc00"
}
}Am I not looking at the correct thing here, or is this indeed weird?
I have looked for rotaryevents and did find some, but they don't have the same unique_id and it seems that they don't correspond to my tap dial switch. I also have some Aqara vibration sensors, so the events might correspond to these. This is a log snippet of these events:
"20:55:59:636": {
"e": "changed",
"id": "101",
"r": "sensors",
"state": {
"expectedeventduration": 400,
"expectedrotation": -15,
"lastupdated": "2024-06-14T18:55:58.214",
"rotaryevent": 1
},
"t": "event",
"uniqueid": "00:17:88:01:0d:d0:26:e0-14-fc00"
},
"20:56:00:787": {
"e": "changed",
"id": "101",
"r": "sensors",
"state": {
"expectedeventduration": 400,
"expectedrotation": 15,
"lastupdated": "2024-06-14T18:55:59.366",
"rotaryevent": 1
},
"t": "event",
"uniqueid": "00:17:88:01:0d:d0:26:e0-14-fc00"
},Update:
I did some more digging. If I have the Phoscon device page open (see screenshot), and I check the event log, then suddenly I do see buttonevents. No rotaryevents that you mentioned, just buttonevents.
"21:11:57:327": {
"attr": {
"id": "100",
"lastannounced": "2024-06-14T18:50:30Z",
"lastseen": "2024-06-14T19:11Z",
"manufacturername": "Signify Netherlands B.V.",
"mode": 1,
"modelid": "RDM002",
"name": "Babyroom Tap Dial",
"productname": "Hue tap dial switch",
"swversion": "2.59.19",
"type": "ZHASwitch",
"uniqueid": "00:17:88:01:0d:d0:26:e0-01-fc00"
},
"e": "changed",
"id": "100",
"r": "sensors",
"t": "event",
"uniqueid": "00:17:88:01:0d:d0:26:e0-01-fc00"
},
"21:12:49:634": {
"e": "changed",
"id": "100",
"r": "sensors",
"state": {
"buttonevent": 5001,
"eventduration": 1,
"lastupdated": "2024-06-14T19:12:48.200"
},
"t": "event",
"uniqueid": "00:17:88:01:0d:d0:26:e0-01-fc00"
},
"21:12:50:4": {
"e": "changed",
"id": "100",
"r": "sensors",
"state": {
"buttonevent": 5001,
"eventduration": 1,
"lastupdated": "2024-06-14T19:12:48.587"
},
"t": "event",
"uniqueid": "00:17:88:01:0d:d0:26:e0-01-fc00"
},If I check the Home Assistant event listener, I also see deconz_events corresponding to these rotations showing up. If I then close the device page again, I don't see these events in the API and in the events listener anymore.
Those are the events allright.
"uniqueid": "00:17:88:01:0d:d0:26:e0-01-fc00"
"uniqueid": "00:17:88:01:0d:d0:26:e0-14-fc00"
I put a fake endpoint, 14, in the uniqueid of the ZHARelativeRotary, to make its value is unique. You can match the ZHASwitch with the corresponding ZHARelativeRotary on the Mac-address in the uniqueid (the part before the first -).
Note that both button and rotary events are reported through the same command on the FC00 cluster, but with a very different payload. This can be seen in the deCONZ GUI.
I only see buttonevents here. No rotaryevents.
Because of the filter on switches?
I updated my response above with some more info.
Looking at your previous message, I wonder what's going on. If I have the device page open, the rotations get published as buttonevents and also forwarded to Home Assistant. But it seems that the individual rotaryevents are not. I'm left with two questions:
- How come that I get the rotations as buttonevents when I have the device page open in Phoscon? And if I close the page, they don't?
- If the rotaryevents do appear when the device page is unopened, why don't they show up in Home Assistant? I'm out of my depth here and speculating, but can it be that since the uniqueid is different, it cannot be coupled to the same device and therefore Home Assistant has no idea what to do with it?
Ad 1. I don't use Phoscon. Afaik, Home Assistant should connect straight to the web socket provided by deCONZ and Phoscon shouldn't be able to interfere in the messages published there. I'm unfamiliar with the API Information page: is that offered by Phoscon or by Home Assistant? Do you also see the 5xxx and 6xxx buttonevent values on other web socket clients, like the Simple WebSocket Client in Chrome (connected to the deCONZ web socket)?
Ad 2. That's conceivable and would be an omission in the Home Assistant integration of deCONZ. As I mentioned before, these events can be coupled based on the MAC address in the uniqueid.
Okay. I think I figured it out. I found this github issue: Kane610/deconz#359. Turns out that I shouldn't listen for deconz_event but to deconz_relative_rotary_event.
This is a horrible implementation. I have no idea why this should be published as a completely different event. No-one who buys a new device should have to scour the internet trying to find out which specific event type each possible action on the device should throw. This is also the first time I noticed this. I have a Moes rotary switch, I have many Aqara switches and every action just throws a deconz_event. Except this one.
I'm a bit struggling trying to wrap my head around this. Do you have a suggestion on how to proceed here? Is there a way to get this nicely implemented instead of how it's currently working?
This is a horrible implementation.
In that case, you'd better complain to Signify (previously Philips Lighting), or buy another device. As I mentioned before, deCONZ follows how the Hue bridge exposes the Hue tap dial switch.
How come that I get the rotations as buttonevents when I have the device page open in Phoscon?
Still breaking my head on this one. It's conceivable, at least in theory, that Phoscon would change the device mode when the device page is open. This would cause the device to send slightly different payloads for the rotary events, that deCONZ wouldn't recognise correctly. So it would report these button events instead. As I mentioned above, both button events and rotary events are reported by the device using the same cluster and command, but a different payload.
If this is indeed the case, you should be able to spot different payloads in the deCONZ GUI, as well as in the deCONZ debug view, with, I think, APS_L2, so you see the asdu: lines with the command payload.
This is a horrible implementation.
In that case, you'd better complain to Signify (previously Philips Lighting), or buy another device. As I mentioned before, deCONZ follows how the Hue bridge exposes the Hue tap dial switch.
What I get from this is that the event type is chosen by the device itself and not by Deconz? But even so, then it's still a Home Assistant thing to decide how these events get exposed to Home Assistant, right? The fact that rotations show up as deconz_relative_rotary_events in Home Assistant and not as deconz_events is a decision by Home Assistant developers, right? It would surprise me if Signify engineers would send deconz_events around when developing their Hue products.
If this is indeed the case, you should be able to spot different payloads in the deCONZ GUI, as well as in the deCONZ debug view, with, I think, APS_L2, so you see the asdu: lines with the command payload.
I have around 110 devices in my network and if I open the deconz viewer via VNC in my browser, I can't copy-paste the logs and go through them. So finding these events in the mess of all data will be a real pain. Is there an easier way to do this?
Edit:
Okay. With the help of ChatGPT I learned a bit more and found that it's more difficult then it seems at first glance (as everything is always). I now understand that deconz is in charge of these events and that Home Assistant just receives these events as-is. Publishing these as deconz_events would require active repackaging of the events.
Knowing that, I do see a few things that could be better. The event data is seen below:
event_type: deconz_relative_rotary_event
data:
id: hue_tap_dial_switch
unique_id: 00:17:88:01:0d:d0:26:e0
device_id: 479e093dd93fc09f8af97957ae5201b8
event: repeat
rotation: -347
duration: 400
origin: LOCAL
time_fired: "2024-06-14T20:27:53.600235+00:00"
context:
id: 01J0C6YTW0X9KDXHYGE8ER9GCZ
parent_id: null
user_id: nullThe device_id is correct in my case. However, the id is not, which should be babyroom_tap_dial, which is correct for the button presses. Additionally, the rotation events do not show up in the Home Assistant log book on the device page:
Do you know if these are things that are reasonably easily implementable? And if so, should these be on the Home Assistant or on the Deconz side?
Thanks for your patience by the way! For me this is clearly a case of "Ik heb wel echt duidelijk de klok horen luiden en volgens mij betekent dat dat er ook ergens een klepel hangt, maar waar precies is me enigszins een raadsel".
deCONZ sends websocket notifications, as seen in #7804 (comment) . I think the translation into deconz_event etc is done by the HA integration for deCONZ. I don’t recognise the device id either, I think these are assigned by the HA integration as well.
If you open the Cluster Info panel in the deCONZ GUI and then select the FC00 cluster of the Hue tap dial, you should see the command payload change as you press the buttons and turn the dial.
If you prefer you can use the node red plugin to do what ever you want with the deconz event and send it to anything like home assistant.
In my setup I use it for complex cases where the rules from phoson is not enough
deCONZ sends websocket notifications, as seen in #7804 (comment) . I think the translation into deconz_event etc is done by the HA integration for deCONZ. I don’t recognise the device id either, I think these are assigned by the HA integration as well.
As far as I understand, you're right indeed. Each device in my Home Assistant setup has a unique device ID. If I go to the URL of my HA box and append /devices/<device_id> I end up at the configuration page of this specific device.
Looking at the messages sent from deCONZ, I do see a field named 'id' and a field with 'unique_id'. The id is 100 for tap actions and 101 for rotation actions. Also the unique_id is different, the difference being this fake endpoint you already mentioned (although I don't exactly know what endpoint means in this case). Now I don't know what's the difference between the id and unique_id fields, but if Home Assistant only receives id and unique_id as device identifiers, it makes sense that Home Assistant doesn't recognize rotation events as coming from the same device, as both are different. Does this make sense?
This leads me to the question: why did you change the endpoint in the unique id? It seems to me that if the action is coming from the same device, it should have the same unique_id, right? Or is this unique_id not connected to a device but to an action?
Also: do you know what the id field is? It seems to me that 100 or 101 is a bit too short to be a real unique identifier, although it could be simply the 100th and 101st devices seen by deCONZ.
The id and uniqueid are per (REST API) resource, not per device. The unique identification of a device is its Zigbee MAC address. The uniqueid is created from this MAC address, the Zigbee endpoint and, for sensors, the Zigbee cluster. The id is just the resource ID, so the resources for this device are /sensors/100 and /sensors/101. To find all resources for a device, match the MAC address part of uniqueid. Alternatively, use the newer /devices API endpoint.
Note that id will change when you remove and re-pair the device, but uniqueid remains the same.
Good to know. Then from the Home Assistant point of view, what would be best to use to identify which device has triggered a certain event? I would guess that's the uniqueid, but that cannot be used as-is. Instead the MAC address would need to be extracted from the uniqueid and then coupled to the Home Assistant internal device_id. I wonder how this is really done.
But I think these are all on the Home Assistant side as far as I understand now.
As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.
Maybe I can Jump into this topic.
I have the same issue. the Buttons are working the rottaryevent is not fired over Websocket but I can see it over the deconz ui.
My Setting
deconz 2.27.04 from Setup file but 2.17.1 on the ui.
I use Windows 10 with a conbee II and USB extension.
The Button under the HUE BUTTON Info
On Deconz Start
Button Pressed
On Rotary
The Node Info
The Deconz Information
I don´t use a common Smart Home. I work only with the Websocket. For this Problem I use 2 simple Websockets clients to see is this a problem in my implementation but all of them got only stuff like this:
`{"attr":{"id":"97","lastannounced":null,"lastseen":"2024-07-13T19:42Z","manufacturername":"Signify Netherlands B.V.","modelid":"RDM002","name":"RDM002 97","swversion":"2.59.19","type":"ZHASwitch","uniqueid":"00:17:88:01:0d:d1:a5:f2-01-fc00"},"e":"changed","id":"97","r":"sensors","t":"event","uniqueid":"00:17:88:01:0d:d1:a5:f2-01-fc00"}
{"e":"changed","id":"97","r":"sensors","state":{"buttonevent":1000,"eventduration":0,"lastupdated":"2024-07-13T19:43:00.925"},"t":"event","uniqueid":"00:17:88:01:0d:d1:a5:f2-01-fc00"}
`
I have no Idea why I can see it on the HUE BUTTON but not in the Websocket message.
I have looked a little deeper and found the issue on my System. The Path of installations was changed after 2.17 and I have not controll quiet installation. So I start since long time everytime a old solution.
Maybe other have the same problem.
Now it works. On Websocket and API I got two Sensors.
Thanks and hope I spell a smile to you ;-)
As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.
As there has not been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it is not solved, request to get this opened again.