That's not a function of the thermostat, it's just a rule in alarm.com. I was thinking more about min/max setpoints, setting the anticipator values, etc.
You can't see many of those settings in the alarm.com interface but going into developer mode in a browser and removing a css class on two elements reveals two additional tabs of settings that are normally only shown to installer-level accounts. This is with the ADC-T2000 and 3000 thermostats, BTW.
Yes, you could replicate the hvac off and similar rules on HE by watching for the Alarm_Mode_Partition_0 attribute to change to ALARM_FIRE. The only problem with that is that it depends on having a connection between the panel and HE. Your weakest link here is your wifi network and router, so if you go this route you should have a UPS on your router and try to make your wifi network as reliable as possible. I don't think the IQ panel has a wired ethernet interface.
In contrast, if these rules are in alarm.com they execute locally on the IQ panel so the only possible weak link is the IQ's z-wave network. My approach is to keep everything related to life and property-safety on the IQ panel. Convenience things like automating lights, etc. are less important and I'm ok with those things being on HE and using my drivers to get alarm sensor events.
I see those extra tabs now, super nice find! No need tweaking imo, but having truly full control over the system is always a great thing.
All great points, thanks for the insight. I will likely just maintain them being managed separately - I have a mesh WiFi network and the main router as well as the hubitat are indeed on a UPS, but it's a good point of life+security all being maintained completely on the same hub makes sense. Door lock of all things is probably the most minor, thermostat is just a convenience thing really - will have to rely on the IQ Panel rules & Google Home routines for that one instead of hubitat then.
Seems to me that the panel does not have an open socket at port 12345. You made sure the C4 option was turned on in the panel settings, right? If so then either they changed the port or it's not implemented in that version of the firmware.
Another user here with IQ 4 panel that was recently installed. Updated to latest firmware and have the same issue with not being able to access. With the default port "12345" I get the error:
It would seem so. Unfortunately, Qolsys does not provide any public information on the C4 interface, or any other external interface that may exist for that matter (some of the settings imply that other 3rd party integrations exist).
In any case I do not have a IQ4 panel and unless one of my IQ2 panels goes south I don't have any need to purchase one. Although I'm not sure how much good that would do anyhow. At least, not until there was some indication from Qolsys that the C4 interface was functional.
Well... dohhhh.... ... I was NOT running 4.1.0! I did software update and I was "current" but I did not realize that 4.1.0 needs to be patched manually. I just did the update to 4.1.0 and it seems to be working! I am getting current status in HE and no connection errors. I do get an error when I try to arm/disarm panel in HE though:
Error_Partition_0 : usercode: Please Enable Six Digit User Code or KeyPad is already Locked
I am assuming I need to change back to 6 digits user code format again and leave it there?
Qolsys seems to have stopped pushing out automatic updates. I had to manually apply the last several to both of my IQ2+ panels.
6-digit user codes had to be enabled before you could enable the C4 interface, but you were able to turn that back off and the C4 interface still worked. Apparently that wasn't intentional and no longer allowed. If you want to arm/disarm via HE, I guess you'll have to leave 6-digit codes enabled. If you just want sensor status, it may not be necessary.
I think they've done the same thing with the IQ2, but I'm not going to upgrade the firmware on mine any further unless I have no choice, as I don't want 6-digit codes.
Is everything else working correctly? All the alarm sensors were recognized?
Yes! After re-enabling the 6 digit code in settings I can now arm/disarm the system via HE device controls. Can't get my mounted tablet to work yet via Maker API calls, but I will look into it later.
I do not have any sensors added yet, this was a builder installed new panel and I declined to sign up for ADT (which they were pushing) so I am waiting for them to de-activate my Alarm.com account that they created and free up the IMEI of the panel so I can connect it through another provider. I would like to reuse my existing hardwired sensors from existing alarm system so I have QS7121-840 hardwired to wireless board on order which should arrive soon and I can add my existing sensors. Will update as soon as I get it all configured. Thank you so much for developing this and helping out with questions.
If you can make do with 8 hard wired inputs, you might want to consider the PG9WLSHW8. It's a larger box but has room for a backup battery, and it also uses PowerG for the wireless connection which is more secure and robust. It can also handle hard wired smoke and CO detectors.
I dont have a disarm action under run custom action thats why I asked. I was expecting something but it doesnt seem to appear. I've enabled the ability for HE to do it and it works fine from the device itself but I can't find that action
It's not very intuitive. You have to select a "capability" first. In this case, select "Actuator". Then click Select Actuators to act on. Choose your alarm panel device, then you'll get a list of commands.
If you don't know a driver's capabilities, look in the code. In this case, if you look at the code for the "QolSys IQ Alarm Panel" in Drivers, on lines 34-36 you'll see some "capability" statements. They're the "capabilities" of the device the driver represents. It's not always intuitative, for example, why would an alarm panel have an "actuator" capability? The reason is that it's the closest defined capability that fits. Capabilities are defined by the platform, so a driver author sometimes has to choose what is the closest set of capabilities that the device offers.
The capabilities supported by the platform are listed here: Driver Capability List - Hubitat Documentation, with little documentation although most are self-evident. There's no "alarm system" capability, unfortunately. "actuator" has no defined attributes or commands, so it can be used as a sort of miscellaneous capability when there's nothing more specific that's appropriate.
... I was NOT running 4.1.0! I did software update and I was "current" but I did not realize that 4.1.0 needs to be patched manually. I just did the update to 4.1.0 and it seems to be working! I am getting current status in HE and no connection errors. I do get an error when I try to arm/disarm panel in HE though:
