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

What is the proper way to completely turn off/disable a hub connection? I setup a connection between my coordinator hub and my dev hub but I want the ability to turn it on and off so I don't have to set it up each time. Here is what I did:

  • On my remote "dev" hub I opened the HubConnect Remote Client app, clicked Connect to Server Hub and toggled "Disconnect Server Hub"
  • On my server coordinator hub I didn't find a "disconnect" setting in the Server Instance app, so I went to devices and pulled up my Dev hub and turned it off
  • I thought this would do it, but the 5 minute poll to this hub produced errors in the log "X is offline" over and over again

There will be cases where I may need to disable/turnoff communications to any of the hubs for maintenance or if there is a hardware/database issue with one of the remote hubs. Please let me know if I am missing something or if this feature isn't implemented in the current version. Ideally I would like to be able to toggle this on/off in one central place and prevent further logging in the server and remote hubs.

Thanks!

I would expect that disable for the Server Instance would ... well disable it :smiley:

46%20AM

Ah you mean the hidden X on the app list that I always forget about. :disappointed_relieved: Good idea though it would be nice to have a Pause button like other apps have.

Yea... that one :smiley::smiley:

But I bet there's only one other person that forgets about that. :smiley:

1 Like

any further thoughts as to why I am not able to save a custom driver?

thanks

OK, I'm stuck.

Has anyone figured out how to add support for centralized Notification devices being mirrored to/from client hubs? I'm interested in both stand-alone Notification devices, as well as adding the "Notification" capability to the Hubitat mobile presence device.

1 Like

All, I just uploaded a new plugin that should fix an issue of devices not disappearing in HomeKit once they got removed in HubConnect.
You can update to the new version by running a

npm - g homebridge-hubitat-hubconnect

In addition, I added an ability for the plugin to write a log file as it can be confusing on how to get the log entries.

The new settings are defined in the platform parameters with the following structure:

"logFile": {
   "enabled": true,
   "path": "",
   "file": "",
   "compress": true,
   "keep": 5,
   "size": "10m"
}

Here is a description of the parameters:

  • logFile Optional
    Settings to enable logging to file. Uses winston logging facility

    • enabled Optional
      Enable logging to file. Default is false. Set to true to enable file logging
    • path Optional
      Path to store log files. Defaults to path where config.json is stored - Only applicable if logFile -> enable is set to true
    • file Optional
      Filename of log file. Default is homebridge-hubitat.log - Only applicable if logFile -> enable is set to true
    • compress Optional
      Compress log files when they rotate. Default is true - Only applicable if logFile -> enable is set to true
    • keep Optional
      Number of log files to keep before deleting old log files. Default is 5 - Only applicable if logFile -> enable is set to true
    • size Optional
      Maximum size of log file. Default is 10m - Only applicable if logFile -> enable is set to true

And as often requested, here is full (simple) config.json that has the new logging settings set:

{  
   "mdns":{  
      "interface":"192.168.10.61"
   },
   "bridge":{  
      "name":"Homebridge Dev",
      "username":"AA:BB:CC:DD:EE:FF",
      "port":51826,
      "pin":"123-45-678"
   },
   "platforms":[  
      {  
        "platform": "Hubitat-HubConnect",
        "name": "Hubitat HubConnect Dev",
        "mode_switches": true,
        "local_ip": "192.168.10.61",
        "local_port": 20009,
        "hubconnect_key": "YOUR-HUBCONNECT-KEY",
        "logFile":{  
          "enabled":true,
          "path":"",
          "file":"",
          "compress":true,
          "keep":5,
          "size":"10m"
        }
      }
   ]
}
1 Like

I got this installed yesterday with an ST hub as client. I'm getting httpGet() request failed with error 504 in ST live logging. I searched the thread but have not found a mention of it.

Edit: HE hub reboot fixed it.

All, I just uploaded a new version of the plugin that fixes a rounding issue with thermostats.

New version is 0.2.10

HubConnect 1.4hf 5 Available

This hot fix release includes some bug fixes and feature updates for Custom Drivers, SpeechSynthesis, AVR and Mobile-App:

Custom Drivers:

  • Added filter so Custom Drivers can find devices to select.

Drivers:

  • Bug fixed typo in Button Driver for “release”.
  • Bug fixed for count of motion sensors selected.

New Drivers:

  • Added SpeechSynthesis driver for speakers.
  • Added AVR (audio video receiver, such as Denon)
  • Added Mobile-App for Hubitat’s Mobile app device. (Notification and Presence)

Hubitat:Apps:

  • HubConnect-Server.groovy
  • HubConnect-Server-Instance.groovy
  • HubConnect-Remote-Client.groovy

SmartThings:

  • HubConnect-Remote-Client.groovy

UniversalDrivers:

  • HubConnect-AVR.groovy
  • HubConnect-Mobile-App.groovy
  • HubConnect-SpeechSynthesis.groovy
5 Likes

I am trying to get echo speaks devices setup on a remote hub mirrored back to the server hub with no luck. The devices are in the hub conncet app on the remote hub. They just never seem to get created on the server hub. I have installed the driver on the server hub.

