Harmony hub problems after update


The current implementation only uses websockets. XMPP was going to be added back but I don’t think any work has been done. Just looking at the harmony resources, nothing has been updated since February 1st. aioharmony which is what is currently being used uses websockets. pyharmony which is the old API that was removed in December used XMPP. pyharmony is not being used in the current implementation. So unless it’s integrated into aioharmony…


So weird. Maybe I just needed to reboot my server, or the hubs. I will say that with the developer firmware, everything seems to be working. Of course the developer firmware would work with xmpp or websockets. I just know the errors in my HA instance have gone away. :slight_smile:


I have an issue with Harmony hub as well. I have the following error in HA log:

ERROR (MainThread) [aioharmony.hubconnector] XXX.XXX.X.X: Exception on post: 0, message='Attempt to decode JSON with unexpected mimetype: ',
ERROR (MainThread) [aioharmony.hubconnector] XXX.XXX.X.X: Unable to retrieve HUB id


Mine also just died off 2 days ago. Same error as the user above. I am running the logitech ‘dev’ firmware which they made available when the whole outcry started.

Exception on post: 0, message='Attempt to decode JSON with unexpected mimetype:


Same issue here. HA can’t connect to hub.


Strange I have also dev firmware and today I needed restart hub and after I have all time problem with connection.


harmony published a new firmware 250, so if you are using old harmony.py file, re enable xmpp again, if yiu are using no custom component , wait for 88.0 it includes a fix for websockets


thank you for info.


Yep seeing firmware .250 they must have pushed.
I’ll wait for 0.88 and hope for the best.


88 released :wink:



Yep harmony back to work :slight_smile:



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 :slight_smile:
if you have this line in your log, you are good :slight_smile:

(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.



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. :slight_smile:

Appreciate feedback etc. on it. Figured might as well get some more testing in place in the mean time. :slight_smile:

PR #22046 WIP: Add support for XMPP to Harmony

Logitech Harmony removes local API

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:

  1. Ability to add a delay for a send command (simulating pressing the button on a remove for x seconds)
  2. Added service change_channel
  3. When sending commands, the device name can be used (instead of device ID)


ahh, change channel? i did it before lilke this :

  - service: remote.send_command
      entity_id: remote.harmony
      device: 43446701
      command: 2


Correct, 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 :