Yeah, does seem something specific to Hassio, maybe it is not downloading it or so. That’s a bummer … was a bit hoping you could test already.
Waiting for that dependent library (slixmpp) to get the fixes and go into pypi.
Probably someone else can test, but I think you can post this new stuff in the other thread about Logitech in the blog section, not this one… 
Anyway, sleep time now, already 00:00
I think that analysis is lacking. The only one mentioning host unreachable seems to be you and Hass.io has lots of TCP-based integrations that work well.
It seems more likely to me that the websocket implementation has an intermittent issue and it is only being observed on Hass.io because that is what everybody is using.
running hassio here, no issues in current versions. In fact, I haven’t had issues since the dark December when they removed xmpp. In fact, I have my ‘dev’ version hassbian and my ‘release’ version hassio working at the same time most of the days both talking with harmony.
i dont have issues with websockets either, but i just from time to time had the undiscoverable issue
so i needed to resync to access the hub again
1 Like
Here is for example where it was reported:
Now the exception reported there is what is being returned by the aiohttp library. Within the Harmony library it is just being caught and reported upon as is.
So it is not just me. Note also that up till now those that have been reporting issue seem to have been on HassIO.
I run it here at my home as well with 2 Harmony HUBs and it’s probably one of the most stable connections I have (cause it is going to something inside the house as well and not to external servers).
I’ve worked with others who run with it without issues and they are not on HassIO.
Been seeing similar issues with another component (August) where it’s network connection is flaky and errors returned back are OS errors like “Host unreachable” or “Network unreachable”.
See: Lot of delay in status, locking, doorbell ding sensor · Issue #9 · snjoetw/py-august · GitHub
This user is also on HassIO.
Here is someone else reporting similar issue on HassIO with host unreachable for no apparent reason:
Now I know for Harmony and August components aiohttp is being used. For August it uses pooled connections (and thus connection to server is kept open) and Harmony is using web sockets (connection is being kept open).
The connections are working fine for a while and then suddenly they fail with errors like “Host Unreachable”. This error is being reported back by the aiohttp library and is an OS error (or aiohttp library is interpreting something else as this).
So far what I know is that the issue like this is being reported not only for Harmony, seems to be for component(s) that keep their connections open, using aiohttp, and seems to be only on HassIO.
Where exactly the issue is however I do not know. Might also be only on HassIO running on certain hardware only. Or be certain level of OS that includes a certain level of driver or so just a lot more common on HassIO?
Be it an issue in the OS, be it an issue within the libraries? I honestly do not know. But for some reason the socket is not only closed but opening a new one fails with errors like it is unable to reach the host.
I do not have HassIO so I am unable to dig deeper into it myself to troubleshoot.
I had asked others to see if they could run something on there to try to determine if things like ping etc. are failing at that same time or not.
in my case, i was running HassOS on esxi (vmdk image)
1 Like
FYI,
Just did a specific search on aiohttp and network unreachable. Others have seen this issue as well, seemingly related when running in Docker or so:
Seems to be something related to IPv6 and suggested solution is to ensure socket is only opened for IPv4 (if I understand these parts right).
Can you do me a favor?
Can you put back in as custom component the one from the PR. But then in the file change
# REQUIREMENTS = ['aioharmony==0.2.0'] REQUIREMENTS = [ 'https://github.com/ehendrix23/aioharmony/archive/dev.zip' '#aioharmony==0.2.0b4', 'https://github.com/ehendrix23/slixmpp/archive/master.zip#slixmpp==1.4.2.2' ]
to
REQUIREMENTS = ['aioharmony==0.1.9']
That still uses web sockets but has the suggested solution from those git hub issues added. Wanna see if that indeed solves the issue here as well (and if it thus, then known solution now for other components that run into same problem). 
Appreciate it!!!
Ok, Will do later, I try today, not at home now
Sorry, I rushed that a bit. I didn’t mean to imply that you were making thing up but just that I didn’t manage to find the report. I did now, thanks.
Since things work with the old XMPP implementation, the only changes seem to be with Harmony itself, aiohttp and the new websocket implementation. None of those relate specifically to Hass.io which is why I am questioning that claim.
For the record, I use your websocket implementation with Hass.io myself and I have not seen those warnings (but I do use my Harmony very little).
ts not about how little you use it
i had the undiscoveable state about 4 times a day, even if you dont use it, it was random
ok, tested this , so i used your new PR, the changed it to , see below
i restart HA, and again the same error :
2019-03-15 20:27:42 ERROR (MainThread) [homeassistant.components.hassio] Testing configuration at /config
Failed config
General Errors:
- Platform not found: remote.harmony
Successful config (partial)
REQUIREMENTS = ['aioharmony==0.1.9']
# WIP - BETA testing
# slixmpp also has an issue with HA>=0.87, fix provided to that library
# in the mean time added to this requirement to download my
# copy from github.
#REQUIREMENTS = [
# 'https://github.com/ehendrix23/aioharmony/archive/dev.zip'
# '#aioharmony==0.2.0b3',
# 'https://github.com/ehendrix23/slixmpp/archive/master.zip#slixmpp==1.4.2.2'
#]really strange, so its not about the requirements then?
When it disconnects it is detected and will then try to reconnect again. Hence even when not used you will see it as technically speaking it is always connected and if not will try to reconnect
in my case, when it was disconnected, it didnt reconnect again
i had an automation active, so when a undiscoveable state occured, i did a resync service, that fixed/masked the issue
Hmmm, can you get to a command line and install the library manually?
pip install aioharmony --upgrade
nope, cant do command lines , i am runnng HassOS, so pip and other stuff is not working for me 
in the custom component, that i am using with xmpp, i see this as requirement
so, maybe its indeed because i dont have the latest version
REQUIREMENTS = [‘pyharmony==1.0.20’]
So you are on Hass.io; use Harmony with web sockets, yet do not see these issues. Even if you do not use it a lot, it is always connected to the Hub, will discover when it gets disconnected, and then reconnect. Irrespective if it is used or not. Just has to be configured. 
Makes me to think that it might be something with on what or within what it is installed?
The git issues I found were referring docker as well.
Would love to get to the bottom of this. Not only for Harmony component but I would think potential other components as well.