I have successfully mirrored presence devices from the remote hub to the server hub, so things seem to be working. Any suggestions?

Edit. Never mind I figured it out.. It helps if you update all the code on all the hubs lol.. Thanks for working at this..

I think that is "my favorite" too. I certainly do it a lot.. so it just has to be a favorite. :smiley:

1 Like

do any of the current driver support the playtrack command?

Edit - NM I managed you hack in support to the speech synthesis device...
seems to work good..

I’m too used to my 3 hub setup, where one hub is dedicated to all the non-Z-stuff, as well as Dashboard and Echo/GH. I haven’t yet noticed a need to mirror that group of drivers. Of course there’s always Custom Drivers. :slight_smile:

lol I couldnt figure out how to get the custom driver to do what I wanted..

was easy enough to add the playtrack command to the stock driver though.. worked great..

I think I’m the same way... very familiar with stub driver requirements.

1 Like

Is anyone else having issues with the Hubitat Hubs not syncing correctly? I was going to switch from WebSocket to HTTP to see if it helps but I'm seeing a lot of issues the past month. Location/HSM statuses are not updating between the hubs and devices are not syncing until I manually sync the device. Not much showing on logs to show the hubs are offline, rebooting the hubs seems to help for a little bit before it'll stop working again overtime.

I'm on the latest version of HubConnect on all hubs and latest version for the hubs too.

I wrote this for a different thread, but the test results are just as valid over here :smiley:

I can't duplicate this.

I ran a test and have logs... that I'll try to explain:

First, these are logs from the remote (ZeeRadioUpper) and the Server (coordinator) merged and then sorted by time... this reverses the normal 'most-recent-on-top' order:

ZeeRadioUpper dev:838 2019-07-29 09:15:39.192 pm info Office WallSwitch was turned off [digital]
ZeeRadioUpper dev:838 2019-07-29 09:15:40.011 pm info Office WallSwitch was turned on [digital]
coordinator   app:3   2019-07-29 09:15:41.067 pm info Received event from ZeeRadioUpper/Office WallSwitch: [switch, off null]
coordinator   app:3   2019-07-29 09:15:41.871 pm info Received event from ZeeRadioUpper/Office WallSwitch: [switch, on null]
ZeeRadioUpper app:837 2019-07-29 09:15:57.117 pm info Received command from server: ["Office WallSwitch": off]
ZeeRadioUpper dev:838 2019-07-29 09:15:57.483 pm info Office WallSwitch was turned off [digital]
ZeeRadioUpper app:837 2019-07-29 09:15:58.150 pm info Received command from server: ["Office WallSwitch": on]
ZeeRadioUpper dev:838 2019-07-29 09:15:58.520 pm info Office WallSwitch was turned on [digital]
coordinator   app:3   2019-07-29 09:15:59.356 pm info Received event from ZeeRadioUpper/Office WallSwitch: [switch, off null]
coordinator   app:3   2019-07-29 09:16:00.438 pm info Received event from ZeeRadioUpper/Office WallSwitch: [switch, on null]

The top two logs are me turning the switch off then on again from the remote.. the Hub that has the 'real' device. It's followed by the pair of logs on the coordinator, showing the change arrived... was correctly "mirrored."

The next 4 are off then on from 'coordinator' and the first indication is on ZeeRadioUpper where it logs that the server sent a change.. an off... followed by the real device going off, which gets mirrored back to coordinator.

The coordinator does NOT change the state of the virtual device initially, it changes in response to a change on the real device. In other words, the top set of 4 and the bottom both reflect that a change occurred on the real device and THAT is what gets mirrored.

I'm sorry that I can't duplicate this for you. The device is the Lamp here in my office, which I certainly noticed turned off and on, on-demand.

I augmented that test with a new one where I'm running a websocket client tool against ZeeRadioUpper looking at responsiveness. I click a Device Info page button and I see the update in the WS client as quickly as my eyes can move. Doesn't matter which Hub I'm on, the resulting WS output is very quick.

Yea, it just happens overtime for me so it's not something that would be easy to duplicate. It has happened multiple times now over the past 2 months. I'll see how it works using HTTP instead of Websocket and report back if I have any issues still.

Example today, all of the contact & motion sensors on my coordinator hub is showing 12 to 1 AM this morning is the last event yet on the hubs where those devices are the devices are showing activity within the past hour. This is even after I rebooted this morning to get the issue fixed with the locations not syncing.

I am as well. I can't be sure if my issue is related to yours, but I think I've discovered the cause of mine. I have way too many devices being synced (most of them virtual).

I've found that when I add all the devices I want, I get the following error on the main hub trying to send the devices to the remote hub (after adding the devices and hitting done in the app):

image

The app appears to error out waiting for a response - not sure if it is a Hubitat limitation with too many devices, or if the app isn't waiting long enough for Hubitat to parse all the devices.

When I back off the number of devices, it finishes correctly and my devices sync correctly again.