I've watched the hubitat logs a few times I did this and the hub reconnecting WASN'T always instant, so yeah, like you said may just take a bit but always fixed it for me and home control buttons returned to working. I'm gonna setup a webcore piston to refresh if presence changes too. Good thinking!
1 Like
Yeah, I'm hopeful, as long as the Debug logging change isn't required. I haven't found a way (and don't know if there even is) to turn that on or off from an app, since it's a preference and not a command.
I can't see how debug logging would make any difference whatsoever. It literally only disables logging, nothing else.
1 Like
Yeah, that's logical, it seems like the "Refresh" is the only action that should actually affect functionality...
Just clicking refresh never fixed it for me. But toggling the debug did ¯_(ツ)_/¯ but the "initialize" option is exposed to webcore so I have a pain set up to initialize if presence switches to not present. See if that is an ok workable solution
"initialize" is also exposed in Rule Machine under custom action (actuator) so no need for webcore
1 Like
Refresh, simply interrogates the Harmony hub for its latest configuration, and then adds any newly created Harmony Activities.
If one changes any of the parent device’s settings, and/or clicks SAVE, then the driver will run the Initialize() command from within the Updated() command. Thus the reason that it appears that enabling debug and then clicking save is a fix for a disconnected hub.
1 Like
Now that makes sense! Thanks for the additional information. Going to update my Rule to run "initialize" via custom action. FTW! (I hope.) 
Also going to add a notification to the rule so I get a text when it runs...that way I know how often presence is getting un-present. 
If you come to any conclusion, I will try to improve the driver’s automatic reconnect logic.
Proof!?
Text notification:
Driver status after notification:
Home control buttons are working.
Logs: (Sorry, in bed on phone.)
There should have been a log.warn entry in your logs just before the Harmony hub's status changed to 'not present'. Do you see that? The reconnect logic has always worked at my house, and it simply calls initialize() when it detects the webSocket connection has been dropped.
There may be one scenario where the reconnect logic is not triggered, however... I am trying to understand why I did not trigger it when the webSocket status was 'closing'??? Maybe because it should eventually change to 'closed', which does trigger the logic?
Yeah, we were in bed, I was on my phone, and it was (according to my CEO/wife) time for sleep so I couldn't grab a lot of logs last night.
Some logs below - hopefully helpful.
I am seeing disconnects/reconnects by the driver (driver-initiated "initialize" fixes it), and then once in a while my five-minute lost-presence trigger for the rule is met and the rule runs initialize.
- dev5276 = Rule
- dev4354 = TV
Rule:
Logs:
And below is all the logs from the TV from this morning around 10 am until about 5 pm, in case that is useful/interesting.
Let me know if you need more/different logs.
I am on the road right now. I’ll take a deeper look when I get home.
1 Like
Hope the trip goes well, and you enjoy some good eats.
2 Likes
Assume there are a few people moving Harmony over with the Groovy shutdown on ST. Here is another version of a webCoRE piston that is somewhat easier to update. Just change the variables to what you need.
This Piston appears to use the Harmony Remote control's "Home Control", buttons, correct? If so, then if folks are still using the SmartThings workaround to use these buttons, be aware that when ST shuts down their Groovy platform, that trick will no longer work.
Do we know that to be true since the Hubitat websocket is directly talking to the Harmony socket for the home button trigger information? The Logitech (Harmony) integration to ST Cloud does use groovy from what I understand, but curious what happens when that is broken.
Will the Harmony hub still issue websocket commands like it does today, or will it know the ST cloud is gone and go mute?
That’s a good point. We really don’t know if existing systems will break when the Groovy platform is shut down. Definitely, new installations will not work. But existing ones might continue to work, unless SmartThings tells Logitech to remove all ST integrations, thereby updating the configuration on the end user’s Harmony hub.
Personally, I simply moved everything over to use the Philips Hue and Logitech Caseta integrations with Harmony hub.
1 Like
@ogiewon , thanks for your efforts on this integration. I was sitting smuggly thinking that the ST/Groovy would not affect my Harmony/ST automations only to find out that was going off the rails too.
I have two Harmony Hubs with the Elite 950 remote, so was scratching my head a bit on setting up two hubs until I figured out that you just set up another virtual device in HE as per the single hub instructions. Easy Peasy, although I did set up the hubs with DHCP static IP assignments.
I had migrated my 130 odd devices over to HE aleady, so your driver made this last bit actually quite easy as all my theatre/living lights are HUE. I installed the Harmony/HUE integration on the Harmony remotes to port my Home Control buttons over to directly control the HUE lights.
Then, to my surprise the "master" Harmony switch that your code installs in HE is all I need to control my motion lighing automations for both living room and theatre by holding off activations, turning off etc. based on the status of the master Harmony device.
Awesome work..and thanks!!
1 Like
