XMC-2 Power On/Off not reporting correctly

[JoshMcWilson]

For some reason, I'm not sure if it's something I changed on my end or not, but any time I turn off or on the XMC-2 from Home Assistant, it will respond to the command to turn on or off but then the integration stops reporting it's power state correctly and is stuck on the previous state.

For example, I turn on the XMC-2, it shows the device is on. Then I send a command from Home Assistant to turn it off

remote.turn_off

And the XMC-2 will turn off but it still shows in HA that the XMC-2 is still powered on. I then can't seem to turn it back on from HA until I reload the Emotiva Processor integration and then it is reporting the correct power state (off in this example).

I ran debug while attempting this and was actually able to get it to come back on by spamming the remote turn on service call two times in a row when attempting to bring it back online. It did bring it back up but logbook for the XMC-2 never reported that it was turned off and still thought it was on the whole time.

I've attached the debug logs for this scenario. Like I said, it was working flawlessly before the past few days, so I'm not sure if something changed on my end or not to cause this. Also, is it recommended to instead of using the remote send command to turn off and on but instead to use the emotiva service command specific to this integration to do "power_on" and "power_off"? I noticed that the logbook for the XMC2 still didn't update when I sent the commands that way but figured it was worth checking.

Let me know if there's anything else I can provide or if this is just due to the differences in the gen 3 processors and maybe an issue with the API not being updated for these. home-assistant_emotiva_2024-06-02T03-29-20.894Z.log

[JoshMcWilson]

Upon further testing it does appear the logbook shows the power on and off after a restart of the integration. I also noticed that the sound modes listed for my device don't seem to line up with the correct options for this processor. So I'm wondering if the integration is identifying it as an incorrect model so it's not reporting the information correctly or something.

[peteS-UK]

Hi @JoshMcWilson . No, nothing's changed recently, so it's an odd one. My first question would be- have you tried turning the XMC-2 off and on again - i.e. actually off with its power switch. I saw something similar a month or so ago, and it was that the processor had just stopped responding correctly to commands, so the states in the integration just got confused.

It doesn't matter which power mechanism you use - they all do the same. I tend to use media_player.turn_on in my own scripts etc., but that's just because when I first started, I hadn't added the remote entitity. When I turn it on and off from the device screen for example, they both do the same. This is using both the remote and media entity power and when you turn off with remote, it turns off the media entity and the remote entity for example

So, let me know if you're restarted the XMC (and then the integration). Turn on the debug before restarting the integration perhaps so I can see the whole startup sequence if you've already power cycled the xmc

[JoshMcWilson]

Hey @peteS-UK , thanks for the recommendations! Long story short, after hours of investigating another issue, I think it may be resolved now! I'm not exactly sure how this was related, but I was getting a lot of weird behavior due to another integration or integrations. My Android TV remote integration was being really wonky and throwing a bunch of errors, after fixing up that issue and disabling the ADB integration, the power status seems to be reporting correctly and all the logs show off and on as expected. I did also reboot the XMC-2 fully a couple times during my troubleshooting so that could have helped as well.

WIth that said, I'm not for sure but I believe that maybe the sound modes are still no longer reporting the correct options for my device. Here is what I'm seeing:

Is this to be expected? I feel like after you pushed the last release that it was showing the correct options for my processor, ex Dolby Surround, DTS X, etc.

[peteS-UK]

Hi @JoshMcWilson . Good to hear it's working again. The listener task (i.e. the one that acts on the feedback it receives from the proc) runs in a separate thread so that it can just run in the background, and I have seen integrations which are not "thread-safe" mess up other threads, so it's possible the adb integration has some not thread safe behaviour in there. They actually changed a load of the way threads work in recent builds to enforce more thread safe behaviour but who knows ..... Anyway, glad it's working now.

