Just wanted to thank you guys for your hard work. Really appreciate it.
The curl command has timed out a few times over the past couple of days even with the keep alive flag. It seemed to fail a bit more often as I added more panels into the flow. I’ll be trying out your qolsys-client python module soon @mzac
Does the python module support multiple panels?
So I’m still running into issues where my node-red daemon of OpenSSL command eventually the panel stops responding until a reboot. What’s odd is it’s not completely blocking it as the daemon does report back the connected 003 (or what ever the first line respond is). I’m not 100% sure when or anything else that it decides to take a poop and require a restart.
Anyone have an idea of things to try? My flow doesn’t send commands much to my panel so I’m at a bit of a loss.
I’m going to leave nodered open on my server with all of the daemon messages into debug. Maybe I can get the last messages sent from the process and see what they say.
I’ve seen the panel stop responding while I’m testing and opening connections repeatedly and/or sending improperly formatted commands. Not sure what trips it off, but I assume there’s some DOS mechanism in the panel to protect itself.
But it has never happened to me in normal running mode.
You’re using node-red-node-daemon to run OpenSSL? Is it up to date? Sometimes it would show “stopped” under the node even though OpenSSL was still running. Updated everything and I haven’t seen that since.
Yes there is IPTables running on the panel. If you look through this thread you’ll find the config that is on the panel that describes how they are blocking repeated connections.
Its my first time using node red. Could you please explain how you built in the restart if it fails? Some steps to follow would be great.
Many thanks
Something I’ve noted is that if the panel gets any bad data or bad command, the socket gets hosed.
In the current release, I detected the badness when the client gets empty data from the socket. The client will drop then reconnect.
That didn’t work for me. The current client takes care of this.
I wonder if that’s what happening with the OpenSSL daemon that I’m running in node red.
If you hang on a bit longer there’s an excellent chance there’ll be an AppDaemon app you can just deploy 
I just migrated over completely to home assistant from smartthings, I’ll need to learn more of how the python module integrates into home assistant.
I just downloaded your node-red flow to look at it. Correct me if I’m wrong in how your setup works. It has a python script that publishes everything to mqtt and the flow will automatically build all of the sensors and such based on the mqtt entries?
Yep!
And I am going to move the python to AppDaemon so you don’t need to run the script in a window or something.
I’m debating getting rid of the node-red flow and doing it all in AppDaemon.
If you were able to move it all into AppDaemon, that would essentially make this a Home Assistant plugin instead of needing node-red and the script you’ve got.
Something I’ve noted is that if the panel gets any bad data or bad command, the socket gets hosed.
In the current release, I detected the badness when the client gets empty data from the socket. The client will drop then reconnect.
Thinking on this comment a bit more, this makes sense that the daemon node that I have in node-red is that if something happens it does seem like the socket get hosed and essentially the node-red daemon reconnects, but no traffic is sent other than the connected message being sent from the panel and nothing else, almost as if the panel still thinks there is a connection and it doesn’t release it, and after a couple of reconnection attempts, the panel eventually says that’s enough connections and stops further communications.
In the flows you have, do you have arming/disarming incorporated into it?
In the node-red flow published in @mzac’s repo, yes. That’s the part I’m working on in AppDaemon right now.
EDIT: If you’re looking for the latest and greatest Qolsys add-on, please use @XaF 's GitHub - XaF/qolsysgw: Qolsys IQ Panel 2+ gateway to an Home Assistant Alarm Control Panel going forward. I’m not updating ad-qolsys any longer.
I have a fully self-contained AppDaemon app (no node-red required). I am going to figure out how to publish it via HACS. In the meanwhile, you can download and unzip in appdaemon/apps.
If you have MQTT Discovery turned on, you should end up with binary sensors for each Door_Window zone. There are more zone types that I don’t have so I have not handled them in anyway.
You’ll also have a binary sensor for each partition (see Known Issues below). Anyone have a better way to track the partition ARMED/DISARMED status than binary_sensor (on/off)?
Add as custom repository in HACS: Now published in HACS. Best to add it directly from HACS now.https://github.com/roopesh/ad-qolsys
Arguments in apps.yaml:
# mqtt_namespace: (optional) namespace for mqtt defined in appdaemon.yaml; defaults to ""
# qolsys_host: (Required) IP address or hostname for the qolsys panel
# qolsys_port: (Optional) Port on the qolsys panel to connect to; will default to 12345
# qolsys_token: (Required) Token from the qolsys panel
# request_topic: The topic to listen to send commands to the qolsys panel
# qolsys_timeout: (Optional) The timeout (in seconds) to wait for any activity to/from the qolsys panel before disconnecting; defaults to 86400
# qolsys_info_topic: (Optional) The topic to publish qolsys INFO events to; defaults to qolsys/info
# qolsys_zone_event_topic: (Optional) The topic to publish ZONE_EVENT events to; defaults to qolsys/zone_event
# qolsys_alarming_event_topic: (Optional) The topic to publish ARMING events to; defaults to qolsys/arming
# qolsys_disarming_event_topic: (Optional) The topic to publish DISARMING events to; defaults to qolsys/disarming
You’ll need you appdaemon apps.yaml to include an app with this module and class:
qolsys_panel:
module: qolsys_client
class: QolsysClient
mqtt_namespace: mqtt <see below for my config>
qolsys_host: <your IP here>
qolsys_token: <your token here>
qolsys_port: 12345 # Optional
request_topic: qolsys/requests # Optional
qolsys_info_topic: qolsys/panel/info # Optional
qolsys_zone_update_topic: qolsys/panel/zone_update # Optional
qolsys_zone_event_topic: qolsys/panel/zone_event # Optional
qolsys_alarming_event_topic: qolsys/panel/alarming # Optional
qolsys_disarming_event_topic: qolsys/panel/disarm # Optional
As far MQTT is concerned, I had to figure out how to enable MQTT inside AppDaemon. In case you’re new to AppDaemon and have the same questions, I had to put this in my appdaemon.yaml:
appdaemon:
latitude: # existing
longitude: # existing
elevation: # existing
time_zone: # your timezone America/Los_Angeles
# HASS plugin is enabled by default if you're using the add-on
plugins:
HASS:
type: hass
# I added on the MQTT plugin
MQTT:
type: mqtt
namespace: mqtt #you will need this namespace name in your apps.yaml
# The IP Address or hostname of your MQTT broker.
client_host: 192.168.x.y
client_port: 1883
I’m by no means an MQTT or AppDaemon expert, so feel free to peruse the documentation for any MQTT configuration help you need MQTT API Reference — AppDaemon 4.2.1 documentation.
Sending commands:
# Request the INFO to be published
{"event":"INFO", "token":"blah"}
# Arm stay:
{"event":"ARM", "arm_type":"stay", "partition_id": 0, "token":"blah"}
# Arm away
{"event":"ARM", "arm_type":"away", "partition_id": 0, "token":"blah"}
# Disarm
{"event":"DISARM", "usercode":"0000", "token":"blah"}
Known issues:
- When the app reloads, sometimes it doesn’t reconnect to the socket and it just hangs. The only way I’ve been able to recover is to restart AppDaemon. If anyone has a way to detect and fix this, let me know.
- I’m not yet processing arming/disarming events. The requests will work
, but the partition doesn’t get updated with the status. I put in another INFO request so the partition sensor will update but it’s a bit hacky for now. If you’re listening to the topics or watching logs, you’ll see a bunch of noise associated with this hack. - MQTT Discovery is being published to
homeassistant/binary_sensor. I’ll make this a config in the future. This is the default MQTT Discovery topic so I think most people will be fine.
I hope this works for everyone! Hit me up with feedback.
Anyone have a better way to track the partition ARMED/DISARMED status than binary_sensor (on/off)?
I would say that using the alarm_control_panel: would probably be the way to go over the binary_sensor. Here is the config that I have for my alarm panel still using node red. Keep in mind that I’m very limited in HA knowledge and there’s likely a better way to get this to work.
alarm_control_panel:
- platform: template
panels:
qolsys:
name: Qolsys Alarm Panel
unique_id: qolsys_alarm_panel
value_template: "{{ states('alarm_control_panel.qolsys_alarm') }}"
arm_away:
service: alarm_control_panel.alarm_arm_away
target:
entity_id: alarm_control_panel.qolsys_alarm
arm_home:
service: alarm_control_panel.alarm_arm_home
target:
entity_id: alarm_control_panel.qolsys_alarm
disarm:
- service: alarm_control_panel.alarm_disarm
target:
entity_id: alarm_control_panel.qolsys_alarm
alarm_control_panel Qolsys:
- platform: manual
name: Qolsys Alarm
arming_time: 0
delay_time: 0
trigger_time: 0
disarmed:
trigger_time: 0
armed_home:
arming_time: 0
delay_time: 0
The reason I did it this way was that I couldn’t use a template entity in node red, and I didn’t want the “arm stay, arm away, and arm home” and the keypad in home assistant, which I could only really control that with a template, but the manual entry was needed to use it in node red (i could be wrong with some of this as it’s been a while since I set it up and haven’t revisited it, and it’s working for me.) Node-red interacts with the manual entity for arming and disarming, the the template uses the manual entity basically for status and control (and to pass the information over to homekit)
Using it this way might be the best way to handle the tracking of the status as it would also give users control if they wanted to create other alarm panels with codes, etc. It wouldn’t mirror the codes that are in the qolsys alarm panel for true disarming, but it would allow for other touch panel configurations and control of the qolsys panel. I’m still messing around with mqtt so I don’t have this working in mqtt yet, but I would assume there is a good way to have mqtt handle alarm panels?
Also where you said sometimes the app hangs, could you have it check for the ACK and if it’s not detected to restart the daemon?
OK. Install (or update) the latest from HACS. I added a fully controllable alarm panel. I think this is working very well! See the config options in GitHub - roopesh/ad-qolsys: AppDaemon app for Qolsys IQ Panel 2.
I would love some feedback from this community!
(HACS hasn’t accepted my pull request yet so you need to add this custom repo to HACS: https://github.com/roopesh/ad-qolsys)