Sorry for the delayed response. I honestly don't remember, I'll have to take a look. I've been tied up with the purchase of a new house and a long drawn out moving process. It should be over in a few weeks.
On the bright side, I have a shiny new IQ4 panel in the new house to play with. Soon as I have a chance to come up for air I'll finalize a new release.
Passing along in case this helps anyone else. I just installed a Qolsys IQ4 panel (purchased via Surety) and was having some issues properly triggering events in Hubitat when the alarm was tripped.
After looking at my Hubitat logs, when the alarm was tripped on my panel, the Alarm_Mode_Partition_0 attribute was reporting an enum value that I was not expecting: ALARM_
I'm not sure why it is reporting this way, as I was expecting it to report ALARM_POLICE. I am self-monitoring the panel, so maybe that is part of the reason, I'm not sure. Essentially, it seems that the panel is not reporting the payload.alarm_type back to Hubitat, causing it not to properly append 'POLICE' to ALARM_
Either way, to get around this, I modified the driver to include an additional enum value for the Alarm_Mode_Partition_0 attribute, and I can now properly trigger events in Hubitat based on the new ALARM_ enum value I added. While I unfortunately cannot differentiate based on POLICE, FIRE, etc. with this method, it is at least usable for the time being.
Portion of the drive I modified for clarity (Line: 43):
attribute 'Alarm_Mode_Partition_0', 'enum', ['DISARM', 'ENTRY_DELAY', 'EXIT_DELAY', 'ARM_STAY', 'ARM_AWAY', 'ALARM_POLICE', 'ALARM_FIRE', 'ALARM_AUXILIARY', 'ALARM_']
If anyone has any idea why I seem to be missing the proper payload.alarm_type, it would be much appreciated!
So payload.alarm_type is an empty string in the data coming from the alarm panel? Could be because you don't have an alarm.com account associated with your panel. Honestly, I haven't done much testing with the IQ4 because everything just seemed to work ok. My system is monitored though.
Do you only have intrusion detectors, or do you have any smoke or heat detectors (which should send ALARM_FIRE)?
Yep, based on the logs when I was testing, it looks to be returning an empty string:
logInfo("Alarm event received: ${payload.alarm_type}")
dev:112023-04-16 05:02:00.930 PMinfoQolSys IQ Alarm Panel: Alarm event received:
dev:112023-04-16 05:02:00.860 PMinfoQolSys IQ Alarm Panel: Zone active received: 4, Open
dev:112023-04-16 05:01:44.913 PMinfoQolSys IQ Alarm Panel: Arming event received: ARM_STAY
dev:112023-04-16 04:59:53.447 PMinfoQolSys IQ Alarm Panel: Zone active received: 4, Closed
dev:112023-04-16 04:59:29.436 PMinfoQolSys IQ Alarm Panel: Arming event received: DISARM
dev:112023-04-16 04:59:25.518 PMinfoQolSys IQ Alarm Panel: Alarm event received:
I currently only have intrusion detectors (PowerG PG9303), so I am unable to test a fire scenario.
Having come from a 2gig alarm system to Qolsys integration with Hubitat is one of the best kept secrets/awesome capabilities in home automation/alarm systems... Just being able to now use old 345MhZ sensors in hubitat because of the integration helps unify everything! Really appreciative of the work that has gone in on this driver!
Just to follow this up, yes HomeKit knows how to deal with both (I have several coming in via HomeBridge), but the official HomeKit integration isn't allowed to interface devices that (in Apple's opinion) should be directly in HomeKit. This means most devices connected to HE by wifi or "virtual" devices like this aren't supported as long as HE wants the integration to be official with Apple's seal of approval.
On another note, I've been using this for the past day (just switched alarm providers) and I'm noticing this about once an hour.
A whole rash (like a few hundred over a few seconds) of these:
dev:2640 2023-05-10 14:58:04.671 error QolSys IQ Alarm Panel: socketStatus: receive error: Connection has closed: javax.net.ssl.SSLException: Connection reset
followed by one of these:
dev:2640 2023-05-10 14:58:18.027 error QolSys IQ Alarm Panel: socketStatus: send error: Connection or outbound has closed
then, a while later:
dev:2640 2023-05-10 15:15:21.953 error QolSys IQ Alarm Panel: no messages received in 17.9 minutes, reconnecting...
and everything works for a while.
I have a feeling that the comments above about sending a CR every 25 seconds would help, but it isn't clear where that should be added.
Any thoughts?
I really need to revisit the whole socket timeout mechanism. When I first wrote this driver, sometimes the alarm panel would just stop responding, and I implemented something that would reconnect after a certain period of inactivity to deal with that. Not sure if it was something corrected in a firmware update of the alarm system, but the interface I'm using isn't publicly documented.
I'll take a look at it soon as I get a bit of time. I'm in the final stages of moving, which is a major PITA. On the positive side though, I have a new IQ4 panel at the new house to test with.
I know the feeling. When we moved into this house 5 years ago, we swore it would be our forever home because of how much we hate moving. LOL
If there's anything I can help with, let me know. I've got an IQ4 with fairly new firmware (4.2.1, IIRC).
I did run into a few issues yesterday when I was setting it up... it seemed to get rate limited, but a panel reboot fixed it each time.
Also, when I arm via this app, it successfully arms the panel, but the panel doesn't seem to bother telling ADC about that -- my app and online interfaces show it as disarmed. I haven't played with it enough to see if it was just a timing thing (I had other family in the house and couldn't trust them to not play with doors, etc.), but I did give it a solid 60 seconds on at least one try and it didn't change. I don't think this is an error with the app, just with how the panel handles instructions from it.
I have the same behavior. What's odd is that disarms are instantaneous but arms can be delayed up to a few minutes. I just setup a notification rule in Hubitat to push when the alarms changes state locally. That is instantaneous.
One of the items I changed in the PR I submitted handles this. Its doing a keepalive to keep the socket open. Has worked flawlessly for me for several months now.
Thanks. I'll take a look as soon as I can.
It looks like I'm already running your version of the driver... and I'm getting that same issue above.
I shortened the connection check timeout from 10 min to 5 min just now. Will see if that improves anything, too.
I'm also going to see if I can add some extra error handling line ~258-271 to catch my error and re-initialize, because that seems to resolve it. In looking at that code, this may just be a new message for the "String index out of range" error that was already being caught as it seems to repeat with similar frequency.
This is the change that my PR implements.
Yeah, turns out I already had that in place from having downloaded the changed file by a reference earlier. 
I had to fix line 143.
Whoops. Not sure how that happened.
Added the error handling to prevent the hundreds of messages, then noted that each time the one occurs (before getting re-initialized), there's this error:
dev:2640 2023-05-11 07:38:29.463 error QolSys IQ Alarm Panel: socketStatus: receive error: Connection reset
Just thought I'd share that in case it helps diagnose anything.
Does anyone know if it's possible to add the ability to disable the entry delay for the "Arm Stay" mode? I can do it from the panel itself, or from a standard keypad, but it doesn't look like there's any way to get Hubitat to do this for me.
When I checked the app logs after doing an instant arm stay from a keypad, Hubitat had received this block from the panel which looks basically like the standard Arm Stay log messages:
dev:946 2023-06-20 09:56:03.768 debug QolSys IQ Alarm Panel: Event: Alarm_Mode_Partition_0 = ARM_STAY
dev:946 2023-06-20 09:56:03.766 info QolSys IQ Alarm Panel: Arming event received: ARM_STAY
dev:946 2023-06-20 09:56:03.765 debug QolSys IQ Alarm Panel: json: [event:ARMING, arming_type:ARM_STAY, partition_id:0, version:1, requestID:260fc3ac-0836-4c8a-b26a-8c08d0023468]
dev:946 2023-06-20 09:56:03.763 debug QolSys IQ Alarm Panel: parse() received 124 bytes : '{"event":"ARMING","arming_type":"ARM_STAY","partition_id":0,"version":1,"requestID":"260fc3ac-0836-4c8a-b26a-8c08d0023468"}
The code is passing delay:0 for ARM_STAY mode so it should be doing what you want. I've never seen a delay in arm stay mode when I arm at the panel; not sure what purpose a delay would serve if you're not exiting. But I'm away for the summer and don't have access to an IQ panel to play with.
Sometimes you want to arm "stay" but leave... Basically just bypassing motions so either someone who is asleep can wake up and not set it off, or if there are issues with false alerts (some balloons seem to set off our motions, for example), you can still arm but leave.
Ok, makes sense. In any case, the driver should be setting the delay to 0 when setting arm stay mode. At least, that's what the code seems to be doing.
Unfortunately, I'm away for the summer and won't have an opportunity to test with my panel for a while.
Download the Hubitat app
