Deconz-rest-plugin: Ikea Symfonisk Controller

Follow the wiki to share what relevant information is needed to add support for it

What if I could not connect the device to Deconz?

Could I help to add support?

Yes, please provide the info described here: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Request-Device-Support.

Intriguing little device: apparently it talks ZigBee, as it requires a Trådfri gateway, but the Symfonisk (Sonos) speakers talk SOAP over http. I wonder how much intelligence is in the device versus the gateway. You won’t be able to use the device to control the speakers through deCONZ (instead of through the Trådfri gateway), but it should be able to get some button events for click and double click. Not sure where we are on exposing turn gesture (with angle). Otherwise we could expose an analogue button event value, cf. the second endpoint of the Xiaomi cube.

Turning works for dimming the Ikea Lights here, that is connect right now.

Do you need anything else?

The _Basic_ cluster. Please read the attributes before taking the screenshot.

I found (the last?) one at IKEA Amsterdam today, even thought they're not yet on ikea.nl. It joins deCONZ's ZigBee network without issues. However, it's only responsive for a very brief period after joining the network, and then goes incommunicado. It won't wake on click, turn, or briefly pressing the reset button.

After several attempts, bombarding it with _Read Attributes_ commands to keep it awake after joining the network, I managed to bind the client _OnOff_ cluster to a group. And then the client _Level Control_ cluster. After that, it now behaves normally, waking up to send commands on click and turn. It sends the following commands:

• _Toggle_ on click;
• _Step Up_ on double click;
• _Step Down_ on treble click;
• _Move Up_ when starting a right (clockwise) turn;
• _Move Down_ when starting a left (counter-clockwise) turn;
• _Stop_ when stopping a turn.

Exposing click (1002), double click (1004) and treble click (1005) will be straightforward.
As far as I can tell, the move rate is constant. The timing between the _Move_ and _Stop_ commands seems to indicate how long you're turning, but not how quickly nor how far. Probably easiest to expose left/right turning as two long press buttons (2001/2003 and 3001/3003).

It's far from trivial to translate these ZigBee commands to Sonos commands. There's no Sonos equivalent of Toggle, to the Trådfri hub needs to keep the play/pause state of the Sonos player. Also there's no _Move_ / _Stop_ equivalent for volume. There's a _RampToVolume_ command, but I don't think that can be interrupted.

I think I managed to touchlink it to my Trådfri hub (the IKEA Home Smart app showed a popup that a new controller was found). However, the app won't find my Sonos speakers, so I cannot setup the controller to sniff the (SOAP over HTTP) commands the Trådfri hub sends to the Sonos player.

Commit below adds support for the sound controller.

{
  "config": {
    "alert": "none",
    "battery": 16,
    "group": "1",
    "on": true,
    "reachable": true
  },
  "ep": 1,
  "etag": "390a8f3dfff393f27db48b6d845550a4",
  "manufacturername": "IKEA of Sweden",
  "mode": 1,
  "modelid": "SYMFONISK Sound Controller",
  "name": "SYMFONISK Sound Controller ",
  "state": {
    "buttonevent": 2003,
    "lastupdated": "2019-09-27T09:15:06"
  },
  "swversion": "2.1.022",
  "type": "ZHASwitch",
  "uniqueid": "14:b4:57:ff:fe:66:48:62-01-1000"
}

For reference, here's the _Basic_ cluster with all attributes read:

@ebaauw would you mind giving a detailed description of what button events the different actions generate?

As I mentioned above:

• 1002 click;
• 1004 double click;
• 1005 treble click;
• 2001/2003 start/stop counter clockwise turn;
• 3001/3003 start/stop clockwise turn.

Thanks Erik! There are no events between start and stop rotate?

No, as far as I can tell, the controller only sends _Move_ when starting to turn and _Stop_ when ending it. Depending how smoothly you turn (or not), you get multiple _Move_/_Stop_ combos per turn. I did see some messages in the deCONZ log that it did drop buttonevent notifications because they happened too quickly in succession, but I don’t know what to do about that (other than ignore them ;-).

I’m dying to find out what Sonos commands the Trådfri hub sends, but the IKEA Home Smart app doesn’t find my Sonos (nor Symfonisk) players, even though the Sonos app does. Also the app crashes on my iPhone Xr (I think since iOS 13.1), but not on my iPad (iPadOS 13.1).

Well you can pair sonos with home assistant and bind them together :)

I've been doing the same with HomeKit; I control my Sonos speakers (through homebridge-zp) using the 5-button Trådfri remote (through homebridge-hue).

How exactly do you pair this with deCONZ?
I'm not able to get that working

Does the Symfonisk Controller fire an event on long press?

when will this be in the release build?

How exactly do you pair this with deCONZ?
I'm not able to get that working

Can't get my remote connected either. Can anyone help?

@Noah-UI - as far as I know, you can connect to it and see that it 'works' in deconz, but you can't really act on it just now. That only works if you have the IKEA bridge and take it from there.

but you can't really act on it just now

While it's not possible to control Symfonisk/Sonos players without the Trådfri hub, the controller can be used just fine with deCONZ to control other ZigBee devices. It sends regular ZigBee commands, which are picked up by deCONZ v2.05.70 to create buttonevent values, which can be used in gateway rules. In addition, you can add lights to the controller's group and control them directly (even when deCONZ is down).

Does the Symfonisk Controller fire an event on long press?

No, see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1898#issuecomment-536069107.

How exactly do you pair this with deCONZ?

Note that deCONZ doesn't support touchlink-pairing (which is what the Trådfri hub uses). You need to search for new devices in Phoscon/open the network in the old web app, and reset the device (pressing the reset button four times - the LED should blink).

