After successfully starting the Devimote program in an attempt to control a D220 PRO master which drives two D220 PRO slaves, I noticed that the Devimote interface was not being updated correctly. Using Wireshark for monitoring 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 Devimote. 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 my Devimote code to account for that particular change, the status updates turned out to perfectly understood and correctly displayed in my Devimote interface. I will be happy to document that change or to provide my modified version if anyone is interested.

However, at this point in time, I am still struggling with two other problems. The first one is reported below, while I will open a separate issue for the 2nd one.

My first problem is that there also appears to be a small change in the command packets that the Devialet is expecting. Basically all the commands sent by Devimote 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 by a specific pair of consecutive bytes, but at this time I do not understand by what logic particular pairs of bytes are supposed to relate to particular sources. In the Devimote program the mapping between the pair of bytes and the sources is determined using a calculus that I do not understand:

        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 (correct) bytes sent by my Devialet Android app with those sent by Devimote:

# 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 )`

The last two bytes must be as in the Android app for the source to be selected correctly. For the time being, I am circumventing this issue by hard coding the relevant pair of bytes in my modified version of Devimote. However, I hope that I will eventually be able understand the correct logic and get rid of any such hard coding.

Congratulations

So much searching for an way to communicate with Devialet Expert ;)

How to integrate with Home Assistant? Any idea?

Best regards
ArchGalileu

In my attempts to use Devimote for controlling my system made up of three chained D220 PRO, I stumbled onto an unexpected problem.

At this time I am using Roon for streaming digital files to my Devialet system. As it turns out, Roon appears to be monitoring the same UDP status packets as Devimote, and Devimote refuses to start whenever Roon is running, which in my case normally means all the time. As soon as I stop Roon, I can start Devimote allright.

I am a newbee at Python, but from what I have been able to gather, there used to be an option that would allow Python to share access to the relevant UDP packets, and that option seems to have been eliminated in recent versions of Python.

Hopefully, expert users of Python will be able to suggest a way to obtain that shared access anyway. After all, sharing is fine between Roon and some other pieces of software, such as the Devialet Android app.

I would very much like to be able to talk to Devimote through MQTT strings. One way of thinking of this, is that "command" MQTT strings would be accepted as an alternative to pressing a button on the GUI and "update" MQTT strings would be sent in parallel to updating corresponding elements of the GUI.

In my case, it would also be OK to completely replace the GUI with corresponding read and write MQTT capabilities, because my current goal is to integrate Devialet control to my home automation system, which is implemented within Openhab.

As I am rather new to both MQTT and python programming, I would be delighted to collaborate with anyone else interested in such an MQTT <--> Python <--> Devialet capability.

Let me know.