[RELEASE] HubConnect - Share Devices across Multiple Hubs (no longer SmartThings!)

I start Homebridge using Config UI and my Homebridge is running in Docker on a raspberry PI. I haven't figured out how to turn on debug mode in the docker instance - I thought adding the debug to the docker-compose file would do it. I looked at the plug in notes for Homebridge and don't see a debug directly in the plugin.

The lights connected with Hubconnect work fine, it's only the motion sensors that seem to get stuck in a triggered state - or no state for motion sensor.

Anyway here is a log of the startup:

[7/6/2019, 9:46:01 AM] [Hubitat hhh:0.2.8] Device Added (Cache) - Name Bonus Room Hallway, ID 324
[7/6/2019, 9:46:01 AM] [Hubitat hhh:0.2.8] Device Added (Cache) - Name Sunroom Overhead, ID 149
[7/6/2019, 9:46:01 AM] [Hubitat hhh:0.2.8] Device Added (Cache) - Name Bonus Room Overhead, ID 162
[7/6/2019, 9:46:01 AM] [Hubitat hhh:0.2.8] Device Added (Cache) - Name Bosch Garage Motion, ID 806
[7/6/2019, 9:46:01 AM] [Hubitat hhh:0.2.8] Device Added (Cache) - Name Bonus room thermostat, ID 769
[7/6/2019, 9:46:01 AM] [Hubitat hhh:0.2.8] Device Added (Cache) - Name Bonus Room Desk, ID 161
[7/6/2019, 9:46:01 AM] [Hubitat hhh:0.2.8] Device Added (Cache) - Name Bonus Room Outlet, ID 770
[7/6/2019, 9:46:01 AM] [Hubitat hhh:0.2.8] Device Added (Cache) - Name Back Bedroom Floor Lamp, ID 166
[7/6/2019, 9:46:01 AM] [DenTV] keysMap is :{}
[7/6/2019, 9:46:01 AM] [MasterBedroomTV] keysMap is :{}
[7/6/2019, 9:46:01 AM] [BonusRoomTV] keysMap is :{}
[7/6/2019, 9:46:01 AM] [SunroomTV] keysMap is :{}
[7/6/2019, 9:46:01 AM] [Hubitat] Hubitat Hub Communication Established
[7/6/2019, 9:46:02 AM] [Hubitat hhh:0.2.8] Fetching Hubitat-HubConnect devices. This can take a while depending on the number of devices are configured!
[7/6/2019, 9:46:02 AM] [Hubitat hhh:0.2.8] Refreshing All Device Data
[7/6/2019, 9:46:03 AM] [Hubitat hhh:0.2.8] Received All Device Data
[7/6/2019, 9:46:03 AM] [Hubitat hhh:0.2.8] Loading Modes
[7/6/2019, 9:46:03 AM] [Hubitat hhh:0.2.8] Processing Modes
[7/6/2019, 9:46:03 AM] [Hubitat hhh:0.2.8] Loading HSM
[7/6/2019, 9:46:04 AM] [Hubitat hhh:0.2.8] HSM not configured, skipping
[7/6/2019, 9:46:04 AM] [Hubitat hhh:0.2.8] Starting receiver
[7/6/2019, 9:46:04 AM] [Hubitat hhh:0.2.8] attempt connection to ws://172.16.16.20/eventsocket
[7/6/2019, 9:46:04 AM] [Hubitat hhh:0.2.8] homebridge-hubitat-hubconnect server listening on 20009
[7/6/2019, 9:46:04 AM] [Hubitat hhh:0.2.8] connection to ws://172.16.16.20/eventsocket established
[7/6/2019, 9:46:04 AM] [Hubitat hhh:0.2.8] Successfully connected to HubConnect

[7/6/2019, 9:47:04 AM] [Hubitat hhh:0.2.8] send ping
[7/6/2019, 9:48:04 AM] [Hubitat hhh:0.2.8] send ping
[7/6/2019, 9:49:04 AM] [Hubitat hhh:0.2.8] send ping
[7/6/2019, 9:50:04 AM] [Hubitat hhh:0.2.8] send ping
[7/6/2019, 9:51:04 AM] [Hubitat hhh:0.2.8] Refreshing All Device Data
[7/6/2019, 9:51:04 AM] [Hubitat hhh:0.2.8] send ping
[7/6/2019, 9:51:04 AM] [Hubitat hhh:0.2.8] Received All Device Data
[7/6/2019, 9:51:04 AM] [Hubitat hhh:0.2.8] Loading Modes
[7/6/2019, 9:51:04 AM] [Hubitat hhh:0.2.8] Processing Modes
[7/6/2019, 9:51:04 AM] [Hubitat hhh:0.2.8] Loading HSM
[7/6/2019, 9:51:04 AM] [Hubitat hhh:0.2.8] HSM not configured, skipping
[7/6/2019, 9:52:04 AM] [Hubitat hhh:0.2.8] send ping
[7/6/2019, 9:53:04 AM] [Hubitat hhh:0.2.8] send ping

