Yes, the difference is in the downloaded file vs the import link below it. If you import using the link below thermostat, it pulls in the old version. Download the file, open in notepad++, copy/paste and I'm good to go.
I also noticed as I tried to add a device from my remote hub to my server hub that it would not create itself on the server hub. I'll have to see if the steps below will end up fixing that...
There was a "Warning" message on my server hub, so I did a connection check.
As for the switch that wouldn't work properly - No change, so I then disconnected the hubs, found that the device was no longer in the list of shared devices, added it again...
I can now see the switch but the behavior is reversed... I can control the switch but can no longer see its status... I have to manually select "Refresh" and then "Sync" to see the updated status... Fun times! 
Maybe it's time to reboot my hubs...
So the reboot fixed my problematic device. That's good! 
The new problem where two devices from my remote hub won't sync to my server hub remains. I tried removing them and then adding them again to the list of shared devices, to no avail. I did confirm that I had the proper driver setup (they use the same driver as other devices that do work).
I also did a refresh on the Server, and it refreshed 17 devices, but I have 18 that are shared with the two new ones... I removed them and still, even though I now have 16 devices shared, it shows 17... Here is a screen shot from when I had the 18 setup. It seems that something is not connecting properly... Suggestions?
Update: I removed a couple of other devices, went through the "next" & "done" cycle, added them again and the two new devices are now in my list, but the ones I had removed and added again are no longer there... Could there be a limit to the number of devices that get transferred?
Steve has 500+ devices and therefore I'd say there's no 'natural' limit. There must be some point where the transfer of data interferes with some other process.. just don't know where that would be.
Run a Version report and verify you have v2.0 everything.
Unortunately thats not possible. It sounds like the hub might be caching the URL or something. But it truly is impossible as there is only one version of the file uploaded to the server.. The download link and the secure import URL both alias the same file. I know, I wrote the server-side code for it. 
If devices are disappearing it means they're not selected on the remote hub. By default, v2 cleans up by removing unselected unless you specifically tell it not to.
Also, as @csteele said, make sure everything across all hubs has been upgraded. In v2, every single file has been updated.
I know based on previous discussions that I have older drivers, so I'll update to the latest. What is the best way to tell that I have the latest version? Is there a version number for the driver somewhere in the code?
Just a sidebar on the version report.. It will show the correctly installed apps and drivers, however until v2 goes live in GA in a few days, the report will show the 1.x branch as the "latest" available.
2 Likes
This is a great report! Thanks!
I have updated all my drivers to version 2, but the problem persists. Two power monitoring devices are still not showing up on my server hub. I can confirm that the devices are selected on the remote hub and that as per my previous screen shots, the numbers of shared devices does not match with the number shown during a refresh.
I have also tried disconnecting and reconnecting the hubs. Any other recommendations? Am I the only one with this issue?
1 Like
Hi,
I installed HubConnect on my Hubitat and ST and everything is working pretty well.
The only small problem I have is in ST, when I try to add my Ring Doorbell in the HubConnect Remote Client under Smartthings Device ofr Ring Doorbell I get "You can't currently add this".
I tried to find something in the messages here, but didn't.
Any idea?
Thank you
Noticed today that mode changes were not being sent to Smartthings with v2. Found this post a few days up, but the smartthings remote server does not have an option to receive event types, only to send.
As mentioned above... the interface has multiple changes to support the new features.. and especially for the NodeJS Server's impact on options.
The connectivity you choose between hubs (Event Socket, Http) alters the interface options to match.
SmartThings <--> Hubitat connectivity will always be http, because that's the Cloud that Samsung chooses. The interface for HubConnect Server Instance changes for SmartThings:
It retains the 'old' mechanism for distributing Mode and HSM.
@csteele
That's exactly how my settings are. A mode change in HE is not changing the mode in ST since upgrading to v2.
I've got it set to circular, infinite loop.. and still it gets through...
1385ee09-ba3e-416c-afec-ccc97964fb08 4:23:09 PM: debug sendGetCommand(): Sending http://192.168.7.64/apps/api/582/modes/set/Away 6f9fef94-4840-43f5-b90c-4a5c8c38d9b2 4:23:09 PM: debug Sending mode change event to server: Away 6f9fef94-4840-43f5-b90c-4a5c8c38d9b2 4:23:08 PM: debug Received mode event from server: Away 6f9fef94-4840-43f5-b90c-4a5c8c38d9b2 4:22:40 PM: debug Received mode event from server: Day
I then disabled the Loop on the ST Client side and:
6f9fef94-4840-43f5-b90c-4a5c8c38d9b2 4:25:14 PM: debug Received mode event from server: Day 6f9fef94-4840-43f5-b90c-4a5c8c38d9b2 4:24:52 PM: info Subscribing to events.. 6f9fef94-4840-43f5-b90c-4a5c8c38d9b2 4:24:52 PM: info HubConnect Remote Client Initialized
In both cases, the ST (classic) App shows the correct mode.
Just ran live logging on ST while sending a mode change, here's the error I'm getting
749183b2-d011-4fab-ae6a-aab3c751509f 8:30:52 PM: error java.lang.NullPointerException: Cannot invoke method sendEvent() on null object @line 373 (remoteModeChange)
What do your logs say? Are you seeing the debug line above?
I enabled debug output and yes I'm getting the debug line above.
[749183b2-d011-4fab-ae6a-aab3c751509f] 9:29:56 PM: error java.lang.NullPointerException: Cannot invoke method sendEvent() on null object @line 373 (remoteModeChange)
[749183b2-d011-4fab-ae6a-aab3c751509f]9:29:56 PM: debug Received mode event from server: Home - Evening
I'm getting this error a lot in my log - about 12 times every hour. Is there something that I am not doing that I should?
errorHome (Client) is offline.
I also often see in the Apps screen "Home (Client) Offline", but my linked devices still work...?
This is most likely not related, but on the server side, I did notice the following tonight:
app:962 2020-04-03 21:22:44.974 error java.lang.NumberFormatException: null on line 577 (systemRemoteUpdate)
app:962 2020-04-03 21:22:43.503 info HubConnect Remote Client Initialized
app:962 2020-04-03 21:22:43.478 info HubConnect Remote Client Updated
app:962 2020-04-03 21:21:34.884 error Received mode event from null: null does not exist!
I gotta ask. Why didn't you put 2.0 on github where it would be easy to import into the hubitat hub and even easier in smartthings? Why is it on some confusing website behind a login for no apparent reason other than to make it more difficult to get?
-
To better safeguard the License.
-
The site's links are Importable into Hubitat, just pretend 'github' is spelled differently.
-
HubConnect support is via a ticketing system, which is the primary purpose of the specific choice of the site software. 3000 posts to a thread is great for me, I've read them all, there's only a few a day to keep up. But new users are certainly going to be daunted. The early stuff is mostly obsolete. HubConnect.to has Knowledgebase that will be easier to 'cleanse'.
You'll find that conversations here in the Community will follow a similar pattern to Hubitat's own... many answers to questions by Community members to give varied viewpoints, but problems get an extra line of advice.. "Did you enter a Ticket with Support?"