As I mentioned before (https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1898#issuecomment-535090364), the device shuts off it's radio very quickly after joining the network - it's critical that deCONZ has setup the bindings before that happens, or the device won't power back on its radio on clicking/turning. The chances of successful pairing can be increased by powering down all routers, and pair the controller close to the RaspBee/ConBee. If needed, keep the radio awake by sending commands to it from the deCONZ GUI while pairing.

@Keesromkes in your screenshot, deCONZ didn't receive the simple descriptors, causing the right dropdown button to be missing. See https://github.com/dresden-elektronik/deconz-rest-plugin/pull/2002#issuecomment-547985838 for details.

Hello, I just updated to the last version of deconz (270), but I cant seems to figure how to add the switch.
I am using the UI, in switch, add other. 4x click quickly but it doesnt add to deconz.
Could you help me ?

Actually it was added, it's just that it doesn't appear in the new Phoscon app in my devices list. I found it in the old app.

What an interesting gizmo!

While it's not possible to control Symfonisk/Sonos players without the Trådfri hub

not true. you can have Node-Red watch for the event clicks/rotate, and then have a flow that adjusts your Sonos devices based on which action it detected.

While it's not possible to control Symfonisk/Sonos players without the Trådfri hub

not true. you can have Node-Red watch for the event clicks/rotate, and then have a flow that adjusts your Sonos devices based on which action it detected.

I am trying to do it using appdaemon and hass automation, everything is almost working, I am just looking for the volume now, since it's just 1 event to start/stop... (see here)

I am trying to do it using appdaemon and hass automation, everything is almost working, I am just looking for the volume now, since it's just 1 event to start/stop... (see here)

For that you have to up/lower the volume repeatedly until the stop event is fired.

I’ve opted for +/- 7% of volume every 500ms. It works quite nicely.

It seems I have successfully paired my sonos controller, can see it in phoscon app (via VNC) and in the old webapp.
However when I listen for events (in HASSIO) I get nothing :(

Oh! It suddenly works! After fiddling a lot in Phoscon and trying to include it several times.
Not really sure how, but now it works and I get the events in HASSIO

wrote a how-to for NodeRed

https://www.reddit.com/r/homeassistant/comments/dssysn/nr_rabbit_hole_part_10_sonic_attack_using_the/

Oh! It suddenly works! After fiddling a lot in Phoscon and trying to include it several times.
Not really sure how, but now it works and I get the events in HASSIO

Do you have a solution to correctly interpret the rotational movement in HASSIO, for example to increase/ decrease volume?

Oh! It suddenly works! After fiddling a lot in Phoscon and trying to include it several times.
Not really sure how, but now it works and I get the events in HASSIO

Do you have a solution to correctly interpret the rotational movement in HASSIO, for example to increase/ decrease volume?

No, that's the next thing. Hoping to see others come up with something for that 😊

See #2040. Better close this issue.

Oh! It suddenly works! After fiddling a lot in Phoscon and trying to include it several times.
Not really sure how, but now it works and I get the events in HASSIO

Do you have a solution to correctly interpret the rotational movement in HASSIO, for example to increase/ decrease volume?

No, that's the next thing. Hoping to see others come up with something for that 😊

Try this: https://github.com/lbouriez/hassio-home-assistant_config/blob/master/appdaemon/apps/modules/symfonisk_sonos.py
For me it works pretty well

Does someone know how to make the switch appears in the phoscon new app ?
I have all my switch but the symfonisk just appears in the old app.

Cant get the symfonisk in phoscon. I am using deconz 2.5.70 and conbee with 26330500. When I try to connect as an ikea switch just show the 5 button remote and the old dimmer. When i try to connect as "other" it doesn't work. (push connect button 4 times on symfonisk remote until led is blinking).
What am I doing wrong? I paired several other devices (ikea and xiaomi) and had not these problems before. :/ Please help.
EDIT: Seems that it is learned by deconz but not shown in phoscon app. I can see the switch in iobroker wich is getting the devices per REST. But in the webinterface the switch is not shown. How can this work?

@siggi85 @lbouriez - in short, it won't you show up in the new phoscon (until they will support it). You can address the device through hass.io or NodeRed (both I've been too busy with other things to set up)

@Keesromkes Thanks for your answer. Yes you are right. In deconz directly i can see the switch and can use it via API.

But unfortunatly the usage of the wheel is not usable at the moment. Event 3001 when you start spining and when it stops event 3003. Additionaly Event 3003 comes not every time when you stop. And you can't check how long or fast you spin. Just start and stop is not enough to use it effective. Don't know how it work smooth with Symfonisk speakers directly.

@siggi85 check my appdaemon script, it's not perfect, I still have trouble with the wheel sometimes but it gives you an idea on how to do until someone comes with a better solution.

But unfortunatly the usage of the wheel is not usable at the moment.

The buttonevents are derived 1:1 from messages sent by the controller. It doesn’t report how long you spin. See my post above.

until someone comes with a better solution.

That some-one will have to be IKEA delivering new firmware for the Symfonisk controller, making it behave differently. Not very likely, in my estimation.

@siggi85 you are being too literal. it simply does not send a continuous signal as you turn it. and it probably never will. all you need to look for is a START spin code. like i said above, if you turn slowly, you get multiple START and STOP spin codes. for each START code then do volume up. (i do a +2 in my NodeRed flow, works great.)

edit: it was in this ticket https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2040

I thought maybe of a stop event with the value of the spin. Maybe 3001 for start and 3500 for a half spin or something like that. But it is not. I will try the +2 Option but my idea of using it was another. I will see wether this is suitable for me. Thanks for your replys guys.

Another question. I got two of those and paired them succesfully.

But now they have the same name and I can not figure out how to change the name because they don't appear as an entity in HomeAssistant and also not in the Phoscon Web App. Maybe somehow trough the Rest API?

FYI

I now use the controller to control my IOTAVX Amp with NodeRed and Home Assistant via a Broadlink Remote Controller. Thanks for the work.

Hi guys,
Is there any update in this topic?
I also have the setting hassio/conbee2/deconz/symfonisk remote and would like to control my Sonos speakers.
Regards,
Dominik

Another question. I got two of those and paired them succesfully.

But now they have the same name and I can not figure out how to change the name because they don't appear as an entity in HomeAssistant and also not in the Phoscon Web App. Maybe somehow trough the Rest API?

Have you already got a solution for this topic?

Another question. I got two of those and paired them succesfully.

But now they have the same name and I can not figure out how to change the name because they don't appear as an entity in HomeAssistant and also not in the Phoscon Web App. Maybe somehow trough the Rest API?

Have you already got a solution for this topic?

You can try using the API yes https://dresden-elektronik.github.io/deconz-rest-doc/sensors/ "Update sensor", but 1 device in deconz can have multiple entries in API so IDK how it will work.

If you still can access the old app (in help>old app) you will see you device.
I don't know why we can't see it in the new app :(

If you still can access the old app (in help>old app) you will see you device.
I don't know why we can't see it in the new app :(

I will try it trough the API.
My old App looks exactly Like the new, what am i doing wrong?

Another question. I got two of those and paired them succesfully.

But now they have the same name and I can not figure out how to change the name because they don't appear as an entity in HomeAssistant and also not in the Phoscon Web App. Maybe somehow trough the Rest API?

Have you already got a solution for this topic?

You can try using the API yes https://dresden-elektronik.github.io/deconz-rest-doc/sensors/ "Update sensor", but 1 device in deconz can have multiple entries in API so IDK how it will work.

I tried it with through the API, but i was Not successful maybe i am too dumb.
I have enabled the Port 40850 in deconz. If i Type it in the Browser i get to the new webapp.
I am Missing the Connection between hass.io entity to deconz symfonisk Controller.
I tried to read the doc, but didn' t get it right.
Can you please give me a few hints, or a short Tutorial what i need to so?
Thank you in advance!

Can you please give me a few hints, or a short Tutorial what i need to so?

I managed to pair a second controller yesterday but had to rename the device through the API. Try something like this:

curl -u 'username:password' http://x.x.x.x:7080/api -X POST -H "Content-Type: application/json" -d '{ "devicetype": "curl" }' (fetch API token, returned as "username")

curl http://x.x.x.x:7080/api/<api token>/sensors -X GET -H "Content-Type: application/json" (list all sensors to find out the ID of the sensor to rename)

curl http://x.x.x.x:7080/api/<api token>/sensors/<sensor id> -X PUT -H "Content-Type: application/json" -d '{ "name": "<new name>" }' (rename sensor)

Another question. I got two of those and paired them succesfully.

But now they have the same name and I can not figure out how to change the name because they don't appear as an entity in HomeAssistant and also not in the Phoscon Web App. Maybe somehow trough the Rest API?

I renamed it via the App Hue Essentials

FYI

I now use the controller to control my IOTAVX Amp with NodeRed and Home Assistant via a Broadlink Remote Controller. Thanks for the work.

Can you post your NodeRed Code?

FYI
I now use the controller to control my IOTAVX Amp with NodeRed and Home Assistant via a Broadlink Remote Controller. Thanks for the work.

Can you post your NodeRed Code?

Sure. I copied just the stuff that is really needed.

[ { "id": "d952ec68.792e6", "type": "deconz-input", "z": "cac2275d.5aab68", "name": "Symfonisk Controller", "server": "9705a63e.b575c", "device": "14:b4:57:ff:fe:69:37:45-01-1000", "device_name": "SYMFONISK Sound Controller : ZHASwitch", "state": "0", "output": "always", "outputAtStartup": false, "x": 110, "y": 440, "wires": [ [ "a1449ad.1aa1068" ], [] ] }, { "id": "a1449ad.1aa1068", "type": "switch", "z": "cac2275d.5aab68", "name": "Events", "property": "payload.buttonevent", "propertyType": "msg", "rules": [ { "t": "eq", "v": "1005", "vt": "num" }, { "t": "eq", "v": "1004", "vt": "num" }, { "t": "eq", "v": "1002", "vt": "str" }, { "t": "eq", "v": "2001", "vt": "num" }, { "t": "eq", "v": "2003", "vt": "num" }, { "t": "eq", "v": "3001", "vt": "num" }, { "t": "eq", "v": "3003", "vt": "num" } ], "checkall": "true", "repair": false, "outputs": 7, "x": 290, "y": 460, "wires": [ [ "3a5dcdc8.481b92" ], [ "1f8c9412.286444" ], [ "2ca5c685.4dabba" ], [ "acbd3ab8.036f08" ], [ "a4e4c412.1a3fb" ], [ "b0800e96.d8f64" ], [ "a4e4c412.1a3fb" ] ], "outputLabels": [ "Triple", "Double", "Single", "Spin Left Start", "Spin Left Stop", "Spin Right Start", "Spin Right Stop" ] }, { "id": "a4e4c412.1a3fb", "type": "function", "z": "cac2275d.5aab68", "name": "Stop", "func": "var newMsg = { payload: \"stop\" };\nreturn newMsg;\n", "outputs": 1, "noerr": 0, "x": 490, "y": 600, "wires": [ [ "b0800e96.d8f64", "acbd3ab8.036f08" ] ] }, { "id": "acbd3ab8.036f08", "type": "looptimer", "z": "cac2275d.5aab68", "duration": "1", "units": "Second", "maxloops": "10", "maxtimeout": "1", "maxtimeoutunits": "Minute", "name": "", "x": 680, "y": 560, "wires": [ [ "ec10c519.7484a8" ], [] ] }, { "id": "b0800e96.d8f64", "type": "looptimer", "z": "cac2275d.5aab68", "duration": "1", "units": "Second", "maxloops": "10", "maxtimeout": "1", "maxtimeoutunits": "Minute", "name": "", "x": 680, "y": 600, "wires": [ [ "18b688c.60c6877" ], [] ] }, { "id": "9705a63e.b575c", "type": "deconz-server", "z": "", "name": "Deconz", "ip": "192.168.188.122", "port": "80", "apikey": "91E977E002", "ws_port": "443", "secure": false, "polling": "15" } ]

@kmplngj did you change something in that code when I try to import it says its not a valid json format.

@ebaauw did you do something special to connect Symfonisk to Deconz? I am having trouble pairing it. I am using Home Assistant Addon and Phoscon web interface. Here is what I am doing:

• Devices > Switches > Add new switch > Other
• Then I inserted the battery, pressed the button next to it 4 times.
• Symfonisk is right next to Conbee 2, pretty much touching it (plugged in into usb3 port of pi4)
• The light blinks a few times then stays solid.

Nothing happens in the UI. Even if do an API request
curl http://core-deconz:40850/api/\F04AC28AFD/sensors -X GET -H "Content-Type: application/json"
I only get Phillips device, which i assume is the virtual one that's already there
{"1":{"config":{"configured":true,"on":true,"sunriseoffset":30,"sunsetoffset":-30},"etag":"36afb24d0ddea3297e6077583506aee3","manufacturername":"Philips","modelid":"PHDL00","name":"Daylight","state":{"dark":false,"daylight":true,"lastupdated":"2020-03-26T13:52:46","status":160,"sunrise":"2020-03-26T13:20:22","sunset":"2020-03-27T01:40:48"},"swversion":"1.0","type":"Daylight","uniqueid":"00:21:2e:ff:ff:05:a1:3e-01"}}#

I have 2 Symfonisk remotes and none of them can connect. Any idea on what could be the issue? Is it that I have a Aeotech zwave stick nearby?

plugged in into usb3 port of pi4

That’s asking for problems. Inadequately shielded (read: almost all) USB-3 controllers and cables interfere with 2.4GHz radio, and ZigBee is especially sensitive to this. Plug the ConBee into a USB-2 port and do not use the USB-3 ports. I’ve seen some reports where people managed to use a USB-3 SSD while ConBee connected to USB-2 using an extension cable, and others where they didn’t. Using an extension cable is a good idea anyways, as is turning off WiFi and Bluetooth on the Raspberry Pi.

Is it that I have a Aeotech zwave stick nearby?

Not sure if ZWave also uses 2.4GHz, but “nearby” doesn’t sound good. Again use a USB extension cable to create some distance to the ConBee.

Nothing happens in the UI.

Do you mean in Phoscon or in the deCONZ GUI? You want to be looking at the GUI. I don’t know if Phoscon yet supports the Symfonisk controller (I don’t use Phoscon), but if it isn’t listed in the API, Phoscon won’t see it anyways.

Thanks for quick response, ill try all that!
How do you connect to the GUI (I've been using Phoscon web interface)? I know there is a VNC port for the Hassio Deconz addon but looks like it's not working when i try to use the my HA ip.

You need to be running deCONZ with the GUI enabled. Use the deconz-gui service instead of the deconz service.

Yep that did the trick, all paired up now. I think it was the combination of turning off wifi, bt on pi4 + using USB extension and deCONZ with GUI enabling. I left the remote next to conbee2 for about a minute, if you move it away it won't fully pair. Thanks again for quick help!

I've noticed that especially on short rotations, I'm not receiving a STOP event.
Is this an issue with the ikea hardware or can we do something about that with deconz?

Theres also #2195 reporting similar issues with ikea hardware

https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1898#issuecomment-536075055

I did see some messages in the deCONZ log that it did drop buttonevent notifications because they happened too quickly in succession, but I don’t know what to do about that (other than ignore them ;-).

Thats probably the culprit here. I guess this can only be fixed by @manup then?

Edit:

Can confirm. This happens all the time

16:24:49:627 button 2001 Move Up
16:24:49:627 button 2001 Move Up, discard too fast event (dt = 25)

Maybe whitelist this specific device?

UTSL, if the same buttonevent value is issued again within 0.5 seconds, it's discarded:
https://github.com/dresden-elektronik/deconz-rest-plugin/blob/b3086c6009154aa1b5cdb89febb5f177912952e9/de_web_plugin.cpp#L3647-L3657

I'm not sure why this code is there. Maybe deCONZ would pick up multiple messages if a group command is sent, and issue multiple buttonevents? Maybe it's some sort of debouncing for a particular device?

Maybe whitelist this specific device?

Not sure if that'll work (depends on why the code is there in the first place). If it is device-related, I'd rather whitelist the device that needs this code.

Not sure how relevant fixing this is, I'd rather spend my time on implementing proper ZHARelativeRotary support (see #2305).

Not sure how relevant fixing this is

Currently, the symfonisk controller is unusable, since it will occasionally increase the music volume without ever stopping. There's just nothing you can do when that happens apart from quickly shutting down the whole soundsystem if you don't want to loose your hearing ability :/

Thanks for pointing to the code. Interestingly, I wasn't able to find that via the github search. I'll try and see what happens when that line is commented-out.

I’ve noticed it happens when you do small adjustments or if you move the dial too fast or too slow. My workaround: stop increasing/decreasing the volume after 5 seconds. Not great to be honest. But not a massive deal breaker for me, not worth installing the ikea bridge just for that.

Currently, the symfonisk controller is unusable, since it will occasionally increase the music volume without ever stopping.

That's not related to this code: it checks for the same buttonevent value, so it doesn't discard a 2003 after a 2001.

How do you control music volume?

How do you control music volume?

I'm starting a 500ms timer loop which increases/decreases volume by 1% on 2001/3001 and stop it on every other event.

Sometimes (especially on short rotations, change of direction and multiple adjustments shortly after another) there isn't any other event.

You're right. Patching that check doesn't help (obviously).
Here's some debug output while I was reproducing the issue:

20:02:50:971 button 3001 Move Down
20:02:50:993 button 3001 Move Down
20:02:50:993 button 3001 Move Down, would discard too fast event (dt = 21)
20:02:51:775 button 3003 Stop
20:02:51:808 no button handler for: SYMFONISK Sound Controller ep: 0x01 cl: 0x0008 cmd: 0x03 pl[0]: 0x00
20:02:56:024 button 3001 Move Down
20:02:56:045 button 3001 Move Down
20:02:56:045 button 3001 Move Down, would discard too fast event (dt = 22)
20:02:56:237 button 2001 Move Up
20:02:56:258 button 2001 Move Up
20:02:56:258 button 2001 Move Up, would discard too fast event (dt = 22)

Another thing I've noticed while staring at the deconz debug log are those lines which do seem to appear quite often.

20:00:42:344 no button handler for: SYMFONISK Sound Controller ep: 0x01 cl: 0x0008 cmd: 0x03 pl[0]: 0x00
20:00:47:150 no button handler for: SYMFONISK Sound Controller ep: 0x01 cl: 0x0008 cmd: 0x03 pl[0]: 0x00
20:00:47:171 no button handler for: SYMFONISK Sound Controller ep: 0x01 cl: 0x0008 cmd: 0x03 pl[0]: 0x00

0x0008 - Level Control (Dimmer)

So those are probably the ones you were talking about regarding ZHARelativeRotary support

How do you control music volume?
I'm starting a 500ms timer loop which increases/decreases volume by 1% on 2001/3001 and stop it on every other event.

Better change the volume on each 2001/3001.

Another thing I've noticed while staring at the deconz debug log are those lines which do seem to appear quite often.

Interesting, the controller is sending another command. Need to check.

Better change the volume on each 2001/3001.

But then you won't get any volume change while rotating with a constant speed

What firmware is your controller on?

The controller is currently running FW 2.1.022.
The OTAU Plugin reports Version 0x21022631 , Image Type 0x11ca and manufacturer id 0x117C.

The latest firmware for this image type seems to be 10043101-3.1-TRADFRI-dimmer-2.1.024.ota.ota.signed which reports as version 0x21024631 in the otau plugin

Should I update the controller?

Edit:

Well. We'll see tomorrow if that new firmware changes anything.
The official changelog states the following:

SYMFONISK Sound Controller V-2.1.024.
Improvement Disconnected state issue.
Improvement Performance.

That's the same version as my controller. They must have released the new version quite recently.

While turning constantly (at least in my perception), I see multiple 2001/2003 events. But sometimes, I see no events at all, when turning.

20:00:47:171 no button handler for: SYMFONISK Sound Controller ep: 0x01 cl: 0x0008 cmd: 0x03 pl[0]: 0x00

Command 0x03 is _Stop_. Problem with that command is, that it doesn't contain the direction (up or down), so we don't know whether to send 2003 or 3003. To cope with that, the REST API plugin stores the directory of the previous _Move_ command. That has worked flawlessly for all devices, since I introduced this, many years ago.

The message would be displayed, when no previous direction has been saved. I think this can only happen when receiving two _Stop_ commands in a row. I need to run the sniffer to see what's happening here. I'll update the controller's firmware first.

Update at 4.07% after 45 minutes. Man this thing is slow.

Meanwhile, I've found a review of the device in the US Ikea shop:

Great concept but have had multiple issues with “run away” volume levels where the speakers just crank themselves full blast to the point I’ve had to scramble to unplug them. Bought four of them but plan to return them all - bummer. Also, set up was a total pain in the you know what - likely due to a dual band router which needed to have the 5ghz channel deactivated temporarily.

That shouldn't keep us from trying to fix that, but it's surely interesting to know that it's happening with the official bridge as way. ..although he doesn't mention that he's using that 🤔

What speakers and volume to you use? What software do you use to map the button events to volume changes?

Update at 4.07% after 45 minutes. Man this thing is slow.

And it will probably fail at 90% or so :-(

I tend to update the IKEA battery-powered devices from my test network (less traffic), making sure the coordinator acts as parent. Still it typically takes 3.5 to 4 hours. Now at 14% in 00:32:30. Mains-powered devices usually take between 10 and 30 minutes.

I've adapted the node-red flow that was pasted in this thread which talks ro home assistant which in turn talks to the logitech media server, ultimately controlling the volume of a few squeezebox booms.

For now, I'm limiting the maximum volume to 70%. That's still very loud but it's not as catastrophic.

Yeah, you tend to get these long chains. I control my Sonos speakers from the controller, using controller -> deCONZ -> Homebridge Hue -> HomeKit automation -> Homebridge ZP -> Sonos. Homebridge Hue translates each x001, x001, ..., x003 series to a _Long Press_ in HomeKit, and Homebridge ZP exposes relative volume setting of the Sonos.

I tried the controller with the IKEA Trådfri hub a while back. The Trådfri hub acts as Sonos client, so the chain is considerably shorter: controller -> hub -> Sonos. From what I remember, it worked a bit smoother, but not flawlessly.

Such a cascaded setup is inherently vulnerable, providing too many places where a message could be lost, and a command goes unstopped. I strongly recommend against using start/stop logic in these cases, but simply send a command per buttonevent. Even the standard Hue app creates Hue bridge rules like this, when holding the _DimUp_ or _DimDown_ buttons of the Hue dimmer. When used standalone (without the bridge), the dimmer does send _Move_ and _Stop_.

Such a cascaded setup is inherently vulnerable, providing too many places where a message could be lost, and a command goes unstopped.

I’m running controller > deCONZ > automation hub > Sonos. And I still have the issue. I’m sure is the controller fault as all the other automation work flawlessly

Even the standard Hue app creates Hue bridge rules like this, when holding the DimUp or DimDown buttons of the Hue dimmer.

You’re right, but the hue dimmer sends _Hold_ events every second until you release. Ikea symfonisk controller doesn’t send a new event at regular intervals; I still don’t get the logic but I’m guessing it sends a new event only when the rate of rotation has changed. But that’s a guess. The only solution is listening for start / stop.

Upgrade succeeded without issues overnight. Now at 2.1.024. Battery down to 16% (from 60%) - I've seen worse. The controller's reliability seems a bit more reliable, but I'm still missing an occasional x003 event.

I re-read "all" comments and other issues regarding the SYMFONISK controller, after a good night's sleep. It seems the communication between the controller and deCONZ is unreliable, causing messages from the controller to arrive at deCONZ out of order, or not at all. The "no button handler" message is caused by two _Stop_ commands to be received in succession; the "discard too fast event" from receiving two _Move_ commands in succession. The more Zigbee hops between the controller and coordinator, the worse these issues get.

It seems the controller sends commands too quickly in succession for the Zigbee network to handle the broadcasts. Effectively, the controller launches a denial-of-service attack on the Zigbee network. Signify recommend at most one broadcast per second, and the Hue bridge tends to have smaller Zigbee networks than deCONZ. Note that the Hue dimmer, Hue button, and Lutron Aurora only send unicast messages for x001 events (effectively acting as sensors). When acting as controllers, they only send a _Move_ on press/hold and a _Stop_ on release.

To confirm, I replaced the group bindings on the controller with unicast bindings to the coordinator. That seems to work miracles.

Make sure to wake the controller when pressing _Bind_ or _Unbind_. The _Bind Dropbox_ displays success when the binding has been created or removed. Retry if needed. Make sure to add the new bindings before removing the old ones, or the controller will go "sleeping beauty" on you, no longer waking on input.

Note that I'm still seeing "discard too fast events" and "no button handler". If the tests are successful, I'll change the check not to discard unicast events. And change the pairing logic for the controller, not to create a group and corresponding binding. I think it makes sense to sacrifice direct light control in favour of working sound control.

I think a similar issue occurs for the Trådfri wireless dimmer. Apparently back then, I decided to map _Move_ to x002 and to ignore _Stop_. That was three years ago, though, I don't remember the details.

@paolotremadio, @Hypfer, others, could you guys please repeat my test and confirm this?

• In the _Binding dropbox_ panel in the deCONZ GUI, bind the client (grey) _On/Off_ cluster on the controller to endpoint 0x01 on the coordinator;
• and bind the client (grey) _Level Control_ cluster on the controller to endpoint 0x01 on the coordinator;
• Check what group the controller is using: in the API lookup the value config.group for the ZHASwitch /sensors resource for the controller. Convert this value to hex.
• In the _Binding dropbox_ panel in the deCONZ GUI, unbind the client (grey) _On/Off_ cluster on the controller from that group (in hex);
• And unbind the client (grey) _Level Control_ cluster on the controller from the group (in hex).

@paolotremadio, @Hypfer, others, could you guys please repeat my test and confirm this?

• In the _Binding dropbox_ panel in the deCONZ GUI, bind the client (grey) _On/Off_ cluster on the controller to endpoint 0x01 on the coordinator;
• and bind the client (grey) _Level Control_ cluster on the controller to endpoint 0x01 on the coordinator;
• Check what group the controller is using: in the API lookup the value config.group for the ZHASwitch /sensors resource for the controller. Convert this value to hex.
• In the _Binding dropbox_ panel in the deCONZ GUI, unbind the client (grey) _On/Off_ cluster on the controller from that group (in hex);
• And unbind the client (grey) _Level Control_ cluster on the controller from the group (in hex).

Done that. One controller seems to work much more reliably. The other one misses some stops but it feels like not as often as before. I'll test it for a day or two.

I'll try it out at some point later.
Thank you for your investigation and work @ebaauw
Maybe we should keep #2195 open for that issue?

Maybe we should keep #2195 open for that issue?

Yeah, it doesn't seem to be related to this issue.

OK, took out the sniffer. When bound to the coordinator, the Trådfri wireless dimmer sends broadcasts to group 0x0000. So this workaround cannot be used with that device.

The controller seems to send multiple unicast messages per action, when bound to the coordinator. They have the same ZCL sequence number, but different MAC and NWK sequence numbers. Checking for repeat buttonevent values only on group messages now results in three x001 and one x003 per series. I'll try and check on ZCL sequence number and filter out duplicate messages.

Added the check on ZCL sequence number. Now it behaves as I'd expect. While turning I see a continuous stream of x001/x003 buttonevent pairs. I double-checked the sniffer log: the _Move_ always seems to be followed by a _Stop_, within 300ms. I think there's no added value in exposing x001 vs x003, and propose to change it to a single x002, just as for the Trådfri wireless dimmer.

Note that the number of buttonevents reflects the _duration_ of the turn, not the angle nor the speed. There is no special message to indicate that you stop turning. Just the absence of the following _Move_/_Stop_ pair.

Please note how cool it is to see milliseconds in lastupdated ;-)

Apr 17 14:53:13 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2001,"lastupdated":"2020-04-17T12:53:13.126"}
Apr 17 14:53:13 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2003,"lastupdated":"2020-04-17T12:53:13.309"}
Apr 17 14:53:13 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2001,"lastupdated":"2020-04-17T12:53:13.329"}
Apr 17 14:53:13 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2003,"lastupdated":"2020-04-17T12:53:13.509"}
Apr 17 14:53:13 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2001,"lastupdated":"2020-04-17T12:53:13.523"}
Apr 17 14:53:13 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2003,"lastupdated":"2020-04-17T12:53:13.884"}
Apr 17 14:53:13 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2001,"lastupdated":"2020-04-17T12:53:13.917"}
Apr 17 14:53:14 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2003,"lastupdated":"2020-04-17T12:53:14.102"}
Apr 17 14:53:14 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2001,"lastupdated":"2020-04-17T12:53:14.118"}
Apr 17 14:53:14 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2003,"lastupdated":"2020-04-17T12:53:14.305"}
Apr 17 14:53:14 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2001,"lastupdated":"2020-04-17T12:53:14.357"}
Apr 17 14:53:14 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2003,"lastupdated":"2020-04-17T12:53:14.547"}
Apr 17 14:53:14 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2001,"lastupdated":"2020-04-17T12:53:14.617"}
Apr 17 14:53:14 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2003,"lastupdated":"2020-04-17T12:53:14.806"}
Apr 17 14:53:14 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2001,"lastupdated":"2020-04-17T12:53:14.892"}
Apr 17 14:53:15 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2003,"lastupdated":"2020-04-17T12:53:15.079"}
Apr 17 14:53:15 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2001,"lastupdated":"2020-04-17T12:53:15.283"}
Apr 17 14:53:15 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2003,"lastupdated":"2020-04-17T12:53:15.472"}
Apr 17 14:53:15 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2001,"lastupdated":"2020-04-17T12:53:15.641"}
Apr 17 14:53:15 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2003,"lastupdated":"2020-04-17T12:53:15.823"}
Apr 17 14:53:15 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2001,"lastupdated":"2020-04-17T12:53:15.923"}
Apr 17 14:53:16 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2003,"lastupdated":"2020-04-17T12:53:16.104"}
Apr 17 14:53:16 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2001,"lastupdated":"2020-04-17T12:53:16.194"}
Apr 17 14:53:16 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2003,"lastupdated":"2020-04-17T12:53:16.378"}
Apr 17 14:53:16 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2001,"lastupdated":"2020-04-17T12:53:16.459"}
Apr 17 14:53:16 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2003,"lastupdated":"2020-04-17T12:53:16.663"}
Apr 17 14:53:16 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2001,"lastupdated":"2020-04-17T12:53:16.691"}
Apr 17 14:53:16 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2003,"lastupdated":"2020-04-17T12:53:16.876"}
Apr 17 14:53:16 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2001,"lastupdated":"2020-04-17T12:53:16.904"}
Apr 17 14:53:17 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2003,"lastupdated":"2020-04-17T12:53:17.071"}
Apr 17 14:53:17 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2001,"lastupdated":"2020-04-17T12:53:17.102"}
Apr 17 14:53:17 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2003,"lastupdated":"2020-04-17T12:53:17.292"}
Apr 17 14:53:17 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2001,"lastupdated":"2020-04-17T12:53:17.353"}
Apr 17 14:53:17 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2003,"lastupdated":"2020-04-17T12:53:17.537"}
Apr 17 14:53:17 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2001,"lastupdated":"2020-04-17T12:53:17.553"}
Apr 17 14:53:17 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2003,"lastupdated":"2020-04-17T12:53:17.734"}
Apr 17 14:53:17 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2001,"lastupdated":"2020-04-17T12:53:17.746"}
Apr 17 14:53:18 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":2003,"lastupdated":"2020-04-17T12:53:18.102"}