Ok, I can see that this log covers about 10 minutes since start. Within that 10 minutes, did you trigger a motion sensor?

Hi

I can't get to update / download anything directly from the repository in ST. tried everything I could think of, to no avail. Forked the repository then created in ST under "mySpaceName"/ HubConnect / master, also tried to do the same directly from HubitatCommunity/HubConnect/master, also tried spacename/hubconnect/subfolder... in any case the github connection happens but I get only blanc fields once I click "update from repository" in ST.

I've then come across the pdf manual but none of the links are either clickable nor selectable for copy..
UPDATE: links are clickable in adobe reader, just not when opened with browser so that's all good.

Any suggestion on what I'm missing? Thank you very much.

You're trying to get the SmartThings code to install??

Go to the github repo and click each code set you want.. click RAW (in a button along the top edge of the code,) then copy the entire code. (click once inside, ^C (altC) ) then in SmartThings add code in via the IDE --> From Code. and paste into the editor. Save, Publish, repeat.

@srwhite @csteele

I am getting the following in Lock Code Manager after Syncing any locks. After removing the device Lock Manager works fine. It looks like if a device has the lock driver Lock Manager does not work.

After more testing, this is only when added through the interface that this issue occurs. I added a virtual lock and no issue. Then I added a virtual device with the universal lock driver and no issue but obviously didn't work. As soon as I add the lock through the HubConnect interface Lock Manager bombs out. I even changed the universal lock driver to the virtual lock and it still fails till I delete the device.

I get the following when opening Lock Manager:
Unexpected Error

An unexpected error has occurred trying to load the app. Check Logs for more information.

Error: The JSON input text should neither be null nor empty.

I really need help with this as I have to remove all my locks to use Lock Manager and then I have to add the locks back along with all the rules. Very Frustrating.

Unable to duplicate, can you offer more specific details on how to reproduce, please?

I removed Lock Manager for reasons I no longer remember, but I added it back and poked a bit and never got an Unexpected Error message.

@csteele I have Schlage deadbolts on 3 of my Hubitat hubs. I want my HubConnect Server to have all the locks to be managed from there using Lock Manager. When I share the locks from the remote hubs to the server hub Lock Manager produces the error after the lock device is created. As soon as the lock device is deleted the Lock Manager functions again. I can screen share if needed.

@csteele I appreciate the time you took to help me but I know how to do that. I am simply used to getting device handlers and smart apps directly from their original repository so they can update almost in real time when modifications are made by the owner... and it keeps me from having to spend literally hours in configurations... I have a lot of devices, a lot of device types...

But thanks anyway for the time you took

1 Like

Ahh... you asked the question on a HubConnect specific thread... What you're asking, I think, is a Hubitat Platform feature request. However, it would be counter to their design goals to automatically upgrade. They don't force platform upgrades, intentionally. Their own built in device drivers are not independently updated, it requires a platform upgrade. Therefore, I'd extrapolate that they would not force a third party device driver or app upgrade either.

I went into my ZeeLower Hub and removed my lock from HubConnect Remote. I then went to 'coordinator' Device List and removed the HubConnect device for the lock, answering Remove from the 12 "In Use" items.

Then I added it back... by adding in in ZeeLower hub's HubConnect Remote and then in 'coordinator' going into the device page and clicking Sync.

Here's 100% of the logs:

app:2 2019-07-07 08:49:18.973 am trace Creating Device HubConnect Lock - Yale DoorLock... 192.168.7.66:806...
app:2 2019-07-07 08:49:22.838 am info  Received event from ZeeRadioLower/Yale DoorLock: [battery, 50 %]
app:2 2019-07-07 08:49:21.852 am info  Received event from ZeeRadioLower/Yale DoorLock: [lock, unlocked null]
app:2 2019-07-07 08:51:00.977 am debug Requesting device sync from ZeeRadioLower: Yale DoorLock

Should that have duplicated your problem?

