I'm using HC 2.0. I enabled the "Send mode changes to Remote Hub". Do I have to create all the modes on the SmartThings side, so that they match Hubitat's modes?
Yes.
HubConnect is going to inform all connected hubs that Mode changed to X.. either that means something to the receiving Hub or it doesn't. If Mode changes to Purple, the receiving Hub will want to set it's mode to Purple. If the mode isn't defined, it can't possibly be successful. 
It would have been true in versions prior to v2 as well.
--// Custom Devices and SmartThings
There are probably 2 or 3 custom devices that I've put together and have them syncing with SmartThings.
Lately, however, I just don't seem to be able to get them to take. I'll create the HubConnect driver for the device, add it as a custom type using the HubConnect app. Install the Device Handler, choose to share a local device with SmartThings, and everything seems to work. However, the device that I'm sharing never gets created on SmartThings. There is nothing in the SmartThings logs nor Hubitat logs to suggest anything went wrong. However, the device doesn't get created. The only thing a little unusual is that in the SmartThings log is that the number of children it mentions in the log doesn't change after sharing the device. Normally, if I've added a device or two, the number of children it mentions will increase.
Example:
324f7...8b345 10:18:02 PM: [debug] getChildDevices(false), children=49
324f7...8b345 10:17:56 PM: [debug] getChildDevices(false), children=49
324f7...8b345 10:16:40 PM: [info] Subscribing to events..
324f7...8b345 10:16:40 PM: [info] HubConnect Remote Client Initialized
324f7...8b345 10:16:40 PM: [info] HubConnect Remote Client Updated
324f7...8b345 10:16:40 PM: [info] HubConnect Remote Client Updated
324f7...8b345 10:16:39 PM: [debug] getChildDevices(false), children=49
324f7...8b345 10:16:38 PM: [debug] getChildDevices(false), children=49
324f7...8b345 10:16:37 PM: [debug] getChildDevices(false), children=49
If I share the same device with another Hubitat hub, using the same HubConnect driver, the device gets created and its state starts syncing exactly as I'd expect.
I've been taking a closer look, trying to figure out how the custom devices that have worked differ from those that don't work and the only thing that jumps out at me is that none of the custom devices that have worked with ST have declared any custom attributes. They attributes they need have instead come packaged in with the capabilities they implement. However, I think that most (maybe all) of the ones that I haven't been able to get to work have at least one custom attribute declared.
Is there anything unusual or particular that one must do to get a custom device to work with SmartThings? Anything to do with attributes? I've noticed that the standard HubConnect drivers have tiles sections, but I think that is just to get them to show up in the app properly. Does one need to define the proper tiles for any custom attributes just to get the device to instantiate and sync state?
Thanks!!
Wow. The hours and hours I've spent trying to unravel this...
I'm starting to thing that something has happened such that any new type of custom device I create in HubConnect simply won't create the device and start syncing in ST any longer. Something got corrupted somewhere or something?
I took a custom device type that I'd done some type ago and added a custom attribute to its definition. I also updated the normal device driver and HubConnect driver files to support this attribute (just made it so one can put text in the attribute). I created devices on the main hub and then shared them with ST via HubConnect and everything worked fine! The devices were created on ST and even the attribute got synced across just fine.
Then I entered a new custom driver that was identical to the one I mentioned above only with a different name. I took the driver and HubConnect drivers and also uploaded them (again, identical to previous, but with a new name).
If I shared devices to ST by adding them under the class name created a while ago, everything worked perfectly. If, however, I "unshared" those devices and then shared them again but this time using the class name I'd just created, they wouldn't work. I was able to go back and forth, split the difference, etc. All devices shared as the older device class worked. All devices shared under the recently created class name failed. Note that this is all still unique to ST. All devices of any type when shared to another Hubitat hub work exactly as one would expect.
It is almost like at some point I lost the ability to create new custom device types for ST. I have no idea if that makes any sense, but I don't know what else to make of what I'm seeing.
Does anyone know if what I'm describing is possible? For more recently defined custom device types to fail while older ones continue to work just fine?
Any suggestions on what I might try other than blow away the entire configuration and rebuild it from scratch? Actually, maybe only my ST part needs to be uninstalled and rebuilt? Even then we're looking at a lot of work... Any way to preserve the configuration? Or somehow just require ST rebuild without needing to remove and then reshare all the devices so that the devices don't all end up with new IDs? Thanks!
agree that this package manager would be great! I just used it for the ecobee integration and it was so much easier. if hubconnect used, then this updates and installs would be so much easier.
2 Likes
I second this. Adding package manager support would be awesome (if not added already)! I can't wait for the day all my stuff is working in it:
1 Like
I'd like to share some of my recent findings on timing with the people who use HubConnect.
I think after you see some of my timings, it may cause you to change or perhaps rethink your configurations.
Originally, after encountering many slowdowns with one hub, I decided to use two hubs (actually 3 if you include ST). I moved all of my rules & integrations (e.g. EcoBee, Google Home, SharpTools, etc.) to a new hub, and I kept my existing Hub with just my devices - very few if any apps. Along the way, I consolidated many rules into fewer, more elegant rules. (H1= Hub with only devices, H2=Hub with all the rules)
Over time, those rules on my H2 became slow again - oh no! the return of the slowdown virus!
So, I decided to do some testing based on something that I read in another post. I read that Rule Machine has a lot of overhead, and may be inadvertently causing a slowdown because of it's complexity. (That's why many of you have started to use Node-Red, etc.).
I have a relatively simple rule in RM of turning on some other switches based on another switch being turned on/off. It w
as the perfect candidate to see if Simple Automation would provide a speed boost.
The results surprised me!
This shows clearly that putting rules into Simple Automation creates much better performance - it took less than half the time!
So, lessons learned:
- Move from Rules in RM to Simple Automation
- SA on the originating hub (the one with the devices)
2 Likes
Just to make sure I understand your results, it looks like simple automation, using Hubconnect, is slower than Rule machine.
What about rule machine on. the device hub?
Thanks for your effort in doing this testing.
1 Like
It appears that Simple Automation rules (even many of them) are much faster to execute than 1 Rule Machine rule.
I'm confused. That is not what your chart shows for Hub 2. SA=1.82 vs RM=1.034
I would think something else is a miss. I can't tell any difference in speed with automations sent over hubconnect vs ones originating on the same hub as the device. I will say that most of my rules (SA, ML, RM) are not on the hub with cloud integrations. Also, I'm not experiencing slowdowns on either hub, and my HE, ST, and HubConnect Server are all on the same network switch.
1 Like
If you're not experiencing any of the "slowdown" virus, you don't have to do anything.
However, if not, or if you just want to improve the speed of execution, then move from RM to SA. Furthermore, moving to the Hub with the originating devices is even faster.
P.S. I transcribed my numbers incorrectly in the chart, I'm updating it right now.
My apologies.
Revised figures:
I also suspect (although I have no proof), that moving RM rules that are frequently used from RM to SA will minimize the "slowdown virus". If there is some sort of resource leak that happens whenever a rule is executed in RM, then this strategy will minimize it.
Of course, there are many situations where a rule cannot be moved to SA because of its complexity.
Nonetheless, whenever you can move a rule to SA, it makes sense to do so.
1 Like
That seems to make much more sense.
1 Like
I was having to reboot my hub daily at one point, which was the impetus for getting the second hub in my case as well. I should clarify my above statement on rules and automation speed. I have all of my ZigBee bulbs and z-wave devices (only 16) on my original hub, with Alexa and HubConnect server. All of my end devices (Buttons, motion, contact sensors, etc) are on the remote hub with most of the rules. So, for the most part, the device initiating the rule is on the same hub and just needs to send the results of the rule to the main hub. This avoids having to make a round trip to fire a rule and doubles my Zigbee bandwidth by using both HE's Zigbee radios. I do see your point and agree there is a big difference in speed between SA and RM, but I can't tell the difference between hubs like you have shown. It seems like the times suffer when trying to make a round trip to the remote hub and back. I measured the round trip time on mine with a virtual switch as approximately 200-300ms.
2 Likes
anyone manage to get this working in container station in QNAP NAS?
Does anyone have a successful ZWN-SC7 scene controller working across hubconnect? I have one connected to a slave hub which reports fine, but the coordinator hub does not receive any updates from the device. If I press the Sync button, it shows the last button pressed but never receives anything in real time.
I looked it up on Amazon and found:
Purchased 1 time.
You last purchased this item on March 23, 2016.
I never got it to work back then, but haven't any need of it, since I'm using Pico's or WallMotes since.
It should just be a button device, much like a WallMote, which I know works across HubConnect.
Which 'real' driver are you using for this on your Remote Hub? And what HubConnect driver for your Server Hub?
On the remote hub I am using the Enerwave ZWN-SC7 7-Button Scene Controller 0.70 by Adam Kempenich and the HubConnect Button driver on the server.
The device driver works fine, but the button driver for HubConnect doesn't communicate over the bridge. I'm sure a custom button driver is needed, but so far not i'm not having much luck creating one.
Again, I don't have one (powered/installed) but I do have a couple of WallMotes.
app:748 2020-04-24 10:41:27.157 am info Received event from ZeeRadioFront/Aeon WallMote: [released, 3 null] app:748 2020-04-24 10:41:24.667 am info Received event from ZeeRadioFront/Aeon WallMote: [held, 3 null] app:748 2020-04-24 10:41:24.623 am info Received event from ZeeRadioFront/Aeon WallMote: [held, 3 null] app:748 2020-04-24 10:40:04.406 am info Received event from ZeeRadioFront/Aeon WallMote: [pushed, 3 null]
The logs above are on my Server via HubConnect Button driver.
I created all the modes in SmartThings and enabled "Send mode changes to remote hub", but it is not working. Changes are not getting sent at all.
I have turned on logging on both sides and see nothing happening about modes.
Running HC 2.0 btw.
