Qolsys IQ Panel 2 and 3rd party integration

Third party integrations
518

EDIT: OK all is working now! I had the token incorrectly placed in the yaml file.

Its working on IQ2 Panel (not +), version 2.7.0

Cheers!

519

Hi just wanted ask something

This integration has been working really well since I solved my typo problem. I use it in conjunction with the alarm.com HACS integegration (uvjustin I think?), and there is a notable advantage to the @XaF local integration, and that is speed. The sensor update almost immediately, whereas the alarm.com integration sometimes takes 30 to 45 seconds update in HA (because its using web scraping)

The alarm.com integrations does have more entiries such as battery indicators, malfunction status, z-wave locks, etc, but the speed of this local integration is extremely valuable for automations!

I did have one question about motion detectors in the XaF integration. Iā€™ve noticed that the detected motion state is short lived, for example, if motin is detected, it will on stay on dectected motion for seconds, then go to clear. However, the alarm.com timeout is 1 hr. I presume this is a normal feature and correct due to battery life being extended for the motion sensor, but just wanted to confirm this, why the difference in reporting of the local and alarm.com-based reporting

thanks

520

Something like that:

- alias: 'alarm: pagerduty alert if alarm triggered'
  description: ''
  trigger:
  - platform: state
    entity_id: alarm_control_panel.partition1
    to: triggered
    for:
      hours: 0
      minutes: 0
      seconds: 5
      milliseconds: 0
  condition: []
  action:
  - service: rest_command.pagerduty_alert
    data:
      dedup_key: alarm_triggered_partition1
      summary: Alarm triggered at xxxxxxx
      severity: error
  mode: single

That difference is not related to the integration, and most probably something that alarm.com does differently than the panel itself. The integration just works with control4 events emitted from the panel. If the panel says the motion sensor signal is cleared, then the integration will report as such. Itā€™s possible that on the alarm.com side, they donā€™t listen to those clear events, and just keep the activity for one hour after the sensor detected something.

1 Like
521

I initially had this problem too but it resolved after several configuration changes I made to the motion sensors on the IQ panel itself. I think it will depend on what specific motion sensors you use (I use the DSC PG9914), but homeassistant would also initially report motion activated and then immiedately clear within one second. I had to change the values of high traffic shutdown and sensitivity on the individual sensors through the panel for it to finally work after initially pairing the sensors to the panel. Now, HA will properly reflect motion state that matches the high traffic shutdown setting, i.e., if I set high traffic shutdown to 30 seconds, then HA will reflect motion state as activated for 30 seconds after the last motion event.

522

thank you for the information! I just check my settings for the motion dector, and I donā€™t think I have such options. THe motion sensors is Qolsys Motion BUT its the standard s-line 319.5 MHz version, Power-G tends to have more options, Iā€™ve noticed.

523

I noticed when I used my admin code it didnā€™t allow Installing, but when I convinced my dealer to give me their code it then did unlock a number of additional menus.

524

Iā€™ve installed, have AppDaemon and MQTT working, and am still having some issues that Iā€™d love help with.

I get a constant stream of connect and closing messages, about 3 sets per second. Anyone know whatā€™s going on? I commented the logging out of the code, but am worried itā€™s causing other issues:

2022-05-19 16:41:18.893962 INFO qolsys_panel: Connection closed by the panel, exiting to reset the connection
2022-05-19 16:41:18.903517 INFO qolsys_panel: Establishing connection to 192.168.1.232:12345
2022-05-19 16:41:19.203002 INFO qolsys_panel: Connection closed by the panel, exiting to reset the connection
2022-05-19 16:41:19.216177 INFO qolsys_panel: Establishing connection to 192.168.1.232:12345
2022-05-19 16:41:19.485785 INFO qolsys_panel: Connection closed by the panel, exiting to reset the connection
2022-05-19 16:41:19.509799 INFO qolsys_panel: Establishing connection to 192.168.1.232:12345
2022-05-19 16:41:19.784441 INFO qolsys_panel: Connection closed by the panel, exiting to reset the connection
2022-05-19 16:41:19.793844 INFO qolsys_panel: Establishing connection to 192.168.1.232:12345
2022-05-19 16:41:20.067314 INFO qolsys_panel: Connection closed by the panel, exiting to reset the connection
2022-05-19 16:41:20.081872 INFO qolsys_panel: Establishing connection to 192.168.1.232:12345