It look like it was asking about ST, not HE. I haven't figured out how to do this on ST, which does support this, I think because of how the files are nested in folders inside the "main" repository. If there's a way anyone has figured out for that, it would make updates a lot easier.

It's not too bad on Hubitat once you get everything installed since apps remember their import URL and the drivers have it set in the code.

1 Like

Oh that WOULD make so much more sense...

It's a phenomena of SmartThings specific URL requirements. From what I understand SmartThings code must be in a "top level directory" -- by having one repo with both Hubitat code and SmartThings code obstructs SmartThings, I believe.

It's a result of not supplying SmartThings with a URL, but with a repo. SmartThings itself then builds the URL and does it rigidly.

53%20AM

If it supported:
25%20AM

but it doesn't because there's no .git in that subdirectory... meaning it's not a repo. Catch-22

56%20AM

1 Like

Yes that should have replicated it.

I did the exact same thing but my lock manager gets the error as soon as I add the lock.
If I go in reverse and add the lock to the remote hubs it also errors in lock manager on the remote hubs...

Here are my logs:

app:6132019-07-07 12:19:37.015 pm debug Requesting device sync from TreeHouse Hub: Treehouse Deadbolt
app:6132019-07-07 12:17:21.142 pm info Received event from TreeHouse Hub/Treehouse Deadbolt: [battery, 99 %]
app:6132019-07-07 12:17:19.198 pm info Received event from TreeHouse Hub/Treehouse Deadbolt: [lock, unlocked null]
app:6132019-07-07 12:17:16.867 pm trace Creating Device HubConnect Lock - Treehouse Deadbolt... 192.168.1.101:257...

UPDATE
I added dummy virtual locks with the yale and schlage drivers and Lock Manager works. So it only fails on a real lock. I only have schlage locks so I cant test if it is just the schalge zwave locks.

Nope :slight_smile: I was looking to connect ST to hubconnect github and I don't know why, while I have been doing this with no issue for years with ST, I couldn't get it to work with HubConnect repository... But, hey, I could not even get HubConnect to work at all, despite "connection ok" on both sides... child devices would not be generated... Probably missed something but in the meantime I had to go back to Hub Link and Other Hub event Pusher... Not perfect but kinda works...

You're right but I think that's why it requires that you fork the repository so it can be set as follows:

Owner: yourGitHubName Name: HubConnect Branch: master  

Which I did, to no avail. It DOES accept the repo with no error message, but doesn't see its content when I try do update from repo.

On the other end, this makes me think that it might be a matter of forking directly from the repo's "device types" subdirectory, then... I'm going to try this and see.

I have tried both Schlage and Twikset locks... Put them back on my ST hub because hubitat has been aware of issues with locks for more than a year now and hasn't provided a solution yet. On my side, locks would pair then... disconnect... then reconnect... then disconnect... totally unreliable. Same goes with some other devices such as Securifi Leak Sensors (won't even pair...) or Zooz water valve, which disconnects after a simple hub reboot... Hubitat doesn't seem to realize how bad this is. I know they have a lot on their plate and probably deal with a long list of issues in a specific order while being a startup size company, but some things seem to me as absolute priority, especially a water valve or water sensors... But, hey, Hubitat remains a much more efficient hub than ST for many reasons. Just know that it won't work for things that can be as vital as a lock or protection against water damage. I had someone telling me, in a different thread, that smart home were for tech savvy people. I wonder what effect this would have if I quoted this thread in Amazon's reviews :smiley:

UPDATE:
Now my kwikset lock seems to work perfectly. The Schlage lock too. I'm going to see if I'll have the same luck with my securifi leak sensors. If so, then I'll be able to say good bye at once to ST!!! :smiley:

Rule Machine is incredible! Also worrying since I don't have to code anymore for most of the things I used to have to code for!

@elfege My Schlage locks have been absolutely solid and I have 7 on 1 hub and 2 on 2 others for 11 total locks. Its just the Lock Manager that is now having issues while sharing them across HubConnect. The crazy part is the locks themselves work with hub Connect where the Lock Manager fails with an error.

I saw another issue a user had that @mike.maxwell said was due to a large amount of locks and codes. I believe he said he found the issue and fixed it.

Not sure if your problem could be related. Just a thought.

Are you on the latest firmware?

@cwwilson08 I am on the latest and I was hoping that was the issue but it doesn't seem to be so. I have also sent the locks to the remote hubs and the count then would be 3 and the Lock Manager fails on the hub as well.

This sounds like the lockCode attribute being sent from one side to the other is malformed.
LCM doesn't store lock codes it reads them in from all the locks when the app is opened.