No, I don’t (just HE). The error is generated for each HE hub.
Are there any logs or anything that I can provide to help track down the issue?
I have a number of devices I've mis-categorized as switches when they should be dimmers, and other similar issues. Is it okay to simply swap drivers on the server-side without going back to the remote hubs and changing them in the app?
Will you remember you did that next year? 
Try reselecting correctly. When you "Done" out, the full list will be sent again and I presume they will all get skipped (not rebuilt). Then you can swap HubConnect driver X for HubConnect driver Y and it should work.
I remember testing driver swapping a very long time ago.. from the pre-EventSocket days. I'm dredging up some pretty antique memories.. accuracy is a question 
1 Like
Thanks for replying. Yes I have 2 remote hubs, ST & a C5, updated drivers on all and driver report shows latest version of everything. Updated all drivers/apps and rebooted after applying all updates
There's a thread on the Heiman Zigbee Gas Detector here.. or were you referring to using them via HubConnect ??
Yes specifically with HubConnect, as it's an entirely new attribute and now supported by Hubitat.
1 Like
I am also seeing this same error:
[app:1959](http://192.168.1.77/logs#app1959)2019-12-29 09:01:12.844 am [error](http://192.168.1.77/installedapp/configure/1959)groovy.lang.MissingMethodException: No signature of method: user_app_shackrat_HubConnect_Server_Instance_66.getSelectedDeviceIds() is applicable for argument types: () values: [] on line 191 (getSelectedDeviceIds)
1 Like
HubConnect 1.6.4 has been released!
I have been having issues with git hub messing up my local repos on my home laptop when switching branches which has caused a some code to randomly disappear at times.. Hopefully I've got that issue fixed.
I'm also giving a sneak peak at a new feature that's going to be part of HubConnect 2; DeviceMatch. DeviceMatch is a concept where a user can select devices based on a physcial driver, a HubConnect driver, or a primary attribute.
- Physical Driver: Select devices based on the actual driver assigned to the physical device.
- HubConnect Driver: Select devices based on the name of the synthetic HubConnect driver. This is useful for selecting virtual HubConnect devices on the server to another remote hub. (i.e. Remote A -> Server -> Remote B)
- Primary Attribute: Selecting based on the main device attribute.. (The way devices are selected now)
What's New?
-
Support to Netatmo Weather Stations
-
Sneak preview of HubConnect 2.0 DeviceMatch feature for Netatmo weather stations.
What's Changed?
No other changes.
What's Fixed?
Hubitat: Fixed error missing method "getSelectedDeviceIds()" due to bad git commit.
SmartThings: Fixed potential error when saving devices to server.
New Drivers (Hubitat):
-
Netatmo Basestation - A virtual driver for the Netatmo weather base station.
-
Netatmo Additional Module - A virtual driver for additional Netatmo indoor sensors.
-
Netatmo Outdoor Module - A virtual driver for the Netatmo outdoor sensor.
-
Netatmo Rain - A virtual driver for the Netatmo outdoor rain gauge.
-
Netatmo Wind - A virtual driver for the Netatmo outdoor wind gauge.
New Drivers (SmartThings):
-
Netatmo Basestation - A virtual driver for the Netatmo weather base station.
-
Netatmo Additional Module - A virtual driver for additional Netatmo indoor sensors.
-
Netatmo Outdoor Module - A virtual driver for the Netatmo outdoor sensor.
-
Netatmo Rain - A virtual driver for the Netatmo outdoor rain gauge.
-
Netatmo Wind - A virtual driver for the Netatmo outdoor wind gauge.
Note: With this release, the HubConnect server code did not change, so that version remains at 1.6.3
Simply import the code for all files and save. There is no need to visit each app and click Done with this release.
Files Changed: Server Instance, Remote Client (ST & HE)
2 Likes
Upgrade to 1.6.4 went fine for me.
One comment on the device report... It would be cool if it listed the devices based on Device Label, not Device Name...
Otherwise for some compound/parent-child devices you get this, which isn't as useful:
2 Likes
Glad the upgrade went well.
Using label when available is coming in the next release as is support for running the report on hubs that have security enabled.
And of course normalizing the color codes (i.e un-decorating the Christmas theme).
1 Like
I have not upgraded to the 1.6.4 version. Would this give me the Christmas effect?? So far it only reports Red, not Red and Green.
And thank you for an incredable add on to Hubitat.
Yes, this one fixes cases where the remote devices do not show in the report. You’ll get both Christmas colors. For now. 
1 Like
Its starting to look a lot like Christmas! Wow that feature helps a lot.
Thank You, and Happy New Year!
1 Like
FWIW: on SmartThings, displayName is generally provided for all devices (and device-related events), where:
device.displayName = device.label ?: device.nameHi @srwhite ,
I just installed HubConnect and I'm struggling with a few things.
First, I don't know why but the app running on Smartthings Classic won't let me add my Ring Doorbell to the list of devices to synchronize. Also, I have Arlo devices shown 3 times in the app (but only one will go to Hubitat as it should) Check out the image attached.
Another thing is I cannot share the devices from Hubitat to Smartthings, just ST -> Hubitat. It tells I don't have anything to share. What am I missing?
Thanks a lot for your work on this app. Always wanted to have my Arlo cameras and Ring doorbell integrated to Hubitat.
New Server Container still says 1.6.3?
Yup:
1 Like
Got it! I was in fact prompted to hit "Done" in the apps, whether required or not.
Thanks, Christmas looking good here, even though I only have 1 outgoing device on my server.
The prompt will still pop up the next time you open an instance or remote after the update. It's just a formality since there's nothing in the 1.6.4 update that needs to be reinitialized.
