IQ motion sensor does not show up as "triggered" in HomeKit

[MistyMoose]

Dealer (not installer) access is needed to enable control4, but everything works as expected and with no latency!

[MistyMoose]

Update: Arm/Disarm and contact sensors continue to function well. Unfortunately haven't been able to get motion sensors to work correctly...

[EHylands]

Hi, tank you for reporting your experience on IQ4 panel !

Have you tried running Homebridge in debug mode with "show qolsys panel debug information enabled" ?

Do you see your motion sensor in log file initial panel information?

Do you see any log file activity when your motion sensor gets triggered?

[MistyMoose]

Hi Eric,

Thank you for reaching out. It's interesting! In the log (for a sample detector) I can see: [3/19/2023, 2:43:37 PM] [homebridge-qolsys] Zone4(Office Motion Detector): OPEN [3/19/2023, 2:43:37 PM] [homebridge-qolsys] Zone4(Office Motion Detector): CLOSED

When looking at the accessories tab on homebridge, intermittently, I can see the motion detector triggered, but only for a fraction of a second. I'm guessing this isn't nearly long enough for it to get into HomeKit.

[MistyMoose]

I have the regular IQ motion detectors.

[EHylands]

Can you see the motion sensor accessory in Homekit ? Should be at the top of the room were your Homebridge hub is configured at first.

[EHylands]

Homebridge plugin is using local pushed notifications from the panel. If Homebridge sees the accessory status change, information is available to Homekit.

Try configuring Motion sensor accessory activity notification setting in Homekit to get a pop up every time the sensor is triggered (for testing purpose)

My test Homebridge server runs on wifi and my Unifi wifi network doesn't play nice with mdns traffic sometimes. I get delayed notifications in Homekit. Absolutely no problem on my daily wired Homebridge server though.

[MistyMoose]

I do see the motion sensor in HomeKit. I will try the activity notifications and report back. My homebridge server is wired in.

On the HomeBridge dashboard, the motion is truly only triggered for a fraction of a second, so it kind of makes sense that it doesn't make it to HomeKit potentially? I'll try the notifications though.

[EHylands]

I just looked at the IQ motion sensor installation guide. Looks like it is the normal behaviour to instantaneously resort back to a closed status once the initial motion event has been detected. There are no user configuration option in that regard.

Homebridge and Homekit are event driven. You may not see your accessory changing state for a long duration in Home app, but any configured automation should be fired.

[MistyMoose]

Tried enabling HomeKit notifications and not getting any. Will try an automation. Are the powerG sensors any different/better?Sent from my iPhoneOn Mar 19, 2023, at 15:29, Eric Hylands @.***> wrote: I just looked at the IQ motion sensor installation guide. Looks like it is the normal behaviour to instantaneously resort back to a closed status once the initial motion event has been detected. There are no user configuration option in that regard. Homebridge and Homekit are event driven. You may not see your accessory changing state for a long duration in Home app, but any configured automation should be fired.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[EHylands]

Unfortunately not using a Qolsys panel myself. I've read PowerG sensor would provide better range coverage. We should get IQ motion sensor to provide notifications as intended.

If you can't get automations to trigger, I will release a beta version introducing a small delay before the motion sensor returns to a closed status.

[MistyMoose]

Thank you very much. Tried automations and they DO work, but unfortunately notifications don't. I think it would be very helpful to have a delay long enough to get a HomeKit notification (e.g send motion notifications when no one is home).

Either way, very much appreciate your help troubleshooting this!

[EHylands]

On further reading, instantaneously reverting back to a closed state may be expected with IQ motion to preserve battery. Sensor will report 2 motion events 4 seconds appart and enter a sleep mode for 5 min afterward.

Wrote to other user and waiting for their reply to see if same delays apply to PowerG and DSC sensors

[EHylands]

Thank you very much. Tried automations and they DO work, but unfortunately notifications don't. I think it would be very helpful to have a delay long enough to get a HomeKit notification (e.g send motion notifications when no one is home).

Either way, very much appreciate your help troubleshooting this!

I don't know how familiar you are with Homekit security system accessory yet, but if an intruder was to trigger your motion sensor while away, the Security Panel accessory would enter a triggered stated and a critical notification bypassing do not disturb mode on your phone would be sent !