Apr 17 14:53:22 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3001,"lastupdated":"2020-04-17T12:53:22.936"}
Apr 17 14:53:23 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3003,"lastupdated":"2020-04-17T12:53:23.122"}
Apr 17 14:53:23 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3001,"lastupdated":"2020-04-17T12:53:23.234"}
Apr 17 14:53:23 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3003,"lastupdated":"2020-04-17T12:53:23.424"}
Apr 17 14:53:23 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3001,"lastupdated":"2020-04-17T12:53:23.593"}
Apr 17 14:53:23 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3003,"lastupdated":"2020-04-17T12:53:23.776"}
Apr 17 14:53:23 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3001,"lastupdated":"2020-04-17T12:53:23.899"}
Apr 17 14:53:24 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3003,"lastupdated":"2020-04-17T12:53:24.088"}
Apr 17 14:53:24 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3001,"lastupdated":"2020-04-17T12:53:24.186"}
Apr 17 14:53:24 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3003,"lastupdated":"2020-04-17T12:53:24.370"}
Apr 17 14:53:24 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3001,"lastupdated":"2020-04-17T12:53:24.456"}
Apr 17 14:53:24 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3003,"lastupdated":"2020-04-17T12:53:24.641"}
Apr 17 14:53:24 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3001,"lastupdated":"2020-04-17T12:53:24.750"}
Apr 17 14:53:24 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3003,"lastupdated":"2020-04-17T12:53:24.938"}
Apr 17 14:53:25 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3001,"lastupdated":"2020-04-17T12:53:25.086"}
Apr 17 14:53:25 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3003,"lastupdated":"2020-04-17T12:53:25.271"}
Apr 17 14:53:25 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3001,"lastupdated":"2020-04-17T12:53:25.401"}
Apr 17 14:53:25 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3003,"lastupdated":"2020-04-17T12:53:25.586"}
Apr 17 14:53:25 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3001,"lastupdated":"2020-04-17T12:53:25.670"}
Apr 17 14:53:25 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3003,"lastupdated":"2020-04-17T12:53:25.860"}
Apr 17 14:53:25 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3001,"lastupdated":"2020-04-17T12:53:25.968"}
Apr 17 14:53:26 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3003,"lastupdated":"2020-04-17T12:53:26.147"}
Apr 17 14:53:26 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3001,"lastupdated":"2020-04-17T12:53:26.338"}
Apr 17 14:53:26 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3003,"lastupdated":"2020-04-17T12:53:26.522"}
Apr 17 14:53:26 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3001,"lastupdated":"2020-04-17T12:53:26.705"}
Apr 17 14:53:26 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3003,"lastupdated":"2020-04-17T12:53:26.889"}
Apr 17 14:53:27 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3001,"lastupdated":"2020-04-17T12:53:27.093"}
Apr 17 14:53:27 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3003,"lastupdated":"2020-04-17T12:53:27.276"}
Apr 17 14:53:27 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3001,"lastupdated":"2020-04-17T12:53:27.442"}
Apr 17 14:53:27 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3003,"lastupdated":"2020-04-17T12:53:27.635"}
Apr 17 14:53:27 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3001,"lastupdated":"2020-04-17T12:53:27.776"}
Apr 17 14:53:27 pi5 dc_eventlog[879]: /sensors/7/state: {"buttonevent":3003,"lastupdated":"2020-04-17T12:53:27.957"}

