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

I attempted to follow that 'recipe' and was unable to duplicate.

New 'mirror' of a honeywell thermo, using that TCC driver. Installed Thermostat Scheduler, first time, ever. Selected the mirrored Thermostat and then dove into heat/cool time periods. I clicked on the pair of toggles and in Fan mode, selected Auto. All 4 places. Then clicked done. Went back and they were all still set to Auto. Done all the way out, back in, still all 4 are set to auto.

Clearly there's something I'm missing in the recipe :slight_smile:

The TCC driver works as expected with no issue. Select HubConect Thermostat driver instead. The HubConnect Thermostat driver has the fan settings in double quotes which breaks it.

As I said, I selected the mirrored Thermostat... so it is using the HubConnect Thermostat driver.

This on the 224 firmware? When you click on the manual settings. The "Set thermostat fan mode" drop down has all the fan settings in quotes. Selecting anything in there will not change it. Try setting to On or circulate. Same thing when trying to set it in the schedule. This is on the 224 firmware though.

image

I tried the analogous thing but nothing changed. It's so weird that the physical device wouldn't be chatty but the hubconnect shadow is very chatty. Anyone have any theories?

I care because I'm desperately trying to find what's causing my event-spamming.

Still no match on quoted flaw...

Screen Shot 2020-11-01 at 6.56.45 PM <- I'm using this device for these experiments.

There's no "real" thermostat in this particular C-7.

Screen Shot 2020-11-01 at 6.57.34 PM

Above is the options in the App...
Screen Shot 2020-11-01 at 6.56.11 PM

Above are the options in the HubConnect Thermostat driver info page.

I looked in HubConnect Thermostat.groovy for "circulate" and can't find it. The closest match is:

/*
	fanCirculate

	Sets the fan operating mode to "circulate".
*/
void fanCirculate()
{
	// The server will update status
	parent.sendDeviceEvent(device.deviceNetworkId, "fanCirculate")
}

That's it... 'circulate' appears in the driver 4 times, and never in Code as circulate by itself. There's a comment, yes, but of course that's nothing.

I then checked HubConnect Remote Client and HubConnect Remote Hub, and they don't have 'circulate' either.

I logged into the st hub to see what the st driver was using and found the double quotes there. I guess they are being passed through the HubConnect driver.

ST??

Horse of a different color!! :slight_smile:

Well I'm using hubconnect to talk to it. It's a built-in driver so no way to filter out what it sends hubconnect.

As far as I know, HubConnect doesn’t do any kind of polling that would increase events on a virtual/remote device. It listens to the Hubitat event socket and merely forwards information from that. So, if there are a lot of events on the remote, they have to be getting generated by the real device. With that said, I don’t think an event every 30 seconds qualifies as a lot. I have never seen the “event queue full” error even when I had several events per second. My guess is that there is some other device, app, or driver that is causing a lot more events than this.

Is it possible that a device could be generating more events than the device's event log would indicate? Wouldn't seem so, but maybe?

Hi, new HE owner here. Just installed Hubconnect to try and connect HE to my Samsung TV which on ST. I'm getting this error. Is there something else I need or is devices like TV not supported via hubconnect?

2020-11-03 09:19:01.432 pm error... Uunable to create device TV: com.hubitat.app.exception.UnknownDeviceTypeException: Device type 'HubConnect AVR' in namespace 'shackrat' not found.

Missing the AVR driver in Hubitat it looks like.

Not sure if this is your problem, but note that there is not always a one to one correspondence for actual events (as displayed in the 'live' or 'past' logging pages) to the events maintained in the device's event history page. Only events that change the state of the device will be visible in the devices' event history.

For example, say an app issues a command to turn off a bulb that is currently on. You'll see the bulb turn off (if descriptive text logging is enabled for it) in the hub's logging page, and if you bring up the device's event history it will be shown there as well. But if your app now issues three more consecutive 'off' commands to that turned-off bulb, all of the 'off' events will be logged in the live logging area, but the device's event history will show none of them. These are actual events that are 'filtered' in the event history since the state of the device hasn't changed.

1 Like

There is a local driver in beta for the Samsung TV's incase you're interested. Can even have both the local and HubConnect if you needed to keep it on ST for whatever reason.

Hey @storageanarchy, I am running into this issue now as well...were you able to complete that solution?

Were you ever able to resolve this? Hitting the same problem myself

Sorry, no. It's been too long and I have pretty much stopped using HubConnect as I moved all my ST devices (including locks) over to HE, except a couple Ring integrations.

1 Like

Please excuse my linux ignorance. How are ya'll starting the proxy server and have it continue to run even after closing the terminal? Simply using node proxy.js stops if I close terminal. I tried searching the thread to no avail. I also Googled and installing "forever" seems to be the most recommended option.

All of my Production nodeJS tools run on my always on Mac Mini (who's primary duty is Media Server - but with plenty of power left to run Homebridge, Node-red and HubConnect proxy Server.)

I use osx's Launchctl to keep it running.

I use a rPi to play/understand a tool and how I'll ultimately use it... then I kill it off and get it running permanently on my MacMini.