slow to respond about denonavr HOT 26 CLOSED

From the hass component, the version that works is REQUIREMENTS = ['denonavr==0.3.1']

from denonavr.

There is nothing in the library which might block the change volume command except the connection to the receiver or the receiver itself.

Please test if the command is delayed in HA or when connecting to the receiver. You could use a python console with the following commands:

>>> import denonavr
>>> d = denonavr.DenonAVR("[IP of your receiver]")
>>> d.volume_up()

You will get a "True" when the volume_up command was successfull

Btw. in HA 0.47 version 0.4.4 is integrated , but not 0.3.1.

from denonavr.

I didn't get anywhere... any ideas? I tried two versions.

denonavr-0.3.1
# python3 -c 'import denonavr; d = denonavr.DenonAVR("[xxxx.61]"); d.volume_up()'
No mapping for network audio source None

denonavr-0.5.2
# python3 -c 'import denonavr; d = denonavr.DenonAVR("[xxxx.61]"); d.volume_up()'
Connection error: volume up command not sent

from denonavr.

I'm not sure why it wasn't connecting earlier. Strange. Maybe it takes awhile after stopping home assistant. Or maybe it wasn't on? No idea. Anyway...

After connecting to the denon with both versions the first volume change is a bit slow, but after that it seems to be instant. The connection appears to be what is taking the time.

So I'm guessing the connection in HASS is persistent so maybe its the component in HASS and not the denonavr lib?

denonavr (0.4.4) results:
~# time python3 -c 'import denonavr; d = denonavr.DenonAVR("[x61]"); d.volume_down()'
No mapping for audio source None
Timeout retrieving data from host [10.0.1.61]

real    0m4.321s
user    0m0.240s
sys     0m0.016s


denonavr (0.5.2) results  . I tried a few times and its always 4.3 seconds.
# time python3 -c 'import denonavr; d = denonavr.DenonAVR("[x61]"); d.volume_up()'

real    0m4.341s
user    0m0.268s
sys     0m0.016s

from denonavr.

Okay, now after the testing I went back to restart homeassistant and it's throwing errors. It's been consistently fine up until now.

It seems that maybe the denon receiver doesn't like when you switch library versions? Very strange. HASS is still using 0.4.4.

HASS is now reporting.

2017-07-12 22:24:43 ERROR (Thread-16) [DenonAVR] No mapping for audio source None
2017-07-12 22:24:54 ERROR (Thread-17) [DenonAVR] No mapping for audio source None
2017-07-12 22:25:05 ERROR (Thread-21) [DenonAVR] No mapping for audio source None
2017-07-12 22:25:16 ERROR (Thread-3) [DenonAVR] No mapping for audio source None

from denonavr.

After power cycling the receiver and reconnecting my iphone to it, HASS seems fine again with it. Maybe if I upgrade to the latest HASS and do the same song and dance it'll work? Bizarre.

from denonavr.

The device is polled by homeassistant, so there should be a delay to create a persistent connection.

Which receiver do you have? Two or three weeks ago there was a firmware update for my AVR-X 4100W and since then I have some connection issues too. Especially when the receiver is in standby or is just waking up it is sometimes rejecting any connection, even if controlling via IP should be allowed according to the settings. In those cases also the built in web interface is not working, so I assume denon broke something at least on my receiver.
For me it seems that this happens when the receiver is getting requests from a "unknown" IP for the first time. After I the first call was successfull the later request usually work out.

When you do a volume up/down call using the HASS web api, it is first performing the volume up/down call and then calling the update method of the library. Thus it is also possible that updating the receiver status (or a combination of command + update) could be the reason for the delay. But this would again lead to the connection issue mentioned before...or maybe a blocked event loop in HASS.