Added the check on ZCL sequence number. Now it behaves as I'd expect. While turning I see a continuous stream of x001/x003 buttonevent pairs. I double-checked the sniffer log: the _Move_ always seems to be followed by a _Stop_, within 300ms. I think there's no added value in exposing x001 vs x003, and propose to change it to a single x002, just as for the Trådfri wireless dimmer.

Note that the number of buttonevents reflects the _duration_ of the turn, not the angle nor the speed. There is no special message to indicate that you stop turning. Just the absence of the following _Move_/_Stop_ pair.

Please note how cool it is to see milliseconds in lastupdated ;-)

That's really great. It would enable a much better volume control. Is there a branch to be tested?

See above commit. Note that this one does send x002 events instead of x001/x003 pairs. Best delete the current /sensors resource (should also cleanup the associated group), and re-pair the controller. Plugin should setup the binding to the coordinator on pairing.

Damn. config.group was re-created when loading the sensor from the database.

The controller actually updated sucesssfully. It just took > 24h to finish.
Anyways. I've removed it from deconz, built the latest ebaauw/master rest-plugin branch and re-paired the controller.

Sadly, I'm only seeing a single x002 event no matter how long I spin the dial :(

I'm seeing quite a few of these:

19:26:31:324 discard sensor state push for 70: state/lastupdated (already pushed)
19:27:44:051 discard sensor state push for 70: state/lastupdated (already pushed)

