That error is from improperly formatted JSON from the driver.
Yes, of course.
We are asking what JSON response HSM is expecting the driver to provide. It isn't in the SecurityKeypad capability documentation, so no one can write a user keypad driver (even a shell/"stub" driver for HubConnect) that works with HSM at this point without some more information/details from Hubitat.
Thanks!
1 Like
Announcing the HubConnect 1.7 Beta
Now that my server hub is back in service it's time to move forward with HubConnect 1.7! With the introduction of the new nodeJS HubConnect server app, I am going to do the 1.7 release a little differently this time with a closed public beta. This beta is not expected to last more than 2 weeks so it won't be a huge time commitment.
I am inviting anyone who wishes to participate in the 1.7 beta who have a need or interest in testing the new server.
I only ask that a five specific skills/requirements are met as closely as possible:
- Must have at least 2 Hubitat hubs currently connected via HubConnect.
- The hubs must be in the same physical location and connected using websockets.
- Must have at least 100 devices shared through HubConnect (to help stress test).
- Have been a user of HubConnect for at least 2 months and are familiar with its operation.
- Have a Raspberry Pi, or always-on Mac or PC capable of running the nodeJS environment.
If you are interested in participating, please send me a PM no later than this Thursday (1/9). In your message, please include the following details;
- Number of Hubitat hubs
- Approx number of HubConnected devices
- Your current nodeJS hardware environment (i.e. Raspberry Pi, Mac/PC server, etc).
I expect to begin this beta group no later than Friday, if not a little sooner.
This will be the last release in the 1.x branch (for sure this time)!
6 Likes
I did do the steps provided in the Classic ST App.
I have a quick question on best practices for HubConnect. I picked up a second hub to build a new mesh for my Zigbee bulbs. Does it make more sense to run with the two hubs or to add a third command hub?
One hub with Zigbee bulbs and one hub with everything else and scripts.
Or one hub with Zigbee bulbs, one with remaining devices, and one with scripts.
I’ve tried many products over the years and things are starting to really take off now with Hubitat. I have about 300 lines of code just to control my exterior lights. 
Currently I have on the order of
25+ Zigbee bulbs
12 Iris motion sensors (only part way through that install)
8 IKEA plug in switches (for repeaters)
12+ z-wave switches
2 z-wave outlets
3 z-wave motion sensors
30 MiLight bulbs
My gen 1 Hue products are currently decommissioned. Not for any reasons other than I haven’t migrated them over to Hubitat and new bulbs are too expensive. I only have a few of them.
Thanks
You can read a few different reasons that people above use multiple hubs--there is no inherently right or wrong way (well, you could probably find a "wrong" way if you tried hard, but...). The reality is that either way you mention above would work. If it were me, I'd start with just two hubs. You can add a third later if you want (and may want to right away if you feel like adding to this any "risky code" like webCoRE or the Chromecast beta, for example, for slightly different reasons that you mention--keeping them off any "important" hub). Most people only have one, after all, and you could probably get away with that too if it weren't for the Zigbee bulb problem that you are wisely choosing to avoid by keeping them off your "main" Zigbee network.
If all of your bulbs are ZLL and not ZHA (ones I know that won't work for what I'm about to mention: Osram/Sylvania/Lightify bulbs in the US and Sengled bulbs anywhere), you could probably get away with just using a Hue Bridge instead of a second Hubitat as well. In my experience, this works better for lights. It's a single-purpose system that does lighting very well and does a lot for you behind the scenes to make things work better, like automatically creating groups based on rooms/zones (Hubitat can do group messaging, but your luck my vary) and supporting "true" scenes (far more reliable in my experience than Hubitat's emulation where it just sends switch/level/color commands to individual bulbs), and Hubitat's built-in LAN integration is a lot easier to set up than HubConnect. I love both HubConnect and Hubitat and this is not a recommendation against either, just something to consider that might be easier (and better, in my opinion and experience) for this specific purpose if everything you have is supported.
1 Like
Thanks for the info. I’m just trying to figure out if it makes sense to go the command hub route before I get too much deeper into it. I’ve been having fun setting up my rooms to use the motion sensors and modes to handle the lighting. Just Rule Machine stuff right now. Only the exterior lights have a custom app as it was getting unwieldy in RM.
Unfortunately all the Zigbee bulbs are Sylvania so using the Hue hub is out. It is the original one they sold when they were exclusive to Apple so I’m not too invested in it these days.
The Sylvania bulbs have been rock solid for me for years - until I started to add all the Iris sensors. Now I’ve been getting some unhappy devices. I just got back from vacation and have a new issue - a couple of rules turn on the lights but don’t turn them off. It seems like they might be using different routes to/from the hub. /shrug I was already planning the new mesh before this. I just found the behavior interesting.
I went from 3 (2 radio + command hub) back to 2 when one of my hubs died. I don't really see any reason to go back to 3 in my setup.
Everything @bertabcd1234 says feels correct to me. I never owned any Hue or Zigbee bulbs, so the wisdom dispensed feels valuable. A third hub is useful as he suggests, for risky apps, risky device drivers.
If you are avoiding those apps and drivers, you will be ok with a simple split down protocol lines. You, like so many of us, have a lot invested in the devices. The cost of a third hub is small when you get that deep into this stuff. But there's no apparent urgency based on your description. Change your description, we'll have new opinions 
Edit: And @JasonJoel is correct too.. which just proves "there's no single correct way."
1 Like
And I have a 3rd hub heading my way, so I could change my mind. 
As a triple-hubber, I'm awaiting the day when only half of my house stops working. Hasn't happened yet, but at least I'll know what's wrong immediately.
As most of you know, I have 5 hubs at this time...
Let's pretend I never saw a sale and paid through the nose... $500
I have 52 ZWave devices on one Hub.
I have 29 ZWave devices and 21 Zigbee devices on a 2nd hub.
I have a box full of unused ZWave and Zigbee devices that I won't use.. let's estimate 16.
118 devices and now let's pretend I got all of those on an incredible sale... $25 each. Let's call it: $3000. All of my hubs together is 16%. Had I stayed at 3, my minimum, I'd save 6%.
Piffle I say
But the math only seems sensible IF one believes that Hubitat is the answer. Obviously I do.
1 Like
Hey, get that math outta here.
1 Like
That’s why I have 30 MiLight devices. They are GU10 RGBWW lamps and I got them direct from the manufacturer for $8 each. That’s still a hard deal to beat for GU10s. I already had several Sylvania recessed lights and now you can get the A19s for about $10. Since I was already invested in them it made more sense to standardize on one brand. That predates my Hubitat setup so I never saw any issues until I started adding more gear.
As for the cost of the hub, that wasn’t really a concern. If I’m rearchitecting the system I wanted to make sure I was being logical about it.
1 Like
Will the nodeJS based hubconnect server will be optional, and only used for websocket based connectoins?
Of course... The traditional http local, http cloud, and Websocket will still be available. This adds an additional option for those with a large number of devices and hubs as it acts as an event router and filter.
I hope to run this on my Synology NAS.
1 Like
I warm my pi up ready 
That's an excellent question...
As we talk up all that is new, there's a long list of all that is the same, that gets no mention. 
One of the many goals @srwhite has with HubConnect is to be as 'light' (efficient) on the hub as possible. The code is ultra optimized, and the introduction of HubConnect Server on an external NodeJS, takes that another step For Those That Need It.
I have 180 ZWave and Zigbee devices. It's not a small system, but compared to @srwhite and his 500 devices, mine isn't large. But mine is large enough to benefit from the use of HubConnect Server. The benefit is the offloading of the filtering that must occur.
This is precisely what I build the server component.. In my topology most of my devices flow inward to a central hub.. In otherwords, the server hub has a virtual copy of every device in each of my remote hubs, while my remote hubs only have a handful of devices shared back from the server hub.
The Hubitat websocket is very fast but it very, very inefficient... We learned recently that events are not deduplicated as they are in the event logs for each device... Second, event traffic on the server hub increases proportionately to each hub connected, thus increasing the number of events presented to each remote hub.
Consider this 3 hub scenario with hypothetical throughput.... (eps = events per second)
Server - 200 HubConnect Devices; 2 eps TX & 2 eps RX on the websocket.
Hub 1 - 100 Devices; 1 eps TX & 2 eps RX on the websocket.
Hub 2 - 100 Devices; 1 eps TX & 2 eps RX on the websocket.
Each remote hub is emitting 1 event-per-second. This means the server hub is receiving and parsing 2eps.. It also means it is emitting 2eps which each of the remote hubs has to receive and parse, regardless if they care about those events or not.
Add a 3rd hub in this scenario...
Server - 200 HubConnect Devices; 3 eps TX & 3 eps RX on the websocket.
Hub 1 - 100 Devices; 1 eps TX & 3 eps RX on the websocket.
Hub 2 - 100 Devices; 1 eps TX & 3 eps RX on the websocket.
Hub 3 - 100 Devices; 1 eps TX & 3 eps RX on the websocket.
So what is effectively happening is that even though you may be adding hubs to spread the load, you inadvertently add some amount of load tp all of your hubs by having to handle (i.e. parse) a lot of traffic for which they do not need to see. Eventually it can start to saturate the hubs ability to process events quickly which manifests itself in slow device updates.
The server has some basic statistical reporting that is made available to the remote hub device.
This is an average of events-per-second one of my remote hubs from the roughly the past 48-55 hours:
- proxyLoadRxPerSecond : 3.97 (events received from the server hub by the HubConnect server)
- proxyLoadTxPerSecond : 0.00 (events forwarded to the remote hub by the HubConnect server)
Essentially, my remote hub would normally be processing 4 eps, but with the filtering & deduplication, the number of actual events forwarded to the remote hub doesn't even register.