Do you get lots of "No mapping for audio source" messages? I mentioned the update method before, which is performed by HASS after each volume call. If the library does not know your current input source, it is trying to build up its source list again, which means 2-3 additional http calls. This would consume some additional time.
If you like I could check that, if you send me the XML answers of your receiver. You can do so by switching on your receiver, setting a reasonable input device and running the attached python file like this:
python denon_receiver_xml.py --host 192.168.0.250 --prefix AVR-X4100W
If you send me the XML files the script saved in the directory it was started from, I could check them.
denon_receiver_xml.zip

from denonavr.

I have an AVR-1912. I haven't checked for Firmware updates in probably 6 months but I don't think there is anything for it since it is quite old.

Regarding the "No mapping for audio source". That seems to go away after things get reset and get in sync. Since I did the last tests, I haven't had any issues with the Denon but I'm still on denonavr 0.4.4. I didn't try the "song and dance" with 0.5.2.

The zip is attached.
avr.zip

from denonavr.

I tried again to make it work in the 0.50.1 release of HASS and its still slow. I tried power cycling the receiver and changing sources etc but that didn't fix it. I attached the error log from hass.
denonerror.txt

from denonavr.

@bbrendon: are you still getting those exceptions in homeassistant 0.53 or later?
I changed the error handling and all timeout exceptions should be caught. Except that socket.timeout exception which is looking like a bug in requests or urllib3.

Btw. starting with homeassistant 0.53 there is a configurable timeout you might increase to not get that many timeouts.

from denonavr.

Okay thanks. I'll look at it again soon then. I'm on the latest HASS but have copied the old denonavr component to custom_components so it works between releases.

from denonavr.

I tried it. Not good.

I renamed the denonavr I had under custom_components and restarted HASS. I noticed some errors in the logs like you mentioned (timeout), and changed the timeout to 8. After that I didn't notice any errors. It sat for awhile and about an hour later I went to watch TV and the volume control was very sluggish.

The TV remote sends a command to home assistant to turn up the volume using the denonavr component. The old version is much more responsive when holding down the volume up/down buttons.

from denonavr.

Homeassistant is doing a status update of the receiver after each volume_up / down call. This is probably the reason for your runtime thing. Could you please check two things.

1. Did you set a name for the receiver in the configuration.yaml? If not please set one and try again. I think your receiver does not provide a "FriendlyName" tag. This could lead to an additional http call on every update.
2. Please check if the [your receivers IP]/goform/formMainZone_MainZoneXml.xml is slower than the [your receivers IP]/goform/formMainZone_MainZoneXmlStatus.xml interface for some reason. This was changed from version 0.5.0 on to support additional zones.

from denonavr.

1. Yes. I have a name set. Below is what I had during my last run.
2. Times listed below.

media_player:
  - platform: denonavr
    name: "denon"
    host: x.x.x.x
    timeout: 8

$ time curl -s x.x.x.x/goform/formMainZone_MainZoneXml.xml > /dev/null

real    0m0.037s
user    0m0.008s
sys     0m0.004s
$ time curl -s x.x.x.x/goform/formMainZone_MainZoneXmlStatus.xml > /dev/null

real    0m0.067s
user    0m0.012s
sys     0m0.000s

from denonavr.

hmm that does not look too slow.
HASS seems to call the update() method after each volume_up, volume_down command. Thus could you please measure the runtime for the update() method in both versions of denonavr like you did before for volume_up, down?

from denonavr.

Timing would be more accurate using timeit, otherwise importing and setting up the device would be measured too:

import timeit
timeit.timeit('d.update()', 'import denonavr; d = denonavr.DenonAVR("192.168.0.250", name="denon")', number=1)
timeit.timeit('d.volume_down()', 'import denonavr; d = denonavr.DenonAVR("192.168.0.250", name="denon")', number=1)

from denonavr.

Below are the times. It looks like the difference between 0.08 and 0.02 is significant when using it to control volume. Heh.

#######################################################
denonavr-0.4.4

>>> import timeit
>>> timeit.timeit('d.update()', 'import denonavr; d = denonavr.DenonAVR("x.x.x.x", name="denon")', number=1)
0.02673786273226142
>>> timeit.timeit('d.volume_down()', 'import denonavr; d = denonavr.DenonAVR("x.x.x.x", name="denon")', number=1)
0.006549206096678972
>>>
>>>

