Yes, it does. But it is NOT clear whether HE deletes all children before the parent app is deleted (ST seems to do this whether you explicitly delete them or not).
In other words, you may want to code the ENTIRE delete process into your uninstalled() method, just in case Hubitat "forgets" to remove a child...
I will add it to a future release just so the phantom devices don't get left behind... I've always thought, because SmartThings does, that all child devices will be deleted when an app is removed, assuming they're not used in automations. Apparently from others experience that's not a given.
HubConnect 1.5.2 has been released!
This release fixes an issue where custom drivers were missing on hubs running the HubConnect Remote Client following the upgrade to 1.5.
This release also adds the humidity attribute to custom drivers too.
If you use custom drivers please update right away. It's only 2 files (Server & Remote Client). If not, there's no need to install this patch unless you need to use humidity in a custom driver.
I wonder if this was my issue.
I will try again.
I haven't looked at the new instructions yet but for you guys that had issues, can you confirm what you checked for and deleted as a belt and braces before I try again as I always end up with issues after a soft reset.
Thanks
As an interim upgrade step I would delete all of the HubConnect Remote Hub devices from your server hub before installing the upgrade. Based on user reports it seems there might be a few instances of orphaned hub devices causing issues. Deleting them will cause HubConnect to recreate them.
Since update on Saturday, I haven't noticed any major issues and love the update.
Something separate from the update, has anyone had any issues with websockets not reporting events at times from remote to server hub? Seems to be 1-2x a week until I turn the Remote Hub off/on on the server hub to reestablish the web sockets connection. I had that issue now for a long time, not related to the 1.5 update at all. HTTP seemed to be worse with that regard when I tried it before months back. I wonder if it's more hub related though maybe with how HubConnect is getting the events from Event Sockets, I did try deleting all HubConnect apps/drivers along with code and recreated everything last month along with soft resets of all 3 hubs but didn't help at all with fully fixing that issue.
No errors shows in logs either so not really sure why that happens. Was mostly curious if anyone has had issues with events not feeding at times from remote hubs to server hub until the Remote Hub was turned off then on to reestablish the Web Socket connection with remote hub.
All 3 hubs are on the same LAN and not seeing too many disconnects between the hubs per logs unless I reboot the hubs for things like updates which would obviously show the errors for no connection between remote/server hubs.
Is Maker API a possible option someday in the future for getting events instead of Event/Web Sockets? Not sure if that would give HubConnect everything Event Sockets does or would even work since I barely played around with Maker API yet myself.
I remember seeing this post previously regarding Maker API, not sure if HubConnect uses the same methods though:
Updates just don't want to work for me.
Getting flooded with websocket reports from my Tado Heating.
Historically MakerAPI would have been a terribly inefficient way to do it, as you had to poll for events. Now that events can be pushed from MakerAPI it might technically be an option,
But I would see little reason to do it until they actually decide to take away the event socket, as it works really well and takes considerably less configuration than MakerAPI.
Gotcha, thanks for explaining. I guess my concern at this point is why the websocket connection seems to be stopping for me really since websockets support was added on HubConnect. I can't figure out why I get the disconnects a 1-2x a week until I turn off then on the websockets device.
Don't know... I have web socket connections that have been open for weeks continuously.
Could be lots of things causing issues though - heavily loaded hub, network interruptions (bad cable, bad switch, other), etc.
Can always turn on the HubConnect web socket daily auto-restart feature on the client devices... See if that helps band-aid it.
HubConnect has nothing to do with the data that is on the websocket. That’s provided by the hub on the other side of the link. All it does is parse the events that are posted to the socket.
I have noticed the same thing, with the websockets slowing down after a few days. That is explicitly why in 1.5 I added the capability in the Remote Hub Device to schedule a daily reconnection of the websocket. I have mine set for 4am. Since doing that I no loner experience any slowdowns on the websocket itself.
I have no plans to implement Maker API. It uses http as a transport and therefore offers nothing that HubConnect over http does not. It in fact it would require a lot of effort to make work since HubConnect also must communicate at the app level between server and remote. It would also create a disjointed user experience as another app would need to be installed and its configuration would be outside of the HubConnect app.
I wouldn’t worry about websockets going away. There are a lot of apps that have come to rely on it, so they would be breaking a lot things if they did. And even if it did happen, you simply switch over to http and things will keep working.
@srwhite
I found my issue with "App driver version report" not reporting the remote hub app version installed and latest.
On the remote hub Hubconnect app if you set an "optional" name for the hub it will not report
If you leave it as default blank it will work fine.
Yeah, I see now how that field which was added over the summer is intefering with the version report. The good news is that it is an easy fix. I'll have a patch out for that and a few other minor things in a day or two.
Thanks for the response, I'll try that option to see if it helps
All has been well since last night. Except for just now for some reason my server hub is showing that my remote hubs are online.
But one of my remotes is showing offline.
Before it went offline I noticed the "Select Devices to Synchronize to the Server Hub" tab went missing.
When selecting the connect to server hub from the offline remote it has this
EDIT: I ended up deleting the remote hub on the server and its device and the app on the remote and reconnecting them again. It's back up and running fine now.
Just upgraded from 1.4 to 1.5. Nothing seems to be working yet report shows everything green.
My logs are flooded with errors:
Any ideas?
We seem to be seeing a lot of the 'orphaned hub device' symptom. @srwhite noted that the device must be a child of HubConnect. Now with that driver on BOTH ends, there's double the opportunity to have "Instance in use by another hub."
The quick cure is to do as you did.. delete the HubConnect Remote Hub device and poke the other hub to recreate it.
The part I thought was strange is it only appeared 'orphaned, visibly on the remote side. The server side continued to show online, and debug logs continued to show events coming from the remote.
It's an orphaned device in the sense that Hubitat does not make the device available to HubConnect. By iteself it will still connect to the websocket and try to parse events. But since it doesn't belong to the HubConnect sever instance anylonger, it cannot be properly initialized.
As @csteele said, delete the virtual hub and go back into the instance and simply click done. HunConnect will rebuild its remote hub device and you'll be good to go.
I have noticed that the fancontroller hubconnect device does not support Set Level, or at least does not accept this command. This makes it impossible to control via smart speakers, or to adjust with a dimmer, etc.
Download the Hubitat app
