Devialet Chat
Unofficial remote control application for Expert - Printable Version

+- Devialet Chat (https://devialetchat.com)
+-- Forum: Devialet Chat (https://devialetchat.com/Forum-Devialet-Chat)
+--- Forum: Devialet D-Premier, Expert 120/200/250, Expert 140/220/250 Pro (https://devialetchat.com/Forum-Devialet-D-Premier-Expert-120-200-250-Expert-140-220-250-Pro)
+--- Thread: Unofficial remote control application for Expert (/Thread-Unofficial-remote-control-application-for-Expert)

Pages: 1 2 3


RE: Unofficial remote control application for Expert - gnulabis - 12-Jan-2021

(12-Jan-2021, 12:45)gnulabis Wrote:
(12-Jan-2021, 10:23)garyUK Wrote: @gnulabis, what exactly would you want in a wireshark capture?

I haven't tried your app on my MacBook pro yet but I have tried the official android app. Although the app says it may not work properly because of the later version of android on my phone it all seemed OK e.g. it showed all of my inputs (with correct names) and I could switch between them, change volume etc.

Let me know what you'd like in the capture.

Thanks.

If you know how to use wireshark, you can start a capture with your Devialet switched on, let it capture for 5-10seconds and then try to mute/unmute, change a couple of channels and adjust the volume a bit using the official application. Then just save the capture and I'll have a look. The only important thing is that once you start doing the various operations, you write down what you did (and in what order) so that I can make sense of the various captured packets.

Many thanks!

Ah sorry, forgot. Unless you run wireshark on the device that is running the remote control application (difficult, I had to install tcpdump on my android phone and connect it over USB to my PC), you will not capture the commands. If you cannot do that, then simply do a few seconds of a capture with the Devialet switched on and send me that. I will already be able to see what the UDP status packet sent by Devialet looks like in your case.


RE: Unofficial remote control application for Expert - garyUK - 12-Jan-2021

@gnulabis, Because I don't usually run wireshark on any of my macs I'll need to install it (I usually use it on Linux) although I'm not sure whether macos will allow switching to monitor and/or promiscuous modes.

However, macs do have tcpdump installed and this is used as part of the built in diagnostics that can be switched on for troubleshooting wifi. Using this feature I've captured what is being received when my 440pro is powered up. 

The attached zip contains a  'pcap' file.  (subset of what was captured).

Have a look and see if its of any use.


RE: Unofficial remote control application for Expert - gnulabis - 13-Jan-2021

(12-Jan-2021, 22:02)garyUK Wrote: @gnulabis, Because I don't usually run wireshark on any of my macs I'll need to install it (I usually use it on Linux) although I'm not sure whether macos will allow switching to monitor and/or promiscuous modes.

However, macs do have tcpdump installed and this is used as part of the built in diagnostics that can be switched on for troubleshooting wifi. Using this feature I've captured what is being received when my 440pro is powered up. 

The attached zip contains a  'pcap' file.  (subset of what was captured).

Have a look and see if its of any use.

Many thanks @garyUK. Indeed, there seems to be an issue with the number of outputs provided by the dual mono setup.

There must be somewhere in the packet a field that tells us how many channels there are to iterate over.


RE: Unofficial remote control application for Expert - stephen0804 - 17-Jan-2021

just thought i would add to the conversation, 
that a couple years ago now i built a windows app for controlling my Devialet 200 at the time (now 220pro CI) via the RS232 3.5mm jack & made a post on this forum, here's a link to the thread RS232 controller (devialetchat.com

not quite the same as it requires a cable between pc and amp, but in my case i have a dedicated pc so i use RS232.

but i don't use the app i wrote anymore, instead i have setup a similar system using EventGhost home automation software which essentially allows me to make a remote and tell the buttons to send commands via RS232(or whatever). 

but using ip control is probably the better option Smile


RE: Unofficial remote control application for Expert - garyUK - 25-Jan-2021

@gnulabis, Did you manage to get anywhere with the file? If I get a chance I'll see if I can get some more (different) data.

Thanks.


RE: Unofficial remote control application for Expert - pisabell - 23-Aug-2022

Hello all,

I tried the Devimote program provided by @gnulabis (huge thanks to him!) for remote controlling my Devialet system, thus far with some success but also with some issues, and I wanted to share my experience.

Originally, I think the program was written for and tested on a D200. My current configuration is a set of three D200 PRO working in AXD (active crossover) mode for feeding a pair of three-way speakers. 

After successfully starting the program, I noticed that the Devimote interface was not being updated correctly.  Using Wireshark for watching the status packets sent by the Devialet, I managed to trace the problem to a minor difference in the structure of the those packets wrt to those expected by my current Deviamote. Basically, the Devialet packets turned out to be somewhat larger, because they were making allowance for a larger number of different sources (15 instead of 8), perhaps because my setup involves chaining several amps. 

After I modified @gnulabis' code to account for that particular change, the status updates turned out to perfectly understood and correctly displayed in my Devimote interface.

However, at this point in time, I am still struggling with two other problems:

1) There also appears to be a small change in the command packets that the Devialet is expecting. Basically all the commands sent by Deviamote to the Devialet are working OK, except those for selecting the first four of my seven different sources. In the Devialet command packets, the source selection is encoded in two consecutive bytes, but at this time I do not understand how specific pairs of bytes are supposed to relate to specific sources. In the Devimote program the value of this pair of bytes is determined using a calculus that I do not understand:
Code:
        out_val = 0x4000 | (output << 5)
        data = bytearray(142)
        data[6] = 0x00
        data[7] = 0x05
        data[8] = (out_val & 0xff00) >> 8
        if output > 7:
            data[9] = (out_val & 0x00ff) >> 1
        else:
            data[9] = (out_val & 0x00ff)

It is the value of bytes 8 and 9 that is expected to select a particular source. However, as it happens, the above calculus does not provide the correct values for my first four sources, as can be seen by comparing the bytes sent by my Devialet Android app with those sent by Deviamote:

Code:
# Change source CMD packets, first 10 bytes, as numbered from 0

44 72 00 2c 00 16 00 05 00 00  (source 0-Cinema, Android app)
44 72 00 04 00 02 00 05 40 00  (source 0-Cinema, devimote)

44 72 00 30 00 18 00 05 3f 80  (source 1-lp12, Android app)
44 72 00 9c 00 4e 00 05 40 20  (source 1-lp12, devimote)

44 72 00 34 00 1a 00 05 40 00  (source 2-upnp, Android app)
44 72 00 a0 00 50 00 05 40 40  (source 2-upnp, devimote)

44 72 00 39 00 1c 00 05 40 40  (source 3-Roon, Android app)
44 72 00 a4 00 52 00 05 40 60  (source 3-roon, devimote)

44 72 00 3c 00 1e 00 05 40 80  (source 4-Airplay, Android app)
44 72 00 a8 00 54 00 05 40 80  (source 4-airplay, devimote)

44 72 00 40 00 20 00 05 40 a0  (source 5-Spotify, Android app)
44 72 00 ad 00 56 00 05 40 a0  (source 5-Spotify, devimote)

44 72 00 44 00 22 00 05 41 60  (source 14-Air, Android app)
44 72 00 b0 00 58 00 05 41 60  (source 14-Air, devimote )

For the time being, I am circumventing this issue by hard coding the relevant pair of bytes in my modified version of Deviamote. However, I hope that I will eventually be able understand the correct logic and get rid of any hard coding.

That being said, at this time my current version of Deviamote is working perfectly both for receing and displaying updates and for sending commands.


2) The second remaing problem is more damning. Deviamote monitors the status of the amp by listening to UDP packets sent by the amp on port 45454. However, my Roon server also needs to listen on that same port, and Deviamote refuses to start whenever Roon is running. For my purpose, this turns out to be a very serious limitation. I hope that Deviamote can somehow be modified to allow for "shared listening". This must be possible, since the Devialet Androis app is listening fine while Roon is running.

Any hints would be most welcome.


RE: Unofficial remote control application for Expert - gnulabis - 29-Aug-2022

(23-Aug-2022, 21:43)pisabell Wrote: 1) There also appears to be a small change in the command packets that the Devialet is expecting. Basically all the commands sent by Deviamote to the Devialet are working OK, except those for selecting the first four of my seven different sources. In the Devialet command packets, the source selection is encoded in two consecutive bytes, but at this time I do not understand how specific pairs of bytes are supposed to relate to specific sources. In the Devimote program the value of this pair of bytes is determined using a calculus that I do not understand:
Code:
        out_val = 0x4000 | (output << 5)
        data = bytearray(142)
        data[6] = 0x00
        data[7] = 0x05
        data[8] = (out_val & 0xff00) >> 8
        if output > 7:
            data[9] = (out_val & 0x00ff) >> 1
        else:
            data[9] = (out_val & 0x00ff)

