I can see if we can maintain the existing entity ids. Do you want me to investigate this? Not sure if that is possible now it uses a config flow, since the old YAML had some design problems.
Or will this not be an issue once you re-configure your media player?
NOTE: You can also manually rename the device/media_player I believe so you don’t have to change any automations/cards/etc.
Yes, the separate controls for balance/base/treble are already queued up to be released, but I was waiting until things settled from the existing release since it was a major structural change.
@ryans … If I can just change names and they stay between upgrades, great.
If they are going to change entity_id back (or I want to rename an input or something) and the entity_id changes back, then I will need to use the new ones and not rename new to old.
Do you know if the config_flow will respect the media player entity ids when updated? It is unlcear to me why “ttyusb0” would be in the name. To me that is a configuration and someone could change that to say USB1 (moving the USB cable). I would assume USB0 is stored internally and not used, but in that case, the name would be misleading.
OK. Here comes the test.
I manually change all the entity_id’s back to their old names.
Everything is back working.
Now I am going to apply this mornings v0.2.6 and see.
NICE!
… All good …
Except I have one zone that has nothing plugged in. That zone is name “Unused”. I cannot change it’s entity ID, it tells me it exists. I try to change the name to the old one … but it is “already registered”
My guess … I didn’t delete it from old integration and now it is stuck “in Limbo”
Yes, be sure to delete ALL of the old ones, now totally back to normal!
Yes, changing the tty would change the ids. I’m not sure that is a bad thing or not. However, if we change it now, yours will break again because the ids will change.
I have everything working on my DAX-88. Volume controls work, on/off works through scripted commands, but the UI doesn’t seem to poll the status of the speakers. They always show that they are off, even though they are on. I can toggle them on and off, and they show as on for a few seconds, then revert to showing that they are not on. My kitchen and living room speakers are physically on in this screenshot
Agreed. It if fine as is now.
Snappy response after the latest upgrade.
I am going to wait for your implementation of bass/treble/balance stuff.
No sense on overriding your implementation and them reapplying mine.
Although it may have broke my Alexa “turn on dax kitchen” … that is not your problem, I will look into it.
I do not see this … mine shows them correctly.
I could see this being an issue if you had the original installation.
What does the generic entities view show?
I had a set of duplicates … one from old and one from new with different IDs.
I had to delete all the old ones by hand.
Living Room, Deck and Hot Tub on … different volumes …
Mapping to my card 100%
I see new release, if I simply upgrade and then try to add/change … I get:
Error
Config flow could not be loaded: 500 Internal Server Error Server got itself in trouble
So not sure how to enable new bass/treble/balance and test without uninstall/reinstall (and will that kill all my zone entity-id’s)?
I just did it and all OK except there is a bug in TREBLE setting. I know my old code had an extra “}” and I think yours does too …
I was getting the config flow error but changing line 277 in config_flow.py to:
self._config_entry = config_entry
seemed to solve it
Confirmed.
But at least for DAX 88 … Treble setting is an error that the command has ‘}’ in it
I am adding a bunch more tests and pre-commit around pyxantech to catch this kind of stuff earlier. As well as tests to detect that entity ids change between release and blocking this (without developers confirming this is intended).
I am using the Xantech MRAUDIO8x8.
The balance, Bass and Treble controls now show up after I delete the old device and re-add it.
The Balance initializes with a value of 32. I can only adjust between 0 and 20. adjusting the balance does not make a difference. Adjusting the Bass and Treble works.
Saw that and yes I can see the error in dayton.yaml protocol that actually I believe I did early on but only fixed my local copy. I see you have caught it. Thanks.
Fantastic!
Which RS232 port did you plug in to? @Montreal666 has been having difficulty getting their MRAUDIO8x8 working and I thought it might be the RS232 port they were using.
I ordered the exact same converter/cable @IRATT is using. Will report back once I test it. Fingers crossed.
Thanks for the latest updates, balance, treble and bass all work great now.
For those looking to do the serial to Ethernet like I did, I used the DB9 at the back. I had to make sure it was configured with the same baud rate as the serial to Ethernet device using the xantech dragon software, I used 9600.
On my DAX88 I think polling isn’t working very well.
My zones frequently report being “off” when they are playing, and the treble and bass entities become “unavailable”. The HA Yellow is directly connected via USB.
What can I do to help debug?
Thanks again.
I do get these in my log:
This error originated from a custom integration.
Logger: custom_components.xantech.coordinator
Source: custom_components/xantech/coordinator.py:63
integration: Xantech Multi-Zone Audio (documentation, issues)
First occurred: 11:05:49 AM (107 occurrences)
Last logged: 9:12:51 PM
Failed to get status for zone 16
Failed to get status for zone 12
Failed to get status for zone 17
Failed to get status for zone 18
Failed to get status for zone 11
Traceback (most recent call last):
File "/usr/local/lib/python3.13/asyncio/tasks.py", line 507, in wait_for
return await fut
^^^^^^^^^
File "/usr/local/lib/python3.13/asyncio/queues.py", line 186, in get
await getter
asyncio.exceptions.CancelledError
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/config/custom_components/xantech/coordinator.py", line 63, in _async_update_data
status = await self.amp.zone_status(zone_id)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/site-packages/pyxantech/__init__.py", line 640, in wrapper
return await coro(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/site-packages/pyxantech/__init__.py", line 660, in zone_status
status_string = await self._protocol.send(cmd, skip=skip)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/site-packages/pyxantech/protocol.py", line 195, in send
return await self._read_response(skip)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/site-packages/pyxantech/protocol.py", line 214, in _read_response
chunk = await asyncio.wait_for(self._queue.get(), self._timeout)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/asyncio/tasks.py", line 506, in wait_for
async with timeouts.timeout(timeout):
~~~~~~~~~~~~~~~~^^^^^^^^^
File "/usr/local/lib/python3.13/asyncio/timeouts.py", line 116, in __aexit__
raise TimeoutError from exc_val
TimeoutError
Did you happen to change the polling frequency for the device? The error is related to a device being overwhelmed with too many requests and timed out.
I realize that you cannot change the baud rate to higher baud, which might help (of course, you’d need to do this somehow on the device itself as well).
Most manufacturers don’t really support fast polling of their RS232 interfaces, so you often don’t get realtime feedback on changes.
No. It’s still default. I think i saw the default is 30 seconds.