The type of driver used by HubConnect can't be replaced by a 'real' driver.
HubConnect drivers for SmartThings are, as you noted, Universal. A series of Universal drivers got updated to include the Tiles section that Hubitat ignores and more are on their way. Soon, I heard.
The Universal drivers will allow you to programmatically detect button pushes on ST, just not "see" them in ST's App.
Not sure if that's what you're asking, but that's what I interpreted.
In post #434 above, it is stated that v1.2 included button translation from ST to Hubitat but "[there] is currently no translation to connect physical buttons in Hubitat to SmartThings." I know 1.3 has been released since, but I don't see any changes in this regard. Srwhite or csteele can correct me if I'm wrong.
I'm assuming you get this error when trying to install the HubConnect-Button.groovy driver in ST, which makes sense to me since ST does not have all the button capabilities that Hubitat does, and it's not clear how they would "translate" Hubitat buttons to ST given the complications (e.g., ST doesn't have DoubleTapableButton [sic.] and there isn't a good way in to differentiate "button 1 pushed" from "button 1 double-tapped" in SmartThings, where many people work around issues like this by mapping these actions to other button numbers entirely...numbers which may already exist in the Hubitat device, further complicating the matter). The other way around is much easier since ST only support press and (possibly deprecated?) hold events, both of which can be easily mapped to Hubitat's capabilities with some "translation" of their slightly differing event-creation methods.
To work around this, someone would need to think of a way to translate Hubitat buttons to ST. Maybe report double the number of buttons if it supports double taps, then map a double tap to a press of button number numberOfButtons + 1 on the SmartThings side? (I think "held" can still translate as-is, since it's an allowed event on the Button capability, and they used to have HoldableButton too but I'm not sure if that still works.) Either way, that will take some work.
To get this to work with what we currently have: could you create virtual devices? Maybe a virtual switch on Hubitat that turns on (and automatically turns off shortly thereafter--you can configure that in the virtual switch device/edit page) whever the Hubitat button event is fired? You can make that happen with Rule Machine or Button Controller. Then, share that Virtual Switch instead of the Button. That should work with existing drivers. Kind of a pain if you have a lot of buttons to share, and maybe there's an easier way, but it's just something that seems like it should work with the existing functionality.
1.3 does have button support for physical buttons located in SmartThings, but there's currently no support for sending button events from Hubitat to SmartThings due to the difference in implementation between platforms. I'll happen, but it won't make 1.4.
I am happy the report that in large part HubConnect allowed me a reasonable pathway to Hubitat.
Over several days I ported all my devices from SmartThings. The two way communication between the hubs allowed my to keep automatons going with little problem.
As it was noted, there is no HC button driver that works on ST. - Would be nice to have
The other snags are the "Missing Tiles" on SmartThings for several devices;
Aeon Appliance Outlet
SmartThings outlets (square cube)
Evolve Outlets and Dimmers
Devices can be controlled on/off but that's about all.
Otherwise performance is excellent, almost instant.
Hi. If you are already setup and then add additional devices to a client hub. How do you get the additional devices on the client to sync back to the master server hub? Thanks
Bi-Directional Hubitat Safety Monitor Support. It is now possible to set an HSM state on one hub and have that state set on another hub. This feature is configurable on a per-hub basis. HSM does NOT need to be installed on the Server hub to use this feature.
Bi-Directional Smart Home Monitor Support. Integration between Hubitat Safety Monitor (HSM) and SmartThings Smart Home Monitor (SHM) is supported. Since SHM and HSM alarm states are not the same, it this feature includes the ability to map SHM states to HSM states in the SmartThings app.
System Version Report Enhancements. The System Version Report now displays the latest available module versions alongside of the currently installed version for each hub and driver.
Upgraded Code Detection & Improvements. Making sure that the proper sequence of events is executing following an upgrade is one of the big challenges to the upgrade process. Starting with HubConnect 1.4, users will be prompted if the installed code is newer than the configured version and prompt the user to press "Done" to complete the upgrade. Pressing "Done" on the main server app will also send a command to all remote hubs to perform the equivalent of clicking "Done" on each remote.
Performance improvements to event handling (device lookup) for both Event Socket & HTTP communication methods.
Bug fixes to SmartThings RGB DeviceType.
User-defined driver types now support up to 18 attributes.
New/Updated Drivers:
Fan Controller (Hubitat & SmartThings)
Dome-Aeon Smart Plug (SmartThings)
Dome-Aeon Motion Sensor (SmartThings)
Garage Door (SmartThings)
Omnipurpose Sensor (SmartThings)
Power Meter (SmartThings)
To upgrade, please re-import all apps (Hubitat and SmartThings), as well as the HubConnect Remote Hub driver for Hubitat. After re-importing all code modules, please go to the Server app and when prompted, click "Done" to upgrade all hubs in your HubConnect system. Once complete, proceed to re-import any updated drivers.
So my Nest thermostat on my client hub shows up as a thermostat but on the server it's a "Hubconnect omnipurpose device" so when I go to share it with homebridge it won't share as a thermostat. If I change it on the server to a "Hubconnect thermostat" it will share with homebridge as a thermostat but in the "Home" app it shows "no response".