Edit:
Commenting-out that check didn't solve the issue. Now it just sends the same single event twice

And /sensors/70 is the controller?

Yes, /sensors/70 is the symfonisk controller. That doesn't seem to be the issue though :/

No, the message indicates that multiple attributes of the same state or config object have been changed. Each attribute change generates an internal event. When the first event is handled, it issues a web socket notification of all (or, depending on websocketnofityall, all changed) attributes. The other events don't need to issue a notification, since the change has already been pushed. So we they issue this message instead.

Anything else to look for?

You're seeing a constant flow of x002 events on the websocket?

Yes. 328 is the contoller:

Apr 18 19:54:14 pi2 dc_eventlog[860]: /sensors/452/state: {"lastupdated":"2020-04-18T17:54:14.069"}
Apr 18 19:54:19 pi2 dc_eventlog[860]: /sensors/452/state: {"lastupdated":"2020-04-18T17:54:19.539"}
Apr 18 19:54:20 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":2002,"lastupdated":"2020-04-18T17:54:20.636"}
Apr 18 19:54:21 pi2 dc_eventlog[860]: /sensors/426/state: {"lastupdated":"2020-04-18T17:54:21.397","power":23}
Apr 18 19:54:21 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":2002,"lastupdated":"2020-04-18T17:54:21.417"}
Apr 18 19:54:21 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":2002,"lastupdated":"2020-04-18T17:54:21.758"}
Apr 18 19:54:22 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":2002,"lastupdated":"2020-04-18T17:54:21.991"}
Apr 18 19:54:22 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":2002,"lastupdated":"2020-04-18T17:54:22.233"}
Apr 18 19:54:24 pi2 dc_eventlog[860]: /sensors/453/state: {"lastupdated":"2020-04-18T17:54:23.967"}
Apr 18 19:54:24 pi2 dc_eventlog[860]: /sensors/314/state: {"lastupdated":"2020-04-18T17:54:24.821"}
Apr 18 19:54:25 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":3002,"lastupdated":"2020-04-18T17:54:25.194"}
Apr 18 19:54:25 pi2 dc_eventlog[860]: /sensors/426/state: {"lastupdated":"2020-04-18T17:54:25.294","power":21}
Apr 18 19:54:26 pi2 dc_eventlog[860]: /sensors/426/state: {"lastupdated":"2020-04-18T17:54:26.329","power":23}
Apr 18 19:54:26 pi2 dc_eventlog[860]: /sensors/454/state: {"lastupdated":"2020-04-18T17:54:26.449"}
Apr 18 19:54:27 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":3002,"lastupdated":"2020-04-18T17:54:27.931"}
Apr 18 19:54:27 pi2 dc_eventlog[860]: /sensors/453/state: {"lastupdated":"2020-04-18T17:54:27.953"}
Apr 18 19:54:28 pi2 dc_eventlog[860]: /sensors/426/state: {"current":247,"lastupdated":"2020-04-18T17:54:28.294"}
Apr 18 19:54:29 pi2 dc_eventlog[860]: /sensors/426/state: {"lastupdated":"2020-04-18T17:54:29.291","power":21}
Apr 18 19:54:31 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":3002,"lastupdated":"2020-04-18T17:54:31.675"}
Apr 18 19:54:31 pi2 dc_eventlog[860]: /sensors/296/state: {"lastupdated":"2020-04-18T17:54:31.736"}
Apr 18 19:54:31 pi2 dc_eventlog[860]: /sensors/296/state: {"lastupdated":"2020-04-18T17:54:31.756"}
Apr 18 19:54:31 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":3002,"lastupdated":"2020-04-18T17:54:31.954"}
Apr 18 19:54:32 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":3002,"lastupdated":"2020-04-18T17:54:32.245"}
Apr 18 19:54:32 pi2 dc_eventlog[860]: /sensors/426/state: {"lastupdated":"2020-04-18T17:54:32.304","power":23}
Apr 18 19:54:32 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":3002,"lastupdated":"2020-04-18T17:54:32.529"}
Apr 18 19:54:32 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":3002,"lastupdated":"2020-04-18T17:54:32.816"}
Apr 18 19:54:33 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":3002,"lastupdated":"2020-04-18T17:54:33.228"}
Apr 18 19:54:33 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":3002,"lastupdated":"2020-04-18T17:54:33.605"}
Apr 18 19:54:34 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":3002,"lastupdated":"2020-04-18T17:54:34.019"}
Apr 18 19:54:34 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":3002,"lastupdated":"2020-04-18T17:54:34.606"}
Apr 18 19:54:34 pi2 dc_eventlog[860]: /sensors/112/state: {"lastupdated":"2020-04-18T17:54:34.730"}
Apr 18 19:54:35 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":3002,"lastupdated":"2020-04-18T17:54:35.147"}
Apr 18 19:54:35 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":3002,"lastupdated":"2020-04-18T17:54:35.408"}
Apr 18 19:54:35 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":3002,"lastupdated":"2020-04-18T17:54:35.679"}
Apr 18 19:54:36 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":3002,"lastupdated":"2020-04-18T17:54:35.955"}
Apr 18 19:54:36 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":2002,"lastupdated":"2020-04-18T17:54:36.668"}
Apr 18 19:54:36 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":2002,"lastupdated":"2020-04-18T17:54:36.948"}
Apr 18 19:54:37 pi2 dc_eventlog[860]: /sensors/113/state: {"lastupdated":"2020-04-18T17:54:37.876"}
Apr 18 19:54:38 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":2002,"lastupdated":"2020-04-18T17:54:38.409"}
Apr 18 19:54:38 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":2002,"lastupdated":"2020-04-18T17:54:38.611"}
Apr 18 19:54:38 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":2002,"lastupdated":"2020-04-18T17:54:38.778"}
Apr 18 19:54:39 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":2002,"lastupdated":"2020-04-18T17:54:39.139"}
Apr 18 19:54:39 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":2002,"lastupdated":"2020-04-18T17:54:39.386"}
Apr 18 19:54:39 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":2002,"lastupdated":"2020-04-18T17:54:39.572"}
Apr 18 19:54:40 pi2 dc_eventlog[860]: /sensors/328/state: {"buttonevent":2002,"lastupdated":"2020-04-18T17:54:40.242"}
Apr 18 19:54:42 pi2 dc_eventlog[860]: /sensors/426/state: {"lastupdated":"2020-04-18T17:54:42.298","power":21}
Apr 18 19:54:45 pi2 dc_eventlog[860]: /sensors/434/state: {"lastupdated":"2020-04-18T17:54:45.049","voltage":237}

