I learned a lesson yesterday, which I guess I should have thought of ahead of time but didn't. I'd moved the vast majority of my ST devices over to my C7, and I wanted to rid my C7 of all the hub connect devices and start fresh, and later bring over the few remaining devices I'd like to have still connected. Rather then having to go remove all the devices manually in the ST app, I just assumed if I killed the connection, the ST devices would also be removed from my C7. Not so, I ended up with all sorts of hubconnect orphaned devices on my C7 and I had to go through and remove them individually.
I'm sure several of you are either laughing at me or slapping your foreheads, or both. So next time before i mess with the connection I'm going to make sure I clean things up on the Smartthings app first so that I don't leave a mess If I kill the connection.
Thanks, @csteele. The problem with my laziness, was that I didn't want to spend the time to deselect the real devices in the SmartThings hubconnect app. I couldn't find a super quick way to unselect them all and one fell swoop, and so jumped straight to the nuclear option and paid the price.
I was thinking about using a technique like @adamkempenich's here to have each of my hubs monitored by one other hub and, if non-responsive, then the "monitoring" hub would fire off a reboot. Then I got to thinking, rather than creating new virtual devices and new monitoring rules, why not use the Hubconnect remote hub devices to do the monitoring? Couldn't the eventSocketStatus and/or presence attributes be used as proxies for the remote hub's health? And then I could fire a reboot based on that.
I'm having some issues and as i'm new to HC, i'm unsure why its happening. Basically events and being sent from the remote to the server and its reacting but the response back to say that the lamp is On for example isn't getting updated. Turned on digging and its working again?
Thanks Adam. Any Hubconnect expert know which attribute(s) of the remote hub device is a good indicator of whether it can "talk to and hear from" the other hub? I tried to test it by purposely turning of the hub and noticed both Presence and eventSocketStatus changed. But I don't know if they'd change for other reasons as well.
HubConnect no longer works with ST. The classic app is being disabled now and when you try to edit it in the new ST app you can't, the spinning wheel just spins and spins so I had to force remove it via the IDE.
Hubconnect smartapp seems to be accessible for me using the new ST app; at least I was able to view lists of devices that I have mirrored to HE. I didn't actually make any changes (I backed out at the point of doing so since I don't want to screw anything up).
Weird. I just went into it again and got a spinning circle. Kill the app restarted it, and was able to get into it again. so I guess it's working as well as anything on SmartThings usually does LOL.
I created a Video of how to add ST as a connected hub a week or so ago.. here
and just now I went in and deleted one of the devices I had mirrored over. It worked.
I then followed up by doing a:
on both ST and the Hubitat hub I used for the video. Earlier this morning I pasted a screen cap of my "production" list of HubConnect:
That was then.. I created an entirely new connection, exchanging key, etc. then 'mirroring' a pair of devices. All of it worked and now my list looks like:
So... as far as I can tell HubConnect is working correctly with ST, for me.
Does anybody know what it takes to make one of the hubconnect drivers fully compliant with new st app?
My mirrored devices work in the new app (or did the last time I checked). However they do not work from the st watch on my galaxy watch.
I tried doing it myself awhile back but could not figure out what the secret sauce was.
If i use a inbuilt st device i can mirror hubconnect devices with webcore and they work fine in the app. Hoping someone watching has some insight. I feel like it cannot be overly complicated. It is for me though.
The Classic ST App will still function as it has until October 14-17 (ST transition doc here) and afterward the new SmartThings app will be the single mobile app. The new ST App falls way short of the functionally of the legacy ST app, and ST Community users have been very vocal about the limitations, missing devices, WebCore interface, etc.
Native ST apps developed using groovy will still function after that October cutoff date and can be added/edited in the ST IDE. The ST cloud will still be accessible via http API as before. The current Cloud-based system for monitoring Hub-connected devices will be replaced with a new service that runs locally on SmartThings hubs. ST Hubs with older firmware (pre-0.32.x) will begin using hub connectivity status to determine online/offline status for hub-connected devices (e.g., Zigbee devices, Z-Wave devices and locally executing LAN devices).
I verified that the latest release of hubconnect App is working in the new ST app, But each day, I have to repair some issue as I have one foot in both ST and Hubitat, and starting to lean toward 99% hubitat with my 130+ devices..
I am so looking forward to brining over my 'Ambient Weather Station, BitBar App, Orbit Bhyve, etc custom apps from ST to Hubitat. I have already added some of my App's version 1.x initial conversion via Package Manager. I will dedicate the rest of the Covid-19 year to making these home automation applications and others fully hubitat compliant and optimize performance..
So next time before i mess with the connection I'm going to make sure I clean things up on the Smartthings app first so that I don't leave a mess If I kill the connection.
