Unfortunately I am still at the same point.
Really disappointing. I have tried reaching out to the 2 main developers but didn’t get a response.
At least I’d like to pinpoint the root cause ( defective unit, incompatible cable, USB port, software issue)
What I have yet to test is another HA instance (I am running HAOS on x86 bare metal, so maybe a USB port/driver issue? What are you using?) or another cable (I’ve ordered exactly the one recommended… what about you?)
As I pointed out in a previous post, I would also like to know if a successful Monoprice Integration install means the cable does communicate properly with the unit?
Also I have not found trace of a successful installation on Xantech MRAUDIO8X8 (most are on DAX88) so wondering if it was actually tested on this unit. Could the cable pinout be different?
I was planning further testing soon. Will keep you posted and would love to hear about your progress/troubleshooting as well.
This was originally developed for the MRAUDIO8x8, but mine has been in storage for almost 1.5 years during a remodel. I’ll bring it out again at some point. I’ve also used this with a MRC88 and recently a MX88ai. Make sure you are plugging the RS232 into the correct serial port. I made that mistake in the last plugging into the wrong one which was not for control.
I am using a MRC88. I have been flipping through the manual for a couple versions. Mine has two serial ports and a USB port. All the versions also seem compatible with some software they used to use called “Universal Dragon.” I might download that onto some PC and ensure I can establish connection between the software and my MRC88 to make sure I can communicate.
I am using the most recent version on Home Assistant OS running on a pi4 for now. If I can get a connection with the universal dragon software maybe I will look into how that communicates vs how pyxantech is attempting to communicate.
With regards to your question. “I would also like to know if a successful Monoprice Integration install means the cable does communicate properly with the unit?”
I am not sure I understand that question. Does it fully work? Can you control your MRAUDIO 8x8 with that integration. If so, cable good. But I imagine that isn’t your question.
According to the manual all three (the two RS232 COM ports and the front usb) can control the box via the dragon software, but under the pyxantech README @ryans says only the back COM works for controlling.
@ryans It looks like the git repo is active, but there hasn’t been a tagged release in ages.
How do you recommend users upgrade? I’d benefit a lot from instructions (however technical) to stay up to date.
It looks like with the latest HA release to 2025.1 the integration no longer works, but it also looks like you’ve already fixed this in the master branch.
My understanding is that it still works with 2025.1, just that there is just a warning regarding MediaPlayerEntityFeature. Reminder this is a community effort requiring contributions from the community to keep it going (e.g. support in this thread, code changes, etc).
I don’t currently have a working Xantech to test the latest changes, so have not released. If someone wants to test installing from main (instead of 0.1.0 release) then it could be released as a new version.
@sorrygofish Btw, I just created a PR to pull in your recent changes to strings.json and manifest.json. Thanks!
Universal Dragon really is just a programming tool from Xantech to setup zones, keypads, etc within a unit during initial setup (and I think required to get the physical wall-mount keypads to work). From what I recall it isn’t useful at all for controlling the device once configured, that is left to the Xantech serial protocol (which is what pyxantech and the Home Assistant hass-xantech implement).
I can’t recall if the MRAUDIO 8x8 requires a null modem adapter (in addition to the RS232 cable) or not for serial control. I don’t think so. I generally used USB to RS232 adapters and controlled mine from my Raspberry Pi 4 as well as from a Home Assistant Blue.
I continue to have usability issues with this integration regarding volume changes.
I sometimes see instantaneous reactions, but other times I see 0.5s up to 5.0s delay.
Looking around the code I see that each config (for example) has a min_time_between_commands value (in this case it’s 0.4s). I also see timeout (of 1.0s) and write_timeout (also 1.0s).
This makes me think that:
Increase volume commands can happen no-faster than once every 0.4 seconds.
Polling commands (are there any?) may result in collisions that lead to a lag on volume changes.
Is that right? Where does the 0.4 come from? IMO, that’s a really long time.
I see that the manufacturer provided “Matrio Control” app does not suffer from this. It is able to make realtime volume changes.
I also see that pymonoprice does not have this rate limit.
when i install version 0.1.2 i still see version 0.1.0, even if i remove xantech folder from home assistant and reinstall 0.1.2 it still shows version 0.1.0
@paulus1 You actually have 0.1.2 release even though it says 0.1.0. Unfortunately, there are multiple places HACS looks for what the version is and the ‘hacs.json’ wasn’t also updated to reflect the github release. I’ve just updated that now, so if you reinstall from scratch it will show the correct version…or you can just leave the 0.1.2 version (that shows 0.1.0) in place. Functionally is the same.
FYI to those that implemented Bass/Treble/Balance code I did. It is not in this latest version so I will need to put that all back in. Perhaps @ryans can squeeze that in at a later time.
I am just a python hack and have no knowledge of how Github works, I suppose there are better ways to do this but I am afraid to break things for others.
Awesome thank you for saving me from going down the Universal Dragon rabbit hole. Back to troubleshooting this weekend and thanks for putting all this (pyxantech and the integration) together.
I did more testing this weekend with my MRAUDIO8X8.
I installed Dragon Drop-IR MRC so I could possibly confirm the unit + cable works .
I had to change the COM port to COM1 (originally COM7 which was not an option for Dragon software) and was able to get the device acknowledgement via the “who am I” command of the software. Not sure if this is relevant or not but only the front DB9 port is responding. The back port doesn’t.
So I tried deleting the HACS integration and installed the latest release from last week.
Does the above provide any clues to what could be wrong?
For testing purposes, I don’t have any speakers, sources or keypads connected to the Xantech; just the power cord and USB-Serial cable. Is this an issue?
As a last resort, I will install HA on a PC+VM.
Otherwise, unless someone has troubleshooting ideas, I am out of options.
Hey, thanks for your work on all of this. I just got a sonance for my in-laws and found some bugs related to that implementation in the pyxantech repo. I wanted to make a branch/PR but the repo is not configured to allow that.
I have the sonance on my table and directly running the examples (and via debugger in vscode) works with a slight caveat. The async works fine, but the sync routines seem to have a problem with the restore_zones (casting to a byte array vs str). Doesn’t seem like that codebase is used much however.
I have this same issue. Even with a clean remove and install.
And to confirm, the folder that hacs puts in config/custom_components/xantech says: pyxantech>=0.7.2 in the manifest.json so I’m sure it’s getting the wrong commit.
It’s weird because the hacs UI clearly says it’s going to download 0.1.2.
I don’t know how hacs works or why it’s staying stuck on 0.1.0. I’m very excited to try 0.1.2 because I see you’ve been changing the timing code.
Oh, I see. You need to re-tag. The tagged commit is 3ba1b7bd3f31e67fa1c0e885eec25268699d5009 which still says 0.1.0 (and has the 0.7.2 version of pyxantech) in the manifest.
