Requesting feedback

[BasVanBoven]

Hi! Thanks to your API, We were able to build a basic Connect <-> Home Assistant integration (https://github.com/jvSomeren/ha-dynaudio-connect). A question I still had was if it was possible to send a command specifically aimed at receiving feedback, without changing any setting on the Connect. Currently, I am requesting feedback by means of a command to an unused zone, but I was wondering if there was anything better?

Thanks again for your documentation, it has been a great help :)

[therealmuffin]

Hello Bas,

Interesting question. Can you try the following for the RED zone:

Can you give the following command a try:
'ff 55 01 80 7f'

I believe that will return a static string: 'ff 55 02 81 00 7d'. I don't believe it can change much, but I'd give it a try, maybe it returns a second answer (or perhaps it isn't that static after all).

This one might be also interesting:
'ff 55 05 2f a0 1d 00 f1 1e'

Not sure what it will return, but give it a try.

If you want I can send you the stripped (but raw) data for the red zone. At this moment I don't have a Dynaudio Connect setup, so I rely on you to test the results (which I'm fine with, but it's not really efficient).

Regards, Maarten

[BasVanBoven]

Hey Maarten,

Sorry for the late reply and thanks a lot for the additional information! I have tested the three commands you mentioned:

• The first returns a static string indeed. There is no state info, unfortunately.
• The second command seems to switch output to USB

If you'd have the raw data, I could perhaps put it to some good use. Also, I am quite interested to know how you figured all of this out to begin with. My hypothesis is that you monitored the TCP traffic of the Android app? Or is there an easier way?

Kind regards, Bas

[therealmuffin]

Hello Bas,

I've added the files to repository, so enjoy digging! Please share any results so I can update the manual accordingly (or create a pull request of course).

As for the second command, I assume you mean it switched over to the USB input? If so, it would be interesting to know what the difference is with the command I previously found.

And for the method I used to get this data, well that's indeed through the method you described. I routed the iOS app via my computer, used Wireshark to monitor and record the data. All in all, it didn't take much time to figure this one out. By triggering the same command a number of times you're bound to see the pattern soon enough.

Regards, Maarten

[BasVanBoven]

Thanks for all of your info! It will take some time to digest all of the material, but I will definitely keep you updated. :)

[BasVanBoven]

Hi Maarten, hope all is well!

Just wanted to let you know that it took me two years and the best part of a pandemic to get to it, but I am finally able to answer the long-burning question "how can the Dynaudio iPhone app possibly know the state without sending a functional command" in an effort to optimize my home automations even further after some efforts this evening.

I have tried all the commands from the Wireshark output to no avail. But then I wondered, what would happen if I keep the socket open instead of immediately closing it after sending the command? As it turns out, a whole lot.

Every few seconds, the Connect unit sends a hex-string of 14N bytes, where N denotes the number of speakers connected to the unit. Every 14 byte sequence corresponds to a speaker, and the speakers appear in random order, swapping places often. An example of such a string would be FF 55 0A 31 52 7F 01 02 05 01 00 00 01 EA.

The pattern is very similar to command and feedback notations. This is what the every byte does (where not noted, coding is equal to your current documentation):
00: Header (FF)
01: Header (55)
02: Payload length of the individual speaker sequence (0A)
03: Always 31
04: Always 52
05: Most mysterious bit. Seems to function as some kind of speaker identifier, but probably unnecessary for most applications. Changes around sometimes, conditions of which currently unknown (probably a Dynaudio connect power loop)
06: Zone
07: Volume
08: Input
09: Power on/off (01 = on, 00 = off)
10: Mute
11: Power off/on (01 = off, 00 = on)
12: Channel (01 = left, 02 = center, 03 = right)
13: Checksum

Note that when you turn a speaker off, its byte output disappears from the string. Only the last string reports power off state according to the above once, before all periodic output disappears.

With this, it should be possible to reconstruct the state of the Connect without sending junk commands. Downside is you have to keep the socket open, but that's manageable for my application. Expect a PR extending your documentation sometime in the future, after I have put this knowledge into good use in the Home Assistant Integration. Thanks again for all your work and help!

Regards,
Bas

[therealmuffin]

Hello Bas,

Thanks for deciphering this message and looking forward to your PR!

Kind regards, Maarten

[BasVanBoven]

Some more remarks/notes to myself before PR/rewrite (not overly interesting for my use case and I would expect you are already aware of these):

Command ff 55 01 1e e1 returns an overview of available zones
(ASCII \ffU\10\1fRed_Green_Blue\00\7f
HEX FF 55 10 1F 52 65 64 5F 47 72 65 65 6E 5F 42 6C 75 65 00 7F)

Command ff 55 01 11 ee returns an overview of the device name, currently used hub configuration and available sources
(ASCII \ffUT\12Dynaudio Connect | A_1MiniJack_1Line_1Optical_1Coax_1USB_1Bluetooth_1*Stream\00o
HEX FF 55 54 12 44 79 6E 61 75 64 69 6F 20 43 6F 6E 6E 65 63 74 20 7C 20 41 5F 31 2A 4D 69 6E 69 4A 61 63 6B 5F 31 2A 4C 69 6E 65 5F 31 2A 4F 70 74 69 63 61 6C 5F 31 2A 43 6F 61 78 5F 31 2A 55 53 42 5F 31 2A 42 6C 75 65 74 6F 6F 74 68 5F 31 2A 53 74 72 65 61 6D 00 6F)