########################################
denonavr-0.5.4


>>> import timeit
>>> timeit.timeit('d.update()', 'import denonavr; d = denonavr.DenonAVR("x.x.x.x", name="denon")', number=1)
0.0855984422378242
>>> timeit.timeit('d.volume_down()', 'import denonavr; d = denonavr.DenonAVR("x.x.x.x", name="denon")', number=1)
0.006712955888360739
>>>

from denonavr.

Just compared the processing times of http request + xml parsing with the whole update method. I can hardly see any difference between those times. Thus there does not seem to be any room for improvement.

from denonavr.

I suppose maybe there isn't much that can be done.

All I can think of is making update a separate thread that doesn't run immediately when multiple actions happen consecutively, but that sounds like a lot of work.

I'll just stay on 0.4.4. Maybe in the future I'll use IR to control the receiver instead and bypass the IP layer.

Another idea is to change the volume in larger increments thereby not having to hold down the volume button on the remote as much/long.

Another idea... Right now volume goes from RF to IP to HASS to IP to DENON. There might be a driver for my remote that would make it : RF to IP to DENON. I don't think its critical to control the Volume via HASS.

Anyway, I can think of many ways to slice this.

from denonavr.

Did you try to use the websocket API of homeassistant?
I would expect from the websocket interface that you can send your volume commands to it at anytime without waiting for a response which fits to your remote control use case.

from denonavr.

I don't see how the websocket would work. Could you elaborate? This is what I did figure out but it's an expensive command. It would also be nice to adjust the volume by more than 0.5 increments but I don't see a way without first getting the current value.

echo -ne MVDOWN\\r | /bin/nc.traditional -q0 x.x.xx.x 23

from denonavr.

Okay, so I just spent an hour or so re-writing my remote integration so it first pulls the current volume level and then add/subtracts 0.05%. It's way better than the 0.5db up/down that is default. The volume control on the remote is waaay better now. I don't have to hold the button down for 10 seconds to get the volume to adjust in 20 increments of 0.5db.

The only problem is that it uses the denonavr component and the HASS Python REST API. So basically I'm more reliant on the old version.

from denonavr.

I never understood why the newer version is noticeably slower for me. Do you know why? Or is it something only I'm experiencing?

I was thinking I could run the new denonavr version and probably change the volume repeat rate to be slower on the remote since I don't need it to be fast anymore.

Anyway, it's probably about time I stop mucking with this and we close it out.

from denonavr.

I don't know neither...I'll fix the one bug which might create unneccessary queries when you don't enter a name for the receiver and none could be found in the XML, but this probably won't help you.
Querying the XML of the newer version seems to last a bit longer and they are also a bit bigger. I don't know if this explains the lower speed in your case completely.

But maybe I found a solution for your remote control issue. I just created a small test implementation for the websocket interface of home-assistant, I mentioned in my last post. You can find it here in github.
The results look as I expected. Sending 100 volume up or volume down commands just take 0.02 seconds. My receiver takes longer to process all the commands, but they won't block your remote control.

>>> import timeit
>>> timeit.timeit('hass.volume_down("receiver_wohnzimmer")', 'import hass_websocket; hass = hass_websocket.HassWebsocket("192.168.0.150"); hass.ws_connect()', number=100)
0.022905174180906093
>>> timeit.timeit('hass.volume_up("receiver_wohnzimmer")', 'import hass_websocket; hass = hass_websocket.HassWebsocket("192.168.0.150"); hass.ws_connect()', number=100)
0.021968359474699106

The implementation is very basic. It does not subscribe any messages, but even if you would do so it will be faster than the REST interface, because you can send and receive simultaneously...unless you don't wait for the update to send the next command ;)
Please feel free to test it.

from denonavr.

Very cool. I'll play with that when I get some time. THanks.

from denonavr.

Closing. I no longer have a Denon.

from denonavr.