Hm. Deleting and re-pairing it again didn't solve it either

Can you check the deCONZ log for something like:

Apr 18 20:01:23 pi2 deCONZ[19662]: 20:01:22:713 APS-DATA.indication srcAddr: 0x56b2, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 255, rssi: -49
Apr 18 20:01:23 pi2 deCONZ[19662]: 20:01:22:713     asdu: 117f0100c30000
Apr 18 20:01:23 pi2 deCONZ[19662]: 20:01:22:716 button 2002 Move Up

The scrAddr is the NWK address of the controller. As I understand dstAddrMode: 2 indicates a NWK address, so a unicast to the coordinator. For groupscasts it's 1.

Over 24h for a firmware update is over four times as long as usual. Maybe indicative of network (interference) issues?

How big is your network? How far away (how many hops) is the controller from the coordinator? Do you run any automations that could be clogging the network (>1 broadcast per second)?

What about interference? Any error codes in the log (see https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Zigbee-Error-Codes-in-the-Log). Are you using a RaspBee or a ConBee? If latter: connected to USB2 port using extension cable? Any nearby Wifi, bluetooth, USB3, DECT, ... devices that might use or interfere with the 2.4 GHz band?

Firmware updates of mains-connected devices do work normally (read: 30-45minutes).
Currently it's a 73 node network which is pretty much idle. Raspbee module. No errors logged.

It's currently one hop away from the coordinator. Said hop is a hue playbar if that matters

I've re-paired the device again and received APS messages. Nothing like APS-DATA.indication though