It is the value of bytes 8 and 9 that is expected to select a particular source. However, as it happens, the above calculus does not provide the correct values for my first four sources, as can be seen by comparing the bytes sent by my Devialet Android app with those sent by Deviamote:

Code:
# Change source CMD packets, first 10 bytes, as numbered from 0

44 72 00 2c 00 16 00 05 00 00  (source 0-Cinema, Android app)
44 72 00 04 00 02 00 05 40 00  (source 0-Cinema, devimote)

44 72 00 30 00 18 00 05 3f 80  (source 1-lp12, Android app)
44 72 00 9c 00 4e 00 05 40 20  (source 1-lp12, devimote)

44 72 00 34 00 1a 00 05 40 00  (source 2-upnp, Android app)
44 72 00 a0 00 50 00 05 40 40  (source 2-upnp, devimote)

44 72 00 39 00 1c 00 05 40 40  (source 3-Roon, Android app)
44 72 00 a4 00 52 00 05 40 60  (source 3-roon, devimote)

44 72 00 3c 00 1e 00 05 40 80  (source 4-Airplay, Android app)
44 72 00 a8 00 54 00 05 40 80  (source 4-airplay, devimote)

44 72 00 40 00 20 00 05 40 a0  (source 5-Spotify, Android app)
44 72 00 ad 00 56 00 05 40 a0  (source 5-Spotify, devimote)

