The request is still valid for Hubitat—>SmartThings and Hubitat—>HomeBridge.
And yes, I have noticed that Hubconnect between two Hubitats delivers more than just the base set of features. For example, both my Ecobee Suite Thermostat and my MeteoBridge Weather Station update more than 30-50 attributes, and ALL of them will be replicated between two Hubitats, regardless of what device type I select them in.
This is less than optimal, especially because HubConnect will apparently override the HTTP connection and switch to web socket if both ends are Hubitat.
You can replace spaces with %20 in a URL, but for these Modes in Hubitat it is not a good idea. I keep my modes all to a single word (Morning, Night, Away, etc.)
Just bringing this back up again...assuming someone else here is using the Google app with hub connect. All of my RGB bulbs that are using the hubconnect stub won't sync with Google through the built in app anymore. Can anyone else confirm this?
org.h2.jdbc.JdbcSQLException: Column "name" not found [42122-197] on line 109 (setLevel)
That came from the HubConnect dimmer driver. Was working on something else looking at the logs and saw that pop up. It was being triggered by a Motion Lighting rule.
FYI - I started getting a new error from SmartThings HubConnect, possibly since the recent SmartThings software update:
12:09:28 PM: error org.springframework.jdbc.UncategorizedSQLException: Hibernate operation: could not execute query; uncategorized SQLException for SQL [select this_.id as id108_0_, this_.version as version108_0_, this_.date_created as date3_108_0_, this_.`key` as key4_108_0_, this_.type as type108_0_, this_.value as value108_0_ from server_config this_ where this_.`key`=?]; SQL state [null]; error code [0]; [SimpleAsyncTaskExecutor-3] Timeout: Pool empty. Unable to fetch a connection in 30 seconds, none available[size:50; busy:0; idle:0; lastwait:30000].; nested exception is org.apache.tomcat.jdbc.pool.PoolExhaustedException: [SimpleAsyncTaskExecutor-3] Timeout: Pool empty. Unable to fetch a connection in 30 seconds, none available[size:50; busy:0; idle:0; lastwait:30000]. @line 742 (sendGetCommand)
Also, would you mind adding the ability to specify the name (label) for the HubConnect Remote Client app? I'm using 1 SmartThings and 3 Hubitat hubs in my home, and thus several of the hubs are remote clients to more than one HubConnect Server - I'd like to name the instances to indicate which hub it is the slave to...
I think I have a similar number and type of system. 1 SmartThings and 4 Hubitat. I have Server on one Hubitat Hub and one Remote Client per each remaining hub. There's no significant coding difference between "Server Instance" and "Remote Client." Both implement a bidirectional ability.
I actually have the same circumstance as the original poster: my "main" setup has one "coordinator" hub with two remote hubs (a ZHA Hubitat hub plus ST), but I also have a third hub that does Zigbee bubls only, and I didn't want to route that one through my "coordinator" hub since that's the one where I relegate Z-Wave, risky code, and anything I'm not quite sure about--and my lights can't be one of those. I wanted them to go directly to the ZHA hub. Thus, my ZHA hub is both a remote client for my "coordinator" hub but also a remote client for my ZLL hub, which runs the server (I could do this the other way around but didn't see a reason to prefer one way or the other).
Adding a "label" field to the app would help distinguish the remote clients since they otherwise show up with the same name--it's the same thing the Server Instance app allows so you can distinguish (except those are child apps and this isn't, but same idea and field--just a label input).
Obviously a fringe case, but just thought I'd throw my use case out there since I'm apparently not the only one.
Is Steve (@srwhite) ever coming back / planning to update things? Or is this a dead product? We can't update it on the community side due to the licensing restrictions on the apps, so I think this is a reasonable question.
For the record I'm not trying to complain about the licensing model, or start a licensing discussion/argument of any kind. Just asking about the future of the apps - nothing more.
it's the stub driver's fault that hubitat doesn't expose that.
I mean I know about naming an App but the need escapes me. It seems tied to:
Before he left for the 'season', he mentioned an idea or two about v1.5 -- so yes, he had a plan 
