I believe panics are invoked as follows (not sure if all the fields are correct though).
ALARM_TYPE can be POLICE, FIRE or AUXILIARY:
{"partition_id":0,"action":"ALARM","alarm_type":"AUXILIARY","version":0,"nonce":"qolsys","source":"C4","version_key":1,"token":"foobar"}
Thatās exactly what I want, thank you so much!
I do not have any sensors besides the panel itself so Iām going to leverage itself as much as I can.
Thanks for the flow Andrew, tested it and it works great for arm_stay and disarm actions. However, arming away on either platform triggers the timeout one after the other:
I guess these can be circumvented by removing the exit countdowns on either platform, but Iām working on another flow which āsynchronizesā both alarm systems by acting on the āArmingā state as well as an instant āArmed_Awayā.
One thing I might do is to implement immediate arm_away on Alarmo when the IQP2 finishes its timeout, but honestly it really depends on how one wants to interact with the alarm. If the IQP2 is strictly a sensor aggregator/secondary panel hidden in a closet, weād want Alarmo to be the āsource of truthā. Otherwise, you have to be careful how exit/entry timeouts are dealt with. Iām in the process of figuring all that stuff out myself 
One example is that if one extends the exit timer through the IQP2 (by pressing the +60 button when arming), that information isnāt handled at the moment even though itās present in the ARMING message passed by the panel (timeout parameter). Thatās why the Control4 implementation works well; C4 always knows how long the alarming/exit timeout is.
Hmm I never alarm away using my IQPanel or Android tablets I have at other doors using Alarmo itās always an instant alarm away using Home Assist so I havenāt run into that. Will have to look into it more does Qolsys panel report a different state when arming but it armed yet? If so we could change it to arm alarmo at same time and count downs should only be off a second or two
The IQPanel2 reports the EXIT_DELAY as well as the timeout through the ARMING event message. If someone extends the Exit Delay through the touchscreen, it resends an ARMING event message with EXIT_DELAY with an updated timeout value.
Initial arming message in qolsys/panel/alarming:
{"event":"ARMING","arming_type":"EXIT_DELAY","delay":60,"partition_id":0,"version":1,"requestID":"..."}
Subsequent message after pressing +60 on the IQP2:
{"event":"ARMING","arming_type":"EXIT_DELAY","delay":107,"partition_id":0,"version":1,"requestID":"..."}
OK, so while rewrite my flow using MQTT topics as triggers and not Qolsys Panel topic I just realized Alarmo can be controlled by MQTT. I"m going to try that today. It looks like it may only read MQTT to control it may not report anything out. So I would still need node red to sync Qolsys Panel to AlarmO
Has there been any progress at solving the disconnect issue? My house sitter uses HomeKit to access my house, but when Appdaemon disconnects, it obviously breaks their ability to disarm my house before entering. It usually is good for 2 weeks before I have to restart AD. For now I use Nabu Casa and restart AD every few days while Iām away.
I know itās a shit workaround but I may just automate a restart every day until this is resolved.
My issue with disconnects was with my network where every evening my APs would scan and change frequencies. Once I turned that off itās been fairly stable unless AD restarts.
I got a second motion sensor and hooked it up yesterday. The new motion sensor is from Qolsys and the old one is from Interlogix.
The Qolsys motion sensor is acting the same as the Interlogix sensor. Both detect motion and send motion events to HA, but they also both send a heartbeat event every 60-70min to the panel, that register as a motion event in HA.
Is anyone using a motion sensor and not seeing the heartbeat motion events every 60-70min?
Really glad I found this integration - great work so far by all. Has anyone had the ad-qolsys AppDaemon show as terminated after a few hours? This has happened every time for me with nothing useful in the logs.
2021-12-19 19:55:52.016319 INFO Qolsys_IQ2: connecting to socket
2021-12-19 20:06:35.976071 DEBUG Qolsys_IQ2: data received from qolsys panel: {"event":"ZONE_EVENT","zone_event_type":"ZONE_ACTIVE","version":1,"zone":{"status":"Open","zone_id":2},"requestID":"707a1021-be12-4459-98cd-e69b561de56d"}
len(data): 155
2021-12-19 20:06:35.978692 INFO Qolsys_IQ2: publishing ZONE_EVENT event to: qolsys/zone_event
2021-12-19 20:06:35.980699 DEBUG Qolsys_IQ2: data being published: {"event":"ZONE_EVENT","zone_event_type":"ZONE_ACTIVE","version":1,"zone":{"status":"Open","zone_id":2},"requestID":"707a1021-be12-4459-98cd-e69b561de56d"}
2021-12-19 20:06:35.982147 DEBUG Qolsys_IQ2: call_service: mqtt/publish, {'namespace': 'mqtt', 'topic': 'qolsys/zone_event', 'payload': '{"event":"ZONE_EVENT","zone_event_type":"ZONE_ACTIVE","version":1,"zone":{"status":"Open","zone_id":2},"requestID":"707a1021-be12-4459-98cd-e69b561de56d"}\n'}
2021-12-19 20:06:35.986576 INFO Qolsys_IQ2: stopped listening on qolsys socket
Every time Iāve checked itās been after a ZONE_EVENT, but not 100% sure.
Based on code inspection of ad-qolsys/qolsys_socket.py at a8530182a436db771063444257c00ee1aabffd6e Ā· roopesh/ad-qolsys Ā· GitHub something is disconnecting or closing the socket, but I donāt see anything in the log that might suggest what. Any ideas are appreciated.
EDIT: I did find one potential causeā¦ I was using the version from July without the socket-reading fix from Ensure that parsable JSON is read from the socket by using a delimiter rather than assuming that messages are complete by Pablo1 Ā· Pull Request #20 Ā· roopesh/ad-qolsys (github.com) from @big.server. Will report back if this fixes my issue.
EDIT2: Seems to kind of work, but many connecting to socket hangs as folks have reported earlier in the thread - likely exacerbated by the number of times I am rebooting HASS. Panel reboots do seem to help, but not a sustainable solutuon. Considering going for an Alarm.com integration instead since all I really want is arm/disarmā¦
@k-d Iāve been experiencing the same issues. Like you observed, restarting AppDaemon seems to fix things until the next time it happens. Iāve been meaning to debug it and see what might be happening because itās unreasonable to depend on the integration if it isnāt rock solid.
@k-d Seems to happen pretty consistently after upgrading home assistant core. In every case I have to restart AppDaemon. Iām wondering if it has something to do with how the socket gets closed. Have you been able to reproduce the issue more consistently?
My the symptom of not having my fix for reading the responses is that you wonāt see any devices in Home Assistant. Not having my fix shouldnāt cause disconnects.
Hey there, community!
I lurked around that thread for a little while, and tried the GitHub - roopesh/ad-qolsys: AppDaemon app for Qolsys IQ Panel 2 repository, which worked a bit but not enough for my needs (including a number of times where my alarm control panel became unavailable in home assistant and I had to setup an automation to automatically restart appdaemon). So as I wanted to take advantage of those different ideas and build on top of them, but the structure available didnāt make me comfortable enough to make the relevant pull requests (or at least not in a way that would have made sense), I started my own automation for this.
You can find it at GitHub - XaF/qolsysgw: Qolsys IQ Panel 2+ gateway to an Home Assistant Alarm Control Panel (Qolsys Gateway) - Note Iām not saying itās better than roopeshās one, just that it fits more my needs, and both roopeshās automation and this community thread gave me the keys to get that version started, so I felt like it was only fair to share back my work if it can help others.
I also tried adding a bit more documentation in order to have traces of the different messages that can be sent to the panel or received from it, and I would definitely be grateful of any other insight you folks got on the commands that are not yet supported
Among others, Qolsys Gateway supports triggering the alarm from home assistant (I actually made a PR in home assistant to support this with MQTT), secure arming mode, and creates a device for the alarm control panel (you can configure multiple devices if using multiple panels by changing the device id). It also supports using a different user code in home assistant than whatās really being sent to the panel, if you want to make a distinction between the two (also allowing to use string passwords in home assistant vs the digit password for the panel), and tries not to send the usercode through MQTT if not necessary. You can also decide to make the automation unaware of any password, and have home assistant send it when an user types it.
Wow I will have to check that out! I was inspired by others to make qolsysad so iām glad you got the itch and improved on it even more! Is yours more stable i.e. less/no drops in connection? More resilient to HA restarts?
Hi allā¦ HA newbie here too. Glad that I found this thread and wondered what I can (or not) do in terms of integration with my Qolsys IQ Alarm Panel.
Panel pre-installed with bunch of sensors (both IR and door/windows) here which is not currently being subscribed to any monitoring service (service disconnected before we moved in).
Any chance that a panel not being monitored also integrate-able with HA?
@galant For sure. I donāt have mine monitored either. Itās a long thread, but youāll find everything you need in here!
Is yours more stable i.e. less/no drops in connection? More resilient to HA restarts?
So as far as my testing went (a single testing user which is me!) I didnāt experience drops in connection (actually realized that thereās a connection drop every 5 minutes if not kept active, so I built in a ākeep-aliveā mode to make sure we donāt reach that 5mn inactivity). For home assistant restarts, Iām using the approach of retaining the messages in MQTT and using the birth and will messages, so home assistant always has accurate information as far as I can tell. In my experience, that thing is pretty resilient so far! (been using it for a little while to make sure it was stable enough to share).
As long as thereās only a single instance of qolsysgw working with a Qolsys Panel, I havenāt experienced any issues where the sockets get stuck (except when playing around while developing and not dropping the connection properly). When having more than one instance, it can still happen (but then again, more than one instance for a single Qolsys Panel only happened when I was developping stuff on my test containers while having the āproductionā ones running also, which was not smart).
Side note: when the Qolsys Panel is in secure arm, if you send an ARM request without usercode, it justā¦ crashes 
- I did crash mine a few times while working on the feature to only send the usercode when necessary, to avoid transmitting codes when not needed.
Of course, since my testing pool is only me so far, I welcome any feedback and issues that people can identify, and ideally things I can reproduce to get fixed! I also couldnāt write clear code for sensors I donāt have, nor play around with commands I didnāt have the chance to capture, so Iām all happy to get information about those stuff 
Youāve got another tester!!
crazeeeyez has done a great job, I wish I had a clue how to help solve the timeout problems - but I love that you both are eager to work together.
Thank you both for these awesome integrations.
Has anyone gotten an IQ Panel 4 to work? Mine refuses to accept connections on port 12345. Iāve used the Dealer code to go to 3rd Party Connections and enabled the Control4 checkbox. Iāve also set 6 digit user codes required (and rebooted separately), in case the 4.0.1 build was branched from 2.6.2 (no dialog warning me that 6 digits was required, though). Is there anything else Iāve missed?
Version 4.0.1, build 20211004_b9.
You donāt happen to have a motion sensor connected to your panel? Have you figured out a way to distinguish a motion event from a heartbeat event that occurs every ~70min?