44 72 00 44 00 22 00 05 41 60  (source 14-Air, Android app)
44 72 00 b0 00 58 00 05 41 60  (source 14-Air, devimote )

2) The second remaing problem is more damning. Deviamote monitors the status of the amp by listening to UDP packets sent by the amp on port 45454. However, my Roon server also needs to listen on that same port, and Deviamote refuses to start whenever Roon is running. For my purpose, this turns out to be a very serious limitation. I hope that Deviamote can somehow be modified to allow for "shared listening". This must be possible, since the Devialet Androis app is listening fine while Roon is running.

Yes, that was a hack on my side, because I could also not fully understand the logic behind the output encoding in my setup. I noticed in wireshark that it was different if the output was above 7, so I coded that without being able to explain why such a thing was necessary.

In recent times I bought a subwoofer and reconfigured my D200 to switch an input to a pre-out to drive the subwoofer, which made me think that perhaps the different encoding is needed for configurable inputs/outputs or other similar stuff. But I never got to test this theory.

As for the different packet size because of more channels, there are two possible approaches that Devialet might be following. Either they read the model and adjust the rest of the code accordingly, or there is a field somewhere that I'm not decoding which declares the number of outputs or the size of the packet.

(23-Aug-2022, 21:43)pisabell Wrote: 2) The second remaing problem is more damning. Deviamote monitors the status of the amp by listening to UDP packets sent by the amp on port 45454. However, my Roon server also needs to listen on that same port, and Deviamote refuses to start whenever Roon is running. For my purpose, this turns out to be a very serious limitation. I hope that Deviamote can somehow be modified to allow for "shared listening". This must be possible, since the Devialet Androis app is listening fine while Roon is running.

Mmmm, a bit outside my field, I did the quickest possible UDP listening implementation but you are probably right. Could you please open an issue in github? It is a much better place to discuss this sort of things.

Cheers


RE: Unofficial remote control application for Expert - mana - 26-Sep-2022

Hi @gnulabis, I tried running devimote on Windows prior to attempting to integrate it into Home Assistant via mqtt as pisabell2 did on Openhab, but it’s only partially working on Windows.

My Devialet is a 220 Pro.

Buffer size can’t be 512
For the UI to start I had to change buffer size from 512 to 1024 in line 177:
data, addr = sock.recvfrom(512) # buffer size is 512 bytes

With 512 I get the following error message:

Code:
ile "c:\DEV\devimote\src\devimote.py", line 177, in update
    data, addr = sock.recvfrom(512) # buffer size is 512 bytes
OSError: [WinError 10040] A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram into was smaller than the datagram itself


Displayed status data not updated & some commands not properly interpreted
With buffer size 1024 I ran wireshark and could see data coming from and to My Expert 220 Pro, but no change was reflected on devimote.

However I ran the android app and I could see status change there. The commands seem to work, but the inputs don’t match. Here is what I found:

Devimote Command => actual change
Mute => Mute
Volume change => Volume change
Digital 1 => Optical 2
Optical 1 => Optical 2
Optical 2 => UPnP
UPnP => UPnP
Roon Ready => Roon Ready
AirPlay => UPnP
Spotify => Spotify
Air => Air
Standby (turn on) => turn on

The wireshark capture attached is for the commands in the sequence above.

I'm not a developer BTW :-)