[RELEASE] QolSys IQ Alarm Panel Drivers

This is a set of drivers for the QolSys IQ2, IQ2+ and IQ4 alarm panels.

Update: This driver works with the IQ4 panel, but you must be running firmware 4.1.0 or later. Also, if you want to arm/disarm through HE, you must leave six-digit codes enabled on the IQ4.

With these drivers you can:

  • Monitor the state of any device connected to your alarm system
  • Monitor the state of the alarm system itself
  • Arm and disarm the alarm system
  • Initiate an alarm condition
  • Change HE modes automatically when the alarm system mode changes

After installing and configuring the driver, you will see something like this in your devices page:

The parent device represents the alarm panel, and has attributes that reflect various states as well as commands to arm, disarm, etc. The parent device creates a child device for every alarm system sensor, which reflects the sensor's current state in one or more attributes.

The most commonly used alarm sensors such as door contacts, motion sensors, smoke and CO detectors, etc. are supported. However, I do not have every possible device that can be connected to the IQ panel, so your system may have a device that is unrecognized. If so, contact me and I'll add support for it.

These drivers provide access to the alarm system and its sensors only. Although the IQ panels have z-wave radios, z-wave devices are not exposed by the interface these drivers use.

Although the IQ panels are frequently used with an alarm.com account, these drivers do not use (or interfere with) any alarm.com services you may be using.

Prerequisites:

  • Your alarm panel must be running firmware 2.4.0 or later (see readme for instructions on how to upgrade the firmware)
  • You must have the dealer code for the alarm panel (not the same as the installer or user codes)
  • Your alarm panel must have wifi enabled, and its IP address must be reachable from your HE hub
  • Your HE hub must be running firmware 2.3.0.110 or later

Installation:

Installation instructions can be found here: Hubitat/README.md at main ยท dcaton/Hubitat (github.com)

Easiest way to install the drivers is via Hubitat Package Manager. In HPM click Install, then Search by Keywords, then search for "qolsys".

3 Likes

So far, no luck with the IQ4 Panel.

I was considering an IQ2 panel and pulled the trigger when I saw this driver existed so I want to thank you for developing it and making the instructions so straight forward. I had no problem following them to enable the C4 interface on the panel and have the driver connect to the panel.

1 Like

Can you elaborate? Does it not have the same options to enable the C4 interface? Does the driver not connect? What about the logs? Can't help without information.

Yeah. I should've been more clear. I followed directions, enabled everything required. My Hub simply wont connect. Logs say connection refused and I have no idea why... Both devices are on the same network. See this log snippet.

dev:602021-12-30 06:43:37.677 pm traceQolSys IQ Alarm Panel: uninstalled()

dev:602021-12-30 06:43:02.770 pm errorQolSys IQ Alarm Panel: 192.168.2.51 initialize error: Connection refused (Connection refused)

dev:602021-12-30 06:43:02.731 pm traceQolSys IQ Alarm Panel: attempting to connect to panel at 192.168.2.51...

dev:602021-12-30 06:43:02.716 pm traceQolSys IQ Alarm Panel: initialize()

dev:602021-12-30 06:42:02.695 pm errorQolSys IQ Alarm Panel: 192.168.2.51 initialize error: Connection refused (Connection refused)

dev:602021-12-30 06:42:02.687 pm traceQolSys IQ Alarm Panel: attempting to connect to panel at 192.168.2.51...

dev:602021-12-30 06:42:02.673 pm traceQolSys IQ Alarm Panel: initialize()

dev:182021-12-30 06:41:48.768 pm infoFamily Room Sonos audio is unmuted

dev:182021-12-30 06:41:48.764 pm infoFamily Room Sonos audio level is 32%

dev:182021-12-30 06:41:48.449 pm infoFamily Room Sonos is playing

dev:602021-12-30 06:41:02.655 pm errorQolSys IQ Alarm Panel: 192.168.2.51 initialize error: Connection refused (Connection refused)

dev:602021-12-30 06:41:02.581 pm traceQolSys IQ Alarm Panel: attempting to connect to panel at 192.168.2.51...

dev:602021-12-30 06:41:02.562 pm traceQolSys IQ Alarm Panel: initialize()

dev:602021-12-30 06:40:02.543 pm errorQolSys IQ Alarm Panel: 192.168.2.51 initialize error: Connection refused (Connection refused)

dev:602021-12-30 06:40:02.465 pm traceQolSys IQ Alarm Panel: attempting to connect to panel at 192.168.2.51...

dev:602021-12-30 06:40:02.451 pm traceQolSys IQ Alarm Panel: initialize()

dev:602021-12-30 06:39:02.433 pm errorQolSys IQ Alarm Panel: 192.168.2.51 initialize error: Connection refused (Connection refused)

dev:602021-12-30 06:39:02.386 pm traceQolSys IQ Alarm Panel: attempting to connect to panel at 192.168.2.51...

dev:602021-12-30 06:39:02.356 pm traceQolSys IQ Alarm Panel: initialize()

dev:602021-12-30 06:38:02.351 pm debugQolSys IQ Alarm Panel: sendCommand { "nonce": "", "action": "INFO", "info_type": "SUMMARY", "version": 1, "source": "C4", "token": "tvchjf"}

dev:602021-12-30 06:38:02.350 pm traceQolSys IQ Alarm Panel: refresh()

dev:602021-12-30 06:38:02.334 pm errorQolSys IQ Alarm Panel: 192.168.2.51 initialize error: Connection refused (Connection refused)

dev:602021-12-30 06:38:02.207 pm traceQolSys IQ Alarm Panel: attempting to connect to panel at 192.168.2.51...

dev:602021-12-30 06:38:02.188 pm traceQolSys IQ Alarm Panel: initialize()

dev:602021-12-30 06:38:02.186 pm traceQolSys IQ Alarm Panel: updated()

dev:602021-12-30 06:37:17.122 pm debugQolSys IQ Alarm Panel: sendCommand { "nonce": "", "action": "INFO", "info_type": "SUMMARY", "version": 1, "source": "C4", "token": "null"}

dev:602021-12-30 06:37:17.119 pm traceQolSys IQ Alarm Panel: refresh()

dev:602021-12-30 06:37:17.117 pm errorQolSys IQ Alarm Panel: IP Address of alarm panel not configured

dev:602021-12-30 06:37:17.079 pm traceQolSys IQ Alarm Panel: initialize()

dev:602021-12-30 06:37:17.078 pm traceQolSys IQ Alarm Panel: updated()

dev:602021-12-30 06:37:17.076 pm traceQolSys IQ Alarm Panel: installed()

Double check the IP address and the token value. Make sure you didn't enter a comma instead of a period in the IP address (I've done that more times than I'd care to admit). You're certain the C4 interface is enabled?

Next step would be to download and run curl for Windows. If you have a Linux box or container, you should already have curl or openssl, which works just as well.

Then at a command prompt run:

C:\Program Files\Curl\curl-7.80.0-win64-mingw\bin>curl -kN --http0.9 -v https://192.168.2.51:12345

Leave the command window open for a while, and you should eventually see event data coming back, after the initial ACK response: (or go open and close a door that has an alarm sensor)

C:\Program Files\Curl\curl-7.80.0-win64-mingw\bin>curl -kN --http0.9 -v https://10.0.2.9:12345
    *   Trying 10.0.2.9:12345...
    * Connected to 10.0.2.9 (10.0.2.9) port 12345 (#0)
    * ALPN, offering h2
    * ALPN, offering http/1.1
    * TLSv1.0 (OUT), TLS header, Certificate Status (22):
    * TLSv1.3 (OUT), TLS handshake, Client hello (1):
    * TLSv1.2 (IN), TLS header, Certificate Status (22):
    * TLSv1.3 (IN), TLS handshake, Server hello (2):
    * TLSv1.2 (IN), TLS header, Certificate Status (22):
    * TLSv1.2 (IN), TLS handshake, Certificate (11):
    * TLSv1.2 (IN), TLS header, Certificate Status (22):
    * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
    * TLSv1.2 (IN), TLS header, Certificate Status (22):
    * TLSv1.2 (IN), TLS handshake, Server finished (14):
    * TLSv1.2 (OUT), TLS header, Certificate Status (22):
    * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
    * TLSv1.2 (OUT), TLS header, Finished (20):
    * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
    * TLSv1.2 (OUT), TLS header, Certificate Status (22):
    * TLSv1.2 (OUT), TLS handshake, Finished (20):
    * TLSv1.2 (IN), TLS header, Finished (20):
    * TLSv1.2 (IN), TLS header, Certificate Status (22):
    * TLSv1.2 (IN), TLS handshake, Finished (20):
    * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
    * ALPN, server did not agree to a protocol
    * Server certificate:
    *  subject: C=IN; CN=qolsys
    *  start date: Apr  5 10:37:18 2017 GMT
    *  expire date: Apr  5 10:37:18 2018 GMT
    *  issuer: C=IN; CN=qolsys
    *  SSL certificate verify result: self-signed certificate (18), continuing anyway.
    * TLSv1.2 (OUT), TLS header, Supplemental data (23):
    > GET / HTTP/1.1
    > Host: 10.0.2.9:12345
    > User-Agent: curl/7.80.0
    > Accept: */*
    >
    * TLSv1.2 (IN), TLS header, Supplemental data (23):
    ACK
    * TLSv1.2 (IN), TLS header, Supplemental data (23):
    {"event":"ZONE_EVENT","zone_event_type":"ZONE_ACTIVE","version":1,"zone":{"status":"Open","zone_id":22},"requestID":"bccafc2c-5dde-42ed-b9d4-6a6c40297d5d"}
    * TLSv1.2 (IN), TLS header, Supplemental data (23):
    {"event":"ZONE_EVENT","zone_event_type":"ZONE_ACTIVE","version":1,"zone":{"status":"Closed","zone_id":22},"requestID":"b9e23b0f-aa70-460c-891d-a2cc2876b055"}
    ^C
    C:\Program Files\Curl\curl-7.80.0-win64-mingw\bin>

If you cannot connect via Curl, then the problem is not with the driver. Either the IP address is wrong or unreachable, or the C4 interface isn't enabled. If your router has a firewall, turn it off temporarily. If all else fails, you could try using a port scanner on the IP address of the panel to see what's open. Maybe they've changed the port number of the C4 interface, but I highly doubt they've removed the functionality altogether.

Looks like they changed the port to 9200. It's now the only open port and closes when I disable C4. I tried CURL and get this;
curl -kN --http0.9 -v https://192.168.2.51:9200

  • Trying 192.168.2.51...
  • TCP_NODELAY set
  • Connected to 192.168.2.51 (192.168.2.51) port 9200 (#0)
  • ALPN, offering h2
  • ALPN, offering http/1.1
  • successfully set certificate verify locations:
  • CAfile: /etc/ssl/cert.pem
    CApath: none
  • TLSv1.2 (OUT), TLS handshake, Client hello (1):
  • LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 192.168.2.51:9200
  • Closing connection 0
    curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 192.168.2.51:9200

Now on the hub I modified your code to use port 9200 instead of 12345. It now connects but also fails on the TLS handshake;
2022-01-01 10:31:41.536 pm errorQolSys IQ Alarm Panel: 192.168.2.51 initialize error: Remote host closed connection during handshake

dev:792022-01-01 10:31:36.355 pm traceQolSys IQ Alarm Panel: attempting to connect to panel at 192.168.2.51...

dev:792022-01-01 10:31:36.340 pm traceQolSys IQ Alarm Panel: initialize()

dev:792022-01-01 10:30:36.342 pm debugQolSys IQ Alarm Panel: sendCommand { "nonce": "", "action": "INFO", "info_type": "SUMMARY", "version": 1, "source": "C4", "token": "tvchjf"}

dev:792022-01-01 10:30:36.341 pm traceQolSys IQ Alarm Panel: refresh()

dev:792022-01-01 10:30:36.323 pm errorQolSys IQ Alarm Panel: 192.168.2.51 initialize error: Remote host closed connection during handshake

Strange that they changed the port, and obviously, something else as well. Maybe they're trying to keep people from reverse engineering the interface.

Far as the handshake error, I really have no idea. Encryption protocols are not my area of expertise. There are no options I can set on HE's socket other than to ignore certificate errors.

If you can successfully get it to connect using curl or openssl, then I could ask the Hubitat developers to add whatever is needed, but I really don't even know what encryption levels HE's secure socket implements.

There are a couple of other third-party integrations on the IQ panels, but AFAIK nobody has reverse engineered them.

Searched in the c4forums.com, found a couple of questions about integrating the IQ4 but no answers, unfortunately.

Edit
Just took a look in Control4 Driver Search and the only Qolsys driver is from 2019. Someone in the Home Assistant forum reverse engineered that, and that's the basis of my driver. It would seem that Control4 doesn't even support the IQ4 yet.

I suppose it's also possible that this is a bug in the IQ4 firmware. It's a fairly new panel and maybe there isn't anyone integrating it with C4 yet.

If you look at page 95 of this manual,

it appears that when C4 is turned on a token is given, and it appears it can be viewed as well. Adding the token to the script may be the only thing missing? I do not have a panel here to test with, but wondered if this hurdle had been met.

Thanks, but that's already covered in the setup for my drivers. The problem with the IQ4 seems to be some sort of SSL error just establishing a connection to the panel. The token is used when sending a command to the panel, but things can't get that far if a connection can't be established.

Either that, or there's an issue in the IQ4 firmware that needs to be fixed. I'm surprised the IQ4 is different than the IQ2+ in this regard.

I talked to a tech at Qolsys this afternoon. The Control4 integration is not complete in the current firmware release. He was not sure if it will be done in the next release, but he will let me know when it is.

1 Like

I should clarify we are talking about the Qolsys 4 panel.

Wow, I'm surprised you could get anyone to talk to you. Are you a professional alarm installer?

Also surprised the code is different in the IQ4.

Yes I am. There are some significant hardware changes in the IQ4 panel that could be affecting the code. Just glad to hear it is on the current to do features list.

I am also curious, since the panel has the ability to add multiple other vendor sensors, how those will respond with your current driver. Hope to be testing this soon.

What type of sensors were you thinking about? I have the IQ2+ at my home and a rental property. One location has the 433Mhz legacy radio and the other, the 345Mhz version. Both have a combination of older sensors plus PowerG sensors. I've got the normal door/window stuff, smokes, CO2, motions, glass breaks, water sensors, and a hardwire adapter, all of which are recognized by my drivers.

If a device isn't recognized, it will show up in the log file and it should be easy for me to add support for it.

Note that z-wave sensors are not exposed by this interface, unfortunately. Would be nice if they would add that at some point, Tamper and low battery alerts would be good as well. If you talk to them again, maybe you could suggest that.

I think you have it covered then. The 345Mhz radio covers 2GIG and Honeywell legacy sensors. The 433Mhz will cover the DSC legacy sensors. The Qolsys radio is 319.5Mhz and that covers interlogix/ITI sensors.

The hardwire adapter your using is it Honeywell 5800C2W or another Vendor like Resolution Products or Alula?

The 2GIG and Honeywell legacy sensors use a loop code 1-4 in addition to the zone information, This is how they report Alarms on different inputs 1-3, or a tamper signal 4

Do you have a Z-wave thermostat on your Qolsys? Can you set a high and/or low alarm temp setting? I would be interested to see if that alarm comes through the current interface. On Honeywell they treated them as zones typically 18x or 28x
.
I would need to find a list of the Control4 integrations. The group that made this integration may not have these requirements for battery level and tamper as part of the interface.

If I can get them to allow us to connect the HA as a remote ethernet keypad (IQ-Remote tablet interface, paired over local wifi), we will get all the information we require as well as Z-wave devices on the system, ability to arm/disarm by code, All tampers and low batteries. See link below

The hardwire adapter is a DSC PG9WLSHW8. At the rental property, the city required hard wired smoke and CO detectors, and I decided to go with this adapter and 24v smokes.

I have both the ADC-T2000 and ADC-T3000 z-wave thermostats, and yes, I have rules set up in the alarm.com interface to notify on high and low temp as well as high humidity, and also shut down the HVAC system if a smoke or CO detector trips. That's a function of the rules though, not the thermostats themselves. Those types of rules don't have the ability to trigger an alarm condition, so such an event wouldn't come across the C4 interface.

Far as I can tell, in the panel itself the security system is completely independent of the z-wave system. You can set some very basic automations, but any real integration between the security system and z-wave devices has to be done through the alarm.com interface, which of course requires you to subscribe to alarm.com automation.

I was aware of the IQ remote, but never really looked at it and just assumed it was a PowerG device. Since it's an ethernet device, it almost certainly has to be using an SSL/TLS connection I'd be really surprised if they gave out the API, let alone the certificates.

The C4 interface does allow you to arm and disarm by code, BTW.

So happy this exists! I did a lot of looking for how to integrate with the iqPanel and everything seemed to say it doesn't like being any sort of a secondary. Got this driver installed and all my sensors showing happily now.

Now for the problem. I have a thermostat and door lock synced with the iqPanel currently due to some of the automations around the smoke alarm (on fire it will auto kill the thermostat and unlock the door) but neither of those devices seem to be coming up in hubitat. The lock is a Kwikset888 (which I haven't been able to find drivers for yet) and the thermostat is the alarm dot com smart thermostat which I DO have the drivers added for.

Any thoughts on why all the sensors/smoke detectors hook in fine but the other devices don't?

The C4 interface on the IQ panel these drivers use does not expose any z-wave devices. That's in the readme, and also in the first post in this thread:

Unfortunately, that's just the way it works, at least for now. If you have C4 home automation you probably wouldn't be using any of the automation capabilities of the IQ panel anyhow.

I have the same setup as you (z-wave thermostats and door locks) in two houses with similar rules. You have two options. Leave them as is and control them via alarm.com rules, or unpair them from the IQ panel and pair them to HE.

The best option would be to pair HE as a secondary controller to the IQ panel, but that's flaky at best. At my house I was able to do that, and it mostly works (but I still let alarm.com rules control the door and thermostat), At our rental property, HE simply will not pair as a secondary controller. Same firmware on the HE and IQ panel as at home, but I've tried multiple times and it just doesn't pair. And using HE as a secondary z-wave controller just isn't high on the list for the HE developers, so I wouldn't expect this to change anytime soon, if ever.

What I started doing at the rental property is to have two z-wave networks, I unpaired some z-wave devices (lights, mostly) from the IQ panel and paired them with HE. This was for cases where I needed more control than the alarm.com rules provided, as well as to use z-wave devices that the IQ doesn't support. I'm not crazy about having some rules in HE and others in alarm.com, but neither system can do everything the other one can so at least for now, that's what worked for me.

BTW, if you're using alarm.com thermostats as I am, you probably want to leave them connected to the IQ panel. If you pair them to HE instead, there are settings that would be inaccessible, at least without a custom driver and someone reverse engineering the various settings specific to those thermostats.

I totally skipped over that (in both places!). Thanks for the thorough response and recommendations though! That's definitely how it currently is, 2 separate networks. The only non-standard thermostat feature I'm using right now is the auto-off on fire, which I'm thinking hubitat can probably replicate on "smoke detected" at the very least (there is a thermostat driver I grabbed but it won't let me post a link alarm-com-smart-thermostat.src/alarm-com-smart-thermostat.groovy on github. I'll also give the secondary controller a shot though because then it can just function through there, if you have a link to the steps on hand that would be great - if not I'll do some digging. Will take a look at the lock as well. As you mention, worst case it's 2 different rules in different places, but that's non-optimal for sure.