You may create automations to be called if the security system is triggered.

[EHylands]

@LolNotACop : Created 0.2.1 beta relase introducing a 2sec delay for the motion sensor to go from an open to close state.

You can install in pugin config page by selecting install alternate version.

[MistyMoose]

The beta works incredibly well! Consistently getting notifications and the device status is accurate in the home app. Thank you very much!

[EHylands]

The beta works incredibly well! Consistently getting notifications and the device status is accurate in the home app. Thank you very much!

Great news ! That was mostly a proof of concept aimed toward motion sensors.

The same situation may happen to any other sensor type that fire almost simultaneously the open and closed state (leak, smoke, co, glassbreak ?).

Will try to write an optional routine that would delay a second detected event by 1 sec if an initial event was fired by the same accessory in the previous 1 sec. (Only delay fast and simultaneous status changes while allowing instantaneous status change to Homekit if accessory has been in the same state for more than 1 sec)

Will update this message when new beta version is available!

[MistyMoose]

Sounds great! Is there a way to make the smoke, glassbreak, and leak notifications be "critical" in homekit, regardless of the armin state? (perhaps this is already the case? Similar to the panel alarm).

On Mon, Mar 20, 2023 at 10:12 PM Eric Hylands @.***> wrote:

The beta works incredibly well! Consistently getting notifications and the device status is accurate in the home app. Thank you very much!

Great news ! That was mostly a proof on concept aimed toward motion sensors.

The same situation may happen to any other sensor type that fire almost simultaneously the open and closed state (leak, smoke, co, glassbreak).

Will try to write an optional routine that would delay a second detected event by 1 sec if an initial event was fired by the same accessory in the previous 1 sec. (Only delay fast and simultaneous status changes while allowing instantaneous status change to Homekit if accessory has been in the same state for more than 1 sec)

Will update this message when new beta version is available!

— Reply to this email directly, view it on GitHub https://github.com/EHylands/homebridge-qolsys/issues/13#issuecomment-1477184657, or unsubscribe https://github.com/notifications/unsubscribe-auth/A6RNOAPLH5E7D5CIOTQACHTW5EFBTANCNFSM6AAAAAAV57TDOE . You are receiving this because you were mentioned.Message ID: @.***>

[EHylands]

Sounds great! Is there a way to make the smoke, glassbreak, and leak notifications be "critical" in homekit, regardless of the armin state? (perhaps this is already the case? Similar to the panel alarm).

On Mon, Mar 20, 2023 at 10:12 PM Eric Hylands @.***> wrote:

The beta works incredibly well! Consistently getting notifications and the device status is accurate in the home app. Thank you very much!

Great news ! That was mostly a proof on concept aimed toward motion sensors.

The same situation may happen to any other sensor type that fire almost simultaneously the open and closed state (leak, smoke, co, glassbreak).

Will try to write an optional routine that would delay a second detected event by 1 sec if an initial event was fired by the same accessory in the previous 1 sec. (Only delay fast and simultaneous status changes while allowing instantaneous status change to Homekit if accessory has been in the same state for more than 1 sec)

Will update this message when new beta version is available!

— Reply to this email directly, view it on GitHub https://github.com/EHylands/homebridge-qolsys/issues/13#issuecomment-1477184657, or unsubscribe https://github.com/notifications/unsubscribe-auth/A6RNOAPLH5E7D5CIOTQACHTW5EFBTANCNFSM6AAAAAAV57TDOE . You are receiving this because you were mentioned.Message ID: @.***>

Smoke, CO, Leak and Security system entering a triggered state will emit a critical notification by default. This is not user configurable.

Glass break sensors are not an available accessory type in Homekit. They are represented through a contact sensor with this plugin. I have not find a way for a contact sensor or motion sensor to send critical notifications. It's not user configurable and I haven't found a way to programmatically make that change in the plugin code.

I think it is best to make all necessary configurations on your Qolsys panel (by example: will a glassbreak sensor only trigger an alarm when system is armed or instant 24/24 without any regard to panel arming status) and base your critical Homekit automations on the security system accessory triggered state.

[EHylands]

