@csteele Thanks. I've sucessfully upgraded to 2.0
I have an issue with modes.
Server Hub
Remote Hub
I'm not sure why the server hub is receiving mode changes. In fact, there is nothing on the remote hub that would change the mode (except HubConnect).
On the server hub, I cant seem to find where to select "send mode changes to remote". I can find receive mode changes from client (again on server hub).
If you are using EventSocket then mode is included.. no special need to enable it. It's the receive that needs to be selected: yea or nay ... track what comes in or ignore.
The "error" is simply saying it's ignoring. I think "Error" is a bit over the top. It's more in the "Info" realm to me.
Thanks @csteele. Makes sense.
A quick update on the issue I had identified. It seems that there was a connection issue between the hubs. I noticed today that some other devices were not communicated. Oddly enough, the commands were going through but didn't seem to be recognized... Though that is just a guess... (Toggeling a switch on a dashboard of the hub with the virtual device would send a signal to the one with the connected device, but the light would not turn off.)
I ended up going to the Hub Connect app, in the hub's Connect menu chose "connect to remote hub", and "Send connection key and automatically configure the remote hub?". After I pressed "Done" until I was out, everything started working again, including the reporting of status of my devices.
So in conclusion, everything seems to be working now! Yay! 
IF the migration technique that Bruce describes works for "real devices" then it should work for virtuals too. BUT, I don't know, never tried it.
I've moved many a device over the years, including Locks and GDO in the last month. I used the older technique of a 'placeholder virtual' that gets swapped into all the Rules, across all the Hubs. Then swapped back when the device is available again.
Want to give it a try and let us all know how it works? 
An issue I think for hub migration is going to be devices that use webURLs regularly.
They won't be 'moved' during backup / restore - ie the rest endpoints will change due to the HUBUID changing.
It is going to be important for folks to understand easily how to correct this, or do they need to re-setup an app like hub connect, homebridge, etc. This will be another pain point if you have to start over with these apps.
I will let everyone know how that approach works.
If it works that way, the migration will be easy peasy.... (I hope).
I think that the real key benefit of HubConnect is that it allows (without too much penalty), for the real devices to be on one hub, and the automations on another. From the tremendous amount of interest in Node-Red, that approach is being used more and more. As others have said "Hubitat is a good device manager". Since my Home Automation needs are relatively modest, I hope that I can also say "Hubitat is a good Home Automater".
It's saying both of those things, at the same time (on the same hub), that's the issue!
HubConnect has a feature aimed at this:
thx, this deals with both IP address and HUBUID changing? it is not clear to me that is what it does.
Any idea what is causing this?
java.lang.NullPointerException: Cannot invoke method getAt() on null object on line 815 (listDevices)
I would like to have a rule run when the Hub connects. Is there something that could be selected as a trigger when it occurs?
There must be an attribute from the Hub Connect device that changes...?
The available attributes that I have access to are:
Would anyone know if one would work? And what would be value I should be looking for?
EDIT: I did some testing and found that when a re-connect is initiated (Ex.: By toggling "Send connection key and automatically configure the remote hub?" from the "Connect to Remote Hub..." screen on the server hub) the "switch" attribute will toggle off and on.
Tried it and confirmed that it does trigger my rule.
Edit 2: I just noticed that on the server hub, the "switch" is set to "off" in the HubConnect Remote Hub device that points to my other hub. Is that normal? Shouldn't it be set to "On"? Does anyone know what would cause it to be set to "Off?
Is there no syncing of illuminance with hub connect? I’ve noticed the motion sensors don’t have a Illuminance level.
You also have the option to create a custom driver. If you are using version 2.0 it is really to create within the app.
I couldn’t figure out what URL to use for 2.0 after I created the account. It looked like it had to be downloaded.
Have you looked at the Upgrade Instructions?
v2.0 Upgrade Installation is part of the RC1 announcement:
https://hubconnect.to/announcements/3/HubConnect-2.0-Release-Candidate-1-Released.html
A more detailed upgrade, from v1.6 to v2.0 RC1 is found:
https://hubconnect.to/knowledgebase/24/HubConnect-1.5x-1.6x-to-2.0-Upgrade-Instructions.html
@edge created a summary of a set of 'clean install' steps a few posts above:
@csteele What am I missing here???? Your links are not about a clean install of v2.0. Not everyone has v1.6 installed.
Agreed. None of the HubConnect.to site links are for a 'clean install.' The only 'clean' one is from you, Edge, above.
We're in a 'trough' between fully released and supported v1.6 and public beta v2.0 RC1 with minimal documentation.
I don't have WRITE access to HubConnect.to to put a version out there. Steve ran out of time prior to his 'start-of-camping-season' in April. I assume everyone knows that once RC1 was released, we started creating RC2. We decided that RC2 was good enough to release.. but he wasn't able to do all the work in the limited time. We'll see what he's dreamed up when he gets back. I'm hoping he'll spend time on releasing it, which INCLUDES removing the v1.6 github code (and then updating that with JUST the v2.0 drivers.)
In other words, Public Beta v2.0 Release Candidate 1 (RC1) is what we have.
I have spent an hour on converting Upgrade Instructions into Installation Instructions and put them:
HubConnect v2.0 RC1 Installation Instructions
It's quite possible I should have spent MORE time on the conversion, but it's all the time I had tonight.
Use the HubConnect DomeMotion Sensor driver. It has illuminance, temp, motion, and battery. I'm using it with a Hue outdoor motion sensor and it works without issue.
@csteele any idea what this error means? It's in the logs of a client hubitat hub, from the server hub device.
Not sure if it has something to do with these devices I just added (log from the client hub's server app instance):
Thanks for any insight.
Edit: should probably have mentioned I'm still using v 1.6 of HubConnect.
Download the Hubitat app
