@csteele, I am up and running on the beta app with the server on the new hub which is what I originally wanted. I set it up exactly like I did ver 1.6 and it works great. No issues so far. I could only get ver 1.6 to report proper state if I had the HubConnect server app installed on the hub that the devices were paired to for whatever reason. I wiped and tried 3 times with the same results. Beta 2.0 had no issues for me.
Edit: That being said, your solution above may have very well solved the issue for me because I had not deleted the virtual servers before reconnecting previously. I did delete them before installing Beta 2.0.
Is there an order which hub first reboot first? I have 3 hubs.
One with all devices (Server)
One with all Rules
One with all custom apps
I still experience after a few weeks (better than a few days), ML is slowing down. If I scheduled these hubs to reboot, I want to make sure I don't cause any issues with Hubconnect.
That's a great question... Similar to what I posted about above... I have my hubs scheduled to reboot a few minutes apart with the server hub first, then the backup hub after. I just assumed the server hub should be first...
Ok, please don't beat me up with this question as it was probably asked somewhere in the thousands of posts above...
How do I go about setting up custom HubConnect devices drivers? I'm sharing some TV's from SmartThings and Tivo devices from another Hubitat hub thanks to martinez.mp3 at:
Anyway, these are pretty complex devices and the current AVR driver doesn't fully capture them...
I'm not afraid of doing the work, just need to be pointed in the right direction...
If you have access to the Hubitat driver for the device you want to virtualize across HubConnect, then it's a fairly simple process. HubConnect encapsulates all device commands and passes them to the physical device driver to process and update any relevent attributes when are then transported to the virtual HubConnect device.
Capabilities and commands are defined the same way they are in the physical driver, so those can pretty much be copied and pasted.
As far as how to implement the commands, for example, look at the on() command for a Zigbee switch device.
def on()
{
zigbee.on()
}
And how it translates in a HubConnect driver:
def on()
{
// The server will update on/off status
parent.sendDeviceEvent(device.deviceNetworkId, "on")
}
If you have parameters to send to the actual driver, like a dimmer level, those are sent as a list in the third parameter to sendDeviceEvent().
def setLevel(value, duration=1)
{
// The server will update status
parent.sendDeviceEvent(device.deviceNetworkId, "setLevel", [value, duration])
}
To actually get HubConnect to recognize your new driver, you'll need to log into your HubConnect Server app, and create the Custom Driver definition for it. That requires a main capability that will act as the selector for devices, then you define any other attributes that your driver uses.
I recommend having a look at the drivers that are bundled with HubConnect for inspiration on how to create your own.
I've got access to the Tivo driver as that was written native to Hubitat... I have some sample drivers for the Samsung TV's related to the SmartThings environment, but not the actual DH it is using for the current TV integration... It's called "Samsung OCF TV" but I'm assuming the commands are pretty similar to the old stuff I've found scouring the web...
Hi all.
I just finished configuring HubConnect.
I was able to get all my dimmers showing up on the server side.
However my switches and door lock are not synching up.
I already installed the drivers before adding the switches and the door locks.
I have rebooted both HEs, but still wont show up on the server side as a device.
I have five (5) hubs -- 3 for "radios" placed proximal to respective devices, one for cloud devices and questionable apps, and one as my HubConnect server/coordinator, dashboard manager, etc.
For the most part, all real devices are on the first 4 hubs, and all HubConnect virtuals are on the server hub.
There are a few cases (~5% of my whole setup of ~350 devices), however, where I want a physical device on one of my radio hubs to be available on another radio hub in addition to the server hub. Better to setup HubConnect to use a hub & spoke topology (radio hub to server hub to other radio hub)? Or an NxN where the device goes in parallel to both the server and the other radio hub?
HubConnect is pairs of hubs... one running Server, one running Remote Client.
I've read of people having both Server (for 'that set' of Hubs) and Remote Client (for a different set) on the same Hub. I don't.
I have a setup similar to yours with one hub for 'Internet facing apps' as well as Dashboard. Pretty much all the real devices and many of the virtuals are mirrored to the Server, for me. Remember, for Event Sockets, there's no 'sending overhead' You send 'everything' to the Dashboard hub anyway, it's practically free to have any/all the other hubs listen to its event socket.
I set up HubConnect last night between two HE's. Worked great out of the gate and set up a link for 3 Lightify lights. Went to bed and woke up to find that the link between the two hubs was broken and had to resetup HC on the Server and Client side. Previously connected lights are not controllable on the main hub. Any suggestions on the best way to recover?
You wouldn't have had to resetup HubConnect.. you could have just deleted the Hub Device on both the Server and Remote, then pretended to exchange the key. As you click Done all the way out, those Hub Devices would have been rebuilt.
However, since you did resetup HubConnect, you probably have to remove all the Virtual devices created the first time. Since they were there during your second, they prevented the build of child devices. You will have to delete them, and again, pretend to exchange the key, and pretend to reselect devices. They will get built as you Done out.
@csteele Thanks for the reply. Actually, what I found that on the main hub(server), that the client connection was no longer present. I re-added, copied the key and went to the remote and pasted the key. The link was re-established (apps show connected on both sides), but devices cannot be controlled by the server hub. I suppose I will try deleting the devices and trying again. What is odd that the connection was broken on its own at 2AMish, I started receiving the flowing error:
[sys:1] (http://192.168.1.241/logs/past#sys1)2020-02-10 02:01:25.645 am warn Received local request for App 394 that does not exist, path: /ping
Don't know, but my best guess is that a Done got missed. OR.. the DB was corrupt and the 2am 'housekeeping' task the hubs run at that time, reverted to an older DB.. the DB from before the app got installed. Again, I don't know, just two wild guesses.
Thanks … didn't know that there was a 2AM housekeeping proc. I'll reinstall the devices and try again. This is exactly why I only wanted to test with a few devices before moving all of my Lightify devices over (about 25). When it was working, it worked great and had no perception of lag vs being run on one hub.
In my case HubConnect sped things up because previously my hub would get bogged down. Leaving devices on one hub and using HubConnect to connect another hub that runs rules and cloud devices made things noticeably faster for me.
