Yep seeing firmware .250 they must have pushed.
I’ll wait for 0.88 and hope for the best.
88 released 
Yep harmony back to work 
Hi,
for the ones using harmony.py as a custom component, make sure you rename it now to remote.py and the folder remote, rename that to harmony
t-its a breaking change in 0.88
if you have this line in your log, you are good
(MainThread) [homeassistant.loader] You are using a custom component for harmony.remote which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant.
1 Like
All,
Just posting it in this thread as well since this one seems most active on Harmony.
I just created a PR to include XMPP support in Harmony component. Logitech stated they will leave XMPP alone (we’ll see). If XMPP is enabled on the Hub, then it will automatically use it. If XMPP is not enabled on the Hub then it will default to using web sockets (what has been working since end of December).
The PR cannot be merged yet as I’m awaiting a fix for a dependent library. From the PR you can retrieve remote.py and then put it as a custom component for HA. Please do not do so if uncomfortable with this.
Appreciate feedback etc. on it. Figured might as well get some more testing in place in the mean time.
PR #22046 WIP: Add support for XMPP to Harmony
ah, i am still using the old harmony.py file as a custom, i enabled xmpp in the harmony app on latest frmware
how is this file now different then the old one from like 84.x and below?
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)