thats indeed working, now i am on 0.1.9
now what, test your original PR ? or test your PR with modifing to 0.1.9 ?
Woohoo… Sorry I did not think about this earlier. 
If you for now can check if this works with this version. Probably need to let it run for a while as you would be getting errors only after x number of hours right?
If this works, then not only will I have it as part of the version that includes XMPP but there is also another component that can then benefit from this change.
So not sure how often the issue would happen, but sounds to me like you could easily see it multiple times within a 24 hour period.
When you feel like it ran long enough without issues (you would normally have seen the issue happen) <fingers crossed you don’t see it happen>. Then feel free to update the requirements to using GitHub to test the new XMPP.
ah, you mean the undiscoverable issue with websockets? ok, il will leave this version now like it is
i had the automation still live in my yaml file, so when the websockets issue occurs, i get a notification
so will let you know…
#Harmony Monitor
- alias: Harmony monitor
trigger:
platform: state
entity_id: remote.harmony
to: 'unavailable'
action:
- service: notify.html5
data_template:
message: >
Harmony is {{ states('remote.harmony') }}, trying to sync
- service: remote.harmony_sync
entity_id: remote.harmonyi had it indeed about 4-5 times a day
Yep, so if we have it for like 24-48 hours without issues then I would definitely think problem solved there.
And after that test (so in 24-48 hours or so), feel free to try out with the new requirements. As long as your hub is enabled for XMPP it will then automatically select XMPP.
Ok, Will do
But what is changed in 0.1.9 that could solve unavailable state?
Changed some options for socket based on some stuff I found online with other people reporting similar issues with aiohttp library but only on certain installations (i.e. within docker). Something mainly to do also with forcing IPv4 socket.
well, a few hours later, and no unavailable state, looks indeed better on 0.1.9
Don’t jinx it!
well, almost 24 hours later, seems stable
Hmm, just turned off an activity… A few seconds later to got the unavailable state 
I keep getting “unavailable” status for my harmony remote also…
But are you also using 0.1.9. ? In my case, it less frequent now then before, only 1 case, and about 30 hours testing
I’m not sure but I’m running HassIO v0.88.2 with no customization per the messages above. Just wanted to confirm that others experience this also, and I use my Harmony daily.
I’ll do an update today just in case it helps, but it’s looking like I’ll have to keep restarting my Home Assistant at until HassIO 0.90.0 is released; if I understand the messages above.
you can use my automation , a few posts above, it will reconnect when its in unavaible state
i am not sure if the new harmony/websokcet 0.1.9 will be included in 0.90 , i dont see it yet in the RC release notes
but after 2 days of testing on 0.1.9 , i only had the issue unavaible once
It would go to unavailable if connection was lost. But it will start trying to reconnect then automatically. Status goes into unavailable if connection has been lost for certain amount of seconds, which normally would already mean that we’ve been unable to connect again.
Anything reported in the log files for this?
If not already enabled, enable some more logging for aioharmony:
logger: default: warning logs: aioharmony.harmonyclient: debug aioharmony.responsehandler: debug aioharmony.hubconnector: debug
Wanna see what it is reporting when connection is lost.
Glad to hear it’s already become more stable however. 
ok, logging now enabled on 0.1.9 edition, although it seems stable for 95%
in my case when it happened once, it was my automation that did the reconnect, thats why i know it disconnected one time
about your new PR, is that also coming in 0.90 or later ? you said earlier, that default is xmpp, if not open, then it will fallback to websockets, but if i look in your code, i see 8088 as default port ? and not the xmpp one?
Thanks!
What happens is on disconnect it will fire an event and then try to reconnect. The event is picked up and then it waits for 10 seconds before setting the entity to unavailable (if not being able to reconnect by then). Thus by the time the entity is showing as unavailable it would have already tried to reconnect back to the Hub.
The new PR will be later, still working with XMPP owner to get fixes in their library and then they need to release it as a new version. Only when the library with the required fixes is released can I then finalize the PR for Harmony and get it included.
But, if we can get this websocket one fixed then that can be pushed faster into HA as not dependent on another library for this.
For port, it is not used. Another PR later will be submitted just to clean that up.
ok, thnx for info
well, i have debug now enabled, when i see something strange in it , i let you know
1 Like
crap, just had a state unavailable and i disabled debug like 2 hours ago
enabled it back now…
2019-03-20 19:45:51 ERROR (MainThread) [aioharmony.hubconnector] 192.168.0.21: Connection timed out for hub 10271701