Sounds great! Is there a way to make the smoke, glassbreak, and leak notifications be "critical" in homekit, regardless of the armin state? (perhaps this is already the case? Similar to the panel alarm).

On Mon, Mar 20, 2023 at 10:12 PM Eric Hylands @.***> wrote:

The beta works incredibly well! Consistently getting notifications and the device status is accurate in the home app. Thank you very much!

Great news ! That was mostly a proof on concept aimed toward motion sensors.

The same situation may happen to any other sensor type that fire almost simultaneously the open and closed state (leak, smoke, co, glassbreak).

Will try to write an optional routine that would delay a second detected event by 1 sec if an initial event was fired by the same accessory in the previous 1 sec. (Only delay fast and simultaneous status changes while allowing instantaneous status change to Homekit if accessory has been in the same state for more than 1 sec)

Will update this message when new beta version is available!

— Reply to this email directly, view it on GitHub https://github.com/EHylands/homebridge-qolsys/issues/13#issuecomment-1477184657, or unsubscribe https://github.com/notifications/unsubscribe-auth/A6RNOAPLH5E7D5CIOTQACHTW5EFBTANCNFSM6AAAAAAV57TDOE . You are receiving this because you were mentioned.Message ID: @.***>

Homekit sensor accessories are not aware of your panel arming status.

Homekit Smoke, CO, Leak sensors will always send a critical notification if triggered even if you panel is not in a armed state.

[EHylands]

@MistyMoose Just released beta version 0.2.2 with generic sensor delay introduction if needed by plugin.

If enabled in config file, plugin will detect any time a sensor tries to switch state twice < 1 sec and introduce a 1 sec delay before sending 2nd event to Homekit.

Experimental option can be enabled in log file: "Sensor minimum trigger duration"

Would you be able to report if everything is still working as expected ?

Tnx !

[MistyMoose]

Just gave it a test. I can't visually see the sensor triggered in HomeKit on V2.2. Reverted back to V2.1 and could see it. The debug console remains accurate. Either way. Automations work with both versions.

[EHylands]

@MistyMoose , I still don't own sensor for my devel Qolsys panel so can't test myself yet.

Made small fix in 0.2.3 and added debug info in log file to see when delay is applied or not.

[MistyMoose]

Happy to help! 0.2.3 works well. Seeing the senior triggered in HomeKit and notifications/automations working as expected.

[EHylands]

Happy to help! 0.2.3 works well. Seeing the senior triggered in HomeKit and notifications/automations working as expected.

Thank you for testing this out ! Will draft an official release.

[MistyMoose]

I think I've found an interesting bug. With the panel in armed stay mode, if an attempt is made to disarm it using the panel (i.e by physically entering the code), a notification is sent to homekit that "panel was armed for AWAY mode" prior to receiving the "panel was disarmed" notification.

Looking at the homebridge debug:

[3/25/2023, 3:28:18 PM] [homebridge-qolsys] Partition0(IQ Hub): ARM_STAY [3/25/2023, 3:28:20 PM] [homebridge-qolsys] Partition0(IQ Hub): ENTRY_DELAY [3/25/2023, 3:28:23 PM] [homebridge-qolsys] Partition0(IQ Hub): DISARM

It looks to me like the "entry_delay" is being interpreted as "armed away" by Homekit. Any idea why?

Thank you

[EHylands]

I think I've found an interesting bug. With the panel in armed stay mode, if an attempt is made to disarm it using the panel (i.e by physically entering the code), a notification is sent to homekit that "panel was armed for AWAY mode" prior to receiving the "panel was disarmed" notification.

Looking at the homebridge debug:

[3/25/2023, 3:28:18 PM] [homebridge-qolsys] Partition0(IQ Hub): ARM_STAY [3/25/2023, 3:28:20 PM] [homebridge-qolsys] Partition0(IQ Hub): ENTRY_DELAY [3/25/2023, 3:28:23 PM] [homebridge-qolsys] Partition0(IQ Hub): DISARM

It looks to me like the "entry_delay" is being interpreted as "armed away" by Homekit. Any idea why?

Thank you

It is a weakness is Qolsys C4 integration:

2 EXIT_DELAY states are available, one for ARM_STAY and one for ARM_AWAY: case QolsysAlarmMode.ARM_STAY_EXIT_DELAY: case QolsysAlarmMode.ARM_AWAY_EXIT_DELAY:

Only one ENTRY_DELAY is available for both arming mode and I made the choice to associate it with AWAY_ARM. case QolsysAlarmMode.ENTRY_DELAY: return this.platform.Characteristic.SecuritySystemCurrentState.AWAY_ARM;

Will open another issue specifically for this bug. Will save previous panel state in memory and return it when panel turn into entry delay !

[EHylands]

https://github.com/EHylands/homebridge-qolsys/issues/14

[cistearns]

I'm wondering if there is value in adding in support to make the motion sensor act more like an occupancy sensor by not allowing it to revert to No Motion unless motion events haven't been seen for N minutes. Or by exposing the single motion sensor into HomeKit as both a Motion and an Occupancy sensor, with the Occupancy sensor having the special logic. This would make using the sensors for turning off lights easier. A 5min linger makes the sensor act more like how people expect a motion sensor to act, and can sort of work for occupancy in a busy room, since it's possible for the sensor to re trigger motion before the 5min timeout. A 30-60min linger makes it act more like an occupancy sensor, when there might be longer periods of stillness in an occupied room. This sort of linger logic really only needs to apply to motion sensors, due to how they physically work to save batteries. Other sensor types don't have this issue.

[EHylands]

Qolsys motion sensor reverts back to a close position right after detecting motion. It doesn't wait for the sensor to stop detecting motion.

With the 5 minutes sleep period after 2 motion event in a 5 min window, it would make sense to keep the Homekit motion sensor accessory triggered for at least 5 min and allow the timer to be restarted when a new motion event is received. I will write the change.

Users have very broad expectations regarding an occupancy sensor. Have you look into this very powerful Homebridge plugin? homebridge-magic-occupancy

[cistearns]

Sounds good. Most motion sensors at the physical layer work this way, so it's up to the panel to implement latching to show the motion state for the duration of the sleep even, not limited to Qolsys. That the C4 interface is giving a direct feed to the events with no extra logic is overall probably for the best.

I'm probably going to tinker some with the motion in a fork, so I could also code something up that I can upstream if you want it. If not no worries. I did look a little at magic-occupancy, and might just end up using it, but it felt like it was going to be a bit fiddly to configure given the number of motion sensors I'm using.

[EHylands]

Sounds good. Most motion sensors at the physical layer work this way, so it's up to the panel to implement latching to show the motion state for the duration of the sleep even, not limited to Qolsys. That the C4 interface is giving a direct feed to the events with no extra logic is overall probably for the best.

I'm probably going to tinker some with the motion in a fork, so I could also code something up that I can upstream if you want it. If not no worries. I did look a little at magic-occupancy, and might just end up using it, but it felt like it was going to be a bit fiddly to configure given the number of motion sensors I'm using.

Published beta version 0.3.1

• Trigger duration for motion sensors is now 5min 30sec. That allows for 30 sec after motion sensor is back in normal mode to reset the timer and postpone return to motion not detected state.
• Tilt sensor should be detected

I could add an option allowing to show motion sensor as HK motion sensor, HK occupancy sensor or both. Trigger duration time could be user selectable for each sensor type.

[EHylands]

@cistearns Just released beta version 0.3.2 Motion Sensor options are user selectable in Homebridge UI (Motion,Occupancy, Both) Different trigger delays are selectable for Motion and Occupancy sensor Let me know what you thibnk about this.

[cistearns]

I'll update to the beta now and give it a spin - this is exactly what I was thinking.

[cistearns]

I suspect the minimum trigger duration experimental feature can go away with these changes.

[EHylands]

I suspect the minimum trigger duration experimental feature can go away with these changes.

I was planning on removing the experimental option in Homebridge UI, but still keeping the code for minimum trigger duration for other sensor type.

[cistearns]

There are some oddities with how these initially show up in the Default Room in the Apple Home app, which is entirely a result of the way Apple treats sensors of similar type, once they all get moved to their correct rooms they show up as expected. I can add a section to the readme about this since sensors are a bit different from other device types. Given the number of devices that can be part of a panel I'm also somewhat inclined to recommend people set it up as a child bridge so it is easier to find any errant ones based on the bridge in the Home App UI.

