I was told that there could be setbacks with Downstairs/Upstairs approach related to Mesh Network so make sure you have good repeaters for both mesh.
There are downsides to any approach. But you bring up a good point. Someone with only a few Zigbee or Z-Wave devices won't benefit as much and may actually introduce coverage issues if there are not enough repeaters. The end goal is to keep everything on one floor so fewer repeaters are needed.
Question:
I have my 3 hubs (2 HE and 1 ST), on a standard gigabit TP-Link switch. (TL-SG1008D)
Since I see that HubConnect is critically dependant on switching ability, is a router usually faster than a switch?
Should I move my hubs to the router, or leave them on the switch?
Or, does it make no difference?
Depends on how swamped your switch is with other traffic.
It would be highly unusual to swamp a switch at home with traffic. Not impossible, just hard.
I'd leave them on the switch.
I'm going to avoid going super technical on this answer, but if ya need it.. 
1 Like
It would be hard, although not impossible to lug down a conventional gigabit switch to the point where hub to hub response times are impacted in a noticeable manner.
Without congestion the typical latency across a cheap consumer switch is only 1-4ms round trip. Congestion can greatly impact that but it it will take a lot.
Most of the messages between hubs are only 1k or less in size. That’s not a lot of bits to move around.
1 Like
I've seen a few times where HSM status does not sync across hubs. I confirmed that HSM sync is enabled (send and receive) on the server hub, and send on the client hub.
You can see below. The system armed at 10:09pm as expected, and the status is reflected on client hub. However, when the server hub disarmed this morning at 05:57am the HSM status never changed on the client hub (notice no "disarm" hsmEvent on the client hub).
Anyone ever see that?
Not a huge issue for me, but if you are relying on HSM "disarm" as a condition, it will break things (and did for me this morning...).
Server hub:
Client hub:
HSM events in 1.6 are still subscription based so it might be that the event was never fired on the originating hub. I have not seen this but I don’t sync HSM. I use mode changes to trigger HSM so I have not encountered this.
There have been a lot of improvement to HSM integration in 2.0, amongst them is location events (SHM/mode) can use the websocket instead of subscriptions & http events.
errorjava.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String (setLevel)
This happens with all my Hubitat's virtual dimmers
What is the driver that you are using for your dimmers? setLevel requires an integer (number) and not a string. That error is being thrown because something is passing a string value to the physical device. Are you using the latest HubConnect apps and drivers? The latest is 1.6.4
Just to rule out a platform change in the latest update I tried the setLevel on three HubConnected devices testing three driver types; GE Smart Ceiling Fan,Generic Z-Wave Dimmer, and Generic Z-Wave Smart Dimmer. I cannot reproduce the error and all of my devices are controllable.
That means there still some data missing. PLease describe the device throwing the error, the driver it's using, what platform it's hosted on, and what platform the virtual HubConnect device is on. There might still be an issue, but I need more data to try to isolate it.
Hubitat's virtual dimmer.
@bptworld, @srwhite, I also get this error code with all my thermostats on my second Hubitat hub, using socket connection:
groovy.lang.MissingMethodException: No signature of method:
user_driver_shackrat_HubConnect_Thermostat_321.currentValue() is
applicable for argument types: (java.lang.String) values: [thermostatMode]
on line 249 (refreshLRM)replacing this:
def lrm = getDataValue("lastRunningMode")
def tm = currentValue("thermostatMode")by that:
def lrm = device.getDataValue("lastRunningMode")
def tm = device.currentValue("thermostatMode")seems to have fixed it
Yes, I am.
Thanks for your support.
typo? 
1 Like
Not sure where, though, since I had to modify the HubConnect Thermostat driver to fix this, as shown in my last post... unless you meant this for yourself, did you? 
Anyway, great work, very useful. Tried to use the Hubitat 's built-in hub link, couldn't get it to work without throwing hundreds of errors...
No, I meant you tagged me, that was the typo. I'm not a developer of this app. I would try @srwhite or @csteele. 
3 Likes
Oh! haha! ok! Need coffee...
1 Like
I’ve been mistaken for far worse people. Lol 
2 Likes
Has anyone had trouble with StmartThings ? My connection seems to be a bit off.
I have added the hub 3 times and I still get this even though the devices I choose do work.
Yes. The past few days I've notice HubConnect reporting my ST hub being offline or missing pings. Nothing on my ST side f things has changed and ST always shows my hub is online without issues.
1 Like
Ok thanks... ST is a pile of crap.
1 Like
I barely use ST. It's strictly so I can assist with HubConnect questions/issues related to ST. I don't, and have never (yet) installed the new ST App.
My connection is quite stable nevertheless. Perhaps Samsung prioritizes non-use ??
j/k
Anything in the live logs on the ST side of things? ST is crap but it's not that bad. I keep my ST instance running and it does get temperamental at times.
connectStatus of error is certainly concerning. The live logs may provide some further clues.