20:13:23:171 APS-DATA.indication from unknown node 0xCCCCCCFFFEE084E5
20:13:23:171 ZDP device announce: 0xCCCCCCFFFEE084E5, 0x9E24, 0x80
20:13:23:186 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 2, node: 0x9E24
20:13:23:186 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 1, node: 0x9E24
20:13:23:186 new node - ext: 0xccccccfffee084e5, nwk: 0x9E24
20:13:23:187 device announce 0xCCCCCCFFFEE084E5 (0x9E24) mac capabilities 0x8020:13:23:187 set fast probe address to 0xCCCCCCFFFEE084E5 (0x9E24)
20:13:23:187 FP indication 0x0000 / 0x0013 (0xCCCCCCFFFEE084E5 / 0x9E24)
20:13:23:187                       ...     (0xCCCCCCFFFEE084E5 / 0x9E24
20:13:23:187 device announce 0xCCCCCCFFFEE084E5 (0x9E24) mac capabilities 0x80

20:13:30:335 FP indication 0x0104 / 0x0019 (0xCCCCCCFFFEE084E5 / 0x9E24)
20:13:30:335                       ...     (0xCCCCCCFFFEE084E5 / 0x9E24)

20:13:31:945 FP indication 0x0104 / 0x0003 (0xCCCCCCFFFEE084E5 / 0x9E24)
20:13:31:945                       ...     (0xCCCCCCFFFEE084E5 / 0x9E24)

20:13:39:757 ZDP status = 0x00 -> SUCCESS
20:13:39:757 ZDP Node_Descriptor_rsp 0xCCCCCCFFFEE084E5 - 0x9E24
20:13:39:757 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 3, node: 0x9E24
20:13:39:757 DB pushZdpDescriptorDb()
20:13:39:757 DB save zll database items 0x00000800
20:13:39:757 DB sql exec UPDATE devices SET nwk = 40484 WHERE mac = 'cc:cc:cc:ff:fe:e0:84:e5';INSERT INTO devices (mac,nwk,timestamp) SELECT 'cc:cc:cc:ff:fe:e0:84:e5', 40484, strftime('%s','now') WHERE (SELECT changes() = 0);
20:13:39:921 DB saved in 164 ms
20:13:39:923 DB UPDATE device_descriptors SET data = x'0240807c11525200002c520000', timestamp = 1587233619 WHERE device_id = (SELECT id FROM devices WHERE mac = 'cc:cc:cc:ff:fe:e0:84:e5') AND endpoint = 0 AND type = 2
20:13:39:923 DB INSERT INTO device_descriptors (device_id, endpoint, type, data, timestamp) SELECT id, 0, 2, x'0240807c11525200002c520000', 1587233619 FROM devices WHERE mac = 'cc:cc:cc:ff:fe:e0:84:e5'
20:13:40:302 don't close database yet, keep open for 900 seconds
20:13:40:309 FP indication 0x0000 / 0x8002 (0xCCCCCCFFFEE084E5 / 0x9E24)
20:13:40:309                       ...     (0xCCCCCCFFFEE084E5 / 0x9E24)
20:13:40:309 ZDP indication search sensors 0xCCCCCCFFFEE084E5 (0x9E24) cluster 0x8002
20:13:40:309 ZDP indication search sensors 0xCCCCCCFFFEE084E5 (0x9E24) clear timeout on cluster 0x8002

20:13:41:812 void deCONZ::zmNode::setFetched(deCONZ::RequestId, bool) fetched item: 7, node: 0x9E24
20:13:41:817 FP indication 0x0000 / 0x8005 (0xCCCCCCFFFEE084E5 / 0x9E24)
20:13:41:817                       ...     (0xCCCCCCFFFEE084E5 / 0x9E24)
20:13:41:817 ZDP indication search sensors 0xCCCCCCFFFEE084E5 (0x9E24) cluster 0x8005
20:13:41:817 ZDP indication search sensors 0xCCCCCCFFFEE084E5 (0x9E24) clear timeout on cluster 0x8005
20:13:41:828 don't use deleted sensor and node 0xCCCCCCFFFEE084E5 as candidate

Nothing like APS-DATA.indication though

You'd see these when pushing or turning the controller. Hopefully every ~300ms while turning.

Cannot confirm. I was triggering button events all the time.

Do I need a debug cli flag or something for that to appear? I was using this commandline deCONZ --dbg-info=2 --dbg-zdp=1 --dbg-zcl=1 --db-aps=1 --dbg-http=1

You definitely want to add --dbg-error=1. Dunno why they don't display errors by default.

To see the APS payload (asdu), set --dbg-aps=2.

Still need to document these command-line parameters in the WIki...

Ah yes. Now I can see those events.

21:25:37:225 APS-DATA.indication srcAddr: 0x9e24, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 127, rssi: -67
21:25:37:307 APS-DATA.indication srcAddr: 0x9e24, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 191, rssi: -67
21:25:38:312 APS-DATA.indication srcAddr: 0x9e24, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 191, rssi: -67
21:25:38:402 APS-DATA.indication srcAddr: 0x9e24, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 191, rssi: -67
21:25:38:512 APS-DATA.indication srcAddr: 0x9e24, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 191, rssi: -67
21:25:38:599 APS-DATA.indication srcAddr: 0x9e24, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 191, rssi: -67
21:25:40:397 APS-DATA.indication srcAddr: 0x9e24, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 191, rssi: -67
21:25:40:507 APS-DATA.indication srcAddr: 0x9e24, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 191, rssi: -67
21:25:42:748 APS-DATA.indication srcAddr: 0x9e24, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 191, rssi: -67
21:25:42:875 APS-DATA.indication srcAddr: 0x9e24, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 191, rssi: -67
21:25:44:635 APS-DATA.indication srcAddr: 0x9e24, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 191, rssi: -67
21:25:44:740 APS-DATA.indication srcAddr: 0x9e24, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 191, rssi: -67
21:25:44:851 APS-DATA.indication srcAddr: 0x9e24, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 191, rssi: -67
21:25:44:939 APS-DATA.indication srcAddr: 0x9e24, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 191, rssi: -67
21:25:52:764 APS-DATA.indication srcAddr: 0x9e24, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 191, rssi: -67
21:25:52:846 APS-DATA.indication srcAddr: 0x9e24, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 191, rssi: -67
21:25:56:046 APS-DATA.indication srcAddr: 0x9e24, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 191, rssi: -67
21:25:56:129 APS-DATA.indication srcAddr: 0x9e24, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 191, rssi: -67
21:26:01:008 APS-DATA.indication srcAddr: 0x9e24, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 191, rssi: -67
21:26:01:069 APS-DATA.indication srcAddr: 0x9e24, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 191, rssi: -67

Here are a few with the asdu payload as well:

21:24:46:719 APS-DATA.indication srcAddr: 0x9e24, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 95, rssi: -79
21:24:46:719    asdu: 11660101c30000
21:24:46:719 APS-DATA.request id: 179 erase from queue
21:24:46:838 APS-DATA.indication srcAddr: 0x9e24, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 103, rssi: -78
21:24:46:838    asdu: 1167030000
21:24:46:931 APS-DATA.indication srcAddr: 0x9e24, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 95, rssi: -79
21:24:46:931    asdu: 1167030000

OK, that's hopeful. AddrMode 2, so the unicast binding seems in effect. I see a _Move_ (third byte 01) at .719 followed by a _Stop_ (third byte 03) at .838 and .931. Note that the ZCL sequence (second byte, 67) is the same for the _Stop_ commands (67), the controller sends each command three times (see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1898#issuecomment-615154288).

The deCONZ logging really sucks there's no easy way to grep only the messages for a single device, as they mix mac address, nwk address, resource and resource name. But can you see if the APS-DATA.indicationfor the _Move_ commandis followed by a button 2002 Move Up or button 3002 Move Down?

You want to analyse your log for missing messages, to get an idea of the reliability of the traffic from the controller to the coordinator. If you see large gaps in the sequence numbers, it would explain why you don't get the repeated buttonevents.

Below is an extract from my log. You see a _Move_/_Stop_ pair, several 100ms after each other, followed by the next _Move_/_Stop_ pair within several 10ms. You see that two messages (sequence 4b and 5b) didn't make it through to the coordinator. Somehow I don't see any repeated messages, maybe one of the routers between the controller and the coordinator figured they wouldn't forward duplicates?

Apr 18 21:56:05 pi2 deCONZ[19662]: 21:56:04:379 APS-DATA.indication srcAddr: 0xd46b, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 151, rssi: -72
Apr 18 21:56:05 pi2 deCONZ[19662]: 21:56:04:379     asdu: 11460100c30000
Apr 18 21:56:05 pi2 deCONZ[19662]: 21:56:04:379 button 2002 Move Up
Apr 18 21:56:05 pi2 deCONZ[19662]: 21:56:04:963 APS-DATA.indication srcAddr: 0xd46b, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 151, rssi: -72
Apr 18 21:56:05 pi2 deCONZ[19662]: 21:56:04:963     asdu: 1147030000

Apr 18 21:56:05 pi2 deCONZ[19662]: 21:56:04:992 APS-DATA.indication srcAddr: 0xd46b, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 159, rssi: -71
Apr 18 21:56:05 pi2 deCONZ[19662]: 21:56:04:992     asdu: 11480100c30000
Apr 18 21:56:05 pi2 deCONZ[19662]: 21:56:04:992 button 2002 Move Up
Apr 18 21:56:06 pi2 deCONZ[19662]: 21:56:06:113 APS-DATA.indication srcAddr: 0xd46b, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 159, rssi: -71
Apr 18 21:56:06 pi2 deCONZ[19662]: 21:56:06:113     asdu: 1149030000

Apr 18 21:56:06 pi2 deCONZ[19662]: 21:56:06:186 APS-DATA.indication srcAddr: 0xd46b, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 159, rssi: -71
Apr 18 21:56:06 pi2 deCONZ[19662]: 21:56:06:186     asdu: 114a0100c30000
Apr 18 21:56:06 pi2 deCONZ[19662]: 21:56:06:186 button 2002 Move Up

Apr 18 21:56:07 pi2 deCONZ[19662]: 21:56:07:632 APS-DATA.indication srcAddr: 0xd46b, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 151, rssi: -72
Apr 18 21:56:07 pi2 deCONZ[19662]: 21:56:07:632     asdu: 114c0100c30000
Apr 18 21:56:07 pi2 deCONZ[19662]: 21:56:07:633 button 2002 Move Up
Apr 18 21:56:09 pi2 deCONZ[19662]: 21:56:08:739 APS-DATA.indication srcAddr: 0xd46b, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 159, rssi: -71
Apr 18 21:56:09 pi2 deCONZ[19662]: 21:56:08:739     asdu: 114d030000

Apr 18 21:56:09 pi2 deCONZ[19662]: 21:56:08:771 APS-DATA.indication srcAddr: 0xd46b, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 159, rssi: -71
Apr 18 21:56:09 pi2 deCONZ[19662]: 21:56:08:771     asdu: 114e0100c30000
Apr 18 21:56:09 pi2 deCONZ[19662]: 21:56:08:772 button 2002 Move Up
Apr 18 21:56:09 pi2 deCONZ[19662]: 21:56:08:974 APS-DATA.indication srcAddr: 0xd46b, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 159, rssi: -71
Apr 18 21:56:09 pi2 deCONZ[19662]: 21:56:08:974     asdu: 114f030000

Apr 18 21:56:09 pi2 deCONZ[19662]: 21:56:09:009 APS-DATA.indication srcAddr: 0xd46b, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 159, rssi: -71
Apr 18 21:56:09 pi2 deCONZ[19662]: 21:56:09:009     asdu: 11500100c30000
Apr 18 21:56:09 pi2 deCONZ[19662]: 21:56:09:010 button 2002 Move Up
Apr 18 21:56:09 pi2 deCONZ[19662]: 21:56:09:346 APS-DATA.indication srcAddr: 0xd46b, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 167, rssi: -70
Apr 18 21:56:09 pi2 deCONZ[19662]: 21:56:09:346     asdu: 1151030000

Apr 18 21:56:09 pi2 deCONZ[19662]: 21:56:09:429 APS-DATA.indication srcAddr: 0xd46b, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 159, rssi: -71
Apr 18 21:56:09 pi2 deCONZ[19662]: 21:56:09:429     asdu: 11520100c30000
Apr 18 21:56:09 pi2 deCONZ[19662]: 21:56:09:429 button 2002 Move Up
Apr 18 21:56:10 pi2 deCONZ[19662]: 21:56:09:614 APS-DATA.indication srcAddr: 0xd46b, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 106, rssi: -71
Apr 18 21:56:10 pi2 deCONZ[19662]: 21:56:09:614     asdu: 1153030000

Apr 18 21:56:10 pi2 deCONZ[19662]: 21:56:09:824 APS-DATA.indication srcAddr: 0xd46b, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 159, rssi: -71
Apr 18 21:56:10 pi2 deCONZ[19662]: 21:56:09:824     asdu: 11540100c30000
Apr 18 21:56:10 pi2 deCONZ[19662]: 21:56:09:824 button 2002 Move Up
Apr 18 21:56:10 pi2 deCONZ[19662]: 21:56:10:004 APS-DATA.indication srcAddr: 0xd46b, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 159, rssi: -71
Apr 18 21:56:10 pi2 deCONZ[19662]: 21:56:10:004     asdu: 1155030000

Apr 18 21:56:12 pi2 deCONZ[19662]: 21:56:12:090 APS-DATA.indication srcAddr: 0xd46b, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 159, rssi: -71
Apr 18 21:56:12 pi2 deCONZ[19662]: 21:56:12:090     asdu: 11560100c30000
Apr 18 21:56:12 pi2 deCONZ[19662]: 21:56:12:090 button 2002 Move Up
Apr 18 21:56:12 pi2 deCONZ[19662]: 21:56:12:363 APS-DATA.indication srcAddr: 0xd46b, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 151, rssi: -72
Apr 18 21:56:12 pi2 deCONZ[19662]: 21:56:12:364     asdu: 1157030000

Apr 18 21:56:12 pi2 deCONZ[19662]: 21:56:12:432 APS-DATA.indication srcAddr: 0xd46b, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 151, rssi: -72
Apr 18 21:56:12 pi2 deCONZ[19662]: 21:56:12:432     asdu: 11580100c30000
Apr 18 21:56:12 pi2 deCONZ[19662]: 21:56:12:433 button 2002 Move Up
Apr 18 21:56:13 pi2 deCONZ[19662]: 21:56:12:632 APS-DATA.indication srcAddr: 0xd46b, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 151, rssi: -72
Apr 18 21:56:13 pi2 deCONZ[19662]: 21:56:12:632     asdu: 1159030000

Apr 18 21:56:13 pi2 deCONZ[19662]: 21:56:12:662 APS-DATA.indication srcAddr: 0xd46b, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 151, rssi: -72
Apr 18 21:56:13 pi2 deCONZ[19662]: 21:56:12:662     asdu: 115a0100c30000
Apr 18 21:56:13 pi2 deCONZ[19662]: 21:56:12:662 button 2002 Move Up

Apr 18 21:56:13 pi2 deCONZ[19662]: 21:56:12:928 APS-DATA.indication srcAddr: 0xd46b, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 151, rssi: -72
Apr 18 21:56:13 pi2 deCONZ[19662]: 21:56:12:928     asdu: 115c0100c30000
Apr 18 21:56:13 pi2 deCONZ[19662]: 21:56:12:929 button 2002 Move Up
Apr 18 21:56:13 pi2 deCONZ[19662]: 21:56:13:049 APS-DATA.indication srcAddr: 0xd46b, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 106, rssi: -71
Apr 18 21:56:13 pi2 deCONZ[19662]: 21:56:13:049     asdu: 115d030000

There's never two of the same button events in a row even while constantly spinning since there doesn't seem to be a constant stream of APS-DATA.indication at all.

This is 10s of constant clockwise spinning:

12:29:58:665 APS-DATA.indication srcAddr: 0x48c0, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 167, rssi: -70
12:29:58:665    asdu: 116c0100c30000
12:29:58:666 button 2002 Move Up
--
12:29:58:686 APS-DATA.indication srcAddr: 0x48c0, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 175, rssi: -69
12:29:58:686    asdu: 116c0100c30000
12:29:58:723 APS-DATA.indication srcAddr: 0x463a, srcEp: 0x0B dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 167, rssi: -70
--
12:30:01:545 APS-DATA.indication srcAddr: 0x48c0, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 167, rssi: -70
12:30:01:545    asdu: 116d0101c30000
12:30:01:546 button 3002 Move Down
--
12:30:01:574 APS-DATA.indication srcAddr: 0x48c0, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 167, rssi: -70
12:30:01:574    asdu: 116d0101c30000
12:30:01:603 APS-DATA.indication srcAddr: 0x48c0, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 167, rssi: -70
12:30:01:603    asdu: 116e0100c30000
12:30:01:604 button 2002 Move Up
--
12:30:01:624 APS-DATA.indication srcAddr: 0x48c0, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 167, rssi: -70
12:30:01:624    asdu: 116e0100c30000
12:30:02:219 poll node 00:17:88:01:06:92:7e:a0-0b
--
12:30:07:328 APS-DATA.indication srcAddr: 0x48c0, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 167, rssi: -70
12:30:07:328    asdu: 116f030000
12:30:07:328 Force binding of attribute reporting for sensor SYMFONISK controller
12:30:07:351 APS-DATA.indication srcAddr: 0x48c0, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0008, lqi: 167, rssi: -70
12:30:07:351    asdu: 116f030000

For reference:
Using grep with -A2 to show the following two lines of a match seems to work quite well.
deCONZ --dbg-error=1 --dbg-aps=2 --dbg-info=2 | grep -A2 -E -i "APS-DATA.indication srcAddr: 0x48c0"

Cool, didn’t know the -A option to grep.

So your controller sends:

• 6c: _Move Up_ which results in a 2002 button event;
• 6c: _Move Up_ repeated, which is rightly ignored;
• 6d: _Move Down_ which results in a 3002 button event;
• 6d: _Move Down_ repeated, which is rightly ignored;
• 6e: _Move Up_, which results in a 2002 button event;
• 6e: _Move Up_, repeated and rightly igonored;
• 6f: _Stop_, now ignored, since we no longer to x001/x003;
• 6f: _Stop_, repeated and rightly ignored.

The good news: No missing messages (sequential sequence numbers), so your network seems fine.

The bad news: very different behaviour from my controller. Also, I'm puzzled by the _Move Down_ in between the _Move Up_ messages. Just to be sure: did you replace the battery after the firmware upgrade?

What type is printed on the back of your controller (mine says E1744). Can you double-check the _Basic_ cluster attributes?

There doesn't seem to be any magic setting on the device, that would change its behaviour. I'm starting to suspect a faulty device. Hard to tell whether that's yours or mine, with just two devices to compare, but mine did work as expected when paired to the Trådfri hub.

lgtm. The text on the back also states TYPE E1744 and even with a new button cell (the fourth one actually) it still behaves like this.

Is yours directly connected to the controller?

Doing short bursts in rapid succession works btw. It's just the continuous spinning which seems to be broken

I did order two of those actually so I just took the second one out of its packaging and paired it to the network.

The behaviour is exactly the same which probably rules out defective hardware as well as the firmware version

I'm out of ideas, I'm afraid. Or maybe it's related to the colour? Mine is black. Almost tempted to get a second controller myself.

Is yours directly connected to the controller?

It's currently connected to an innr SP 120 smart plug. It was connected to the coordinator (Conbee II) in my test network (for fastest firmware upgrade).

Would like to hear from @paolotremadio, @rchl, and others how their controllers behave.

Anyways, I reverted to x001/x003 button events by default, but it won't solve your issue of run-away changes in case a _Stop_ is missed.

Use the API to set mode to 4 (ModeDimmer, also used by the Trådfri wireless dimmer) to get x002 events instead. To revert to the default, set mode to 1 (ModeScenes).

They're both black as well, sadly.
~I seem to have paired it to the Raspbee module.~ Still the same behaviour.
Edit:
No. Its paired to the ikea light right next to the raspbee module

There's a number next to the battery: 1938-1. I have no idea what that may mean but it could be different?

but it won't solve your issue of run-away changes in case a Stop is missed.

Really? I thought those happend due to the network being unable to keep up. That should in theory be solved by using unicast, right?

I thought those happend due to the network being unable to keep up. That should in theory be solved by using unicast, right?

You’re right, of course. If that was indeed the cause, it should be solved. I was more worried than an individual message could still go missing. But as multiple copies seem to reach you coordinator, the chances of that are quite slim.

Looks like it's working like one would expect it.
I'm unable to cause any run-away volume issues.

Great!
The latency is quite good as well. Overall a nice solution.

Thanks for looking into that @ebaauw

I'm seeing the same behavior as @Hypfer after following steps from https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1898 (note that I'm on latest deconz version and not the @ebaauw's branch):

• when rotating slowly right, I'm seeing repeating pairs of 2001, 2003 events
• when rotating right fast and with steady pace, I'm seeing one 2001 event at the beginning and then one 2003 event after I'm finished with rotating. It doesn't matter how long I'm rotating as long as it's fast and steady.

But I can't reproduce missing "stop" (*3) events anymore! :)

I think this issue can be closed after #2658 has been merged

And what about the issue with constant changes not triggering events? Is that something that works correctly with the afore-mentioned PR?

@rchl

That issue is avoided by not using mode 4 and instead keeping the x001/x003 events like before.
https://github.com/dresden-elektronik/deconz-rest-plugin/pull/2658/commits/7035ee72624e9765d1573f343480208ccefec468

I think this issue can be closed after #2658 has been merged

And it seems to have been merged 10 days ago. 😄 👍

Is there any action necessary to take advantage of the fix?
Is it enough to update deconz or it's necessary to reset and re-bind controller?

Is there any action necessary to take advantage of the fix?

I would also be interested in this answer. I have a Deconz stick in my Home Assistant Raspberry Pi and it says that I have FW version 2.5.75 and that it's up-to-date.

I have the Symfonisk connected but I only get one event on which direction it's being turned (2001/3001) turned and when it stopped turning (2003/3003), and button presses (1001, 1004, 1005). But no repeated events or something that says by how much it was turned.

From what I understand, the PR will send the direction events continuously as I turn the knob. But does on event represent a certain number of degrees of rotation?

You probably need to re-pair the Symfonisk controller or manually update the binding so that it's using unicast as described here https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1898#issuecomment-615078454

The other questions are also all answered in this thread.

But does on event represent a certain number of degrees of rotation?

See here:
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1898#issuecomment-535090364

Please consider reading the full thread before commenting.

It seems this issue is resolved or otherwise inactive. If it is not, please re-open!

I’ve updated deCONZ, repaired both the controller and manually done the binding (not sure if that’s still needed). They are both incredibly reliable. The only thing I’ve noticed: the codes for clockwise and anti-clockwise have been inverted. But it was easy for me to fix the automation so I don’t mind.

Thanks for the amazing work, as usual!

I got a second controller. I have both connected to the network but it seem the new one does not fire any events in Node-RED. Any idea what the problem could be?

I'm on the newest Deconz docker release.

@kmplngj Probably the binding. Try re-pairing it a few times.