is the new file just checking if the port on the hub is open/closed and then fallback to websockets?
btw @ehendrix , are you aware there is an issue in websockets? that the hub is in a undiscoverable state after a while?
The new one has been using asyncio as that is what Home Assistant has been moving to. There are also a number of updates that have occurred such as:
- Ability to add a delay for a send command (simulating pressing the button on a remove for x seconds)
- Added service change_channel
- When sending commands, the device name can be used (instead of device ID)
ahh, change channel? i did it before lilke this :
harmony_channel_2:
sequence:
- service: remote.send_command
data:
entity_id: remote.harmony
device: 43446701
command: 2Correct, it checks if port on the hub or XMPP is open or closed. If open then it will use XMPP, if closed it will fallback to websockets (and put a warning in the log file as Logitech stated that for open source XMPP is the way to go).
No, I am not aware of an issue with that. I also just checked and there are no open issues on GitHub.
seem my comment here :
https://github.com/home-assistant/home-assistant/issues/21191#issuecomment-465168485
here is the community thread :
thats the reason why i am still using it as a custom
Yep, that works too. The change channel service uses the actual Harmony functionality to change channel (same as remote or Harmony app does).
So you can do (Harmony will then send change channel to correct device depending on activity, same as remote does):
harmony_channel_2: sequence: - service: remote.harmony_change_channel data: entity_id: remote.harmony channel: 2
or, for sending command instead of using device ID use device name (assuming 43446701 wold be device with name TV):
harmony_channel_2: sequence: - service: remote.send_command data: entity_id: remote.harmony device: TV command: 2
Issue in GitHub was closed
I do recall some of it. There seems to be an issue on HassIO itself. I have been working on another component (does not use web sockets if I recall correctly but keeps HTTP connection open) and similar issues on HassIO.
The errors being reported back are like “host unreachable” etc, that really is the OS returning that it cannot open a socket to the host.
I think it is an issue in the OS or an issue within the Pyton libraries for HassIO itself. Harmony component here is then just a victim of the issue. Don’t like putting “blame” somewhere else, but here we do a call to connect and what is returned is an error from that call (which ends up being a OS error).
As you had the issues, if you can check out this updated one using XMPP. Would appreciate it.
will do, i really love the harmony component, together with xmpp 
hmm, loaded the new file :
2019-03-14 21:51:13 ERROR (MainThread) [homeassistant.components.hassio] Testing configuration at /config
Failed config
General Errors:
- Platform not found: remote.harmony
Successful config (partial)
@ehendrix
this is the correct file? new PR
https://raw.githubusercontent.com/home-assistant/home-assistant/da89f0ffa0592077a415599218990861e6c00333/homeassistant/components/harmony/remote.py
as soon as i overwrite my older custom compotent remote.py file, i get th error below?
2019-03-14 21:51:13 ERROR (MainThread) [homeassistant.components.hassio] Testing configuration at /config
Failed config
General Errors:
- Platform not found: remote.harmony
Successful config (partial)
what am i missing?
seems it doesnt install the new aioharmony requirement or something?
Yep, that is the correct file.
I would have expected some other kind of error if it would not install. Can you enable debug for homeassistant itself. See what it is failing on?
Must be somewhat specific to HASSIO I think. I tested multiple times on mine and it would download it successful. Also with it as a custom component right now.
Hopefully debug logs will show more info.
hmm, nothing to see actually in debug :
2019-03-14 23:12:05 DEBUG (SyncWorker_2) [custom_components.harmony.remote] Discovered host already known: (‘Harmony’, ‘192.168.0.21’, 5222)
and then this :
2019-03-14 23:12:10 ERROR (MainThread) [homeassistant.components.hassio] Testing configuration at /config
Failed config
General Errors:
- Platform not found: remote.harmony
Successful config (partial)
Hmmm, cause the message that discovered host is already known, that means that the Hub was already added.
There definitely should be more DEBUG entries then. If you did not enable debug as default, then make sure you have:
logger: default: warning logs: custom_components.remote.harmony: debug aioharmony.harmonyapi: debug aioharmony.harmonyclient: debug homeassistant.core: debug
ok, copy pasted your “logger” stuff, so i have more logs: there
but when i do a restart, i do have nothing more then below:
2019-03-14 23:28:21 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=homeassistant, service=restart, service_data=>
2019-03-14 23:28:25 ERROR (MainThread) [homeassistant.components.hassio] Testing configuration at /config
Failed config
General Errors:
- Platform not found: remote.harmony
Successful config (partial)
2019-03-14 23:28:25 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: domain=persistent_notification, service=create, service_data=title=Config validating, message=Config error. See dev-info panel for details., notification_id=homeassistant.check_config>i cant do a restart when i load your new .py file, its stuck then
thats why i maybe dont see anything in logs?
A new comment on GitHub. : Python modules have to be available via pypi.
That’s maybe the issue? Hassio isn’t downloading it?
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.