The sound modes are as they should be. The way the API works is a little strange (and not very well done!). When you query the mode, the name it gives Dolby is mode_dolby value="Dolby" and then it gives you mode_movie value="Movie". It also gives you the "actual" mode in mode value="Dolby Surround" but this is just a piece of text - it's not linked to the way it actually stores the states internally. So, you can't "set" the mode to "Dolby Surround", you set it by saying mode value="dolby" and mode_movie value="Movie", which the processor then tells you the mode is "Dolby Surround". It's a bit messy, so I just use the Dolby and DTS generic names, which are also consistent across XMC-1, XMC-2 and RMC. You should find that when you select DTS Movie for example, it will then display DTS Neural X (or whatever it's called). So, what you see in the list (and the way the proc actually stores the modes) isn't the same as the name it shows. Let me know if selecting the modes doesn't work though.

[peteS-UK]

Closing. Problem was caused by a different integration.

[JoshMcWilson]

HI @peteS-UK , thanks for previously getting back to me on that. Really sorry it's taken me this long to respond, life has been very hectic the past couple weeks! So I'm still unfortunately having this issue after disabling that ADB integration. The issue seemed to be fixed for a few days but I seem to be having it occur much more frequently now. I don't think it's helped by the lack of stability witth the Emotiva processor, as it does lock up from time to time. I've also noticed it drop off the network while it's powered on, so I am suspicious that perhaps there's some correlation between the stability of the NIC in the unit and it reporting to HA.

With that said, it was working fine until I had to do a full power cycle of the unit to try and fix an issue I was having with it at the time (unrelated to HA) and ever since then I can't seem to get it to report after taking it to standby or powering it back on.

I've tried running the debug logs to see if there's anything out the ordinary but they don't seem to indicate anything is (as far as I can tell at least).

I will also add that totally understand if this is not within the scope of this integration as it is very possible there is something else on my end that could be causing it or perhaps even just a bug in the firmware of this generation of processors that is causing it. But if there's anything you would recommend or would like me to provide to see if this can be resolved I'd be glad to do so. Thanks!

[peteS-UK]

Hi @JoshMcWilson . I've been doing some work on RMC with another user and posted a new version 1.7.2 yesterday which fixes a similar but perhaps not related problem with reloading the integration. Have you tried 1.7.2? If so, post the log and I'll take a look. As you say, lack of nic stability certainly doesn't help.

[JoshMcWilson]

@peteS-UK oh yeah, reading through that issue is exactly what I am seeing! I just updated, great timing, will report back when I can test it out this evening. Thanks!

[JoshMcWilson]

@peteS-UK , also, not sure if this is an issue or not, but last night I noticed in the attributes for the XMC-2 it shows HDMI 8 as null. Figured it as worth mentioning if this was an issue:

[peteS-UK]

Have you actually assigned input 8 to anything? Remember that the inputs are in effect the buttons on the remote, and you have to add them to a physical input. Certainly isn't a problem though I think.

[JoshMcWilson]

I have not assigned anythign to that input, though I have only used inputs 1-4 on the processor in the past. I just thought perhaps there could be something going on there. I also have an update on the power issue but it might make sense to add the info in the open ticket so I can do so for what I've found in my testing today.

[peteS-UK]

Yes, that's fine

---

From: JoshMcWilson @.> Sent: Wednesday, June 12, 2024 9:11:45 PM To: peteS-UK/emotiva @.> Cc: peteS-UK @.>; Mention @.> Subject: Re: [peteS-UK/emotiva] XMC-2 Power On/Off not reporting correctly (Issue #5)

I have not assigned anythign to that input, though I have only used inputs 1-4 on the processor in the past. I just thought perhaps there could be something going on there. I also have an update on the power issue but it might make sense to add the info in the open ticket so I can do so for what I've found in my testing today.

— Reply to this email directly, view it on GitHubhttps://github.com/peteS-UK/emotiva/issues/5#issuecomment-2163817613, or unsubscribehttps://github.com/notifications/unsubscribe-auth/API7QEML43ZDTNQVTHOFYB3ZHCTQDAVCNFSM6AAAAABIUWFCH2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRTHAYTONRRGM. You are receiving this because you were mentioned.Message ID: @.***>