Is there any possible way when a Hubitat Hub is deleted, it'll automatically delete all of the HubConnect devices automatically on both Client and Server? Not sure if this is a platform thing since it works fine on Smartthings if I delete the HubConnect app for example but doesn't do that on Hubitat.
Glad to see some fixes will be for 1.5. Doing custom driver is pretty annoying and confuse in the current release (1.4), maybe more doc/help/sample for it?
I'm surprised so many people have issues with custom drivers. For MONITORING, I've found that if you are using the eventsocket connection, all attribute/event updates come over whether you want them or not / whethr they are specified in the stub driver or not - thus not needing a custom driver above and beyond the tempates already provided.
You definitely need a custom driver if you want all of the capabilities/commands on the repeated side, though. But not for events.
1 Like
There's always a way, but I have not pursued that as an option.. The reason I've not considered this to date is primarily due to the flexibility.. One can uninstall and reinstall HubConnect server or remote, and any devices shared to remote hubs will automatically re-link when they're selected again. This obviously has the potential to save a lot of hassles in updating automations or dashboards that use the virtualized devices.
Custom drivers were really meant for people with some familiarity with coding. You first have to create a stub driver then go into HubConnect and define the attributes that HubConnect will pass to that driver. I will see what can be done in a future release to make this easier.
Not my experience... If the hubs are connected via event socket all events come over for a device whether the attributes are in the stub driver or not. 
Unless I'm really remembering incorrectly and made more stub drivers than I remember? I'm not in front of the system to verify.
Commands are a different story, of course, as there has to be explicit support/capabilities in the stub driver for them to show up at all on the repeated device.
You are correct.. For performance reasons HubConnect doesn't filter attributes coming over the websocket so your method works perfectly. 
I was pretty sure that is where I left it...
Although I balked as I made a 'super mega omni' stub driver at one point with basically EVERY capability HE supports (well every capability that I use/needed - not 100% of the HE supported capabilities) in one stub so I wouldn't have to mess with stub drivers any more.
Yes, with an omni stub like that you will have many commands/capabilities that don't actually work for a given device/type - which would definitely be confusing to most, which is why I never released it - but it is super easy to implement.
Then you're probably going to really like the fact that in 1.5 websockets are bi-directional now! 
1 Like
I was hoping that is what @csteele was implying. But I didn't want to start a big conversation on it. lol.
That is a welcome change!
By the way, I applaud you remembering how it all fits together after taking your summer hiatus! I haven't really touched HubConnect since setting it up, other than adding new devices, so I forget what I did sometimes. lol
Haha.. I shifted more processing onto the remote hub device driver and added on-device filtering. The previous challenge was preventing a hub-crashing event loop from bouncing between hubs via the websocket. That's solved and working pretty nicely now.
Thanks! I haven't touched HubConnect (or Hubitat) much over the summer. It was quite a testament to the stabilty of Hubitat.. A few sensor batteries went dead without my catching them, but overall things worked well.
Many of these improvements were already underway this spring. The real challenge was trying to decipher incomplete code changes and figure out what the heck I was thinking.
Makes sense. It is a more elegant solution.
With bi-directional web sockets, and device filtering, it mostly eliminates the need for a distinction of "server" and "client". They are just equally capable connections on both sides. I thought about that this summer, but never got around to doing it (secretly hoping someone else would).
"Server" --> Hub A
"Client" --> Hub B
Noe you're revealing new features.. lol. Although not in 1.5, it is on the roadmap to only have a single set of apps and eliminate the remote client, except for SmartThings.
1 Like
Prefer a simple/easier way to have these customer driver devices in the configuration. I used to create stub driver and then config in the HubConnect. After failed couple times, I gave up, using defined common driver even it's not perfect...
Maybe clear instructions for how to use customer driver in 1.5 will help people like me with limited coding skills 
Remember, there were a couple of bugs in the Custom Driver code and I merged @storageanarchy code a month or so ago... any attempts prior to that had at least double the frustration 
Whether fully realized in 1.5 or not, the changes discussed above will/should make the stub driver situation MUCH simpler.
At that point all you would do is define which devices transfer between hubs in the HubConnect config, and in the stub driver make sure the right capabilities/commands are in there. No more specifying attributes/commands/etc in the custom driver section of HubConnect UI.
And to take it to another level/phase - Theoretically someone could make a "dynamic" stub driver generator by pulling the capability/command list from the physical device via MakerAPI (if on the remote side) or generating it locally if on the "server" side... Then it would be a copy/paste exercise to make any stub driver based on the actual capabilities/commands in the physical device. Wouldn't be too hard to do - I can picture how I would do it in code right now (and I'm just a high functioning moron).
Well, at least for HE devices. ST is out of my field of view at this point.
I already have a driver builder in my "playground" code.. It's a read-only attribute generator, but it's a start. If I can make it more intuitive it'll be released in the future.
As @csteele has learned, I have a codebase that I just play with; adding things, refactoring, etc. The ideas I like or the code changes that work well migrate to production. Once in a while I surprise him by adding a change or feature he suggests, sometimes within minutes of his suggestion. 
5 Likes
2 Likes
This reinforces bad behavior. Now I can only think of - "what else can I goad him into making/releasing?".
Looks good. I very much like how this part of the system is getting simplified as, in my opinion, it was the most difficult part for a lot of end users. That is, managing stub drivers and understanding how to implement custom stub drivers.
4 Likes
I will have to keep that in mind.. I was able to back port this with minimal effort so it'll be in 1.5 albeit with a "beta" disclaimer....
6 Likes
Heads up... HubConnect v1.5 is coming this weekend!
The HubConnect Driver Builder is official but is going to be tagged as beta for now.
The builder generates a usable "stub" driver that can be directly imported as-is, or improved on (i.e. adding commands).
The version report has also been updated with the new UI..
I'll post the official changelog in the release notes.
11 Likes
