How goes Harmony Hub implementations?

This is becoming more and more frustrating...

I went to the lengths of:
- deleting the Harmony driver and
- reinstalling the Harmony driver
- flashing the hub back to factory settings
- restoring the Hub from the Logitech servers (from a previous backup)


I have now re-added the Hub to myserver (again, having to do this manually with the IP - autodiscover does not work).

The Hub now appears in myServer (as AV|3), but brand-new device addresses have been assigned to all of its devices and activities.

For some reason the server still uses the old device addresses. Given those addresses have changed, nothing now works at all.

I have tried this with (a) my own remote scenes and overlays (b) the smart-remote template (updated twice to check it wasn't me) and (c) direct server commands.

By way of example:

- The activity 'Watch Plex on TV' now has device address 51927820 associated with it.  It previously had device address 52254493.
- When I click to run the activity from the remote, nothing happens.
- The log shows:
 03/04/2024 20:59:48.59 · DEBUG · Server.doCommand - SetActiveSource|Plex on TV from smartremote-template-fx-giw803/04/2024 20:59:48.59 · DEBUG · Server.doCommand - SetVariable|{{activeroom_{{clientname}}}}_source~{{activesource_sourcename_{{clientname}}}} from smartremote-template-fx-giw803/04/2024 20:59:48.59 · DEBUG · Server.doCommand - SetVariable|extension_source~Plex on TV03/04/2024 20:59:48.59 · DEBUG · Server.doCommand - AV|3~Select~activities~52254493 from smartremote-template-fx-giw8


ie - it is attempting to activate the old (ie wrong) device address


To check, I ran the following command direct from the dashboard

AV|3~Select~activities~51927820 

it worked and the activity started

Why is the Harmony Driver still attempting to use an old set of Device IDs?  There must be a table somewhere which is not being updated? 
(I am really starting to loathe the Harmony driver - but I really want to get it to properly work)

I hear you. I started looking at the Harmony driver over the weekend and found that I can no longer connect to my test hub using the xmpp protocol. Not sure if anyone else is seeing this but is highly repeatable. So I am in the process of migrating the Harmony driver from the older xmpp protocol to the newer websockets protocol that is still working. It is going to take me another day or two to get everything re-written and tested. 

The goal is that when you update the Harmony driver it will seamlessly switch to the new protocol without you having to do anything. Then I can get to the bottom of fixing any remaining issues. Bear with me while I get this done. 

Thanks so much Dave. I am more than happy to assist if I can - if you want me to test functionality etc or report back. Just let me know.

@CrabPatties - In your removing and reinstalling the Harmony devices did you restart myServer at all? In my experimenting I've been removing devices, removing drivers, reinstalling them etc. a lot and it appears to me that even if you remove a bunch of devices provided by a driver then they stay in memory doing whatever they do until the next time you restart myServer. So you wouldn't see them in the myServer web interface but it might still be using them. Just a thought.

Andrew

andrew wrote:

@CrabPatties - In your removing and reinstalling the Harmony devices did you restart myServer at all? In my experimenting I've been removing devices, removing drivers, reinstalling them etc. a lot and it appears to me that even if you remove a bunch of devices provided by a driver then they stay in memory doing whatever they do until the next time you restart myServer. So you wouldn't see them in the myServer web interface but it might still be using them. Just a thought.

Andrew

Thanks Andrew.  Yes it occurred to me that it might have been some sort of temporary cache issue, but after many resets the problem remains.  The driver still seems to call on old/prior ID addresses which are no longer current.  On very first install of driver and connection to hub, there must have been some table written to file somewhere which is persistent and is not deleted or overwritten when a new / factory reset and restored hub is added.

I am now totally stuck.  My only option is to manually change every macro to launch the activity / device not by name but by reference to the new Device ID.  I have already done this for a few use cases (ie operating my blinds) but if the device IDs change again then this too will break.  I would prefer to use variables rather than absolute references for this very reason.

Hopefully Dave has something up his sleeve.  Seems me that getting Harmony sorted is key - there is a pretty big potential user base out there looking to replace / update Harmony remotes no longer sold by Harmony (and who knows how long supported)?

CrabbyPatties wrote:

andrew wrote:

@CrabPatties - In your removing and reinstalling the Harmony devices did you restart myServer at all? In my experimenting I've been removing devices, removing drivers, reinstalling them etc. a lot and it appears to me that even if you remove a bunch of devices provided by a driver then they stay in memory doing whatever they do until the next time you restart myServer. So you wouldn't see them in the myServer web interface but it might still be using them. Just a thought.

Andrew

Thanks Andrew.  Yes it occurred to me that it might have been some sort of temporary cache issue, but after many resets the problem remains.  The driver still seems to call on old/prior ID addresses which are no longer current.  On very first install of driver and connection to hub, there must have been some table written to file somewhere which is persistent and is not deleted or overwritten when a new / factory reset and restored hub is added.

I am now totally stuck.  My only option is to manually change every macro to launch the activity / device not by name but by reference to the new Device ID.  I have already done this for a few use cases (ie operating my blinds) but if the device IDs change again then this too will break.  I would prefer to use variables rather than absolute references for this very reason.

Hopefully Dave has something up his sleeve.  Seems me that getting Harmony sorted is key - there is a pretty big potential user base out there looking to replace / update Harmony remotes no longer sold by Harmony (and who knows how long supported)?

A lot of work is going into rewriting the Harmony driver for the API.  Behind the scenes that's a whole new driver.  So, let us finish that and give er a go when done.
If Logitech shut down the XMPP, then possibly they are starting to shut down services, or aren't monitoring their servers, or whatever conspiracy theory we can come up with, but that is what stinks about any integration reliant on cloud.  What is surprising is it seems to work on some systems and completely not on others....who knows, maybe they have multiple servers and not all are up at the same time.  Looking at Reddit posts, lots of folks have issues with Logitech / Harmony servers when others aren't.  Not sure how much of that is user error / local networking (probably most) or server unavailability....

If it were me, I would be moving stuff off of Harmony Hub completely and onto native myServer drivers.  Use Harmony Hub for devices that myServer doesn't support natively.  Your user interfaces will be more intuitive (customizable), and less pieces in the chain for reliability.