For the delays, if another event comes in before going back to inactive, does it push out the timer or just start a new delay?

[EHylands]

There are some oddities with how these initially show up in the Default Room in the Apple Home app, which is entirely a result of the way Apple treats sensors of similar type, once they all get moved to their correct rooms they show up as expected. I can add a section to the readme about this since sensors are a bit different from other device types. Given the number of devices that can be part of a panel I'm also somewhat inclined to recommend people set it up as a child bridge so it is easier to find any errant ones based on the bridge in the Home App UI.

Other problem is that any changes between motion, occupancy or motion and occupancy is unfortunately disruptive for Homekit automations using that accessory ...

I have tried in my Bosch plugin to maintain an accessory uuid (not to delete associated automations) while changing accessory service type after restarting the plugin. It didn't worked as planned...

Any service type changes to an already created accessory renders that accessory unusable. I would like to be proven wrong on this one because it would be much easier to dynamically change an accessory type while maintaining schedule automations.

For the delays, if another event comes in before going back to inactive, does it push out the timer or just start a new delay?

If another event comes in before going back to inactive, it starts a new delays. It motion is regularly occurring, Homekit motion sensor could stay indefinitely on.

[cistearns]

Yeah the other oddity I hadn't anticipated thinking through is the naming of the sensor. There really isn't a good universal solution so it will be on the user rename one of the two as desired. The only place that really gets confusing is places where Apple truncates parts of the name shared with the room, Automations in particular, so you need to pay attention to the device icon if you don't rename them.

[EHylands]

I have proven myself wrong. Released beta version 0.3.3 I Kept same UUID for MotionOccupancy Accessory in all situations I'm adding or removing motion and occupancy sensor services based on user choice in Homebride UI Automations will persist as long as the accessory is kept active Motion Sensor -> Motion and Occupancy sensors (Motion sensor automations will persist) Motion and Occupancy sensor -> Motion sensor (Occupancy sensor automations will be deleted)

[cistearns]

When I upgrade from 0.3.2 beta am I going to notice any issues, or odes this only apply to the case when changing that setting? (ie my existing UUID for the Occupancy sensor is fine)

[EHylands]

When I upgrade from 0.3.2 beta am I going to notice any issues, or odes this only apply to the case when changing that setting? (ie my existing UUID for the Occupancy sensor is fine)

Occupancy sensor uuid will change from 0.3.2 to 0.3.3.

I haven't tested, but maybe keeping the same uuid will prevent accessory from resorting to default room.

After, it only applies after settings changes.

[cistearns]

Occupancy sensor uuid will change from 0.3.2 to 0.3.3.

Good to know, I might hold off on my update for a couple of days when I'll also be replacing a couple of panel sensors that this project made me realize have gone bad. Then I'll just tear down the bridge and start from a clean install.

[EHylands]

Release beta version 0.3.4. Found a way to keep same UUID as version 0.3.0 while adding Motion or Occupancy sensor services. Planning on releasing as version 0.4.0. Tested on my production setup: Established automations for motion sensors will persist from version 0.3.0 to 0.3.4 !

Also, take over module and bluetooth sensors don't provide any useful user interaction through the C4 interface and I 'm thinking about removing associated accessories.

[cistearns]

Also, take over module and bluetooth sensors don't provide any useful user interaction through the C4 interface and I 'm thinking about removing associated accessories.

Makes sense to me. I didn't play with the Bluetooth device to see what it provided. I did look at the events we get back for a keyfob, and they also aren't that useful. All we get is a 'Closed' event after the release of any button press on the Fob, but don't get any 'Open' events for specific buttons. I didn't experiment with it in all the group types but I think it is the same behavior for all group settings. So for now leaving it as recognized as a zone type but not used seems the right thing.

[cistearns]

Release beta version 0.3.4.

Been running it for a few days and everything seems to be looking good.

[EHylands]

Release beta version 0.3.4.

Been running it for a few days and everything seems to be looking good.

Great ! Out of town for a few days. Will issue formal release on my way back !

[cistearns]

@EHylands I'm going to close this out. I think the enhancements have been working very well and provide the flexibility to adjust to most/all use cases.