0.32 broke media_player.yamaha #4226
Comments
|
cc: @postlund |
|
I will look into this as soon as I can, thanks you for reporting 👍 |
|
It works for me, but I do get an error. I can't see that it is actually stopping any functionality that I use though. Here is my configuration if at all helpful: |
|
With nearly the same configuration (the main difference I can see is I specified an |
|
Update: I have the same error as above without specifying the |
|
Ok, there are 2 issues here. The play_info one is it's own thing, the zone_ignore is because optional voluptuous attributes don't actually set a default. The zone_ignore is easy to fix. I don't know about the other. |
|
Out of curiosity, for folks where zone_ignore fails, do you have > 1 media_player component? |
|
The above fixed the zone_ignore issue, for the original issue, I'm not really sure what the issue is. We'd probably need a dump of the XML that is failing to parse to see what's up with it. |
|
Good, I see there's some progress. The initial problem is because the receiver does not support the command so we should not use play_status. Not sure how to make a clean implementation, but I will think about it. |
|
@postlund we can discover that from the desc.xml I think. It also probably makes sense to make rxv be extremely robust on all it's method calls, even in the face of bad xml. |
|
Maybe we can, not sure. Should be easy enough to check though. Would be good to have a proper strategy in rxv for presenting/verifying support for different things. Since functionality is quite limited in rxv, adding is_x_supported-methods for things that are not supported by all receivers might be the easiest and cleanest solution. But it will explode if we add more functionality down the road. Another way is to just throw NotImplementedError and let the user take action (this is what we can do with the current version and I will provide a fix so dev works as expected). I would not say that it's bad xml in this case, more lack of it. But yeah, better handling of received data would be nice. |
|
Is there any way I can fetch the |
|
Sure, just visit/download http:///YamahaRemoteControl/desc.xml |
|
Argh, github... insert IP-address of receiver at the right place. |
|
Wow, I didn't except such a big file. Would any specific part (or the whole file) help for this issue? |
|
No, we need the whole thing. Yamaha basically has a full API discovery system in there, so every function and parameter supported in the receiver is there. I would suggest pasting into a gist somewhere. I started building some testing in the rxv project that can use some of these to figure out platform differences. |
|
@sdague: Which approach for "exposing" available support are you aiming for in rxv? |
|
I've made some sort of fix for the current problem, feel free to try it out. |
|
I'm using docker so I won't be able to test easily, I'll set up a test instance on your branch and keep you posted. I'll probably won't be able to do this today, though. |
|
@Kernald before we merge the work around, it would be good to know that it fixed things for you. It could just get us to another issue with the rxv support of that receiver, and if the issue is deeper than this work around I'd rather figure out how to fix it in the library for real. |
|
@Kernald any idea which input your stereo was on when this happened? |
|
Sure, it was HDMI 1. |
In response to Home Assistant bug - home-assistant/core#4226 When things go wrong with a request in unexpected ways, we really don't have enough information to figure out what just happened. This is especially true with hardware generations that none of the upstream developers have. This adds logging support to the library, and introduces a couple of error cases where we will log low level details of a failure to help debug these kinds of issues in the future.
In response to Home Assistant bug - home-assistant/core#4226 When things go wrong with a request in unexpected ways, we really don't have enough information to figure out what just happened. This is especially true with hardware generations that none of the upstream developers have. This adds logging support to the library, and introduces a couple of error cases where we will log low level details of a failure to help debug these kinds of issues in the future.
|
HDMI1 makes total sense. The update call is doing the play_status on update regardless of input. Which is definitely not going to work on HDMI inputs. So, I actually think - wuub/rxv@82b3806 (upstream fix in rxv) is probably a better fix than #4281 for this, because that makes the library behave more consistently here, and keeps the logic out of HA when possible. @Kernald any chance you can pull that branch and try that upgraded library? If it works I'll see if we can get rxv released and bump the dependencies in HA for the next release. |
|
Sure, I should be home in a couple hours :-) Le lun. 7 nov. 2016 21:01, Sean Dague notifications@github.com a écrit :
|
|
@sdague I can confirm your fix in By the way, a work-around for anyone encountering this issue: restarting hass on another input (it works for me on AV5 for example) allows the entity to be instantiated, then it's totally usable (with the same stacktrace being logged anytime I'm using HDMI1). |
In response to Home Assistant bug - home-assistant/core#4226 When things go wrong with a request in unexpected ways, we really don't have enough information to figure out what just happened. This is especially true with hardware generations that none of the upstream developers have. This adds logging support to the library, and introduces a couple of error cases where we will log low level details of a failure to help debug these kinds of issues in the future.
|
@Kernald ok, rxv fix is merged upstream. Once we get a release I'll propose an HA req bump. |
|
Great, thanks! |
rxv version 0.3 will issue the play_status command even for sources that don't support it, causing stack traces during updates when receivers are on HDMI inputs. This was fixed in rxv 0.3.1. Bump to fix bug home-assistant#4226.
…4279) * Fix "argument of type 'NoneType' is not iterable" during discovery When yamaha receivers are dynamically discovered, there config is empty, which means that we need to set zone_ignore to [] otherwise the iteration over receivers fails. * Bump rxv library version to fix play_status bug rxv version 0.3 will issue the play_status command even for sources that don't support it, causing stack traces during updates when receivers are on HDMI inputs. This was fixed in rxv 0.3.1. Bump to fix bug #4226. * Don't discovery receivers that we've already configured The discovery component doesn't know anything about already configured receivers. This means that specifying a receiver manually will make it show up twice if you have the discovery component enabled. This puts a platform specific work around here that ensures that if the media_player is found, we ignore the discovery system.
…4279) * Fix "argument of type 'NoneType' is not iterable" during discovery When yamaha receivers are dynamically discovered, there config is empty, which means that we need to set zone_ignore to [] otherwise the iteration over receivers fails. * Bump rxv library version to fix play_status bug rxv version 0.3 will issue the play_status command even for sources that don't support it, causing stack traces during updates when receivers are on HDMI inputs. This was fixed in rxv 0.3.1. Bump to fix bug #4226. * Don't discovery receivers that we've already configured The discovery component doesn't know anything about already configured receivers. This means that specifying a receiver manually will make it show up twice if you have the discovery component enabled. This puts a platform specific work around here that ensures that if the media_player is found, we ignore the discovery system.
Home Assistant release (
hass --version):0.32
Python release (
python3 --version):Don't know exactly, I'm using the docker images
Component/platform:
media_player.yamaha
Description of problem:
Upgrading to 0.32 from 0.31.1, the
yamahacomponent fails to initializeProblem-relevant
configuration.yamlentries and steps to reproduce:Traceback (if applicable):
Additional info:
The exact same configuration works perfectly fine on 0.31.1.
The text was updated successfully, but these errors were encountered: