So let me know if I miss some of your questions, I’ll try to answer to everything 
Looking at your interactions documentation on GitHub, I’m assuming that you look for Status: “Open” and and “Closed” for the motion sensors too? […] So instead of using status i defined Zone Active as Open and Zone Update as Closed. This worked fine, except that the heartbeat also triggered an open event.
Yes, I check the actual status of the sensor reported by the events. ZONE_ACTIVE events are related to a change happening, while ZONE_UPDATE events seemed to be related to the regular heartbeat of the whole system that’s happening regularly to inform of the current status of sensors that haven’t changed recently, and inform they’re still around and working.
Is there a way to view or log the JSON from the panel with the Gateway integration? It’s been about a year since I looked at what’s coming in. I could pass you a sample.
Yes, you can set the AppDaemon flag for debug with log_level: DEBUG in your apps.yaml. This will automatically enable all the debug logs, which include whatever information is received from the panel itself, and the full path (panel → qolsysgw → mqtt event → qolsysgw → [whatever happens from that]). That will give you (and me from what you’ll share!) all the needed information to figure things out 
Assuming other people have motion sensors that work fine, I’m wondering what type are they? Z-wave?
Can’t talk for others, my motion sensors are PowerG.
PS is there an equivalent of “arm_away_exit_delay” for Arm Stay / Arm Home? I’d like to be able to adjust that timing as well.
Haven’t built it in as I didn’t realize this was something that was supported for arm stay also. I can add a new arm_stay_exit_delay parameter that would be use in such case. Created Add `arm_stay_exit_delay` parameter to change the delay to use when arming in stay / home mode · Issue #5 · XaF/qolsysgw · GitHub to track.
I’m noticing that the Gateway is reconnecting to the IQ panel every 65-70min. I have a feeling this is related to the motion sensor heartbeat.
A full reset might mean that some event received by the panel is not handled properly by qolsysgw. To avoid a full crash and a desync, qolsysgw would restart in such case so it resets the maintained state. With the DEBUG logs, we should be able to know more about this. That being said, even without the full debug logs, you should already be able to see what are the last events that trigger a full restart ?
