OK - in Hubitat Server Instance, and Hubitat Remote Client on both platforms, you need to fix the same reference in the getDevice(params) function so that it uses the ${groupname} instead of the ${device.selector}.
OK, the above fixes appear sufficient to make Custom Devices fully functional, supporting all the defined Events (from the source Capabilities) and Commands in the supplied Custom Device Driver. I have successfully (
) linked devices from Hubitat Remote Clients to a (centralized) Hubitat Server, and then linked them from the Hubitat Server to a SmartThings-based Remote Client.
A couple of things I learned:
-
You do in fact have to install a version of the Custom Device Driver on any SmartThings Remote Client, or it can't create the client device. (Probably need on HE Remote clients, too - see below)
-
Said SmartThings device probably should include tile definitions, with all the tiles/commands that you want exposed. Most importantly, you will want a
syncand aversiontile, so you can verify that the ST device is in fact connected to the Server -
If you are only forwarding devices from ST or HE Remote Clients to a centralized server, you don't need the Custom Device Driver on the Remote Clients.
-
But if you want to send Custom Devices from the Server to the Clients, I'm pretty sure you need the Custom Device Driver on your ST & HE Remote Clients.
Once it is all working, it is pretty cool...
Also, FWIW, I have code modification to Hubitat Server Instance that reflects the userName from Rboy's Lock DTH into the HE lastUsedName. lockCodes is still in a different format, but that's easily fixed.
Using Rboy/SmartThings locks instead of HE's is WAAYYY better 
Yes, the custom driver -- which is why in my test example I used an existing HubConnect driver... to save a) writing what would amount to a duplicate, and b) spreading it around my Hubs.
That's directional of course, but yes, writing a Custom Driver entails all the portions 
The purpose of the driver is largely "local" -- local to the Hub If you want buttons etc, much like you want Tiles on the ST end, then you'd want a more complete stub driver. Effectively Hubitat includes 'tiles' by capability on their side.
yes.. but I don't use it much since, in most cases, the driver I write for some need probably deserves going in the Repo.
(FWIW, I intended this post to help others who might be trying to implement custom drivers in HC).
Yes, it is very nice that Hubitat gives 'tiles' for each command a driver exposes; my comment was that a ST driver needs the two additional tiles to be most useful/similar to the HE experience.
And I needed a custom driver for my EcoNet Vents because:
- Hubitat doesn't supply a standard driver for this device (it's basically a dimmer, with
open/closecommands in addition toon/off), so I use the one I originally created for ST, ported to HE - the implementation was throwing errors on the HubConnect Server if apps on my Client hub (SmartThings) invoked commands not supported by a standard "dimmer" - my driver supports
open, close, configure,andrefresh, while the stock dimmer device doesn't. This is probably a ST thing, because the HE eventSocket approach doesn't seem to suffer from the same problem
I have a Fan (Bedroom Fan) connected to HE using the Bond Hub. Works fine.
I have multiple hubs and as only one hub can use the Amazon Echo Skill I have the Fan replicated using HubConnect to my "Grand Central Station" hub.
HubConnect sees it as a device type of "HubConnect Fan Controller", the Echo Skill ignores this device type. If I change type to "HubConnect FanSpeed Controller" it gets recognised by the Echo Skill and I get a message in the Amazon App saying that "Light Bedroom Fan" was found, however it gets created as a type of "Switch" and selecting my device "Bedroom Fan" in the Amazon App simply displays a screen "Waiting for Hubitat...." and three alternating dots.... forever.
Anyone any ideas what I've done wrong or how I can get this working?
Thanks,
Simon
you can try setting it to be a HubConnect Dimmer and see if Echo likes that better.
Nope - same behaviour when redefined as a Dimmer.
Amazon App gets to other HubConnect devices just fine.
Perhaps unrealistic to expect this feature...
I'm currently using HubConnect with dan.t"s HomeBridge connection. If I have a device that is a native HomeKit device that can't connect to HE (let's pretend a thermostat), would I be able to somehow create a virtual thermostat on the HE side that would pick up the temperatures/settings in HomeKit?
You can 'mirror' a virtual thermostat to Homekit and then potentially use automations in Homekit to transfer the values into the virtual, which will then show up on HE.
wouldn’t that be great.... but it is not as straight forward as you might hope for. Unfortunately, @csteele idea won’t work either as HomeKits automation options are very limited. As of now, there is no clean way of bringing a HomeKit only device back into Hubitat. Sorry
Ahh, that would explain why one of my devices on the second hub has thousands of entries, whilst the actual device only has changes.
Please confirm you are using Connection Type = Hubitat Event Socket.
Just changed it to be "Hubitat Event Socket" and i'm now seeing events on the 2nd hub 
That I am, that's how I've had it setup from the get go.
edit:
On further review looks like most of the time they update but not all the time. But with the simple addition of the isStateChange, they definetly change every time.
(Tested by moving around the house and then running a bunch of Device Watchdog Status reports 
)
Thanks
No doubt that making every event a state change will fix the issue. It just isn't clear to me why that happens.
As long as the event isn't a repeat from the last, the built in HE state logic should work as expected and make an event, or toss it (if duplicate).
It certainly doesn't hurt anything to make them all state changes, you just might get some duplicates if there is an event with a repeat/same value. I'll point out that could make a repeated device work differently than the source/original device would too.
It does in the sense of filling the DB with superfluous event logs. It’s 100% of the reason I removed that from Apixu and added in the selectors for attributes. But as far as I know that’s all. It makes pulling up the event log page for that device slower but it should have zero effect on other traffic.
HubConnet is different because it’s intent is to inject into “this hub” what occurred on “that hub”. I think “by definition “ an event that makes it into event Socket did so because of an isStateChange at the source. Therefore HubConnect injects received events and adds on an isStateChange = true
There’s a certain amount of “garbage in = garbage out” because errors in using isStateChange for a real device get mirrored on the upstream hub. Got an ‘exhuberant’ driver for your real device. It’s exuberant on the upstream too.
I have two C-5 Hubitat elevation hubs, and I installed HubConnect on them in a server-client configuration.
The devices I exported from the client hub to the server show up fine - I just did a couple switches and a couple contact sensors to get my feet wet with HubConnect.
I can control devices on the client hub from the server hub with no problem.
The issue is that device state is not updating unless I hit the Sync button.
What do I do to fix this?
Thanks!
FWIW, I am using Hubitat Event Socket. I'm not getting any device status updates (are these called events?)
Unable to duplicate. 
I did this in both directions and it worked...
From a Remote, I set a dimmer to 15% and it worked.
app:3 2019-10-20 09:30:14.796 pm info Received event from ZeeRadioUpper/Hallway Dimmer: [level, 15 null, descriptionText: Hallway Dimmer was set to 15%] app:3 2019-10-20 09:30:13.920 pm info Received event from ZeeRadioUpper/Hallway Dimmer: [level, 5 null, descriptionText: Hallway Dimmer is 5%]
Then from the Server, I set the same dimmer to 5%.
The server logs (shown) identify that a message from the hub with the physical device sent a message. In my case, making a change on server goes to the hub-with-physical and then that hub sends back a message saying it's done. Same message, just in one of the two directions, it's a round trip.
What should I try to fix? Reinstall everything? If it matters, my server and client hubitats are not on the same switch - they are on the same network. Should I put them on the same switch?
