I’m right there with you @absentspace and @jtharveyjr. Been an Alarm.com customer for 12 years now and have been along for the journey through their automation from x10 to zwave from a simon 3 panel to a Qolsys IQ panel. The biggest advantage of keeping the Qolsys panel in the loop is the ability to use existing non-zwave security sensors to interact with z-wave devices for automation rather than duplicating z-wave or zigbee sensors where sensors exist already for security purposes. The qolsys panel is for the most part a much better security device in terms of cellular backup, central monitoring and other true security features that adhere to recognized security standards. That said, while the automation features have greatly expanded in recent iterations of the website and app, the actual hardware support on the panel is still very limited in comparison to ST hub and the likes.
I personally think the best move for Alarm.com is to offer cloud-to-cloud integration with systems like SmartThings so that the sensor activity could be exposed to SmartThings to use for automation without the need for a local z-wave controller on the panel. It’s nearly the way it works in their own system from what I understand since not all of the automation happens locally on the panel. Alarm.com is already supporting certain devices like Lutron RadioRa lights and Chamberlain MyQ garage openers in a cloud-to-cloud scenario.
I too received a ST hub for Christmas and I’ve been determined to make the hardware level integration work. I’ve had limited success using the ST hub as primary controller and the Qolsys as secondary (available in firmware 1.6.1 and later however I’m running and recommend 1.6.2). In primary testing with a couple devices, all seemed good and the inclusion went smoothly. The ST hub showed up as an unknown device on the Qolsys and the Qolsys showed up as a generic controller in ST. Things got worse when I learned my entire network of devices of varying brand and age into ST Hub and then attempted to use the “Add controller” function on the Qolsys (exposed when you uncheck the Make Primary Controller box in the Qolsys settings). Firstly, the ST hub crashes after it sends a device list payload to the Qolsys panel and reboots itself. When this happens, the Qolsys panel isn’t learned into the ST hub device list but if I unplug the ST hub after it initially crashes, most of the devices load “successfully” into the Qolsys panel even with the ST hub unplugged. It seems the ST crash happens after it’s trying to acknowledge something back from Qolsys is my guess, it’s already sent it’s device list and Qolsys is able to chug through adding them one at a time, chiming after each device is added. I don’t get my older schlage BE369 lock to show up in the Qolsys even though it was successfully added as a device (with limited functionality) previously and it works with full functionality on ST using the native DH.
The biggest issue I’ve encountered is that Qolsys isn’t as aware of the z-wave states of devices as ST hub is. I can control devices form the Alarm.com app for most functions (lights on/off, locks lock/unlock). I’m not able to send user codes to the Yale locks in my system nor can I see status changes from the locks or lights when initiated from ST. More testing is required because I swear on initial attempts to load the devices into the Qolsys panel from ST the devices had full communication with both systems but I tried relearning the devices so many times it’s hard to say at this point.
Much of the automation that’s initiated from Alarm.com works, lights turn on when motion is sensed, locks lock when panel is armed as I’ve setup rules for these actions. I just don’t think automation attempts from ST will be recognized by the Qolsys/ADC app.
Anyway, long winded I know but that’s as far as I’ve got. I’ve spoken to Qolsys and ST support and both of them throw their hands up essentially saying they (Qolsys) don’t support using the Qolsys as a secondary controller or they (SmartThings) don’t support using a secondary controller with the ST hub. This seems very silly to me for systems purporting to adhere to the z-wave standards which HAVE provisions for a primary/secondary controller scheme. What I don’t know is how these standards vary when you are talking about the difference between a controller classified as a static controller vs a portable controller (I’ve found over the years that portable controllers support the primary/secondary scheme generally pretty well).