ā€“

Also, on motion sensing, it triggers this error:

022-05-19 16:41:21.375891 ERROR qolsys_panel: Error calling callback for event: <QolsysEventZoneEventUpdate zone=<QolsysSensorMotion id=BA74A5 name=Living Room Motion group=awayinstantmotion status=Closed state=0 zone_id=8 zone_type=2 zone_physical_type=2 zone_alarm_type=3 partition_id=0> version=1>
Traceback (most recent call last):
  File "/config/appdaemon/apps/qolsysgw/mqtt/listener.py", line 47, in event_callback
    await self._callback(event)
  File "/config/appdaemon/apps/qolsysgw/gateway.py", line 196, in mqtt_event_callback
    self._state.zone_update(event.zone)
  File "/config/appdaemon/apps/qolsysgw/qolsys/state.py", line 48, in zone_update
    raise Exception(f'Zone not found for zone update: {sensor}, '\
Exception: Zone not found for zone update: <QolsysSensorMotion id=BA74A5 name=Living Room Motion group=awayinstantmotion status=Closed state=0 zone_id=8 zone_type=2 zone_physical_type=2 zone_alarm_type=3 partition_id=0>, we might not be sync-ed anymore

(Which seems like a zone-not found error, possibly from not correctly loading partitions on startup?

ā€“

Also (this is minor), to get AppDaemon not to report these warnings in the log (I see many log dumps have this):

2022-05-19 16:51:04.787000 WARNING AppDaemon: No app description found for: /config/appdaemon/apps/qolsysgw/qolsys/state.py - ignoring
2022-05-19 16:51:04.793405 WARNING AppDaemon: No app description found for: /config/appdaemon/apps/qolsysgw/qolsys/partition.py - ignoring
...

We can add this setting to appdaemon.yaml:

appdaemon:
  latitude: !secret latitude_home
  longitude: !secret longitude_home
  ....
  missing_app_warnings: 0
525

On further research, it looks like for me the

class MqttWrapperQolsysSensor(MqttWrapper):

    PAYLOAD_ON = 'Open'
    PAYLOAD_OFF = 'Closed'

    QOLSYS_TO_HA_DEVICE_CLASS = {
        QolsysSensorDoorWindow: 'door',
        QolsysSensorMotion: 'motion',
        QolsysSensorGlassBreak: 'vibration',
        QolsysSensorBluetooth: 'presence',
        QolsysSensorSmokeDetector: 'smoke',
        QolsysSensorCODetector: 'gas',
        QolsysSensorWater: 'moisture',
    }
   ...

class is never invoked and so those info messages are never sending. Iā€™m thinking nothing is triggering those Info calls that create the MQTT Discovery objects, and thus no objects are created in HA. Any ideas on what is missing in triggering that? A different software version of the Qolsys or Control4 perhaps?

526

@jaycrossler

Iā€™m not sure about all your errors but I had this one below and it turned out to be I incorrectly typed my token in AD file. Check your token or make a new one, see if that helps.

1 Like
527

OMG.

I had made 50 changes to the code and built an entire MQTT redirector to redirect the paltry messages I was getting. I had kludged and jury rigged binary_sensors inā€¦

But resetting the token and entering the new one fixed everything! Thank you, kind stranger. I feel that I have a much better understanding of AppDaemon and MQTT_Discovery now, but kinda wished I had tried that before. My guess is I typed an 0 as an O, or something.

1 Like
528

Kind of interesting to know weā€™re still receiving some panel notifications about sensors even when the token is invalid (which triggered the zone not found error!)

529

One ā€œhackish HAā€ way to do things would be to create an helper sensor or something like that, which would change status when the motion is detected, and clear after the duration of time you want. This would ā€œmimicā€ the effect youā€™re looking for ?

530

Would you be up for adding some extra exception handling for things like this? Iā€™ve started adding some but your python-fu is much better than mine.

531

this is also a good option. What I typically do is just add a ā€œforā€ line in automations that I use this sensor for. Its almost the same, but a helper would be more robust for sure!

532

@XaF

just curious how long it takes for the integration to update the sensor listā€¦I had to remove a failed sensor, and I replaced it (added the new one), and then I added 2 new ones. None of these changes are showing upā€¦is there some refresh I have to do? Iā€™ve had to restart HA a couple of times already but changes not showing up.

Cheers

533

Difficult to identify exactly why we donā€™t know the zone, it could also be caused by something else if we fail loading a zone for some reason.
Adding a ā€œmaybe you need to refresh your panel tokenā€ message would be doable. Mind opening an issue on GitHub for that? Been quite taken recently for work, but Iā€™m using GitHub to keep track of stuff that needs doing :slight_smile:

That should be ā€œinstantā€. When adding sensors in the past, I identified thereā€™s a panel event Iā€™m not handling at the moment for a new sensor addition, which justifies why a newly added sensor wouldnā€™t appear immediately (planned to add that support when I get the chance, Iā€™m waiting to receive my new sensors too so Iā€™ll have means to test that properly). However, the next refresh from the panel should give the info about all the sensors, and have HA pick up on all the sensors (including the newly added). Restarting HA should be triggering that, but you could also try and restart the panel. Another way to make sure you get the newly information would be to force-clear MQTT as to make sure stale INFO results do not stick around (they shouldnā€™t, but better be safe).

Iā€™d advise to look at the logs also if youā€™ve already restarted a few times. Do those sensors appear in the logs? What type of sensors are those?

534

Done. Now that I got it working, I love this integration - combined with my MQTT messages from BlueIris, itā€™s a huge part of my HA setup (and lets me cancel my expensive alarm.com subscription). Thanks for the hard work!

535

@XaF props to you! I finally got around to switching to your integration a couple months back and itā€™s rock solid! One day Iā€™m gonna comb through your code and learn from you :slight_smile: . Iā€™ve update my repo to point to you and highly recommend everyone on this thread to stop using ad-qolsys and upgrade to qolsysgw!

1 Like
536

@XaF
Ok, I found the issue, it actually did add to my entities, but for some reason I thought it was going to update the entity list automatically!

I do have one minor issue with the sensor that failed and was replaced. Itā€™s a water sensor and it failed in the wet state. When I added the new sensor I named it the same name but it seems the new sensor is still stuck in the wet state.

This is probably an mqtt issue.

You mentioned force clearing mqtt. How do I actually do that?

Is that something I do in AD?

My mqtt broker is a local broker on my home network, same as HA but a ubuntu server.

If I deleted the device in HA would it reappear as the correct State ? Or should I rename the sensor?

537

Your extension is what started this for me, and gave me the will to write qolsysgw, so thanks a lot to you too for all that initial clearing of brushwood!

Oh interesting, upon restart it should have sent the information in the same MQTT topic with the current status as seen by the panel. Are you able to see what messages the panel is sending in the logs? The INFO message as answered by the panel when asked for by the extension should give interesting information as to the sensor status.

For the clearing out, the ways I can think of:

  1. You can manually empty the MQTT cache, which should repopulate things properly. Will most probably need a restart, at least of AppDaemon, and maybe of HA.
  2. You can use the mqtt_retain parameter of the extension and set it to false temporarily. Will definitely need AppDaemon to reload the extension, which should trigger the INFO message and should send all the things in MQTT without any retention flag, hence clearing it out.

It should reappear in the correct state if the name is the same, as it would generate the same unique ID for the entity. Logs would tell if thereā€™s a conflict somewhere, or maybe somethingā€™s just stuck in MQTT!