No, the HC Arlo driver installed on the HE side so it can properly coordinate with the real driver on the ST side.
I really need some way to control my Arlos, and so far HC was the only method I could find if I stick with Hubitat. Sigh. There's just no good way to troubleshoot.
I don't have any Arlo products so I have no way to test.
Let me ask some dumb questions so I can see what it is you're trying to accomplish...
You have 5 Arlo Cams on St using some usable, functioning ST driver. Clicking within the ST app does everything you want.
true or false?
You've added them to HubConnect on ST and the virtual HubConnect devices themselves are created and display in Device list and they correctly use the HubConnect Arlo Driver automatically.
true or false?
The HubConnect Arlo driver supports the following Capabilities:
I imagine those answers will lead to more questions, so I'll wait for those. 
Your assumptions are correct, and the device (arlo control) works just fine on both sides of the house, (ST and HE.) I really only NEED the switch functionality, to turn the cameras on and off based on presence, but it's an added bonus if I can get some of the other metrics.
The issue I am having is that if I enable this HC integration, I experience slow-downs within 12-18 hours, and typically my hub is totally crashed by the time I wake up each morning. Other than the slow-downs and inevitable crashes, the functionality is spot-on. It's as though this causes some sort of memory leak.
Disable this automation, and bam, no problems. Support has combed through the best they can, it seems, and they pinpointed my problems to be this app/driver combo, and Chromecast Beta TTS. Either of those enabled causes things to go sideways in roughly the same amount of time. It feels slightly sooner when I have them both on.
I managed to get everything working again by doing a sift reset and loading an older backup.
When I updated to the latest version of the app to my server and remote I imported the code, cannot remember in which order, then opened the app and clicked done to update. Again I can't remember what order.
Is there a preferred way/order to update.
Could this have caused my issues?
Just wondering before I try again.
Thanks.
Because I'm writing, rewriting and tweeking code, I haven't found an order that is wrong. That said, I usually install the 'candidate release' in order.. Server, Server Instance, Remote Hub all on the Server Hub. Then I hit all my Remote Hubs with Remote Client. Finally, I go into Server and it has the "Press Done to complete" and I do that. But that's mostly about making sure I get all the pieces and reducing the number of copy-import-url I do.. Above, where I said I reimported everything, and it worked, I did it in that order.
As @aaiyar mentioned, there's an on/off button inside the virtual hub devices. That's been useful once or twice. Inside each Remote Client, there's an option to Disconnect. You have to copy the key again to restore functionality, but I do those as one of the many tests during Candidate Release testing. Haven't found any harm in either option.
Maybe your Design is different from mine that you've uncovered a bug. I'm certain that there's a historical reason I have a rather strict core-spoke Design: The first ever copies of HubConnect I tried were installed in parallel to the working HubLink/Link to Hub installation. The split of devices was already done by the time I tried HubConnect.
Thanks for the prompt reply.
I'll try again later and follow your order and see what happens. 
It could have been how I updated the code. Who knows. 
What I can say though is this code has let me use both my hubs in parallel which has been brilliant.
Thanks again.
EDIT: Just updated following the order you have suggested and again everything has stopped working.
Not sure what to say. No errors in logs.
2 hubs, correct?
What Design are you using?? What connectivity are you using (http oAuth or Event Socket)?
For Event Socket, on the Hub with the real device, you shouldn't see any HubConnect logs. You should see device/driver logs. The Hub receiving, by listening to the Event Socket, will log:
app:32019-10-24 07:53:46.527 am info Received event from ZeeRadioUpper/MultiSensor6A (officeDesk): [acceleration, inactive null] app:32019-10-24 07:53:46.500 am info Received event from ZeeRadioUpper/MultiSensor6A (officeDesk): [tamper, clear null] app:32019-10-24 07:53:46.478 am info Received event from ZeeRadioUpper/MultiSensor6A (officeDesk): [motion, inactive null] app:32019-10-24 07:53:46.074 am info Received event from ZeeRadioUpper/MultiSensor6A (officeDesk): [motion, inactive null]
"Received event" and the App# are how you can tell. If they are not occuring, I'd go into the device list and find the Hub device and turn it off, then on.
The details of what it's doing, are there too:
You're not alone, I'm seeing the same issue. I had to restored both of my databases to get everything working again.
I have Arlo cameras as well on ST. I exposed them to HE as a simple switch. The on/off capability is a basic switch in ST. I only use this to turn them on and off based on presence and haven't had any issues. I have not tried to integrate them with HE through HubConnect with an Arlo Camera Driver.
I'm really struggling trying to create a custom driver. I spend the last hour reading every reference to custom driver in this thread, but no joy.
Here's what I did: I built the custom driver definition (list of capability attributes) on the receiving hub. Then went to the sending hub, and selected the physical device (an EZMultipli) without a problem. Then when I saved out of the app, the virtual device never showed up on the receiving hub (I have many other non-custom devices that work fine, thank you very much!) and the following error showed up in the receiving hub's log:
Uunable to create device Princess Hallway Motion: com.hubitat.app.exception.UnknownDeviceTypeException: Device type 'EZMultiPli' in namespace 'shackrat' not found.
Any ideas? What is an "attribute class name"? Below is the custom driver definition:
You are missing the driver "EZMultiPii.groovy" from your 'receiving' hub. I suspect you didn't detect that you have to write a stub driver for it. You take a 'close to' universal driver and modify it to be what you need.
However, in the case you display, there's no need for a custom driver, I think. The Dome Motion driver supports both Illuminance and temperature. Option Harder: Grab a copy, change the name, inside and out, put it in your receiving hub. Option Easier: change your Custom to use "Dome Motion Sensor" ... install it if not already on your Hub Either gets you to the same place, I believe.
Your EZMultiPii is not selectable with the standard choices. Custom cures that problem, and repurposing an existing driver saves you time. The Dome Driver has Battery and Motion attributes BUT no events will arrive for those attributes.
I'm trying to sync a Virtual Button from a Hubitat device to a Smartthings device. I'm unable to find the HubConnect Button DeviceType for Smartthings. The Universal one doesn't seem to work.
This might be a dumb question but I only have a Hubitat Hub and SmartThings is running in the cloud (no ST hub) can I still use HubConnect? I am assuming I would need to install both the server and client (since I only have one Hubitat hub)?
I plan to share my Honeywell Lyric Thermostat with Hubitat
I'm having sync issues with this most recent update also. The devices I'm having trouble with all seem to be shared from my server hub back to my remote hubs - both sensors and switches. I can manually sync it by hitting the sync button in the web interface on the remote hubs and then it will update, but it isn't updating automatically.
my devices that go from my remote hubs to my server hub seem to updating normally. its the ones that go the other way from the server to the remote hubs that I'm having trouble with.
prior to this minor release update it was working fine.
Ok, that's 3 reports of trouble with this release. I'll retract the update and see if I can find the issue. Sorry for the trouble. 
Ah, you filled in my blind spot, thanks. I dumbly understood that "stub driver" equaled fill-out-custom-driver page in the app. Get it now.
Not sure I can use the dome motion driver because EZMultiPli uses motion, temperature, RGBW bulb, and switch. I need at least the first three, which I think takes me to Option Harder.
I've not ever written DH's. Does change the name mean just go into the driver code and replace exiting driver name with custom driver name? Would the code itself also need to change to reflect the different device capabilities? Perhaps I'm overthinking this....
Not exactly but very close.. you don't want to "destroy" your Dome driver in case you ever get one.. so yes, go look at that driver on the repository, click raw, copy everything, then paste it into your favorite text editor.
Now change the name inside the metadata, after "definition" and save a copy under a new name too. Then copy that into the Driver's Code area as a new driver. All of this does not add your 3rd attribute, but you can test 2 of them to understand the process.. plus then you only have to worry about one change at a time. 
Do you know what would cause sync to not work with the Custom Drivers? I created a custom stub driver for my Xiaomi Temp/Humidity Sensors but cannot get the Sync to work to sync the attributes to the Coordinator hub. The attributes does seem to actually update though when the attributes update on these devices, but not sure why Sync option doesn't do anything. The device itself doesn't support Refresh but when I created the Stub driver and added the device to the Server Instance/Remote Client on App Code the Sync option works fine so it appears to be something odd with the Custom Drivers.
I was planning on creating a few more drivers and was looking to get this to work so it fully functions like a normal stub driver.
Is the sync option supposed to work on Custom Drivers?
Logs:
[app:2442] (http://10.100.11.110/logs/past#app2442)2019-10-27 10:09:04.388 pm [warn] (http://10.100.11.110/installedapp/configure/2442)The device [Main Bathroom Temp Sensor] does not support the command refresh.
[app:2442] (http://10.100.11.110/logs/past#app2442)2019-10-27 10:09:04.326 pm [info] (http://10.100.11.110/installedapp/configure/2442)Received command from server: ["Main Bathroom Temp Sensor": refresh]
[app:2442] (http://10.100.11.110/logs/past#app2442)2019-10-27 10:09:04.088 pm [warn] (http://10.100.11.110/installedapp/configure/2442)The device [Family Room Temp Sensor] does not support the command refresh.
[app:2442] (http://10.100.11.110/logs/past#app2442)2019-10-27 10:09:04.086 pm [info] (http://10.100.11.110/installedapp/configure/2442)Received command from server: ["Family Room Temp Sensor": refresh]
Stub Driver:
/*
- Copyright 2019 Steve White
- Licensed under the Apache License, Version 2.0 (the "License"); you may not
- use this file except in compliance with the License. You may obtain a copy
- of the License at:
http://www.apache.org/licenses/LICENSE-2.0- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
- WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
- License for the specific language governing permissions and limitations
- under the License.
*/
metadata
{
definition(name: "HubConnect Xiaomi Temp Humidity Sensor", namespace: "shackrat", author: "Steve White", importUrl: "https://raw.githubusercontent.com/HubitatCommunity/HubConnect/master/UniversalDrivers/HubConnect-TempHumidSensor.groovy")
{
capability "Battery"
capability "RelativeHumidityMeasurement"
capability "Sensor"
capability "PressureMeasurement"
capability "Temperature Measurement"attribute "version", "string" command "sync"}
}/*
installedDoesn't do much other than call initialize().
*/
def installed()
{
initialize()
}/*
updatedDoesn't do much other than call initialize().
*/
def updated()
{
initialize()
}/*
initializeDoesn't do much other than call refresh().
*/
def initialize()
{
refresh()
}/*
parseIn a virtual world this should never be called.
*/
def parse(String description)
{
log.trace "Msg: Description is $description"
}/*
refreshRefreshes the device by requesting an update from the client hub.
*/
def refresh()
{
// The server will update status
parent.sendDeviceEvent(device.deviceNetworkId, "refresh")
}/*
syncSynchronizes the device details with the parent.
*/
def sync()
{
// The server will respond with updated status and details
parent.syncDevice(device.deviceNetworkId, "temperature")
sendEvent([name: "version", value: "v${driverVersion.major}.${driverVersion.minor}.${driverVersion.build}"])
}
def getDriverVersion() {[platform: "Universal", major: 1, minor: 1, build: 1]}
Custom Driver:
I'm actually on the 10/23 release still, not sure if you want me to test on the updates from today.
I reverted back a couple of changes that occurred in just a few hours. One was to do with Custom Drivers that @storageanarchy suggested. Mixed in were some other changes I had been testing for quite a few days. All of them have been reverted to try and get back onto stable ground. I plan on rebuilding them back into the main flow and releasing them in more bite sized (not interlaced) versions.
The Custom Driver changes are very straightforward and only affect Custom, so I'm going to get that merged back in as quickly as I can.
Download the Hubitat app
