HEOS "Unavailable" requiring HA restart

Feature Requests
1

Hello! The original HEOS support thread was closed, and I’m not even sure this is an issue with HA. I’m more looking to see if anyone else has a similar use model/issue.

I do NOT log in to a HEOS account and I prefer not to – I realize I’m missing some of the features but my preference is to not allow devices to phone home.

I have a HEOS 1 speaker which I purchased as a test. The entity comes up fine (thanks for this!) and I have automations that play media on the device from internet streams or a local DLNA server.

The issue is that something always glitches (blue LED on front panel starts flashing) and the HEOS device will then show as unavailable and HA will never recover from this. I must reboot the HEOS speaker and wait for it to attach to the network, then restart HA – no other combination has worked in getting the speaker back on line.

The mobile app will stream media to the speaker even when HA is showing the device as unavailable, so apparently the component isn’t attempting to restart the interface to the speaker.

I have added debug to the logs for both the heos component and pyheos with no indication of a cause.

Is it at least possible to restart the heos entity if it shows as unavailable, or as a service call? I would probably be OK with intermittent glitches if I can get the system to autorecover but as it is the HEOS speaker is a brick without an HA restart. This makes the speaker basically useless in my case.

2

Hi @inkblotadmirer,
I have the same problem, it seems to be an error in the TCP stack of a Raspberry. I tried it from different platforms, containers etc. It al works fine, but with a PI I get the same results. It seems to happen after a power down of the Heos device (for a few minutes). A manual restart option/button would be nice until then I am hoping for a fix in the PI TCP stack.

3

Same here, how did you solve it for now? Maybe the component can check every so often to see if it became available? Really annoying to reboot HA once every 2 days because of this

4

With the latest update of hassbian and home assistant (I don’t know which did the job), the problem is solved.

5

@williamgeurts

Based on your feedback I’ve brought my HEOS back on line to revisit its use in my setup. I reset the unit and set up integration again but I don’t know if that actually does anything except create extra work. :slight_smile:

In debugging my automations I did notice a behavior difference from what I expected. If you stream an mp3 file to the speaker, it plays fine and status changes to “playing”. Upon completion it returns to “idle”. My automation relies on this, a trigger occurs on transition from playing to idle, and another song is queued up – but the speaker does not clear the old song from the queue, so the new song will play followed by the old song before returning to idle!

This wreaked havoc on my automations because I can select from a streaming source or DLNA server, for example – anything played in the past stayed in the queue.

I’ve updated my automation to “clear_playlist” prior to sending a stream or upon stopping. It’s TBD whether the issues I was having with the offline behavior is fixed or not. Since I have a nominally working setup I can spend some time troubleshooting this: wireless vs. wired, app vs. Home Assistant, etc. I’m sure hoping I don’t just have a unit with bad hardware.

6

@inkblotadmirer
As I mentioned at Oct the 8th, it suddenly worked as expected. I don’t know what did the trick, because I sort of accepted the situation. I am running HA .101.3 on Hassbian. The HEOS runs on 1.520.200. I am not a developer, so I cannot help you.
Good luck

7

I am having similar problems. Seems like the integration only tries to connect once at startup, if the configured unit is not reachable at startup of HA it will not recover the connection unless I restart HA.
And at least in my setup it happens a lot that HEOS units sometimes takes long time to respond which seems to be enough for the HEOS integration to think it is unreachable.
This has been the case “always” since HEOS integration was included in HA as far as I have seen.
Other HEOS units than the one with the IP address configured in HA will eventually recover if they are unreachable at startup.
Seems alos like it can loose the connection after a few days even if it had a working connection at startup, and then never recovers.

So I think there definitely is some room for improvement on error recovery in the HEOS integration.

Anyone else having similar issues?

8

Yup, same behaviour for me!

9

@inkblotadmirer @Cadish @olalid @skynet01

Bumping a very old thread.
I had the same problem but managed a small work around which should do the trick.

I use nmap to detect if the wireless speaker is connect to my network.
When it’s connected I restart the config.

- alias: Restart Heos add-on when wireless speaker is connected
  id: '910'
  mode: single
  trigger:
    - platform: state
      entity_id:
        - device_tracker.denon_slaapkamer_1
      to: home
  condition: []
  action:
    - service: homeassistant.reload_config_entry
      metadata: {}
      data: {}
      target:
        entity_id: media_player.slaapkamer_1
10

Wow. Many thanks for necro’ing this thread!

Since the original post, I have converted from a manually supported installation to the docker installs of OS, supervisor and core.

I found my stashed speaker and luckily I didn’t delete anything from my automations/scripts, just removed the HEOS integration. The only thing I had to change is playing media files from my server is now “music” and no longer “url” (streaming is still “url”).

Just playing with it, there are still dropouts but it appears this may be usable albeit somewhat unreliable. I already have network nodes monitored with ping so I could add the speaker and reload with your method if that proves necessary – so far, I haven’t had to do this. I did configure the speaker with wireless power saving “off”.

11

Welp, somewhat disappointing conclusion to this update. I spent a few hours reliving this experience, but either the device has a fatal design flaw or I received a lemon. My HEOS still resets in unusably short time intervals (whether on wired network or wireless), making it pointless to use. (To be honest, I was surprised it was completely intact when I retrieved it from storage, because I came to this conclusion the last go-around and was planning to pull it apart and do some troubleshooting.)

Kudos to HA and the integration, however – when it resets it typically re-appears automatically in HA without having to reload the config.

I’d still be in the market for a quality speaker I can attach via wifi but it seems this battle is lost and only closed or cloud based solutions remain.